As discussed inside forbole/juno#5, particularly here, we should track how average block time changes over time.

For this reason, we should create three different tables:

CREATE TABLE average_block_time_per_minute 
(
  average_time DECIMAL NOT NULL, 
  timestamp TIMESTAMP WITHOUT TIMEZONE NOT NULL
);

CREATE TABLE average_block_time_per_hour
(
  average_time DECIMAL NOT NULL, 
  timestamp TIMESTAMP WITHOUT TIMEZONE NOT NULL
);

CREATE TABLE average_block_time_per_day
(
  average_time DECIMAL NOT NULL, 
  timestamp TIMESTAMP WITHOUT TIMEZONE NOT NULL
);

Each of these tables should be updated every time a new block is created. Particularly, here are how values should be computed.

average_block_time_per_minute

average_time = (BlockTime - PreviousMinuteBlockTime) / (BlockHeight - PreviousMinuteBlockHeight)

average_block_time_per_hour

average_time = (BlockTime - PreviousHourBlockTime) / (BlockHeight - PreviousHourBlockHeight)

average_block_time_per_day

average_time = (BlockTime - YesterdayBlockTime) / (BlockHeight - YesterdayLastBlockHeight)

@kwunyeung can you please confirm this is correct?

Feature description

On the home page UI, we have this section which shows the real time consensus state. This is to show whether the chain is making consensus even if the chain is waiting for blocks.

We will need that data to be provided by the GraphGL endpoint.

Implementation proposal

The data can be captured by this Tendermint RPC endpoint.

http://rpc.morpheus.desmos.network:26657/consensus_state

As most of the time the consensus will be made if the the prevotes are enough for making consensus (assuming precommits will be the same as the prevotes), we can just get the voted percentage in the prevotes_bit_array.

The values here mean voting power 99924 out of total 160299 has voted which is around 62%.

@RiccardoM @ryuash

Feature description

Show all message json types so the UI can reference and adjust according to message type

Bug description

in gov/MsgHandler there is no msg passing in and all gov modules message cannot be parsed at the moment.

The total amount of staked tokens can be queried by

http://lcd.cosmoshub.bigdipper.live/staking/pool

which will provide us the staking ratio as it has the number of bonded and unbonded tokens.

I would like to store the staked tokens with historical data so that we can plot graph over time. The following screen shows that we will have the graph for "Online Voting Power" which refers to the change of staked tokens over time.

https://xd.adobe.com/view/53042c53-f384-451e-7cee-e0da21dabd79-2535/screen/a841230f-7490-4652-bcbc-4768948daee9/1-1-overview-dropdown

In the current implementation, I already have this.

The number of staking tokens will be updated every 15s. 0 min every hour and midnight every day, the backend will make a snapshot so that users can switch to see the staking information before. Actually the data we have acquired in the current implementation already enough for us to plot graphs in voting power vs time with scale in 15s, 1h and 1d.

@kwunyeung inside the requirements we have

Calculate validator self delegation ratio (staking)

Looking at the x/staking API the best one seems to be /staking/validators?height=446016:

http://lcd.morpheus.desmos.network:1317/staking/validators?height=446016

For each validator, what I suppose we should do to compute the self delegation ratio is:

self_delefation_ration = tokens / delegator_shares * 100

Is this correct?

Feature description

There should be some function on test cases in the cosmos SDK which we can do test cases on a dummy chain maybe?

