# Introduction ![](/files/-MWGO0aHgUEPyY2jdXdw) HiveSQL is a **publicly available Microsoft SQL database** containing all the Hive blockchain data. Data are structured and easily accessible from any application able to connect to an MS-SQL Server database. It allows you to easily access data contained in the Hive blockchain and perform analysis or find valuable information. Browsing the blockchain over and over to retrieve and compute values is time and resource consuming.\ Instead of having a local copy of the blockchain or downloading the whole data from some external public node to process it, you will send your query to HiveSQL server and get the requested information. HiveSQL makes it possible to produce quick answers to complex questions. #### Why use a SQL database? The main advantage of having such a database is the fact data are structured and easily accessible\ from any application able to connect to a SQL Server database. Having a SQL Server database makes\ it possible to produce quick answers to complex queries. Simply put, a query is a question. You ask the server for something and it sends back an answer (the query result set).\ For example, when dealing with large amounts of data such as the Hive blockchain data, you might want to search for the following information: * What was the Hive power-down volume during the past six weeks? * Which are the top 10 most rewarded post ever? * How many times have I been mentioned in a post or comment last 7 days? * How many posts are talking about ants? # Register your HiveSQL account Before being able to access the HiveSQL database, you will have to create a HiveSQL account. The process is very simple: 1. Transfer **1 HBD** to [@hivesql](https://peakd.com/@hivesql) (no memo required) 2. As soon as [@hivesql](https://peakd.com/@hivesql) receives your transfer, your activation will be processed 3. A few seconds later, you will receive a micro-transfer back from [@hivesql](https://peakd.com/@hivesql). ![](/files/-MZPkqFVgwh-icfVTV6M) The [@hivesql](https://peakd.com/@hivesql) transfer memo contains your new credentials and is therefore encrypted.\ There are two easy ways to see its decrypted content: 1\. If you use **peakd.com**, click on the small green lock. It will decrypt and display the memo ![](/files/-MZPlS6ntpHVwg9HGlnv) 2\. If you have **Keychain** installed, open it and click on the History button\ \ ![](https://images.hive.blog/0x0/https://i.imgur.com/7OerE4l.png)\ \ ![](https://images.hive.blog/0x0/https://i.imgur.com/jQtQGgl.png) The memo contains the following information: * the hostname to connect to. * the database name * your personal login * your password # Support Support for HiveSQL is provided on the [HiveSQL Discord Channel](https://discord.gg/kyEFDfT) only! If you have any questions, remarks or suggestions, feel free to post them. # Database Diagram
#### Blocks and Transactions Each block recorded in the blockchain is processed by the database injector and split among several tables. The Blocks table contains bare block information (timestamp, witness, …).\ Each block can contain one or more transactions (stored in the Transactions table) which in turn can contain several operations **Operations (Transactional - User-generated)** The Blocks table contains bare block information (timestamp, witness …) Each block can contain one or more Transactions which in turn can contain several operations. Depending on each operation type, the associated data is stored in the related table (Tx...). **Virtual Operations (Transactional - System generated)** Virtual operations are operations resulting from the activity on the blockchain but, unlike standard operations, they are not the result of actions initiated by users. #### State tables (non-transactionnal) The database also contains several tables that reflect the result of the operations recorded in the blockchain. For example, the "Accounts" table contains all the user accounts that have been created as well as their wallet balance, and other information relating to each account. # Operations All operation tables contain the following columns: | Column | Description | | --------- | -------------------------------------------------------------------------- | | ID | This is an HiveSQL internal row identifier | | tx\_id | This is the ID of the transaction in the `Transactions` table | | timestamp | This is the date and time of the block in which the operation was recorded | Additional columns are described on each table related page | Table | Description | | ----------------------------------------------------------------------------------------- | ----------------------------------------------- | | [TxAccountClaims](/technical-informations/operations/txaccountclaims) | Claims of account creation tickets | | [TxAccountCreates](/technical-informations/operations/txaccountcreates) | New account creations | | [TxAccountRecoveryChanges](/technical-informations/operations/txaccountrecoverychanges) | Recovery Account changes | | [TxAccountRecoveryRequests](/technical-informations/operations/txaccountrecovers) | Account recovery requests | | [TxAccountRecoveryConfirms](/technical-informations/operations/txaccountrecoveryconfirms) | Account recovery confirmations | | [TxAccountUpdates](/technical-informations/operations/txaccountupdates) | Updates of account data | | [TxAccountUpdates2](/technical-informations/operations/txaccountupdates2) | Updates of account data (v2) | | [TxAccountWitnessProxies](/technical-informations/operations/txaccountwitnessproxies) | Delegations of governance votes | | [TxAccountWitnessVotes](/technical-informations/operations/txaccountwitnessvotes) | Votes/unvotes for witnesses | | [TxClaimRewardBalances](/technical-informations/operations/txclaimrewardbalances) | Claims for rewards | | [TxComments](/technical-informations/operations/txcomments) | Posts and comments | | [TxCommentsOptions](/technical-informations/operations/txcommentsoptions) | Posts and comments options | | [TxConverts](/technical-informations/operations/txconverts) | Requests for conversion from HBD to HIVE | | [TxCustoms](/technical-informations/operations/txcustoms) | Custom JSON (non-consensus operations) | | [TxDeclineVotingRights](/technical-informations/operations/txdeclinevotingrights) | Requests to decline voting rights | | [TxDelegateVestingShares](/technical-informations/operations/txdelegatevestingshares) | Hive Power delegations | | [TxDeleteComments](/technical-informations/operations/txdeletecomments) | Posts and comments deletions | | [TxEscrowApproves](/technical-informations/operations/txescrowapproves) | Escrow approvals | | [TxEscrowDisputes](/technical-informations/operations/txescrowdisputes) | Escrow disputes | | [TxEscrowReleases](/technical-informations/operations/txescrowreleases) | Escrow funds releases | | [TxEscrowTransfers](/technical-informations/operations/txescrowtransfers) | Escrow creations | | [TxFeeds](/technical-informations/operations/txfeeds) | Witnesses price feed publications | | [TxLimitOrdersCreates](/technical-informations/operations/txlimitorders) | Internal market orders creations | | [TxLimitOrdersCancels](/technical-informations/operations/txlimitorderscancels) | Internal market orders deletions | | [TxPows](/technical-informations/operations/txpows) | Proof of Work (mining - deprecated) | | [TxProposalCreates](/technical-informations/operations/txproposalcreates) | Proposals creations | | [TxProposalRemoves](/technical-informations/operations/txproposalremoves) | Proposals removals | | [TxProposalUpdates](/technical-informations/operations/txproposalupdates) | Proposal updates | | [TxProposalVoteUpdates](/technical-informations/operations/txproposalvoteupdates) | Proposal approvals and disapprovals | | [TxTransfers](/technical-informations/operations/txtransfers) | Assets transfers | | [TxVotes](/technical-informations/operations/txvotes) | Posts and comments votes | | [TxWithdraws](/technical-informations/operations/txwithdraws) | Requests for Hive Power withdrawals (powerdown) | | [TxWithdrawVestingRoutes](/technical-informations/operations/txwithdrawvestingroutes) | Routes for powerdown definitions | | [TxWitnessSetProperties](/technical-informations/operations/txwitnesssetproperties) | Blockchain properties proposals by witnesses | | [TxWitnessUpdates](/technical-informations/operations/txwitnessupdates) | Witnesses information updates | # TxAccountClaims #### Blockchain operations * claim\_account #### Columns | **name** | **Description** | | ---------- | ------------------------------------------- | | creator | account claiming an account creation ticket | | fee | fee paid | | extensions | reserved for future use | #### Description This table contains the “requests” from users or dApps to get an account creation ticket in order to create new accounts. These operations are issued **before** the actual creation of the account on the blockchain. Although at the blockchain level the operation of creating a claimed account is of different type (*create\_claimed\_account*) from the previous account creation operations (*account\_create* and *account\_create\_with\_delegation*), HiveSQL stores them all in a single table: `TxAccountCreates`. # TxAccountCreates #### Blockchain operations * account\_create * account\_create\_with\_delegation * create\_claimed\_account #### Columns | Name | Description | | ------------------ | ----------------------------------------------------- | | fee | amount of HIVE paid to create the account | | delegation | amount of VESTS delegated to the account (deprecated) | | creator | username of the new account creator | | new\_account\_name | new account username | | owner\_key | owner public key of the new account | | active\_key | active public key of the new account | | posting\_key | posting public key of the new account | | memo\_key | memo public key of the new account | | json\_metadata | metadata describing the new account | | extension | reserved for future use | #### Description These operations are broadcasted to the blockchain to create a new account. When creating accounts with claimed tickets (create\_claimed\_account), there is no fee to pay. {% hint style="warning" %} The `account_create_with_delegation` operation is deprecated as of Hardfork 20 {% endhint %} # TxAccountRecoveryChanges This is ds #### Blockchain operations * change\_recovery\_account #### Columns | Name | Description | | ---------------------- | ----------------------------------------------------- | | account\_to\_recover | the account that wants to change its Recovery Account | | new\_recovery\_account | the new Recovery Account | #### Description This table contains operations broadcasted to the blockchain when users want to change their Recovery Account. Once the operation has been broadcasted to the blockchain, the user (account\_to\_recover) has to wait 30 days before the new recovery account will become effective and before the user can initiate a recovery. # TxAccountRecoveryRequests #### Blockchain operations * request\_account\_recovery #### Columns | Name | Description | | --------------------- | ------------------------------------------------------------------------------- | | recovery\_account | username of the Recovery Account | | account\_to\_recover | username of the account to recover | | new\_owner\_authority | new public owner key provided by the account to recover to the recovery account | #### Description This table contains operations broadcasted to the blockchain by the Account Recovery of an account that has been hacked to initiate the recovery process. # TxAccountRecoveryConfirms #### Blockchain operations * recover\_account #### Columns | Name | Description | | ------------------------ | ------------------------------------------------------------------------------- | | account\_to\_recover | username of the account to recover | | new\_owner\_authority | new public owner key provided by the account to recover to the recovery account | | recent\_owner\_authority | a public owner key of the account to recover **before** it was last changed | #### Description This table contains operations broadcasted to the blockchain by the hacked account's owner to confirm the account recovery request sent by its Recovery Account. Although it is a recent **private** owner key that is broadcasted to the blockchain node, it is the corresponding **public** owner key that is stored in the blockchain (and in the database). # TxAccountUpdates #### Blockchain operations * account\_update #### Columns | Name | Description | | -------------- | ------------------------------------------------------------------------------------ | | account | username of the account to change | | owner | new owner public authorities. If null, the existing authorities are left unchanged. | | active | new active public authorities. If null, the existing authorities are left unchanged. | | posting | new posting authorities. If null, the existing authorities are left unchanged. | | memo\_key | new or existing memo key (it cannot be null) | | json\_metadata | new account metadata. If null, the existing metadata is left unchanged. | #### Description This operation is used to update the account information. As it allows to change the account authorities and memo key, the Private Active Key is required to broadcast it to the blockchain. # TxAccountUpdates2 #### Blockchain operations * account\_update2 #### Columns | Name | Description | | ----------------------- | ------------------------------------------------------------------------------------ | | account | username of the account to change | | owner | new owner public authorities. If null, the existing authorities are left unchanged. | | active | new active public authorities. If null, the existing authorities are left unchanged. | | posting | new posting authorities. If null, the existing authorities are left unchanged. | | memo\_key | new or existing memo key. If null, the existing data is left unchanged. | | json\_metadata | new account metadata. If null, the existing metadata is left unchanged. | | posting\_json\_metadata | new account posting metadata. If null, the existing metadata is left unchanged. | | extensions | reserved for future use | #### Description This operation behaves identically to the `account_update` operation (see [TxAccountUpdates](/technical-informations/operations/txaccountupdates)) except that, when the owner, active and posting authorities and the memo key are not present, the transaction can be signed with the posting key instead of the active key. # TxAccountWitnessProxies #### Blockchain operations * account\_witness\_proxy #### Columns | Name | Description | | ------- | ------------------------------------------------- | | account | username who wants to proxy his votes | | Proxy | username of the account to whom votes are proxied | #### Description Allows one account to delegate governance votes (witnesses, proposals) to another account. If a proxy is specified then all existing witness or proposal votes are removed. {% hint style="info" %} As of HF21, setting a witness proxy also applies to Hive DHF proposal approval. If you trust someone to cast your witness votes, it is assumed that you would also trust them to cast your proposal votes. {% endhint %} # TxAccountWitnessVotes #### Blockchain operations * account\_witness\_vote #### Columns | Name | Description | | ------- | --------------------------------------------------- | | account | username voting or unvoting for a witness | | witness | username of the witness | | approve | true = approve (vote) , false = disapprove (unvote) | #### Description All accounts with stacked HIVE (VESTS aka Hive Power) can vote for up to 30 witnesses. If a proxy is specified then all existing votes are removed. # TxClaimRewardBalances #### Blockchain operations * claim\_reward\_balance #### Columns | Name | Description | | ------------- | ------------------------- | | account | username | | reward\_hive | amount of HIVE collected | | reward\_hbd | amount of HBD collected | | reward\_vests | amount of VESTS collected | #### Description Author and curator rewards are not automatically transferred to the account's balances. One has to issuer a claim\_reward\_balance operation to trigger the transfer from the reward pool to its balance. # TxCollateralizedConverts #### Blockchain operations * collateralized\_convert #### Columns | Name | Description | | -------------- | ------------------------------------- | | owner | The account requesting the conversion | | requestid | A request identifier | | amount | The amount of HIVE to convert | | amount\_symbol | HIVE | #### Description The `collateralized_convert` operation is similar to `convert` operation (see [TxConverts](/technical-informations/operations/txconverts)), and instructs the blockchain to convert HIVE to HBD. Half of the HIVE amount is converted immediately into HBD (using the minimum witnesses price feed for the last 3.5 days) and sent to the owner.\ The remaining HIVE amount (the collateral) is put on hold till the actual conversion takes place 3.5 days later. \ The HIVE/HBD price variation risk is cushioned by an extra 5% HIVE fee that will be applied to the collateral. \ When the actual conversion takes place (3.5 days later), HBD is printed out of thin air, the equivalent HIVE amount (using the median witness price feed for the last 3.5 days) and the collateral fee is burned, and the remaining amount is returned to the owner. **Example** * let's say the current HIVE price is $0.10 * the user issues a `collateralized_convert` operation with 2000 HIVE (worth $200) * 2000 HIVE are temporarily removed from the user wallet. * the user gets 100 HBD (half of 2000 HIVE => 1000 HIVE converted to HBD) immediately. * the remaining 1000 HIVE are put on hold as collateral * At the end of 3.5 days, if the price of HIVE hasn't changed, the user gets 950 HIVE back, that is 1000 HIVE - 50 HIVE (the 5% fee on the 1000 HIVE collateral) # TxComments #### Blockchain operations * comment #### Columns | Name | Description | | ---------------- | ------------------------------------------------------------------------------------------------- | | author | author of the post/comment (username) | | permlink | a unique string identifier for the post, linked to the author of the post | | parent\_author | the author that comment is being submitted to, when posting a new blog this is an empty string | | parent\_permlink | specific post that comment is being submitted to, when posting a new blog this is an empty string | | title | human-readable title of the post being submitted. This is left blank for comments | | body | body of the post/comment being submitted, or `diff-match-patch` when updating | | json\_metadata | JSON object string containing post or comment metadata | #### Description This operation is used to create or update posts and comments. * `permlink` - Two authors may have the same permlink as it’s unique to the author only. For example, there could be two authors, Alice and Bob, and both could have a permlink of `firstpost` * `json_metadata` - There is no blockchain-enforced validation on `json_metadata`, but the community has adopted a particular structure. It should contain a JSON object with the following keys: * `tags` - An array of up to 5 strings. Although the blockchain will accept more than 5, the tags plugin only looks at the first five * `app` - A user agent style application identifier. Typically `app_name/version`, e.g. `hiveblog/0.1` * `format` - The format of the body, e.g. markdown * In addition to the above keys, application developers are free to add any other keys they want to help manage the content they broadcast. **Create vs. Update** When a comment is first broadcasted, the `permlink` must be unique for the `author`. Otherwise, it is interpreted as an update operation. Updates either replace the entire body with the latest operation or patch the body if using [`diff-match-patch`](https://github.com/google/diff-match-patch). For example, if we have a paragraph that has already been broadcast: > “It’s been quite a lot of fun working with these wonderful folk on the Open Hive Network” and it's changed to : > “It’s been quite a lot of fun working with these wonderful people on the Open Hive Network” the `comment` operation will have the following `body`: ``` - "@@ -406,12 +406,14 @@" - ful - -folk - +people - at ``` In addition to `body`, the `title` and `json_metadata` fields are also replaced by the latest operation. # TxCommentsOptions #### Blockchain operations * comment\_options #### Columns | Name | Description | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------ | | author | author of the post/comment (username) | | permlink | a unique string identifier for the post, linked to the author of the post | | max\_accepted\_payout | HBD value of the maximum payout this post will receive | | percent\_hbd |

