The hardfork 25 (codename Equilibrium) should be activated in a few weeks. With these harfork will come many changes in the blockchain data which must obviously be passed on to HiveSQL.
Therfore HiveSQL has undergo a lot of updates to be prepared to the new specs and configuration of the blockchain after the hardfork.
Of course, all of these changes have been implemented in such a way as to minimize the impact on users, apps and processes relying on HiveSQL, which means... they shouldn't be affected at all!
Here is the list of all these changes.
Two new operation tables and height virtual operation tables have been created to store the new virtual operations data.
The collateralized_convert operation is similar to the convert operation and instructs the blockchain to convert HIVE to HBD. The operation is performed after a 3.5 days delay, but the owner gets HBD immediately. The price risk is cushioned by extra HIVE. After actual conversion takes place the excess HIVE is returned to the owner.
| Column | Description |
|---|---|
| owner | The account requesting the conversion |
| requestid | A request identifier |
| amount | The amount of HIVE to convert |
| amount_symbol | HIVE |
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 the 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.
| Column | Description |
|---|---|
| from | Account to transfer an asset from |
| to | Account to transfer an asset to |
| amount | The amount of asset to transfer |
| amount_symbol | The symbol of the 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 |
This virtual operation is issued each time a new account has been successfully created.
| Column | 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 |
This virtual operation is issued when the blockchain effectively changes the recovery account of an account after it issued such a request.
| Column | Description |
|---|---|
| account | account who changed its recovery account |
| old_recovery_account | old recovery account |
| new_recovery_account | new recovery account |
This virtual operation is issued when a vote on a post or comment becomes effective.
| Column | 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. It is used to calculate the pro-rata share of curation payouts |
| pending_payout | potential payout of related comment at the moment of this vote |
| pending_payout_symbol | HBD |
This virtual operation is issued when governance votes for an account have expired and are removed.
| Column | Description |
|---|---|
| account | Account for who governance votes have expired |
This virtual operation is issued when a recurrent transfer has failed to be executed.
| Column | Description |
|---|---|
| from | Account to transfer an asset from |
| to | Account to transfer an asset to |
| amount | The amount of asset to transfer |
| amount_symbol | The symbol of the asset to transfer |
| memo | |
| 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 |
This virtual operation is issued when a HIVE to HBD conversion is completed.
| Column | Description |
|---|---|
| owner | Account requesting the conversion |
| requestid | conversion request identifier |
| amount_in | Amount of hive to be converted |
| amount_in_symbol | HIVE |
| amount_out | Amount of HBD to be received |
| amount_out_symbol | HBD |
| excess_collateral | excess HIVE returned to the owner |
| excess_collateral_symbol | HIVE |
This virtual operation is issued when a recurrent transfer is executed.
| Column | 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 |
This virtual operation is issued when a power-up is finally taken into account for governance votes.
| Column | 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 |
The HiveSQL documentation has been updated accordingly and can be viewed at https://docs.hivesql.io
If you have any questions or remarks, support is provided on the HiveSQL Discord Channel.
Thank you.
Vote for the proposal on Ecency Vote for the proposal using HiveSigner |