There is only one row on consensus table and it never updates.
```
"height": 1761,
"round": 0,
"step": "RoundStepPrevote"

That is currently no data is capture in the database after x/inflation is enabled

Problem definition

I was going through the different requirements that should be satisfied properly, in particular the ones that regard the staking module.

While doing so, I've noticed there are currently two ways of getting the following set of information:

• Update validator information
• Calculate validator voting power percentage
• Calculate validator self delegation ratio
• Update the total staked tokens

Solutions

1. Read the per-block state

The first thing that came into my mind was:

Ok, to do so we can simply query the x/staking LCD endpoints and get the returned values. This way we will be able to get all the info we need.

This can be achieved using the following endpoints:

• /staking/validators/{address}
• /staking/validators/{address}/delegations

The problem with this approach is that if you use those endpoints without any additional parameter, they will always returns the latest block state.

To solve this, you can use the ?height= parameter at the end of the endpoint, specifying the block height. However, this only works for all heights if the fullnode on which the LCD relies has been started in archive mode and thus stores all the blocks information. Otherwise, if the fullnode has not started in such mode, the following error will be returned when querying too-old blocks states:

{
  "error": "invalid request: failed to load state at height <height>; version does not exist (latest height: <latest_height>)"
}

Also, the downside of this approach is that you need to perform a lot of LCD queries (namely, 2 per validator, per block) to get all the data you need.

2. Rely on messages parsing

The alternative to the above explained approach is to handle data set changes the same way that DJuno does: parsing different messages.

Following this approach, we will store the data only when it is effectively changed, instead that on a per-block basis.

The problem with this way of doing is that continuously changing data (i.e. validators/delegators rewards) would never be updated.

In order to solve this problem, what we can do is subscribe to events using the Tendermint websocket. Such events should include everything that we need. As an example, here you can see the x/distribution events including the rewards ones.

Conclusions

I'd like to know @kwunyeung what you think is best.

I personally think that approach number 2 would create a much more efficient code since there are no doubled queries of sort.

Implementation proposal

We can store current average block time for each block and do calculation on the next block time on database side.

Feature description

There should be a view set on the database side that gets all data needed for the main page other pages on big dipper so that no need to write a long query in Hasura.

Implementation proposal

Implement views statements in the schema.

How do i query this?
Correct me if i'm wrong but would i..
query the voting power by height and each time there is a change find the transaction that caused it?

Feature description

Let me know if this idea is even realistic.

Currently all messages returns a self delegate address for all parties involved. Because they are self delegates there is no sure way to know if the user is also a validator unless another query is called to check. Out of all the checks approximately only 30% or less will hold a validator identity.

{
    "timestamp": "2020-10-10T18:08:07",
    "hash": "87CFD8594E65ABFBA58F49B2D7F05C97C7C8A28B75D51CEBF53BB0D33D4274B0",
    "height": 67144,
    "memo": "Welcome, to the real world...😎",
    "messages": [
      {
        "type": "cosmos-sdk/MsgSend",
        "value": {
          "amount": [
            {
              "denom": "udaric",
              "amount": "10000000"
            }
          ],
          "to_address": "desmos168wz6xz6tnzvl2qwee264x0x9sr8yz0vtkp2cj",
          "from_address": "desmos1dzn2s7l0wm9kekyazcnhapu8j95n90efmcmrad"
        }
      }
    ]
  }

Implementation proposal

Add an aggregation to return all validators involved in the transaction.

ex:

{
  ..tx stuff,
  validators: [
    identity
    moniker
    validator_address
  ]
}

@kwunyeung Inside the requirements we find

Calculate validator voting power percentage (staking)

I've seen that the validator voting power can be fetched using the /validatorsset/latest API:

http://lcd.morpheus.desmos.network:1317/validatorsets/latest

Is this sufficient or should it be fetched in another way?

Bug description

Some of the account from the genesis file is not on the account table

Feature description

Be able to filter out self delegations within a group of delegations towards a single validator

Implementation proposal

Add a is_self_delegated prop

delegation (where: {is_self_delegated: {_eq: true}}) {
  ...
}

Is https://m1k.gql.morpheus.desmos.network/console still the correct api?

Just to give me a kickstart can you provide me with the follow queries while I slowly figure out the schema?

Latest Height

Validators

Stabilities (ignore this one if the comment below is still valid)

Consensus

Previous Edit (Reference Purposes)

## Average Block Time [OK]

/**
 * Get the average block time from genesis
 */
export const AVERAGE_BLOCK_TIME_FROM_GENESIS_QUERY = gql`
query AverageBlockTimeAllTime{
  average_block_time_from_genesis(limit: 1, order_by: {height: desc}){
    average_time
  }
}`;

/**
 * Get the average block time by last minute
 */
export const AVERAGE_BLOCK_LAST_MINUTE_QUERY = gql`
query AverageBlockTimeLastMinute{
  average_block_time_per_minute(limit: 1, order_by: {height: desc}){
    average_time
  }
}`;

/**
 * Get the average block time by last hour
 */
export const AVERAGE_BLOCK_LAST_HOUR_QUERY = gql`
query AverageBlockTimeLastHour{
  average_block_time_per_hour(limit: 1, order_by: {height: desc}){
    average_time
  }
}`;

/**
 * Get the average block time by last 24 hours
 */
export const AVERAGE_BLOCK_LAST_DAY_QUERY = gql`
query AverageBlockTimeLastDay{
  average_block_time_per_day(limit: 1, order_by: {height: desc}){
    average_time
  }
}`;

Price [OK] - I currently hardcoded 0 since this is a testnet

export const PRICE = gql`
  subscription price{
    token_price(limit: 1, order_by: {timestamp: desc}) {
    price
    market_cap
    denom
    }
}`;

Stabilities

I don't think this is the correct query

query community_pool {
  community_pool(limit: 1, order_by: {height: desc}) {
   coins
 }
}

Consensus

I have the following query below but it returns an empty array at the moment. Not sure if this available for testnet

query consensus_state{
    consensus{
      height
      round
      step
    }
  }

Latest Blocks

The following query does not give me info about the proposer itself. I need the identity and moniker of the proposer not the validators

/**
 * Get the latest blocks with pagination
 * @param limit limits the amount of data coming back
 * @param offset offset
 */
export const LATEST_BLOCKS_QUERY = gql`
query LatestBlocks($limit: Int!, $offset: Int!) {
  block(limit: $limit, order_by: {height: desc}, offset: $offset) {
    hash
    proposer {
      validator_infos {
        validator_descriptions(order_by: {timestamp: desc}) {
          moniker
          operator_address
        }
      }
    }
    height
    num_txs
    timestamp
  }
}`;

Latest Activities

Is there a way to filter by message.type?

query LatestActivies {
  transaction(order_by: {timestamp: desc}, where: {messages: {_is_null: false}}, limit: 10) {
    messages
  }
}

Feature description

Currently, it is not possible to know what status a given validator has. For this reason, we should implement the update, on a block basis, of each validator status. This will allow users to implement the following component:

Implementation proposal

What I propose to do is the following.

PostgreSQL

Define two new table as follow:

CREATE TABLE validator_status
(
    validator_address TEXT    NOT NULL REFERENCES validator (consensus_address),
    status            INT     NOT NULL,
    jailed            BOOLEAN NOT NULL
);

CREATE TABLE validator_status_history
(
    validator_address TEXT                        NOT NULL REFERENCES validator (consensus_address),
    status            INT                         NOT NULL,
    jailed            BOOLEAN                     NOT NULL,
    height            BIGINT,
    timestamp         TIMESTAMP WITHOUT TIME ZONE NOT NULL,
    PRIMARY KEY (validator_address, height)
);

The first one will contain the latest status, while the second one will contain the history of all the statues.

Parsing

Per each block, we should:

1. Call the /staking/validator/<address> endpoint
2. Parse the response
3. Store the jailed and status field values

Request example

With the modular structure, I would like to have a way to query the enabled modules in the BDJuno. The idea is that once the modules is enabled in BDJuno, a GraphQL query will return the list of modules enabled, so that the frontend application will know which corresponding components should be enabled. We are going to develop the frontend following the same modular structure.

Feature description

Currently there is no efficient way for the frontend of big dipper to calculate the average online voting power by day without some performance costing calculation.

Implementation proposal

Make an aggregation what will allow big dipper to input a start and end date (if end date is null return only start date) and return the average of each day.

notes: or i can pass 2021-01-03T00:00:00Z to 2021-01-03T11:59:59Z. Whichever works better

ex:
start_date : 2021-01-03T00:00:00Z
end_date : 2021-01-06T00:00:00Z

return

[
    {
        date: '2021-01-03T00:00:00Z',
        average_voting_power: 1200,
    },
    {
        date: '2021-01-04T00:00:00Z',
        average_voting_power: 1200,
    },
    {
        date: '2021-01-05T00:00:00Z',
        average_voting_power: 1200,
    },
    {
        date: '2021-01-06T00:00:00Z',
        average_voting_power: 1200,
    }
]

how could i query this?

this is the query i made now, please help me check if it's correct? not sure how to query the amount of available, reward, commission, and the reward address, total amount in $USD? Thanks

query UserInfo {
  account(where: {address: {_eq: "cosmosvaloper14kn0kk33szpwus9nh8n87fjel8djx0y070ymmj"}}) {
    account_balances {
      coins
    }
    delegations {
      amount
    }
    redelegations {
      amount
    }
    unbonding_delegations {
      amount
    }
  }
}

Bug description

Currently inside the GraphQL data definitions, there are some places in which 1-to-n relationships are used instead of 1-to-1. For example, this is the case in the following query used when retrieving all validators' identities.

Currently it is:

query Validator {
  validator{
    validator_infos {
      validator_descriptions {
        identity
      }
    }
  }
}

The returned value is:

{
  "validator": [
    {
      "validator_infos": [
        {
          "validator_descriptions": [
            {
              "identity": ""
            },
            {
              "identity": "51468B615127273A"
            }
          ]
        }
      ]
    }
  ]
}

Instead, the query should be

query Validator {
  validator {
    validator_description {
      identity
    }
  }
}

And the returned value should be

{
  "validator": [
    {
      "validator_description": {
        "identity": "51468B615127273A"
      }
    }
  ]
}

The relationships

• validator -> validator_info
• validator_info -> validator_description

Should both be 1-to-1 instead of 1-to-n.

We need to check those relationships to make sure they are initialized as 1-to-1 instead of 1-to-n. Also, a check should be made on all other relationships as well.

Feature description

Big dipper would like to be able to display the withdrawal amount but it currently lives in the event section of a transaction

Implementation proposal

Add an event key prop in to transactions so Big dipper would be able to get the required data based on the UI

Feature description

Currently the missed_blocks_counter is a total accumulation of all the missed blocks the validator has missed in total.

In order to get the condition feature I need the signed_blocks_window (I have this) and the missed_blocks_counter within the signed_blocks_window time frame.

In the future Kwun wants to add a detailed addon to display “if the validator goes offline now, how long until they will be jailed” and in order to do that I would need min_signed_per_window

Implementation proposal

Update missed_blocks_counter to follow signed_blocks_window

Add min_signed_per_window

Feature description

There's the need to periodically get the total supply of tokens.

Implementation proposal

We can implement this by using the following endpoint:

/supply/total

(Example)

What it should be done is querying this endpoint periodically (let's say every 30 seconds) and then store the data inside the database.

For the validator list and validator detail page, we will only show the latest information of a validator.

https://xd.adobe.com/view/53042c53-f384-451e-7cee-e0da21dabd79-2535/screen/b69298e1-3197-4d89-ba85-ffe0d214abda/2-2-validator-details

Validator detail

However, when a validator updates its validator detail and commission rate, the old values will be removed. I would like to let the users see the changes of the validator. Especially when a validator change its commission rate.

This can only be done when parsing the cosmos-sdk/MsgEditValidator message. When the parser see this message, it has to store the original value of the validator and the changes it has done. The simplest way would be to link the original value with the corresponding edit validator tx.

Validator uptime

The validator uptime is calculated by the amount of signatures the validator should have voted in the signed block window. The parameters can be retrieved from this endpoint.

http://lcd.cosmoshub.bigdipper.live/slashing/parameters

Here are the current slashing parameters

{"height":"2225861","result":{
  "max_evidence_age": "1814400000000000",
  "signed_blocks_window": "10000",
  "min_signed_per_window": "0.050000000000000000",
  "downtime_jail_duration": "600000000000",
  "slash_fraction_double_sign": "0.050000000000000000",
  "slash_fraction_downtime": "0.000100000000000000"
}}

The validator signing information can be retrieved with the following (undocumented) endpoint.

http://lcd.cosmoshub.bigdipper.live/slashing/validators/{validator_consensus_pubkey)/signing_info

For example, to get the signing information of Forbole, you can query

http://lcd.cosmoshub.bigdipper.live/slashing/validators/cosmosvalconspub1zcjduepqmfxl36td7rcdzszzrk6c7kzp5l3jlw4lnxz8zms3py7qcsa9xlns7zxfd6/signing_info

and the result will be like this.

{"height":"2225917","result":{
  "address": "",
  "start_height": "0",
  "index_offset": "5627914",
  "jailed_until": "1970-01-01T00:00:00Z",
  "tombstoned": false,
  "missed_blocks_counter": "0"
}}

The validator uptime can be calculated as

uptime = ( signed_blocks_window - missed_blocks_counter ) / signed_blocks_window * 100%

Feature description

Save time and block height when the validator updates his description so that we can retrieve the description that the validator has made.

Feature description

The various chains could have enabled the community pool module. For this reason, we need to periodically query the amount of tokens contained inside such pool.

Implementation proposal

The querying of the community pool can be done by querying the following endpoint:

/distribution/community_pool

(Example)

What I suggest we do is query this endpoint periodically (let's say every 30 seconds) and then store the data inside the database.

Feature description

When the chain updated, the block count from zero again. Making a new database to store the data from new chain should persist the data from the old chain as well as logging data from the new chain.

Implementation proposal

Check chain ID every time when setting up bdjuno. If the chain ID is different from the previous run, make a new database and store data there.

Signed voting power

I am trying to query the voting power in a block by using the following query

query BlockDetail {
  block(limit: 1, where: {height: {_eq: 314300}}) {
    hash
    timestamp
    num_txs
    validator {
      validator_description {
        moniker
        identity
      }
    }
    pre_commits
    proposer_address
    validator_voting_power_histories_aggregate {
      aggregate {
        sum {
          voting_power
        }
      }
    }
  }
}

The result i am getting is the following:

{
  "data": {
    "block": [
      {
        "hash": "1C8215F97F09B437E78E4D492EA9E8BF75715621E33D37C651E949EEE64DDBF7",
        "timestamp": "2020-10-26T21:14:51.166442",
        "num_txs": 0,
        "validator": {
          "validator_description": {
            "moniker": "novy",
            "identity": "5422BE13389B2B4D"
          }
        },
        "pre_commits": 88,
        "proposer_address": "desmosvalcons1v5ejtt5dff85c5zfy8gxea25d92yzrw0lewxyw",
        "validator_voting_power_histories_aggregate": {
          "aggregate": {
            "sum": {
              "voting_power": null
            }
          }
        }
      }
    ]
  }
}

My expected result is that the voting_power sum would not be null. Is this the correct assumption?

Signatures by Block

Is it possible to get a list of signers per block and their sign status (I'm not sure if that makes sense or not)

Side questions

1. Is voting power displayed in udaric?

Feature description

After implementing #28, we need to get each proposal tally result. As far as I've understood, tally results represent the current proposal status. This means that if it's in DepositPeriod, it represents the total amount of tokens deposited. Otherwise, if it's in the VotingPeriod it represents the different votes that have been casted.

Implementation proposal

To implement this, I would suggest we store in two different tables each deposit made and each vote casted for a proposal. Such data can be get handling properly the MsgDeposit and MsgVote messages respectively.

These data should be later sufficient to properly display anything the explorer might want to display.

Inside the requirements, there's the following:

Read the latest consensus state

@kwunyeung can we more details on what you mean by "consensus state"?

Is there a way to query transactions by delegator's address? I see we have a signer info with a pub key now but i'm not sure if that's exactly what i'm looking for.

Bug description

When the config.toml file input with the corresponding rpc and lcd node, the websocket didn't work.

Steps to reproduce

In .toml file change the rpc and client node to the following:
rpc_node = "https://rpc.stargate.bigdipper.live:443"
client_node = "https://api.stargate.bigdipper.live:443"

It gives out the error message :
ERROR: websocket: bad handshake: failed to start RPC client [desmos-labs/[email protected]/parse/handler.go:38]

Expected behavior

The rpc node should work as well as on desmos.

Bug description

If you are using big.Int.int64 that is not the real value, especially on the validator_delegation module.

Expected behavior

Expected much smaller value than 80000000000000

We would like to show the daily delegation and unbonding amount. This can be done by querying all the delegations and unbonding information from all validators. It will be interesting when comparing the delegations with token price.

Feature description

We need to get the created governance proposals.

Implementation proposal

To implement this, I think we can simply create a message handler that handles MsgSubmitProposal messages. Such kind of messages should contain all the information that is worth saving about a proposal.

@kwunyeung do you think that would be sufficient?

Bug description

Currently there is no indication on if a tx has successful or not

{
    "timestamp": "2020-10-10T18:08:07",
    "hash": "87CFD8594E65ABFBA58F49B2D7F05C97C7C8A28B75D51CEBF53BB0D33D4274B0",
    "height": 67144,
    "memo": "Welcome, to the real world...😎",
    "messages": [
      {
        "type": "cosmos-sdk/MsgSend",
        "value": {
          "amount": [
            {
              "denom": "udaric",
              "amount": "10000000"
            }
          ],
          "to_address": "desmos168wz6xz6tnzvl2qwee264x0x9sr8yz0vtkp2cj",
          "from_address": "desmos1dzn2s7l0wm9kekyazcnhapu8j95n90efmcmrad"
        }
      }
    ]
  }

Steps to reproduce

add something like
success: boolean

Expected behavior

Feature description

I found that when we start bdjuno the transaction between the last opened (maybe genesis) and current block height. However we don't need to query each block for that information, and just querying endpoint at the start of program will work.
The things we may lose are like validators accounts, accounts, proposals...

Implementation proposal

Just a simple one-shot operation in the modules while setting up. This query the existing sets from LCD and update the database.

Feature description

Saving HEX pubkey into database so that we do not need to calculate that everytime we want to get HEX from pubkey

Implementation proposal

When adding a validator we can map to a HEX pubkey as well.

I read the schema again and find that the tombstone status of a validator is not being tracked. A validator will be put in tombstone 🪦 if the validator has double signed. When a validator double sign, there is an evidence record in a block stating the votes from a single validator. We should store there when a double signing happens.

The double sign evidence is similar to this

{
			"type" : "tendermint/DuplicateVoteEvidence",
			"value" : {
				"PubKey" : {
					"type" : "tendermint/PubKeyEd25519",
					"value" : "rPVOGBuNjQb17F21UBOKOvkl1AlcFBRm314IoUaBzFA="
				},
				"VoteA" : {
					"type" : 1,
					"height" : "70115",
					"round" : "0",
					"block_id" : {
						"hash" : "A42C9492F5DE01BFA6117137102C3EF909F1A46C2F56915F542D12AC2D0A5BCA",
						"parts" : {
							"total" : "1",
							"hash" : "418A20D12F45FC9340BE0CD2EDB0FFA1E4316176B8CE11E123EF6CBED23C8423"
						}
					},
					"timestamp" : "2019-02-17T10:02:06.060481406Z",
					"validator_address" : "AB89E14820E9C0EE81EA47BD3BF0658D7F7CAD7B",
					"validator_index" : "69",
					"signature" : "1qwPQjPrc7DH7+f6YAE3fOkq6phDAJ60dEyhmcZ7dx2ZgGvi9DbVLsn4leYqRNA/63ZeeH5kVly8zI1jCh4iBg=="
				},
				"VoteB" : {
					"type" : 1,
					"height" : "70115",
					"round" : "0",
					"block_id" : {
						"hash" : "29D583DE786844F8FDE727EB5F9BEF9B73184BB0891BA3E279B751C527F4BB82",
						"parts" : {
							"total" : "1",
							"hash" : "8C93F21EB7E580DC52D6F2EFF3515B5D458ADED40B97B414FF8435E47257694D"
						}
					},
					"timestamp" : "2019-02-17T10:02:06.217508301Z",
					"validator_address" : "AB89E14820E9C0EE81EA47BD3BF0658D7F7CAD7B",
					"validator_index" : "69",
					"signature" : "A5m7SVuvZ8YNXcUfBKLgkeV+Vy5ea+7rPfzlbkEvHOPPce6B7A2CwOIbCmPSVMKUarUdta+HiyTV+IELaOYyDA=="
				}
			}
		}

Example query of signing-info of a validator

Let me know if you want me to provide visuals on where the query is being used

Latest Activities

The timestamp is being used but no longer found in hasura

subscription LatestActivity {
    transaction(limit: 1, order_by: {height: desc}) {
      timestamp
      hash
      height
      messages
      success
    }
  }

query Activities($limit: Int, $offset: Int, $height: bigint) {
    transaction(limit: $limit, offset: $offset, order_by: {height: desc}, where: {height: {_eq: $height}}) {
      timestamp
      hash
      height
      messages
      success
    }
    transaction_aggregate(where: {height: {_eq: $height}}) {
      aggregate {
        count
      }
    }
  }

Activity Details

The timestamp is being used but no longer found in hasura

  query ActivityDetails($hash: String) {
    transaction(where: {hash: {_eq: $hash}}) {
      hash
      height
      fee
      gas_used
      gas_wanted
      success
      memo
      messages
      timestamp
    }
  }

Validators Count

Is the following query still valid?
Doing my best to update the queries and I noticed all the history tables are now gone so just double checking

query Validators {
    active_validators: validator_aggregate(where: {validator_statuses: {status: {_eq: 2}}}) {
      aggregate {
        count
      }
    }
    not_active_validators: validator_aggregate(where: {validator_statuses: {status: {_neq: 2}}}) {
      aggregate {
        count
      }
    }
  }

Validators Staking

Is the following query still valid?
Not sure what the new query is for the following

  query ValidatorStaking($address: String) {
    validator(where: {_or: [{validator_info: {consensus_address: {_eq: $address}}}, {validator_info: {operator_address: {_eq: $address}}}]}) {
      delegations {
        amount
        delegator_address
      }
      redelegations {
        src_validator_address
        dst_validator_address
        delegator_address
        amount
      }
      unbonding_delegations {
        amount
        delegator_address
      }
    }
  }

Currently many tables (esp. in the staking module) are related to one another. We should check the relationships between them and ensure they are properly respected using the REFERENCES keyword inside column definitions.

Feature description

Implementation proposal

Feature description

We need to implement the ability of fetching every 30 seconds the token price and market cap.

Implementation proposal

I think that the token denomination can be easily get from the /staking/parameters endpoint, taking the bond_denom denomination.

@kwunyeung do you have any preference from where to get the data? Do you know any API that might allow us to fetch it?

Does proposal_id exist in MsgSubmitProposal or is there any way to access it?
I've read the docs provided in bdjuno and have found only MsgVote and MsgDeposit has a proposal_id.

Can I get a confirmation that CommunityPoolSpendProposal does not have a proposer or a initial_deposit

CommunityPoolSpendProposal

{
  "@type": "/cosmos.gov.v1beta1.MsgSubmitProposal",
  "content": {
    "@type": "/cosmos.distribution.v1beta1.CommunityPoolSpendProposal",
    "title": "Community spend proposal",
    "description": "This is a community spend proposal",
    "recipient": "desmos13yp2fq3tslq6mmtq4628q38xzj75ethzela9uu",
    "amount": [
      {
        "denom": "udaric",
        "amount": "20000000"
      }
    ]
  }
}    

Is it even possible that we can have a daily account snapshot? I want eventually let users to see the daily change of the account. This affect to those accounts which has delegation as the reward (and commission for validators) keep changing on every block. We can't just rely on the transfer transactions to track the changes.

Feature description

In order to take the previous block sign, we can get the block height for each pre_commit so that in we can get who signed the previous block from JSON.