percent of payout paid in HBD, the remaining value will be paid in VESTS.
The value must be divided by 100 to get the real float percentage

| | allow\_votes | allows/disallows a post/comment to receive votes | | allow\_curation\_rewards | allows/disallows the voters to receive curation rewards. If set to false, curation rewards are returned to the reward pool. | | extensions | Reserved for future use | #### Description Authors of posts may not want all of the benefits that come from creating a post. This operation allows authors to update properties associated with their posts/comments. Typically, these options will accompany a `comment` operation in the same transaction. As of HF17, content creators can specify beneficiaries to receive a part of their author rewards. The list of beneficiaries is specified in the extension field of the `comment_options` operation and is a sorted array (by account name) of account and weight pairs. The beneficiaries can only be specified once and must be specified before any votes are cast on the comment. Most apps are adding the`comment_options` operation in the same transaction that creates the comment. **Notes:** * The max\_accepted\_payout may be decreased, but never increased. * The percent\_hbd may be decreased, but never increased. * `beneficiaries` array * * Must have at least one item (empty `beneficiaries` is not allowed). * Cannot have more than 127 (witness currently only allow up to 8). * Cannot allocate more than 100% of rewards to one account. * Cannot allocate more than 100% of rewards to a comment. * Must be specified in sorted order (account ascending; no duplicates). # TxConverts #### Blockchain operations * convert #### Columns | Name | Description | | --------- | ---------------------------------- | | owner | username requesting the conversion | | requestid | conversion request identifier | | amount | amount of HBD to convert | #### Description This operation instructs the blockchain to start a conversion of HBD to HIVE. The funds are deposited after 3.5 days. The identifier `requestid` will match the one find in VOFillConvertRequests when the request is executed by the system. # TxCustoms #### Blockchain operations * custom\_json #### Columns | Name | Description | | ------------------------ | ------------------------------------------------------------------- | | tid | less than 32 characters long identifier | | json | a proper utf8 / JSON string | | required\_posting\_auths | list of accounts who signed the transaction using their posting key | | required\_auths | list of accounts who signed the transaction using their active key | | required\_posting\_auth | the first value from required\_posting\_auths | | required\_auth | the first value from required\_auths | #### Description The `custom_json` operation provides a generic way to add higher-level protocols on top of witness consensus. This operation is designed to be human-readable/developer-friendly. There is no validation for this operation other than that the required auths are valid. `required_posting_auths` and `required_auths` are arrays. If more than one authority has been included in the operation, the `required_posting_auth` and `required_auth` columns will contain the first value from their respective arrays # TxDeclineVotingRights #### Blockchain operations * decline\_voting\_rights #### Columns | Name | Description | | ------- | -------------------------------------------- | | account | account declining rights to vote | | decline | true=decline false=cancel a previous decline | #### Description An account can choose to decline its voting rights after a 30 days delay. This includes voting on content and governance (witnesses, proposals). # TxDelegateVestingShares #### Blockchain operations * delegate\_vesting\_shares #### Columns | Name | Description | | --------------- | --------------------------------------------------- | | delegator | the account that delegates its Hive Power | | delegatee | the account that receives the Hive Power delegation | | vesting\_shares | amount of Hive Power delegated in VESTS | #### Description The table contains all vesting shares (Hive Power) delegation operations from one account to another. The vesting shares are still owned by the original account, but content voting rights and resource credit are transferred to the receiving account. Multiple operations involving the same accounts can be used to increase or decrease the amount of VESTS delegated. If the amount is set to 0 then the delegation is removed. When a delegation is removed, the VESTS are placed in limbo for 7 days to prevent using them and voting on the same content twice. # TxDeleteComments #### Blockchain operations * delete\_comment #### Columns | Name | Description | | -------- | ------------------------------- | | author | author of the post or comment | | permlink | permlink of the post or comment | #### Description A post or comment can only be deleted when it has no vote or sub-comment. They are not really deleted from the blockchain as they are still recorded in the [TxComments](/technical-informations/operations/txcomments) table. When a post or comment is successfully deleted, it is removed from the [Comments](/technical-informations/state-tables/comments) table. # TxEscrowApproves #### Blockchain operations * escrow\_approve #### Columns | Name | Description | | ---------- | ----------------------------------------------------------- | | from | account sending assets | | to | account receiving assets | | agent | the name of the agent who has authority to resolve disputes | | who | the account that raises the dispute | | escrow\_id | the escrow unique identifier assigned by the sender | | approve | true=approve false=disapprove | #### Description After creating an escrow transaction, both the receiver or the agent can approve or disapprove the deal. If nobody approves or disapproves the transaction before the deadline date, the funds are returned to the sender. # TxEscrowDisputes #### Blockchain operations * escrow\_dispute #### Columns | Name | Description | | ---------- | ----------------------------------------------------------- | | from | account sending assets | | to | account receiving assets | | agent | the name of the agent who has authority to resolve disputes | | who | the account that raises the dispute | | escrow\_id | the escrow unique identifier assigned by the sender | #### Description Either the sender or receiver of the payment may initiate a dispute anytime between the start of payment and the expiration. Once a dispute is raised, the escrow agent has the authority to release funds to either the sender or receiver (but no one else). # TxEscrowReleases #### Blockchain operations * escrow\_release #### Columns | Name | Description | | ------------ | -------------------------------------------------------- | | from | account sending assets | | to | account receiving assets | | agent | the name of the agent who has authority to release funds | | who | the account that raises is releasing the funds | | receiver | the account that receives the released funds | | escrow\_id | the escrow unique identifier assigned by the sender | | hbd\_amount | amount of HBD sent | | hive\_amount | amount of HIVE sent | #### Description This operation can be used by the sender, receiver, or agent to release funds. If the sender releases then the funds go to the receiver. If the receiver releases then they go to the sender. If the agent releases then the funds can go to either the sender or receiver. This operation is designed to allow partial releases. After the expiration, the receiver can use this operation to claim the funds. If the funds are not claimed by the receiver within 1 month of expiration then the sender can reclaim the funds. # TxEscrowTransfers #### Blockchain operations * escrow\_transfer #### Columns | Name | Description | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | | from | account sending assets | | to | account receiving assets | | hbd\_amount | amount of HBD sent | | hive\_amount | amount of HIVE sent | | escrow\_id | a unique identifier assigned by the sender to this transaction | | agent | the name of the agent who will have authority to resolve disputes | | fee | the fee that goes to the agent regardless of any dispute | | fee\_symbol | the fee asset symbol | | json\_meta | extra meta-information that is not part of the consensus | | ratification\_deadline | the time before which the receiver and the escrow must agree to commit the transaction. If no action is taken, the funds are returned to the sender. | | escrow\_expiration | the time at which the funds will go to the receiver if no other action is taken | #### Description This table store transfers initiated just like any other transfer that requires the approval of a third party. Unlike a normal transfer, an escrow transfer specifies some additional fields. An escrow payment facilitates trade among two or more parties with the potential for dispute resolution. When a user makes a payment via escrow the escrow agent receives a fee regardless of whether or not a dispute was raised. # TxFeeds #### Blockchain operations * feed\_publish #### Columns | Name | Description | | --------------------- | ---------------------------------------------- | | publisher | witness account publishing a price feed update | | exchange\_rate\_base | HBD price on exchanges | | exchange\_rate\_quote | HIVE price on exchanges | #### Description Witnesses regularly publish a price feed that enables the blockchain to calculate a conversion ratio between HBD and HIVE. # TxLimitOrdersCancels #### Blockchain operations * limit\_order\_cancel #### Columns | Name | Description | | ------- | --------------------------------------------------- | | owner | account who filled a limit order | | orderid | an order ID defined by the owner. It must be unique | #### Description This table contains operations broadcasted to the blockchain when users want to cancel orders created on the internal market (see [TxLimitOrdersCreates](/technical-informations/operations/txlimitorders)). # TxLimitOrdersCreates #### Blockchain operations * limit\_order\_create * limit\_order\_create2 #### Columns | Name | Description | | ------------------------ | -------------------------------------------------------------------------------------------------------------- | | owner | account who filled a limit order | | orderid | an order ID defined by the owner. It must be unique | | amount\_to\_sell | amount of asset | | amount\_to\_sell\_symbol | symbol of the asset | | min\_to\_receive | The target asset expected price (limit\_order\_create only) | | min\_to\_receive\_symbol | The target asset expected symbol (limit\_order\_create only) | | exchange\_rate | The target asset expected price (limit\_order\_create2) | | fill\_or\_kill | flag to specify if the order should be killed (removed) from the order book if it cannot be filled immediately | | expiration | expiration time for the order | #### Description This table contains operations broadcasted to the blockchain when users want to buy or sell assets on the internal market. `min_to_receive` and `min_to_receive_symbol` are used by limit\_order\_create operation only and will be left to NULL for other operations. `exchange_rate` is used by limit\_order\_create 2operation only and will be left to NULL for other operations The meaning of `fill_or_kill` is the same as literally, either fill (match) or kill (close). That is to say that when the user puts an order, if it can be filled, it will be filled and if it cannot be filled, it will be closed. So fill\_or\_kill can also be counted as a means to cancel an order `expiration` is to specify when the order will expire. It can even be any time within 28 days. The order is automatically canceled when it expires, so this is also another way to cancel an order. # TxPows #### Blockchain operations * pow * pow2 #### Columns | Name | Description | | --------------- | -------------------------- | | block\_id | block number | | worker\_account | username who mined a block | #### Description These operations have been deprecated since mining has been removed from the blockchain protocol. # TxProposalCreates #### Blockchain operations * create\_proposal #### Columns | Name | Description | | ------------------ | --------------------------------------------------- | | creator | the account that created the proposal | | receiver | the account that will receive the funding | | start\_date | the start date of the funding | | end\_date | the end date of the funding | | daily\_pay | the amount that will be paid daily to the receiver | | daily\_pay\_symbol | the asset symbol (HBD) | | subject | The name of the proposal | | permlink | a reference to the post describing the proposal | #### Description This table contains all proposal creation operations. The list of all proposals created can be found in the [Proposals](/technical-informations/state-tables/proposals) table. # TxProposalRemoves #### Blockchain operations * remove\_proposal #### Columns | Name | Description | | --------------- | ------------------------------------------------------------------------------------------------ | | proposal\_owner | the proposal's owner username | | proposal\_ids | the identifier of the proposal (see [Proposals](/technical-informations/state-tables/proposals)) | | extensions | reserved for future use | #### Description This table contains proposal removal requests. Even if removed (i.e. it will no more receive fundings from the DHF), the proposal's information will still be available in the [Proposals](/technical-informations/state-tables/proposals) table but tagged as deleted. # TxProposalUpdates #### Blockchain operations * update\_proposal #### Columns | Name | Description | | ------------ | ------------------------------------------------------------------------------------------------ | | proposal\_id | the identifier of the proposal (see [Proposals](/technical-informations/state-tables/proposals)) | | creator | the account that created the proposal | | daily\_pay | the amount that will be paid daily to the receiver | | subject | The name of the proposal | | permlink | a reference to the post describing the proposal | #### Description This table contains proposal updates. Only a few pieces of information can be changed and the new daily\_pay amount can only be lowered. # TxProposalVoteUpdates #### Blockchain operations * update\_proposal\_votes #### Columns | Name | Description | | ------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | voter | the username | | proposal\_ids | the identifiers of the proposals the user wants to vote or unvote (see [Proposals](/technical-informations/state-tables/proposals)) | | approve | true=approve - false=disapprove | | extensions | reserved for future use | #### Description This table contains all votes or votes removals for proposals. `proposal_ids` is a JSON array of proposals so multiple proposals can be approved or unapproved at once using a single operation. {% hint style="warning" %} Proposal votes are only summed at payment time (once per hour) and may not be reported immediately by related API. {% endhint %} # TxRecurrentTransfers #### Blockchain operations * recurrent\_transfer #### Columns | Name | Description | | -------------- | -------------------------------------------------------------------------------------------------------------------------------- | | from | Account to transfer asset from | | to | Account to transfer asset to | | amount | The amount of asset to transfer | | amount\_symbol | The symbol of asset to transfer | | memo | communication that accompanies the transfer. The memo is plain-text, any encryption on the memo is up to a higher-level protocol | | recurrence | How often will the payment be triggered (hours) | | executions | How many times the recurrent payment will be executed | | extensions | reserved for future use | #### Description The `recurrent_transfer` operation creates/updates/removes a recurrent transfer (Transfers any liquid asset every fixed amount of time from one account to another). If `amount` is set to 0, the recurrent transfer is be deleted. If there is already a recurrent transfer matching from and to, the recurrent transfer is updated. # TxTransfers #### Blockchain operations * transfer * transfer\_to\_vesting * transfer\_to\_savings * transfer\_from\_savings * cancel\_transfer\_from\_savings #### Columns | Name | Description | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------- | | type | Contains the blockchain operation name | | from | account sending assets | | to | account receiving assets | | amount | amount sent | | amount\_symbol | asset symbol | | memo | a communication that accompanies the transfer. The memo is plain-text, any encryption on the memo is up to a higher-level protocol. | | request\_id | only for transfer\_from\_savings or cancel\_transfer\_from\_savings | #### Description **`transfer`** Transfers assets from one account to another. * Transferring of Hive Power (VESTS) is not allowed. * Cannot transfer a negative amount. * `memo` must be less than 2048 bytes. * `memo` must be UTF-8. **`transfer_to_vesting`** This operation can converts HIVE into VESTS (Hive Power) at the current `hive_per_vests` rate (see [DynamicGlobalProperties](/technical-informations/state-tables/dynamicglobalproperties)). With this operation, it is possible to give vesting shares (Hive Power) to another account. * `amount` must be in HIVE. * `amount` must be greater than zero. **`transfer_to_savings`** and **`transfer_from_savings`** A user can place Hive and Hive Dollars into time -locked savings balances. \ Transfer from an account to savings is instant.\ Funds withdrawals from the savings to an account take three days. Their execution is recorded in the blockchain with the `fill_transfer_from_saving` virtual operation (see [VOFillTransferFromSavings](/technical-informations/virtual-operations/vofilltransferfromsavings)) **`cancel_transfer_from_savings`** Funds withdrawals from the savings can be canceled at any time before it is executed. # TxVotes #### Blockchain operations * vote #### Columns | Name | Description | | -------- | ------------------------------------------- | | voter | account performing the vote | | author | author of the post or comment being voted | | permlink | permlink of the post or comment being voted | | weight | vote weight in percent | #### Description A voter can vote several times on the same post and comment with a different weight value ranging from -10000 to 10000. The `weight` value is stored in the blockchain as an integer and must be divided by 100 to get the real float percentage. # TxWithdraws #### Blockchain operations * withdraw\_vesting #### Columns | Name | Description | | --------------- | ------------------------------------------------ | | account | username of the account performing the powerdown | | vesting\_shares | amount of VESTS to powerdown | #### Description This table store the VESTS withdrawals (i.e. Powerdown) requests from users. A powerdown request will be split into multiple virtual operations (see [VOFillVestingWithdraws](/technical-informations/virtual-operations/vofillvestingwithdraws)) at the pace of one per week (currently 13 weeks) Each subsequent `withdraw_vesting` operation issued from a user will reset the powerdown duration to 13 weeks if the previous one is not complete. # TxWithdrawVestingRoutes #### Blockchain operations * set\_withdraw\_vesting\_route #### Columns | Name | Description | | ------------- | ----------------------------------------------------------------------------------- | | from\_account | account doing the VESTS (Hive Power) to HIVE conversion (powerdown) | | to\_account | account who will receive HIVE assets | | percent | percentage of the powerdown value received by the recipient | | auto\_vest | true=automatically perform a reverse conversion from HIVE to VESTS to the recipient | #### Description When initiating a powerdown, the initiating account can request the blockchain to send the converted liquid HIVE to one or multiple accounts rather than the withdrawing account. In addition, those funds can be immediately vested again, circumventing the conversion from VESTS to HIVE and back. # TxWitnessSetProperties #### Blockchain operations * witness\_set\_properties #### Columns | Name | Description | | ---------- | -------------------------------- | | owner | witness account username | | props | an array of properties to update | | extensions | reserved for future use | #### Description This table contains the operations published by the witnesses to adapt the dynamic parameters of the blockchain. # TxWitnessUpdates #### Blockchain operations * witness\_update #### Columns | Name | Description | | ----------------------------- | ----------------------------------------------------------- | | owner | witness account | | url | an URL to a post or website describing the witness activity | | block\_signing\_key | the public key of the key pair used to sign blocks | | props\_account\_creation\_fee | the witness proposed fee for account creation | | props\_maximum\_block\_size | the witness proposed block size | | props\_hbd\_interest\_rate | the witness proposed HBD interest rate | #### Description This table contains transactions by account who declare themselves as a witness or who update their witness parameters. # Virtual Operations **What are Virtual Operations?** Virtual operations are operations resulting from the activity on the blockchain but, unlike classic operations, they are not initiated by users. Example: 1. When a user publishes a post or comment, a `comment` operation is issued by the user or the front-end it uses. This operation will be stored in the blockchain and in the TxComments table in HiveSQL. 2. If some users consider this post or comment worth it, they may upvote it. These upvotes are stored in the blockchain as `vote` operations and stored in the TxVotes table in HiveSQL. 3. After 7 days, if the post or comment has received enough powerful upvotes, the user is awarded a payout for it and an `author_reward` virtual operation is recorded in the blockchain. The user did nothing to trigger it, the system did it automatically.
TableDescription
TableDescription
VOAccountCreatedsCreations of new accounts
VOAuthorRewardsAuthor rewards
VOChangedRecoveryAccountsAccount Recovery changes
VOClearNullAccountBalancesZeroing of the @null account balance
VOCollateralizedConvertImmediateConversionsConversions from HIVE to HBD
VOCommentBenefactorRewardsBenefactor rewards
VOCommentPayoutUpdatesPosts and comments final payout computations
VOCommentRewardsComments rewards
VOConsolidateTreasuryBalancesTransfers from the old treasury account to the new one
VOCurationRewardsCuration rewards
VODelayedVotingsPower-ups who become effective for governance
VODHFConversionsConversion of Ninja mined HIVE to DHF
VODHFFundingsDHF proposals payments
VOExpiredAccountNotificationsNotifications of governance expirations
VOFillCollateralizedConvertRequestsExecution of conversion from HIVE to HBD
VOFillConvertRequestsHBD to HIVE conversions
VOFillOrdersInternal Market orders filled
VOFillRecurrentTransfersExecution of recuurent transfers
VOFillTransferFromSavingsExecution of Transfers from savings
VOFillVestingWithdrawsExecution of Powerdown
VOHardforkHiveRestoresPost Hive hardfork airdrops
VOHardforkHivesHive hardfork airdrops
VOHardforksBlockchain hardforks
VOInterestsHBD interest payments
VOLimitOrderCancelledsLimit order cancellations
VOLiquidityRewardsDeprecated
VOPowRewardsMiner rewards
VOProducerRewardsProducers rewards
VOProposalFeesFees paid when creating proposals
VOProposalPaysProposal payments
VOReturnVestingDelegationsExecution of HP delegation removals
VOShutdownWitnessesDeprecated
VOSPSConvertsConversions from HIVE to HBD for the DHF
VOSPSFundsDHF fundings
VOTransferToVestingCompletedsTransfers to vesting completion
# VOAccountCreateds #### Blockchain Virtual Operations * account\_created #### Columns | **Name** | **Description** | | -------------------------------- | --------------------------------------------------------------------------- | | new\_account\_name | name of the newly created account | | creator | name of the account creator | | initial\_vesting\_shares | Amount of VESTS given to the created account | | initial\_vesting\_shares\_symbol | VESTS | | initial\_delegation | Amount of VESTS delegated if created with account\_create\_with\_delegation | | initial\_delegation\_symbol | VESTS | #### Description This virtual operation is issued each time a new account has been successfully created. # VOAuthorRewards #### Blockchain Virtual Operations * author\_reward #### Columns | **Name** | **Description** | | --------------- | ------------------------------- | | author | author of the post or comment | | permlink | permlink of the post or comment | | hbd\_payout | HBD value of the reward | | hive\_payout | HIVE value of the reward | | vesting\_payout | HP value of the reward | #### Description This virtual operation is triggered after the payout period on posts and comments # VOChangedRecoveryAccounts #### Blockchain Virtual Operations * changed\_recovery\_account #### Columns | **Name** | **Description** | | ---------------------- | ---------------------------------------- | | account | account who changed its recovery account | | old\_recovery\_account | old recovery account | | new\_recovery\_account | new recovery account | #### Description This virtual operation is issued when the blockchain effectively change the recovery account of an account after it issued such request (see [TxAccountRecoveryChanges](/technical-informations/operations/txaccountrecoverychanges)). # VOClearNullAccountBalances #### Blockchain Virtual Operations * clear\_null\_account\_balance #### Columns | **Name** | **Description** | | -------------- | -------------------------------------------------- | | total\_cleared | a JSON array with the assets that have been burned | #### Description This table contains virtual operations created by the blockchain when the @null account balances need to be zeroed. The [@null](https://hiveblocks.com/null) account is a special account used to burn assets and its balance should always be null. Each time assets are sent to the [@null](https://hiveblocks.com/@null) account, their balances must be reset to zero. This virtual operation is issued per-block processing that clears null account balances. # VOCollateralizedConvertImmediateConversions #### Blockchain Virtual Operations * collateralized\_convert\_immediate\_conversion #### Columns | **Name** | **Description** | | --------- | ------------------------------------- | | owner | The account requesting the conversion | | requestid | The request identifier | | hbd\_out | Amount of HBD sent to the account | #### Description This virtual operation is triggered after a `collateralized_convert` operation is issued to convert HIVE to HBD. Half of the HIVE amount is converted immediately into HBD (using the minimum witnesses price feed for the last 3.5 days) and sent to the owner. {% hint style="warning" %} This table currently only contains records from hardfork 26 and later. It is planned to perform a replay of the blockchain to re-inject data relating to previous events. {% endhint %} # VOCommentBenefactorRewards #### Blockchain Virtual Operations * comment\_benefactor\_reward #### Columns | **Name** | **Description** | | --------------- | ---------------------------------------------------- | | benefactor | account receiving part of the post or comment reward | | author | author of the post or comment | | permlink | permlink of the post or comment | | hbd\_payout | HBD value of the reward | | hive\_payout | HIVE value of the reward | | vesting\_payout | HP value of the reward | #### Description This virtual operation is triggered after the payout period on posts and comments if the original author has decided to share his reward with other users. # VOCommentPayoutUpdates #### Blockchain Virtual Operations * comment\_payout\_update #### Columns | **Name** | **Description** | | -------- | ------------------------------- | | author | author of the post or comment | | permlink | permlink of the post or comment | #### Description This virtual operation is issued when a post or comment reaches the end of the payout windows and its final payout values are computed. # VOCommentRewards #### Blockchain Virtual Operations * comment\_reward #### Columns | **Name** | **Description** | | -------------- | ------------------------------- | | author | author of the post or comment | | permlink | permlink of the post or comment | | payout | value of the payout | | payout\_symbol | asset symbol of the payout | #### Description This virtual operation is issued after the payout period on posts and comments The value of this operation is the global payout value for the post or comment. A separate virtual operation is issued for the author, the curators and the beneficiaries (see [VOAuthorRewards](/technical-informations/virtual-operations/voauthorrewards), [VOCommentBenefactorRewards](/technical-informations/virtual-operations/vocommentbenefactorrewards) and [VOCurationRewards](/technical-informations/virtual-operations/vocurationrewards)) The value is the equivalent HBD value of the payout even if no HBD will be effectively paid to the author, curators or beneficiaries. # VOCommentsVotes #### Blockchain Virtual Operations * effective\_comment\_vote #### Columns | **Name** | **Description** | | ----------------------- | ----------------------------------------------------------------------------------------------------- | | voter | account performing the vote | | author | author of the post or comment being voted | | permlink | permlink of the post or comment being voted | | weight | defines the score this vote receives, used by vote payout calc. 0 if a negative vote or changed votes | | rshares | The number of rshares this vote is responsible for | | total\_vote\_weight | the total weight of voting rewards, used to calculate pro-rata share of curation payouts | | pending\_payout | potential payout of related comment at the moment of this vote | | pending\_payout\_symbol | HBD | #### Description This virtual operation is issued when a vote on a post or comment becomes effective (see [TxVotes](/technical-informations/operations/txvotes)) # VOConsolidateTreasuryBalances #### Blockchain Virtual Operations * consolidate\_treasury\_balance #### Columns | **Name** | **Description** | | ------------ | ------------------------------------------------- | | total\_moved | a JSON array with the assets that have been moved | #### Description This virtual operation is issued when assets move from the old treasury account to the current one, on an ongoing basis. Note that the obsolete account is still considered a treasury (cannot be reused for other purposes), but all funds and actions are redirected to the new one. The old ([@steem.dao](https://hiveblocks.com/@steem.dao)) and new ([@hive.funds](https://hiveblocks.com/@hive.funds)) treasury accounts are defined in the static configuration values of the blockchain (see [Hive developer portal](https://developers.hive.io/tutorials-recipes/understanding-configuration-values.html\))) # VOCurationRewards #### Blockchain Virtual Operations * curation\_reward #### Columns | **Name** | **Description** | | -------- | -------------------------------- | | curator | user getting the curation reward | | author | author of the post or comment | | permlink | permlink of the post or comment | | reward | value of the reward | #### Description This virtual operation is issued by the blockchain after the payout period on posts and comments. # VODelayedVotings #### Blockchain Virtual Operations * delayed\_voting #### Columns | **Name** | **Description** | | -------- | ----------------------------------------------------------------- | | voter | account who performed a power-up and whose votes will be impacted | | votes | amount of additional VESTS to take into account for votes | #### Description This table contains virtual operations issued when newly powered up VESTS (Hive Power) become counted towards witnesses and DHF proposals votes. The delay for Hive Power to become effective for governance has been set to 30 days in HF24. # VODHFConversions #### Blockchain Virtual Operations * dhf\_conversion #### Columns | **Name** | **Description** | | ---------------- | ----------------------------- | | treasury | The account of the DHF | | hive\_amount\_in | The amount of HIVE to convert | | hbd\_amount\_out | The amount of HBD generated | #### Description When a user transfer HIVE to the DHF account (hive.fund), the amount is immediately converted to HBD and this virtual operation is generated. This virtual operation is also generated during block processing every day during daily proposal maintenance. **Note:** a portion of the HIVE on the treasury balance is converted to HBD and thus increases the funds available for proposals. {% hint style="warning" %} This table currently only contains records from hardfork 26 and later. It is planned to perform a replay of the blockchain to re-inject data relating to previous events. {% endhint %} # VODHFFundings #### Blockchain Virtual Operations * dhf\_funding #### Columns | **Name** | **Description** | | ------------------------- | ----------------------------- | | treasury | The account of the DHF | | additional\_funds | The amount of HIVE to convert | | additional\_funds\_symbol | HBD | #### Description This virtual operation is generated during block processing every proposal maintenance period. **Note:** while the DHF receives part of inflation every block, this virtual operation is generated only when there are proposal payouts. {% hint style="warning" %} This table currently only contains records from hardfork 26 and later. It is planned to perform a replay of the blockchain to re-inject data relating to previous events. {% endhint %} # VOExpiredAccountNotifications #### Blockchain Virtual Operations * expired\_account\_notification #### Columns | **Name** | **Description** | | -------- | --------------------------------------------- | | account | Account for who governance votes have expired | #### Description This virtual operation is issued when governance votes for an account have expired and are removed. # VOFailedRecurrentTransfers #### Blockchain Virtual Operations * failed\_recurrent\_transfer #### Columns | **Name** | **Description** | | --------------------- | -------------------------------------------------------------------------------------------------------------------------------- | | from | Account to transfer asset from | | to | Account to transfer asset to | | amount | The amount of asset to transfer | | amount\_symbol | The symbol of asset to transfer | | memo | communication that accompanies the transfer. The memo is plain-text, any encryption on the memo is up to a higher-level protocol | | consecutive\_failures | How many times the recurrent payment failed to be executed | | remaining\_executions | How many times the recurrent payment should still be executed | | deleted | Indicates that the recurrent transfer was deleted due to too many consecutive failures | #### Description This virtual operation is issued when a recurrent transfer has failed to be executed (see [TxRecurrentTransfers (HF25)](/technical-informations/operations/txrecurrenttransfers-hf25)). # VOFillCollateralizedConvertRequests #### Blockchain Virtual Operations * fill\_collateralized\_convert\_request #### Columns | **Name** | **Description** | | -------------------------- | ------------------------------------------------ | | owner | Account requesting the conversion | | requestid | conversion request identifier | | amount\_in | Amount of HIVE that has been converted (burned) | | amount\_in\_symbol | HIVE | | amount\_out | Amount of HBD to be received | | amount\_out\_symbol | HBD | | excess\_collateral | Excess collateralized HIVE returned to the owner | | excess\_collateral\_symbol | HIVE | #### Description This virtual operation is issued when a HIVE to HBD conversion is finalized (see [TxCollateralizedConverts](/technical-informations/operations/txcollateralizedconverts-hf25)). When issued, the blockchain calculates how much HIVE has to be taken out of collateral in order to produce HBD that was already given to the user, using the median of median hourly HIVE prices from the last 3.5 days corrected by the 5% fee. The price might be smaller than the "official" price in case the main price was artificially corrected upward when the hard limit condition was hit in the meantime. If collateral exceeded the amount needed for HBD production, the extra is returned to the user balance and the rest is burned. If during 3.5 days of wait the market price fell more than twice from the previous minimum, all collateral is burned, nothing is returned to the user and the associated loss is absorbed by the network in form of higher than the proper supply of HIVE. In such a case, a system\_warning\_operation virtual operation is produced. # VOFillConvertRequests #### Blockchain Virtual Operations * fill\_convert\_request #### Columns | **Name** | **Description** | | ----------- | ---------------------------- | | owner | account doing the conversion | | requestid | id of the request | | amount\_in | amount of HBD converted | | amount\_out | amount of HIVE received | #### Description This virtual operation is issued when the delay for an asset conversion is complete and the assets are effectively converted (see [TxConverts](/technical-informations/operations/txconverts)). # VOFillOrders #### Blockchain Virtual Operations * fill\_order #### Columns | **Name** | **Description** | | --------------------- | ---------------------------- | | current\_owner | account who filled the order | | current\_orderid | order identifier | | current\_pays | amount of asset | | current\_pays\_symbol | symbol of asset | | open\_owner | account who issued an order | | open\_orderid | order identifier | | open\_pays | amount of asset | | open\_pays\_symbol | asset symbol | #### Description This virtual operation is issued when orders on the internal market are filled (see [TxLimitOrdersCreates](/technical-informations/operations/txlimitorders)) # VOFillRecurrentTransfers #### Blockchain Virtual Operations * fill\_recurrent\_transfer #### Columns | **Name** | **Description** | | --------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | from | account sending assets | | to | account receiving assets | | amount | amount sent | | amount\_symbol | asset symbol | | memo | a communication that accompanies the transfer. The memo is plain-text, any encryption on the memo is up to a higher-level protocol | | remaining\_executions | Number of remaining executions | #### Description This virtual operation is issued when a recurrent transfer is executed (see [TxRecurrentTransfers (HF25)](/technical-informations/operations/txrecurrenttransfers-hf25)). # VOFillTransferFromSavings #### Blockchain Virtual Operations * fill\_transfer\_from\_savings #### Columns | **Name** | **Description** | | -------------- | ------------------------------- | | from | Account doing the transfer | | to | destination account | | amount | amount of asset transferred | | amount\_symbol | symbol of the asset transferred | | memo | communication text | #### Description This virtual operation is issued when the delay for a transfer request from a savings balance is complete and the transfer is effectively executed (see [TxTransfers](/technical-informations/operations/txtransfers)) # VOFillVestingWithdraws #### Blockchain Virtual Operations * fill\_vesting\_withdraw #### Columns | **Name** | **Description** | | ----------------- | ------------------------------ | | from\_account | account doing the withdrawal | | to\_account | destination account | | withdrawn | amount of the withdrawal | | withdrawn\_symbol | asset symbol of the withdrawal | | deposited | amount of asset received | | deposited\_symbol | received assets symbol | #### Description This virtual operation issued when each week after a user has initiated a withdrawal from VESTS to HIVE (see [TxWithdraws](/technical-informations/operations/txwithdraws)). # VOHardforkHiveRestores #### Blockchain Virtual Operations * hardfork\_hive\_restore #### Columns | **Name** | **Description** | | ----------------- | ---------------------------------------- | | account | account whose assets are restored | | treasury | account where the assets are coming from | | hbd\_transferred | amount of HBD transferred | | hive\_transferred | amount of HIVE transferred | #### Description This virtual operation is issued to restore the liquid balance of accounts that were not airdropped in the original Hive hardfork (see [VOHardforkHives](/technical-informations/virtual-operations/vohardforkhives)). Their assets were restored later. # VOHardforkHives #### Blockchain Virtual Operations * hardfork\_hive #### Columns | **Name** | **Description** | | ------------------------- | --------------------------------------- | | account | username | | vests\_converted | amount of VESTS (Hive Power) airdropped | | sbd\_transferred | amount of HIVE airdropped | | steem\_transferred | amount of HBD airdropped | | total\_steem\_from\_vests | amount of HIVE airdropped | #### Description This virtual operation is issued for a very particular event: the hardfork 23 that happened when the Hive blockchain split from Steem. At this time, several accounts have not been airdropped with HIVE tokens, so their existing delegations were instantly removed. However, there were no operations of type `delegate_vesting_share` relating to this. It was recorded in the blockchain with `hardfork_hive` virtual operations, stored in the [VOHardforkHives ](/technical-informations/virtual-operations/vohardforkhives)table. # VOHardforks #### Blockchain Virtual Operations * hardfork #### Columns | **Name** | **Description** | | ------------ | --------------- | | hardfork\_id | Hardfork number | #### Description This virtual operation is generated during block processing every time new hardfork is activated. {% hint style="warning" %} This table currently only contains records from hardfork 26 and later. It is planned to perform a replay of the blockchain to re-inject data relating to previous events. {% endhint %} # VOInterests #### Blockchain Virtual Operations * interest #### Columns | **Name** | **Description** | | -------- | ------------------------------- | | owner | account receiving the interests | | interest | amount of interest (in HBD) | #### Description This virtual operation is issued when interests are paid on HBD or HBD saving. # VOLimitOrderCancelleds #### Blockchain Virtual Operations * limit\_order\_cancelled #### Columns | **Name** | **Description** | | ------------------------- | --------------------------------- | | seller | The account who created the order | | amount\_back | The amount of the cancelled order | | additional\_funds\_symbol | HIVE or HBD | #### Description This virtual operation is generated every time an existing limit order is canceled. It happens on explicit call (first operation), or in the rare case of filling a limit order (second or third operation) when, after filling most of it, the remaining funds are too small (they would round to zero when sold). This virtual operation is also generated during block processing for orders that reached their expiration time without being filled. {% hint style="warning" %} This table currently only contains records from hardfork 26 and later. It is planned to perform a replay of the blockchain to re-inject data relating to previous events. {% endhint %} # VOLiquidityRewards #### Blockchain Virtual Operations * liquidity\_reward #### Columns | **Name** | **Description** | | -------- | --------------- | | owner | username | | payout | amount of HIVE | #### Description Liquidity reward was a reward mechanism for the on-chain market designed to pay users who provide liquidity to the market. {% hint style="warning" %} This virtual operation is deprecated as of HF12 and is no more used. {% endhint %} # VOPowRewards #### Blockchain Virtual Operations * pow\_reward #### Columns | **Name** | **Description** | | -------------- | ---------------------- | | worker | account mining a block | | reward | amount received | | reward\_symbol | HIVE | #### Description This virtual operation occurs each time a block is produced. It contains the rewards that are given to witnesses (and previously miners) for their work. {% hint style="warning" %} This operation has been introduced with HF5 and deprecated with HF17. The table is empty for now and it is planned to perform a replay of the blockchain to re-inject data relating to previous events. {% endhint %} # VOProducerMisseds #### Blockchain Virtual Operations * producer\_missed #### Columns | **Name** | **Description** | | -------- | -------------------------------------- | | producer | Name of the witness who missed a block | #### Description This virtual operation is generated during block processing when a witness failed to produce his block on time. {% hint style="warning" %} This table currently only contains records from hardfork 26 and later. It is planned to perform a replay of the blockchain to re-inject data relating to previous events. {% endhint %} # VOProducerRewards #### Blockchain Virtual Operations * producer\_reward #### Columns | **Name** | **Description** | | --------------- | ------------------------- | | producer | account producing a block | | vesting\_shares | amount of VESTS received | #### Description This virtual operation occurs each time a block is produced. It contains the rewards that are given to witnesses (and previously miners) for their work. # VOProposalFees #### Blockchain Virtual Operations * proposal\_fee #### Columns | **Name** | **Description** | | ------------ | ----------------------------------------- | | creator | Account creating a proposal | | treasury | The account of the DHF | | proposal\_id | The proposal identifier | | fee | The amount paid for creating the proposal | | fee\_symbol | HBD | #### Description This virtual operation is generated every time an account creates a new proposal. {% hint style="warning" %} This table currently only contains records from hardfork 26 and later. It is planned to perform a replay of the blockchain to re-inject data relating to previous events. {% endhint %} # VOProposalPays #### Blockchain Virtual Operations * proposal\_pay #### Columns | **Name** | **Description** | | --------------- | -------------------------------------- | | proposal\_id | id of the proposal | | receiver | Account receiving the proposal funding | | payment | amount received | | payment\_symbol | asset symbol | #### Description This virtual operation is issued every hour during a proposal payment phase. Proposals without any votes are not considered active and do not receive any payment. If the payment of a proposal exceeds the amount of the available daily budget, it will receive a partial payment with what's left in the daily budget. # VOReturnVestingDelegations #### Blockchain Virtual Operations * return\_vesting\_delegation #### Columns | **Name** | **Description** | | -------------- | ------------------------------ | | account | Account who did the delegation | | amount | Amount of assets returned | | amount\_symbol | Symbol of assets returned | #### Description This virtual operation occurs when the Hive Power that has been previously delegated by an account to another account comes back to the original owner. When a user cancels its delegation, it takes 7 days to complete (see [TxDelegateVestingShares](/technical-informations/operations/txdelegatevestingshares)). # VOShutdownWitnesses #### Blockchain Virtual Operations * shutdown\_witness #### Columns | **Name** | **Description** | | -------- | ------------------------ | | owner | witness account disabled | #### Description This virtual operation was previously issued when the system automatically disables a witness because it was missing too many blocks. {% hint style="warning" %} This operation has been introduced with HF14 and deprecated with HF20. {% endhint %} # VOSPSConverts #### Blockchain Virtual Operations * sps\_convert #### Columns | **Name** | **Description** | | ---------------- | --------------------- | | fund\_account | account of the DHF | | hive\_amount\_in | amount of HIVE burned | | hbd\_amount\_out | amount of HBD created | #### Description This table contains virtual operations issued when a Proposals Fund (DHF) conversion from HIVE to HBD occurs. When the Hardfork that created Hive happened back in March 2020, the Steemit Inc ninja-mined funds were moved into the [@hive.fund](https://hiveblocks.com/@hive.funds) account as a development fund. As proposals are paid in HBD and most of the moved funds were in HIVE, an automatic conversion process has been put in place. # VOSPSFunds #### Blockchain Virtual Operations * sps\_fund #### Columns | **Name** | **Description** | | ------------------------- | ------------------------------------- | | additional\_funds | amount of asset added to the fund | | additional\_funds\_symbol | symbol of the asset added to the fund | #### Description This virtual operation is issued once per maintenance interval to document how much HBD was added to the treasury from inflation in that maintenance interval (i.e., to track the funding of the Proposals Fund - DHF). # VOTransferToVestingCompleteds #### Blockchain Virtual Operations * transfer\_to\_vesting\_completed #### Columns | **Name** | **Description** | | --------------------------------- | ------------------------- | | from\_account | account powering up HIVE | | to\_account | account receiving VESTS | | hive\_vested | amount of HIVE powered up | | hive\_vested\_symbol | HIVE | | vesting\_shares\_received | amount of VESTS received | | vesting\_shares\_received\_symbol | VESTS | #### Description This virtual operation is issued when a power-up is finally taken into account for governance votes (see [TxTransfers](/technical-informations/operations/txtransfers)). # State tables State tables reflect the result of operations recorded in the blockchain. | Table | Description | | --------------------------------------------------------------------------------------- | ------------------------------------------- | | [DynamicGlobalProperties](/technical-informations/state-tables/dynamicglobalproperties) | Dynamic global properties of the blockchain | | [Accounts](/technical-informations/state-tables/accounts) | Accounts created on the blockchain | | [Blacklists](/technical-informations/state-tables/blacklists) | Decentralized blacklists | | [BlacklistsFollows](/technical-informations/state-tables/blacklistsfollows) | Decentralized blacklists followers | | [Comments](/technical-informations/state-tables/comments) | Posts and comments and related information | | [Communities](/technical-informations/state-tables/communities) | Communities | | [CommunitiesRoles](/technical-informations/state-tables/communitiesroles) | Roles in each community | | [CommunitiesSubscribers](/technical-informations/state-tables/communitiessubscribers) | Subscribers of each community | | [Delegations](/technical-informations/state-tables/delegations) | Active delegations | | [Followers](/technical-informations/state-tables/followers) | Who is following who | | [Mutes](/technical-informations/state-tables/mutes) | Decentralized mutes lists | | [MutesFollows](/technical-informations/state-tables/mutesfollows) | Decentralized mutes lists followers | | [Proposals](/technical-informations/state-tables/proposals) | Proposals | | [ProposalsApprovals](/technical-informations/state-tables/proposalsapprovals) | Proposals approved by each account | | [RCDelegations](/technical-informations/state-tables/rcdelegations) | Active RC delegations | | [Reblogs](/technical-informations/state-tables/reblogs) | Reblogs of posts | | [Tags](/technical-informations/state-tables/tags) | Tags used on each post | | [Witnesses](/technical-informations/state-tables/witnesses) | Witnesses and related information | # DynamicGlobalProperties #### Description This table contains the data returned by the `get_dynamic_global_properties` API. This API call is used to get the state of the Hive blockchain and its global parameters. It is updated every time a block is processed. #### Columns
NameDescription
NameDescription
head_block_numberlast block number of the blockchain but not yet irreversible
timePoint in time (UTC) that the block was included in the chain.
current_witnessAccount name of the current witness.
current_supplyHIVE currently in existence.
current_supply_symbol"HIVE"
current_hbd_supplyHBD currently in existence.
current_hbd_supply_symbol"HBD"
total_vesting_fund_hiveHIVE that are staked into Hive Power (powered up)
total_vesting_fund_hive_symbol"HIVE"
total_vesting_sharesVESTS that are staked into HIVE POWER (powered up).
total_vesting_shares_symbol"VESTS"
total_reward_fund_hiveHIVE available in the reward pool for pending (liquid) rewards
total_reward_fund_hive_symbol"HIVE"
total_reward_shares2Deprecated - number of shares in the pool.
pending_rewarded_vesting_sharesAmount of VESTS produced from HIVE held in pending reward vested fund.
pending_rewarded_vesting_shares_symbol"VESTS"
pending_rewarded_vesting_hivePool of HIVE tokens for pending (vested) rewards.
pending_rewarded_vesting_hive_symbol"HIVE"
hbd_interest_rateinterest rate that HBD deposits receive.
hbd_print_ratePercentage of HIVE being converted to HBD during payouts
maximum_block_sizeMaximum block size set by top20 witnesses (can change every round)
required_actions_partition_percentsize of the block that is partitioned for actions.
Required actions can only be delayed if they take up more than this amount.
More can be included, but are not required.
Block generation should only include transactions up to maximum_block_size -required_actions_parition_size to ensure required actions are not delayed when they should not be.
current_aslotcurrent absolute slot number. Equal to the total number of slots since genesis. Also equal to the total number of missed slots plus head_block_number.
recent_slots_filledUsed to compute witness participation.
participation_countUsed to compute witness participation.
last_irreversible_block_numlatest block number that has been confirmed by two thirds of all block producers and is thus irreversible.
vote_power_reserve_ratenumber of votes regenerated per day.
Any user voting slower than this rate will be “wasting” voting power through spillover; any user voting faster than this rate will have their votes reduced.
target_votes_per_periodnumber of votes regenerated per day.
Any user voting slower than this rate will be “wasting” voting power through spillover; any user voting faster than this rate will have their votes reduced.
delegation_return_perioddelay (in seconds) before Hive Power is returned to the original owner when a delegation is removed.
reverse_auction_secondsduration (in seconds) of the reverse auction period
available_account_subsidies
hbd_stop_percentDebt ratio percentage at which HBD printing will stop
hbd_start_percentDebt ratio percentage at which HBD printing will start to be reduced
next_maintenance_timeUsed to compute payments for proposals.
last_budget_timeUsed to compute payments for proposals.
content_reward_percentpercentage of the inflation allocated to the reward pool
vesting_reward_percentpercentage of the inflation allocated to reward stakeholders
sps_fund_percentpercentage of the inflation allocated to the DHF
sps_interval_ledgerAmount that will be sent to the DHF account at the next funding interval.
sps_interval_ledger_symbol"HBD"
downvote_pool_percentUsed by a separate downvote pool that is a percentage of the max size of the voting mana. Downvotes will be taken from the downvote pool first, and then the upvote pool once the downvote pool has been consumed. The downvote pool will follow the same rules as the upvote pool, regenerating over five days and filling instantly and proportionally to new Hive Power and delegations.
hive_per_vestHIVE to VEST conversion ratio
smt_creation_feeFee to create a new SMT
smt_creation_fee_symbol"HBD"
price_hive_usdHIVE price in USD
price_hbd_usdHBD price in USD
confidential_supplytotal asset held in confidential balances.
confidential_supply_symbol"HIVE"
confidential_hbd_supplyTotal HBD held in confidential balances.
current_remove_thresholdnumber of objects that can be removed in one automatic operation (only applies to situations where many objects can accumulate over time but need to be removed in a single operation f.e. proposal votes)
early_voting_secondsDuration of the first period where all votes are considered equally regarding vote time and the linear rewards curve is applied (equal weight to all voters in that window) - currently 24 hours
mid_voting_secondsDuration of the second period where with reward weight/2 is applied - currently 48 hours
max_consecutive_recurrent_transfer_failuresMaximum number of consecutive failures for a recurring transfer before it is automatically canceled
max_recurrent_transfer_end_dateMaximum difference between start and end of a recurring payment - currently 730 days (2 years)
min_recurrent_transfers_recurrenceMinimum time to elapse between two recurring transfer - currently 24 hours
max_open_recurrent_transfersMaximum number of recurring payments that can be scheduled for execution per account - currently 255
# Accounts The Accounts table is a non-transactional table and contains a list of all accounts and related information resulting from the activity of accounts on the blockchain. #### Columns | Name | Description | | ------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | id | blockchain internal identifier | | name | account name | | owner | owner authorities | | active | active authorities | | posting | posting authorities | | memo\_key | memo public key | | json\_metadata | account metatada (updated with active key) | | posting\_json\_metadata | account metatada (updated with posting key) | | proxy | account to which governance votes are proxied | | last\_owner\_update | last time of owner authorities change | | last\_account\_update | last time the account data have been updated | | created | account creation time | | mined | set to true if the account has been created through mining | | recovery\_account | recovery account | | last\_account\_recovery | the last time the account has been recovered | | post\_count | total number of posts and comments published | | voting\_manabar\_current\_mana | current upvote mana | | voting\_manabar\_last\_update\_time | last time the upvote mana has been updated | | downvote\_manabar\_current\_mana | current downvote mana | | downvote\_manabar\_last\_update\_time | last time the downvote mana has been updated | | voting\_power | current voting power (integer value - must be divided by 100) | | last\_vote\_time | last time account voted | | balance | HIVE balance | | balance\_symbol | "HIVE" | | savings\_balance | HIVE savings balance | | savings\_balance\_symbol | "HIVE'" | | hbd\_balance | HBD balance | | hbd\_balance\_symbol | "HBD" | | hbd\_seconds | used to compute interest value | | hbd\_seconds\_last\_update | used to compute interest value | | hbd\_last\_interest\_payment | the last time interest has been paid | | savings\_hbd\_balance | HBD saving balance | | savings\_hbd\_balance\_symbol | "HBD" | | savings\_hbd\_seconds | used to compute interest value | | savings\_hbd\_seconds\_last\_update | used to compute interest value | | savings\_hbd\_last\_interest\_payment | the last time interest has been paid on savings | | savings\_withdraw\_requests | number of pending savings withdrawal requests | | reward\_hbd\_balance | claimable reward HBD balance | | reward\_hbd\_balance\_symbol | "HBD" | | reward\_hive\_balance | claimable reward HIVE balance | | reward\_hive\_balance\_symbol | "HIVE" | | reward\_vesting\_balance | claimable reward VESTS balance (HP) | | reward\_vesting\_balance\_symbol | "VESTS" | | reward\_vesting\_hive | claimable reward VESTS balance converted into HIVE | | reward\_vesting\_hive\_symbol | "HIVE" | | vesting\_shares | amount of Hive Power | | vesting\_shares\_symbol | VESTS | | delegated\_vesting\_shares | amount of Hive Power delegated | | delegated\_vesting\_shares\_symbol | VESTS | | received\_vesting\_shares | amount of Hive Power delegation received | | received\_vesting\_shares\_symbol | VESTS | | vesting\_withdraw\_rate | amount HP to powered down by week | | vesting\_withdraw\_rate\_symbol | VESTS | | next\_vesting\_withdrawal | next powerdown time | | withdrawn | total amount powered down (in VESTS) | | to\_withdraw | current amount to power down (VESTS) | | withdraw\_routes | number of active withdrawal routes | | curation\_rewards | total curation reward (HP equivalent) | | posting\_rewards | total author reward (HP equivalent) | | proxied\_vsf\_votes | use to compute the amount of HP proxied | | witnesses\_voted\_for | an array of witnesses the account is voting for | | last\_post | last post or comment time | | last\_root\_post | last post time | | pending\_claimed\_accounts | number of account creation ticked collected | | vesting\_balance | amount of Hive Power delayed for voting | | vesting\_balance\_symbol | VESTS | | reputation | a big integer number that represents the reputation acquired over time. | | reputation\_ui | a human-readable value of the reputation | | witness\_votes | number of witnesses votes for | | post\_voting\_power | Effective HP that are used for curation (vesting\_shares - delegated\_vesting\_shares + received\_vesting\_shares) | | post\_voting\_power\_symbol | VESTS | | pending\_transfers | Pending transfers for escrow operations | | governance\_vote\_expiration\_ts | date and time that the account governance votes for witnesses and proposals will expire | | delayed\_votes |

