Blocks and Transactions
Last updated
Last updated
This document describes the block and transaction structure of the Cronos POS Chain and explains different ways to extract and parse the details of them.
This API returns block details, a list of transaction bytes and consensus commits.
This API returns the events of the block. These events include the outcomes from transactions, and block changes such as block rewards minted ("mint") and distributed as well as consensus state updates such as validator missing block counts ("liveness")
This API returns the parsed transaction details and events of a particular transaction hash
This API support event-based query and returns parsed transactions. Common events include:
tx.height
Transaction(s) in a particular block
message.module & message.action
Search for messages belonged to a particular module and actions. Note that this index will degrade when more transaction of its kind grows in number
message.sender
Search for message with particular signer
Note:
The API supports pagination, make sure you have iterate all the pages pagination.offset=[offset starting from 0]&pagination.limit=[record per page]
The performance will degrade if you are searching for a result set that will grow over time. For example, if we search for events that grow with the block height, such as validator's reward distrubtion.
Multiple events in a single search are queried by AND condition. i.e If you do tx.height and message.sender. It will search for transactions that happened on that particular block height AND signed by the sender.
Note that when you integrate with the API you should still base64 decode the attributes programmatically.
To get the minted token every block:
Base64Decode(result.begin_block_events[event_index].attributes[attribute_index].value)
where
Base64Decode(result.begin_block_events[event_index].type) === "mint" && Base64Decode(result.begin_block_events[event_index].attributes[attribute_index].key) === "amount"
In every block, mint tokens and transaction fees are distributed to every active validator in the network. As a result, there will be multiple events, each corresponding to a validator and the rewards it receives.
To get the reward per validator:
Validator Address
Base64Decode(result.begin_block_events[event_index].attributes[attribute_index].value)
where
Base64Decode(result.begin_block_events[event_index].type) === "rewards" && Base64Decode(result.begin_block_events[event_index].attributes[attribute_index].key) === "validator"
Reward Amount
Base64Decode(result.begin_block_events[event_index].attributes[attribute_index].value)
where
Base64Decode(result.begin_block_events[event_index].type) === "rewards" && Base64Decode(result.begin_block_events[event_index].attributes[attribute_index].key) === "amount"
String
Validator Address
Base64Decode(result.begin_block_events[event_index].attributes[attribute_index].value)
where
Base64Decode(result.begin_block_events[event_index].type) === "proposer_reward" && Base64Decode(result.begin_block_events[event_index].attributes[attribute_index].key) === "validator"
Reward Amount
Base64Decode(result.begin_block_events[event_index].attributes[attribute_index].value)
where
Base64Decode(result.begin_block_events[event_index].type) === "proposer_reward" && Base64Decode(result.begin_block_events[event_index].attributes[attribute_index].key) === "amount"
String
To get the commission received by each validator:
Validator Address
Base64Decode(result.begin_block_events[event_index].attributes[attribute_index].value)
where
Base64Decode(result.begin_block_events[event_index].type) === "rewards" && Base64Decode(result.begin_block_events[event_index].attributes[attribute_index].key) === "validator"
Commission Amount
Base64Decode(result.begin_block_events[event_index].attributes[attribute_index].value)
where
Base64Decode(result.begin_block_events[event_index].type) === "rewards" && Base64Decode(result.begin_block_events[event_index].attributes[attribute_index].key) === "amount"
String
There are mainly two types of assets and amount representation:
This is commonly seen in staking module but may appear in other modules as well. It represents a single token type.
Example
where denom is the asset type and amount is the amount and basecro is the basic unit of CRO token (where 10^8 basecro = 1 cro)
This is commonly seen in most message types. It represents a list of tokens.
Example:
This is commonly seen in events' attributes of block and transaction.
Example:
Descriptions: Simple transfer message
Funds movement: Yes
Transaction Type
tx.body.messages[message_index]["@type"] === "/cosmos.bank.v1beta1.MsgSend"
String
From address
tx.body.messages[message_index].from_address
String
To address
tx.body.messages[message_index].to_address
String
Amount
tx.body.messages[message_index].amount
Descriptions: Multiple inputs, multiple outputs transfer message.
Funds movement: Yes
Transaction Type
tx.body.messages[message_index]["@type"] === "/cosmos.bank.v1beta1.MsgMultiSend"
String
From Addresses
tx.body.messages[message_index].inputs[m].address where m>=1. There can be multiple (m) from addresses.
String
From Amounts
tx.body.messages[message_index].inputs[m].coins where m>=1. There can be multiple (m) from addresses and their corresponding input amount.
To Addresses
tx.body.messages[message_index].outputs[n].address where n>=1. There can be multiple (n) destination addresses.
String
To Amounts
tx.body.messages[message_index].outputs[n].coins where n>=1. There can be multiple (n) destination addresses and their corresponding input amount.
Descriptions: Sets the withdraw address for a delegator (or validator self-delegation)
Funds movement: No (Pay for fee only)
TODO
Descriptions: Withdraw delegation rewards from a single validator
Funds movement: Yes
Transaction Type
tx.body.messages[message_index]["@type"] === "/cosmos.distribution.v1beta1.MsgWithdrawDelegatorReward"
String
Delegator
tx.body.messages[message_index].delegator_address
String
Withdraw From Validator
tx.body.messages[message_index].validator_address
String
Withdraw To Address
tx_response.logs[message_index].events[event_index].attributes[attribute_index].value
where
tx_response.logs[message_index].events[event_index].type === "transfer" && tx_response.logs[message_index].events[event_index].attributes[attribute_index].key === "recipient".
String
Withdraw Reward Amount
tx_response.logs[message_index].events[event_index].attributes[attribute_index].value
where
tx_response.logs[message_index].events[event_index].type === "transfer" && tx_response.logs[message_index].events[event_index].attributes[attribute_index].key === "amount".
Descriptions: : Withdraws the full commission of a validator to the validator creator (initial delegator) address.
Funds movement: Yes
Message Index: 1
This transaction will trigger an internal transfer from the "Distribution" module account to the withdraw to address. Note that the "Distribution" module account is an internal account in Cronos POS Chain to hold the rewards, commissions and community pool funds before they are being distributed.
Transaction Type
tx.body.messages[message_index]["@type"] === "/cosmos.distribution.v1beta1.MsgWithdrawValidatorCommission"
String
Validator
tx.body.messages[message_index].validator_address
String
Withdraw From Validator
tx.body.messages[message_index].validator_address
String
Withdraw To Address
tx_response.logs[message_index].events[event_index].attributes[attribute_index].value
where
tx_response.logs[message_index].events[event_index].type === "transfer" && tx_response.logs[message_index].events[event_index].attributes[attribute_index].key === "recipient".
String
Withdraw Commission Amount
tx_response.logs[message_index].events[event_index].attributes[m].value
where
tx_response.logs[message_index].events[event_index].type === "transfer" && tx_response.logs[message_index].events[event_index].attributes[attribute_index].key === "amount".
Descriptions: : Fund from an account to the community pool. The community pool can later be sent to another by submitting a MsgSubmitEcProposal
Funds movement: Yes
This transaction will initiate a transfer from an account to the "Distribution" module account. Note that the "Distribution" module account is an internal account in Cronos POS Chain to hold the rewards, commissions and community pool funds before they are being distributed.
Transaction Type
tx.body.messages[message_index]["@type"] === "/cosmos.distribution.v1beta1.MsgFundCommunityPool"
String
Deposit From Account
tx.body.messages[message_index].depositor
String
Deposit Amount
tx.body.messages[message_index].amount
Delegate To Address ("Distribution" module account)
tx_response.logs[message_index].events[event_index].attributes[attribute_index].value
where
tx_response.logs[message_index].events[event_index].type === "transfer" && tx_response.logs[message_index].events[event_index].attributes[attribute_index].key === "recipient".
String
Descriptions: : Create a new validator
Funds movement: Yes
Transaction Type
tx.body.messages[message_index]["@type"] === "/cosmos.staking.v1beta1.MsgCreateValidator"
String
Initial Delegator Address (Validator Creator)
tx.body.messages[message_index].delegator_address
String
Delegated Amount
`tx.body.messages[message_index].value
Descriptions: Edit and existing validator
Funds Movement: No (Pay for fee only)
TODO
Descriptions: Perform a delegation of coins from a delegator to a validator
Funds movement: Yes
Transaction Type
tx.body.messages[message_index]["@type"] === "/cosmos.staking.v1beta1.MsgDelegate"
String
Delegate From Address
tx.body.messages[message_index].delegator_address
String
Delegate To Validator
tx.body.messages[message_index].validator_address
String
Delegate Amount
tx.body.messages[message_index].amount
Descriptions: Perform a redelegation of coins from a delegator and source validator to a destination validator.
Note that the redelegation is just a record update of the internal state of a delegator's staked funds. The delegator account won't have any funds movement based on the redelegation except.
There is a side effect of MsgBeginRedelegate, upon successful execution of this message, all the rewards of the delegator from the previous (source) validator will be withdrawn automatically to the delegator account.
Funds movement: Yes
Transaction Type
tx.body.messages[message_index]["@type"] === "/cosmos.staking.v1beta1.MsgBeginRedelegate"
String
Redelegate From Address
tx.body.messages[message_index].delegator_address
String
Redelegate From Validator
tx.body.messages[message_index].validator_src_address
String
Redelegate To Validator
tx.body.messages[message_index].validator_dst_address
String
Redelegate Amount
tx.body.messages[message_index].amount
Auto Withdraw Rewards To Address #
tx_response.logs[message_index].events[event_index].value
where
tx_response.logs[message_index].events[event_index].type === "transfer" && tx_response.logs[message_index].events[event_index].attributes[attribute_index].key === "recipient".
String
Auto Withdraw Rewards From Address (Always the "distribution" module account) #
tx_response.logs[message_index].events[event_index].value
where
tx_response.logs[message_index].events[event_index].type === "transfer" && tx_response.logs[message_index].events[event_index].attributes[attribute_index].key === "sender".
String
Auto Withdraw Rewards Amount #
tx_response.logs[message_index].events[event_index].value
where
tx_response.logs[message_index].events[event_index].type === "transfer" && tx_response.logs[message_index].events[event_index].attributes[attribute_index].key === "amount".
String
Descriptions: Perform an undelegation from a delegate and a validator.
Funds movement: Yes
Transaction Type
tx.body.messages[message_index]["@type"] === "/cosmos.distribution.v1beta1.MsgFundCommunityPool"
String
Undelegate From Address
tx.body.messages[message_index].delegator_address
String
Undelegate From Validator
tx.body.messages[message_index].validator_src_address
String
Undeleate Amount
tx.body.messages[message_index].amount
Auto Withdraw Rewards To Address #
tx_response.logs[message_index].events[event_index].value
where
tx_response.logs[message_index].events[event_index].type === "transfer" && tx_response.logs[message_index].events[event_index].attributes[attribute_index].key === "recipient".
String
Auto Withdraw Rewards From Address (Always the "distribution" module account) #
tx_response.logs[message_index].events[event_index].value
where
tx_response.logs[message_index].events[event_index].type === "transfer" && tx_response.logs[message_index].events[event_index].attributes[attribute_index].key === "sender".
String
Auto Withdraw Rewards Amount #
tx_response.logs[message_index].events[event_index].value
where
tx_response.logs[message_index].events[event_index].type === "transfer" && tx_response.logs[message_index].events[event_index].attributes[attribute_index].key === "amount".
String
Descriptions: The undelegation is completed on the first block after the "Unbond Completion Time", in which there will be a special event in the Tendermint Block Results API.
Funds movement: Yes
Undelegate From Validator
.result.end_block_events[event_index].attributes[attribute_index].value
where
.result.end_block_events[event_index].type === "complete_unbonding" && .result.end_block_events[event_index].attributes[attribute_index].key === "validator".
String
Undelegate To Address
.result.end_block_events[event_index].attributes[attribute_index].value
where
.result.end_block_events[event_index].type === "complete_unbonding" && .result.end_block_events[event_index].attributes[attribute_index].key === "delegator".
String
Undeleate Amount
.result.end_block_events[event_index].attributes[attribute_index].value
where
.result.end_block_events[event_index].type === "complete_unbonding" && .result.end_block_events[event_index].attributes[attribute_index].key === "amount".
Descriptions: : Unjail a validator
Funds movement: No (Pay for fee only)
TODO
A validator can get jailed for two reasons:
Liveness
Double sign
Liveness issue occurs when the validator fails to sign 50%* of the blocks in a 5000# blocks sliding window.
Upon a validator committing a liveness issue, the validator is jailed for 24 hours (85400 seconds#).
Double sign occurs when a validator attempts to provide multiple signatures of the same block height.
This is considered as a serious fault and upon committing the validator will get jailed forever and get slashed for 5% of the total staking#.
This slashing is applied to all the delegations (both self delegation and delegation from other accounts).
There is a limitation in the protocol that the slashing amount cannot be easily extracted right now. Theoretically one could calculate the slashed amount of each delegator by applying the slash rate and delegation proportion but in practice small precision issues may be introduced in the calculation process and introduce discrepancies with the chain, so it is not recommended to do so.
On the other hand, the slashed amount, similar to the block rewards and commission, is not deducted from delegator account directly. There are events to signal the jail and slashing occurs but it serve more of the purpose of describing such as event occurs only.
Signing window size (in Blocks)
Liveness
.params.signed_blocks_window
String
Minimum # of blocks to sign in the window
Liveness
.params.min_signed_per_window
String
How long to jail
Liveness
.params.downtime_jail_duration
String (Duration)
Slashing ratio
Liveness
.params.slash_fraction_downtime
String
Slashing ratio
Double Sign
.params.slash_fraction_double_sign
String
Jail
Liveness, Double Sign
.results.begin_block_events[event_index].type === "slash" && Base64Decode(.results.begin_block_events[event_index].attributes[attribute_index].key) === "jailed"
Assertion
Jailed Reason
Liveness
Base64Decode(.results.begin_block_events[event_index].attributes[attribute_index].value === "missing_signature"
where
.results.begin_block_events[event_index].type === "slash" && Base64Decode(.results.begin_block_events[event_index].attributes[attribute_index].key) === "reason"
String
Jailed Reason
Double Sign
Base64Decode(.results.begin_block_events[event_index].attributes[attribute_index].value === "double_sign"
where
.results.begin_block_events[event_index].type === "slash" && Base64Decode(.results.begin_block_events[event_index].attributes[attribute_index].key) === "reason"
String
Jailed Validator Address
Liveness, Double Sign
Base64Decode(.results.begin_block_events[event_index].attributes[attribute_index].value)
where
.results.begin_block_events[event_index].type === "slash" && Base64Decode(.results.begin_block_events[event_index].attributes[attribute_index].key) === "jailed"
String
Slashed Validator Address
Liveness, Double Sign
Base64Decode(.results.begin_block_events[event_index].attributes[attribute_index].value)
where
.results.begin_block_events[event_index].type === "slash" && Base64Decode(.results.begin_block_events[event_index].attributes[attribute_index].key) === "address"
String
Liveness Event Example
Double Sign Event Example
Submit proposal
Initial deposit will transfer from the proposer account to the "gov" module account.
Funds movement: Yes
Transaction Type
tx.body.messages[message_index]["@type"] === "/cosmos.gov.v1beta1.MsgSubmitProposal"
String
Deposit From Address
tx.body.messages[message_index].porposer
String
Deposit Amount
tx.body.messages[message_index].initial_deposit
After a proposal of this kind is passed, it will release the funds to the grants recipient account.
Proposal Type
tx.body.messages[message_index].content["@type"] === "/cosmos.distribution.v1beta1.CommunityPoolSpendProposal"
String
Grants Recipient Address
tx.body.messages[message_index].conbtent.recipient
String
Spend Amount
tx.body.messages[message_index].content.amount
Example of Community Pool Spend Proposal transaction:
Proposal Passed
Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].value) === "proposal_passed"
where
.result.end_block_events[event_index].type === "active_proposal" && Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].key) === "proposal_result".
String
Grant from "distribution" Module Account
Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].value) === "{distribution module account}"
where
.result.end_block_events[event_index].type === "transfer" && Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].key) === "sender".
String
Recipient Account
Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].value)
where
.result.end_block_events[event_index].type === "transfer" && Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].key === "recipient").
String
Grants Amount
Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].value)
where
.result.end_block_events[event_index].type === "transfer" && Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].key === "amount").
Example of Block Results API when Community Pool Spend Proposal Funds is Released:
Descriptions: Submit a deposit to an existing proposal
Deposit will transfer from the proposer account to the "gov" module account.
Transaction Type
tx.body.messages[message_index]["@type"] === "/cosmos.gov.v1beta1.MsgDeposit"
String
Deposit From Address
tx.body.messages[message_index].depositor
String
Deposit Amount
tx.body.messages[message_index].amount
If a proposal does not meet the deposit requirement after the deposit period, the deposit will NOT be returned to the depositors. Those deposits will be burnt from the "gov" module account as well.
To monitor a proposal becomes inactive, it can be detected by monitoring the end_block_events in Tendermint Block Results API. However, for the amount of deposit burnt, you have to keep track of the deposits made to the proposal before. Note that this operation does not involve any user account as the deposits are burnt.
Proposal Id
Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].value) === "{gov module account}"
where
.result.end_block_events[event_index].type === "inactive_proposal" && .result.Base64Decode(end_block_events[event_index].attributes[attribute_index].key) === "proposal_id".
String
Assert Proposal is Dropped
Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].value === "proposal_dropped")
where
.result.end_block_events[event_index].type === "inactive_proposal" && Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].key === "proposal_result").
String
The return deposit can be detected by monitoring the end_block_events in Tendermint Block Results API.
Return From "gov" Module Account
Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].value) === "{gov module account}"
where
.result.end_block_events[event_index].type === "transfer" && Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].key) === "sender".
String
Return To Address
Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].value)
where
.result.end_block_events[event_index].type === "transfer" && Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].key) === "recipient".
String
Returned Deposit Amount
Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].value)
where
.result.end_block_events[event_index].type === "transfer" && Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].key === "amount").
Note that there may be multiple depositors of a proposal, so the event may appear multiple times.
If a proposal does not get enough votes that exceed the "quorum" or has the "No with Veto" votes exceed the "veto_threshold", the deposit will NOT be returned to the depositors. Those deposits will be burnt from the "gov" module account as well.
However, for the amount of deposit burnt, you have to keep track of the deposits made to the proposal before. Note that this operation does not involve any user account as the deposits are burnt.
Proposal Id
Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].value) === "{gov module account}"
where
.result.end_block_events[event_index].type === "active_proposal" && .result.Base64Decode(end_block_events[event_index].attributes[attribute_index].key) === "proposal_id".
String
Assert Proposal is Rejected
Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].value === "proposal_rejected")
where
.result.end_block_events[event_index].type === "active_proposal" && Base64Decode(.result.end_block_events[event_index].attributes[attribute_index].key === "proposal_result").
String
Tendermint Block Results API JSON Example (Base64 Decoded):
Descriptions: : Submit a vote to an existing proposal
Funds movement: No (Pay for fee only)
All voter has no staked coins
Rejects
No
Not enough tally_params.quorum of votes
Rejects
Yes
No one votes (Everyone abstain)
Rejects
No
More than tally_params.veto_threshold voter veto
Rejects
Yes
More than tally_params.threshold non-abstaining votes No
Rejects
No
More than tally_params.threshold non-abstaining votes Yes
Passes
No
More than tally_params.threshold non-abstaining votes Yes but the proposal cannot be executed (e.g. Insufficient funds in community pool to spend)
Failed
No
mint
fee_collector
distribution
bonded_tokens_pool
not_bonded_tokens_pool
gov
URL format: [height]
Example: Checking the block at height 10000 of the mainnet:
URL format: [height]
Example: Checking the block result of height 10000of the mainnet:
URL format: [Transaction_Hash]
Example:
URL format:
Most of the block events can be accessed using the . One caveat of using this API is that all the events key-value attributes are base64 encoded. Therefore it is non-human readable.
A simple Node.js tool has been written to help parse and decode all key-value attributes in the block results API response. It can be downloaded at .
In every block, CRO is minted and offered to the active validators and their delegators as block rewards. The actual minted token is subject to inflation and is adjusted every block. Further details on the minting parameters and configuration can be found .
Minted tokens are distributed as blocks and proposer rewards in the same block. However, since Cosmos SDK does the , the minted tokens are first sent to the "Distribution" module account and are later transferred to an account when a delegator withdraws the rewards or commissions by sending a or .
So , and events are for record-keeping only and do not represent any actual token transfer between accounts.
Block rewards are not credited to the delegator account directly. This event serves as a record-keeping purpose only. Each delegator account must explicitly send a message transaction to collect the rewards.
Block proposers can get extra transaction fees bonus for the block they have successfully proposed. More details can be found for reference.
Similar to block rewards, proposer rewards are not credited to the account directly. This event serves as a record-keeping purpose only. Each validator creator account must explicitly send a message transaction to collect the rewards.
Validator can charge a commission to the block rewards received by delegators. Commissions is already included in and
Similar to block rewards, commission rewards are not credited to the account directly. This event serves as a record-keeping purpose only. Each validator creator account must explicitly send a message transaction to collect the rewards.
: result.block.header.height
: result.height
: tx_response.height
: tx_response[index].height
: Uppercase(SHA256(Base64Decode(result.block.data.txs[index])))
: Not available, should use . Match transaction [index] in result.txs_results with result.block.data.txs[index]
: tx_response.txhash
: tx_response[index].txhash
: tx.auth_info.fee.amount
: tx[index].auth_info.fee.amount
Transaction fee is an , meaning that a transaction can pay fee in more than one token types.
Note that the amount is always in string for precision accuracy. Please make sure your language is capable of handling big integer numbers. It is highly recommended to use library similar to in your language to handle the amount.
At the time of writing, there will only be a single entry in this array because basecro (or basetcro in Croeseid Testnet) is the only supported asset on Cronos POS Chain. However, after IBC transfer and other coins issuance methods are enabled, there will be more asset types, the coin source tracing and their denomination can be found
Each object in the array has the same format as .
Cosmos Transaction Query API:
Cosmos Transaction Query API:
Cosmos Transaction Query API:
Cosmos Transaction Query API:
Cosmos Transaction Query API:
The "Distribution" module account is different on different chain. In Cronos POS Chain Mainnet, it is .
This "Distribution" module account is different on different chain. In Cronos POS Chain Mainnet, it is .
Cosmos Transaction Query API:
Cosmos Transaction Query API:
Cosmos Transaction Query API:
Cosmos Transaction Query API:
Note that the funds are moved between module accounts upon a MsgUndelegate message execution. The funds movement to the user account happens only when the unbond completes. For details, you can refer to the .
Cosmos Transaction Query API:
Tendermint Block Results API:
Cosmos Transaction Query API:
# The liveness metrics and the penalty are subject to the network parameters to be explained in the
# The slashing rate is subject to the network parameters to be explained in the
Cosmos Slashing Params API:
Tendermint Block Results API: =[height]
You can use the to decode the event details for readability during integration.
Liveness Example:
Double Sign Example:
Cosmos Transaction Query API:
One sub-type of proposal is to spend community pool. The community has to pre-funded using .
Cosmos Transaction Query API:
The latest deposit requirement ("min_deposit") and deposit period ("max_deposit_period") can be checked on . Note that they are network parameters and may change over time after governance proposals.
Tendermint Block Results API:
There are a few cases where a proposal deposit will be returned to the depositors. For details, please refer to .
Tendermint Block Results API:
There are a few cases where proposal deposits will be burnt. For details, please refer to for more details.
To monitor a proposal that got rejected and deposits got burned, it can be detected by monitoring the end_block_events Tendermint Block Results API. There will be a "proposal_result" event marking the proposal as rejected, and different from , there will be NO transfer event in the end_block_results, which means the deposit is NOT returned and is burnt.
Latest tally params can be retrieved from: . The params may change from time to time after the governance proposal.