The following is a brain dump on things that could be valuable to track from a Data perspective, from broad to specific things. As a reference, Will has built this in the past, which can be useful: https://opengov.metakosmia.host/ (don't know if the site is working, but this is the repo: https://github.com/wpank/open-gov-insights) 1. **Treasury spending vs income**. Having a clear picture on how the treasury will evolve over time, both from an income and a spending perspective is crucial. I would have two views from this: (1) current state (income + burning); (2) Proposed state (income + burning + currenty being voted referenda). 2. **Referenda details**. It would be good to classify all referenda (mkt, tech, bd, etc) and be able to cross-reference it with the tracks. That way, it can be aggregated to see how much polkadot is spending on each type of request (mkt, tech, bd, etc) and also how this cross-references with tracks. I can imagine these three tables: EDIT AFTER: would also add some more info to the table like: frequency in usage of each track (total and in % of it all), how much money is on each track (total and in % of it all). And also be able to see this with what has already happen, but also with what's being voted on. - By Track | OpenGov track | Spending | Avg Turnout | Avg Voting (aye / nay) | Avg length (# blocks) | |:--------------:|----------|-------------|------------------------|-----------------------| | Big Spender | XYZ DOT | X % | X % | X Blocks | | Small Spender | XYZ DOT | X % | X % | X Blocks | | Medium Spender | XYZ DOT | X % | X % | X Blocks | | Treasurer | XYZ DOT | X % | X % | X Blocks | | Root | XYZ DOT | X % | X % | X Blocks | - By Type | Classification | Spending | Avg Turnout | Avg Voting (aye / nay) | Avg length (# blocks) | |:--------------:|----------|-------------|------------------------|-----------------------| | MKT | XYZ DOT | X % | X % | X Blocks | | BD | XYZ DOT | X % | X % | X Blocks | | Parachains | XYZ DOT | X % | X % | X Blocks | | Tech | XYZ DOT | X % | X % | X Blocks | | etc | XYZ DOT | X % | X % | X Blocks | - Cross-reference | OpenGov track | Classification | Spending | Avg Turnout | Avg Voting (aye / nay) | Avg length (# blocks) | |:-------------:|----------------|----------|-------------|------------------------|-----------------------| | Big Spender | Mkt | XYZ DOT | X % | X % | X Blocks | | Big Spender | BD | XYZ DOT | X % | X % | X Blocks | | Big Spender | Parachains | XYZ DOT | X % | X % | X Blocks | | Big Spender | Tech | XYZ DOT | X % | X % | X Blocks | | Big Spender | etc... | XYZ DOT | X % | X % | X Blocks | 3. 1. **Single referenda details**. Once a referenda has passed, it be good to have a 'referenda dashboard' where all the deatails that pertain that referenda would be seen. Who's the beneficiary, how many DOT were requested, turnout, aye/nay, top 10 voters in favor, top 10 voters against, top 10 voters abstained, how long it took for it to pass. Also, after that, it'd be very, very interesting to have a tracking of the DOT. So for example we know that account 1XYZ..ABC got the funds on Block #123, then after that, the 'referenda dashboard' could have a part where there's some tracking of this money, to see to what account it was sent, when, and all that. 2. **Ongoing referenda details**. This would be similar to (a), however with the caveat that we wouldn't know when this will pass, but rather we could have a guess depending on the curves for OpenGov. For this, it will be required to somehow read the chain to understand the functions and parameters that OpenGov has for each track, and show that info. 1. For any referenda to pass, two things need to happen: right amount of turnout and right amount of aye/nay votes. For any ongoing referenda, it would be very interesting to be able to allow users to extract the current data and do some math on how to influence the referenda so that it passes at a certain block height. 5. **Frequent voters**. It would be good to know which accounts vote on which referenda, and with what conviction to see if we can find some patterns. The above classification on (2) can also be valuable here when looking into single voters. I can imagine seeing a voter