a JSON array of objects with the following properties:

| | open\_recurrent\_transfers | Number of recurring transfers scheduled for execution | **Notes:** {% hint style="info" %} This table is **not** updated in real-time when an operation involving an account requires its state to be updated. Therefore, there may be a slight difference in the information provided by the blockchain API. {% endhint %} Read [this post](https://peakd.com/hive-167922/@themarkymark/finding-out-how-does-hbd-interest-work-by-reviewing-code) by @themarkymark to learn what `hbd_seconds`and `hbd_seconds_last_update` are and how they are used to compute interests. # Blacklists Blacklists allow anyone to construct a set of blacklisted users and allow each user to use one or more blacklists created by others. Blacklisting an account implies the blacklister thinks the account is doing something wrong, and is intended to be used as a way to warn others that he thinks they should be careful when dealing with that account. #### Columns | Name | Description | | ----------- | ---------------------------- | | blacklister | account owning the blacklist | | blacklisted | account being blacklisted | # BlacklistsFollows Blacklists allow anyone to construct a set of blacklisted users and allow each user to use one or more blacklists created by others. This table contains a list of account following other account's blacklist #### Columns | Name | Description | | --------- | --------------------------------------------------------------------------------------------------- | | account | account following a blacklist | | blacklist | account who created a blacklist (see [Blacklists](/technical-informations/state-tables/blacklists)) | # Comments The Comments table is a non-transactional table and contains all posts and comments and the related information resulting from activity related to posts on the blockchain (updates, votes, ...) #### Columns | Name | Description | | ----------------------------- | ----------------------------------------------------------------------------------------------------------------------- | | author | author of the post or comment | | permlink | permlink of the post or comment | | category | first tag | | parent\_author | parent post or comment author (comment only) | | parent\_permlink | parent post or comment permlink (comment only) | | title | title (post only) | | body | content of the post or comment | | json\_metadata | additional JSON information | | last\_update | last update time | | created | creation time | | active | the last time this post was "touched" by voting or reply | | last\_payout | last payout time | | depth | depth in the comments tree. 0=root post | | children | number of sub comments | | net\_rshares | sum of rshares of all votes | | abs\_rshares | sum of absolute rshares of all votes | | vote\_rshares | sum of all positive rshares from all votes | | cashout\_time | payout time for the post or comment | | max\_cashout\_time | | | total\_vote\_weight | total weight of voting rewards (used to calculate pro-rata share of curation payouts) | | reward\_weight | percentage of reward | | total\_payout\_value | total comment payout received over time, measured in HBD | | curator\_payout\_value | total curator payout received over time, measured in HBD | | author\_rewards | total author payout received over time, measured in VESTS | | net\_votes | total of upvotes - downvotes | | max\_accepted\_payout | HBD value of the maximum payout this post will receive | | percent\_hbd | percentage of HBD to pay, remaining amounts will be received as VESTS | | allow\_votes | allows a post to receive votes | | allow\_curation\_rewards | allows a post to generate curation rewards | | beneficiaries | JSON array of beneficiaries information (see [TxCommentsOptions](/technical-informations/operations/txcommentsoptions)) | | url | front-end relative URL | | root\_title | title of the root post (comments only) | | pending\_payout\_value | pending payout value (in HBD) | | total\_pending\_payout\_value | pending payout value including comments (in HBD) | | active\_votes | JSON array with votes information | | promoted | amout spent for the post promotion (in HBD) | | body\_language | JSON information about post language (posts only) | | body\_length | post or comment length (in charactersàà | # Communities For more information about communities, read [this document](https://gitlab.syncad.com/hive/hivemind/-/blob/master/docs/communities.md). All blockchain operations reference communities by their owner account name, i.e. something like `hive-NNNNNN` where NNNNNN represents the community identifier. That'snot really user-friendly. Moreover, if you want to get communities related information, you have to browse all operations in chronological order to know what happened within each community. Add to this that the community management operations are non-consensual, and therefore not validated by the blockchain. This will put you in front of **a lot of ill-formatted operations** you have to deal with and filter. That's why HiveSQL communities table stores a real-time updated list of all communities and their properties. #### Columns | Name | Description | | ----------- | ----------------------------------------------------------------------------------------------------- | | name | community account | | type | 1=topic 2=journal 3=council | | title | display name of this community | | about | short blurb about this community | | description | a blob of markdown to describe the purpose of the community, enumerate rules, etc. (up to 5000 chars) | | flag\_text | custom text for reporting content | | language | primary language | | nsfw | true if this community is 18+. UI to automatically tag all posts/comments NSFW | # CommunitiesRoles Contains a real-time updated list of all accounts having a specific role or status within a community, whether administrators, moderators or even users who have been muted. {% hint style="warning" %} **Attention:** there is a trick with the last table given how communities work at the blockchain level: if a specific user is missing from the table, it is considered being a ”guest” because an account is only inserted in the table if it is explicitly assigned a role by an admin or moderator! {% endhint %} #### Columns | Name | Description | | --------- | ---------------------------------------- | | community | community account | | account | account with a role within the community | | role | account role within the community | | title | text describing the account role | # CommunitiesSubscribers Contains a real-time updated list of all subscribers for each community. #### Columns | Name | Description | | ---------- | ------------------ | | community | community account | | subscriber | subscriber account | # Delegations While the Hive API makes it easy to know to whom an account is delegating using `condenser_api.get_vesting_delegations`, the opposite is more difficult. There is currently no API call to know who has delegated to an account. Fortunately, HiveSQL allows you to easily retrieve this information thanks to the [TxDelegateVestingShares](/technical-informations/operations/txdelegatevestingshares) table which includes all creation, modification or removal of delegation operations carried out by users. However, the main difficulty comes from the fact that you have to check the last `delegate_vesting_share` operation involving two accounts to get the state of the delegation between these accounts. Due to all the technical reasons mentioned above, retrieving an accurate list of delegators or delegatees has become much more complex and resources consuming. The non-consensus state table Delegations allows you to retrieve delegations data quickly and easily. It contains the list of all active delegations with the following info: #### Columns
NameDescription
NameDescription
delegatorThe account delegating Hive Power
delegateeThe account receiving Hive Power delegation
vestsThe amount of Vesting Shares delegated
# Followers Follow related operations are not associated with a dedicated transaction, they are stored in the blockchain using `custom_json` transactions (see [TxCustoms](/technical-informations/operations/txcustoms)). Storing the details of a "follow" operation in a JSON string is pretty annoying because this requires deserializing the content of the JSON string before you can analyze its contents.\ Even if the SQL server has JSON functions to perform such operation, this will slow down queries as the server has to process every row before being able to filter data. Unfortunately, it is not possible to create an index on values contained in the JSON string. Searching for followers or reblogs is all but efficient, especially when you know that the [TxCustoms](/technical-informations/operations/txcustoms) table contains **several million rows!** Moreover, the format of the JSON string of "follow" operations has changed over time. This has to be taken into account when parsing the data. Writing an efficient query can quickly become cumbersome. The table is a non-transactional table that enables one to know who is following who. It does not store transactions, meaning it does not expose historical data and does not allow one to know when an account started or stopped to follow another account. #### Columns | Name | Description | | --------- | ----------------------------- | | follower | the name of the follower | | following | the name of the followed user | # Mutes Mutes lists allow anyone to construct a set of users and allow each user to use one or more mute lists created by others. Muting an account means one doesn’t want to see the account’s posts and comments. Most frontends honor muting by preventing those posts from being displayed when its users view the site. #### Columns | Name | Description | | ----- | ----------------------------- | | muter | account owning the mutes list | | muted | account being muted | # MutesFollows Mutes lists allow anyone to construct a set of users and allow each user to use one or more mute lists created by others. This table contains a list of account following other account's mutes list #### Columns | Name | Description | | -------- | -------------------------------- | | account | account following a mutes list | | mutelist | account who created a mutes list | # Proposals List of ALL proposal and their data (including deleted ones) #### Columns | Name | Description | | ------------------ | ---------------------------------------------------- | | id | proposal identifier | | creator | account who created the proposal | | receiver | account who will receive the proposal funds | | start\_date | when the proposal start receiving funds if approved | | end\_date | when the proposal stop receiving funds | | daily\_pay | amount requested per day | | daily\_pay\_symbol | "HBD" | | subject | a short description | | permlink | a permlink to a post describing the proposal | | timestamp | creation time | | deleted | True if the proposal has been removed or is expired. | # ProposalsApprovals The table is a non-transactional table that enables one to know who is supporting which proposal. It does not store transactions, meaning it does not expose historical data and does not allow one to know when an account started or stopped to support a proposal. | Name | Description | | ------------ | ------------------------------- | | proposal\_id | proposal identifier | | voter | account supporting the proposal | # RCDelegations Although the Hive API generally allows you to retrieve information from the blockchain, there is no API call to easily know who has delegated RCs to whom. Fortunately, HiveSQL allows you to retrieve related information thanks to the [TxCustoms](/technical-informations/operations/txcustoms) table which includes all creation, modification or removal of RC delegation operations carried out by users. However, the main difficulty comes from the fact that you have to filter custom\_json operations, parse the JSON payload and perform computations with the retrieved operation to get the state of the delegation between accounts. Due to all the technical reasons mentioned above, retrieving an accurate list of delegators or delegatees has become much more complex and resources consuming. The non-consensus state table RCDelegations allows you to retrieve delegations data quickly and easily. It contains the list of all active delegations with the following info: #### Columns
NameDescription
NameDescription
delegatorThe account delegating Hive Power
delegateeThe account receiving Hive Power delegation
rcThe amount of RCs delegated
# Reblogs Reblog related operations are not associated with a dedicated transaction, they are stored in the blockchain using `custom_json` transactions (see [TxCustoms](/technical-informations/operations/txcustoms)). Storing the details of a "reblog" operation in a JSON string is pretty annoying because this requires deserializing the content of the JSON string before you can analyze its contents.\ Even if the SQL server has JSON functions to perform such operation, this will slow down queries as the server has to process every row before being able to filter data. Unfortunately, it is not possible to create an index on values contained in the JSON string. Searching for reblogs is all but efficient, especially when you know that the [TxCustoms](/technical-informations/operations/txcustoms) table contains **several million rows**! Moreover, the format of the JSON string of "reblog" operations has changed over time. This has to be taken into account when parsing the data. Writing an efficient query can quickly become cumbersome. The table is a non-transactional table that enables one to know who has reblogged which post. It does not store transactions, meaning it does not expose historical data and does not allow to know when an account reblogged a post or removed the reblog. #### Columns | Name | Description | | --------- | -------------------------------- | | account | account doing a reblog | | author | author of the reblogged post | | permlink | permlink of the reblogged post | | timestamp | when the post has been reblogged | # Tags This table stores all the tags of all the posts published. #### Columns | Name | Description | | ------------ | ------------------------------------------------------------------------------------------------------------------------------------ | | `comment_id` | a foreign key containing the ID of the post in the Comments table. (see [TxComments](/technical-informations/operations/txcomments)) | | `tag` | one of the tags used to publish the post | #### Query example To retrieve all posts related to a specific tag, for example *cats*, you can issue the following SQL query: ``` SELECT Comments.author, Comments.permlink FROM Tags INNER JOIN Comments ON Tags.comment_id = Comments.ID WHERE Tags.tag = 'cats' ``` # Witnesses The Witnesses table is a non-transactional table that contains a list of all witnesses and related information. The table content is updated every witness round (i.e. every 63 seconds as there are 21 witnesses producing a block every 3 seconds in each round) #### Columns | Name | Description | | ---------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | name | Account name of the witness | | votes\_count | Number of votes the witness received | | url | The URL of the witness presentation post | | votes | Total amount of VEST from voters | | total\_missed | Number of blocks missed | | last\_aslot | This value indicates when the witness was last scheduled for block production | | last\_confirmed\_block\_num | Block number of the last block signed by the witness | | signing\_key | Current signing key use by the Witness. A value of `STM1111111111111111111111111111111114T1Anm` means the witness has been deactivated and will no more be scheduled for block production | | account\_creation\_fee | Proposed cost for the creation of a new account | | account\_creation\_fee\_symbol | HIVE | | maximum\_block\_size | Proposed maximum block size. The greater, the more information and transactions the blockchain can store in each block | | hbd\_interest\_rate | Proposed interest rate to reward users holding HBD | | hbd\_exchange\_rate\_base | Proposed cost in HBD to buy 1 HIVE | | hbd\_exchange\_rate\_base\_symbol | HBD | | hbd\_exchange\_rate\_quote | Proposed value for the ratio between HBD and HIVE for rewards | | hbd\_exchange\_rate\_quote\_symbol | HIVE | | last\_hbd\_exchange\_update | Last time the witness updated its price feed | | running\_version | Current version of the witness node | | hardfork\_version\_vote | Current version of the hardfork supported by the witness | | hardfork\_time\_vote | Time of vote from the witness for the latest supported hardfork | --- [Next Page](/llms-full.txt/1)