I’ve recently put up a forum post for discussion of the Squidsway proposal.
If you’ve not read that, read it first.
This forum post is aimed at data geeks in the ecosystem.
I welcome ideas from the whole community but I’m particularly looking at you:
Parity Data Team
individuals and teams working on OpenGov transparency
product team members who design and assess KPIs
builders of the ecosystem’s various dashboards
I would like your feedback and suggestions on
. the kind of data / insights that the Squidsway project should be generating
. the areas in which Squidsway should be investigating
As a reminder on the kinds of data which are technically possible to ingest:
A major USP of the Squidsway tool is the ability to ingest offchain data, particularly unstructured or loosely structured offchain data, such as texts from canonical sources (eg Polkadot Forums, Polkassembly).
The tool will be a reindexer, using sets and tags to curate data and queries to compile data before reingestion so that commonly used properties such as ‘whale account’, ‘first-time voter’, ‘sophisticated user’ or ‘contentious referendum’ can be efficiently recombined into more detailed queries.
The kinds of data which it makes sense to reingest are those that let us aggregate individuals’ considered behaviour (such as using an extrinsic, writing a proposal) into trends.
It makes less sense to follow long ‘threads’ on individual accounts or referenda, for example a ‘follow the money’ investigation - while this would be possible with Squidsway, the efficient ETL flow for indexing would provide no advantage on single 'threads.
Some things are encouraged uses of the Squidsway tool, for which the tool would be appropriate, but would be out of scope for the treasury-funded proposal (ie the tool and project). An example would be generating an assessment mechanism for detailed KPIs of a rollup product - this would be something appropriate for the product team themselves to use the tool to develop.
The insights the project will produce should be action-focused, allowing us to guide user behaviour through the choices we make as OpenGov, and to do this effectively and objectively.
Some examples of the level of insight which the project (using the tool) could produce:
Assessment of Polkadot Referendum 1701:
This is an example of a hard (ie on-chain) change we make in order to encourage some user behaviour.
The actual user behaviour we seek is reasonably well-defined.
Some of the aims are subjective and can only be proxied subjectively (eg ‘elevate the quality of governance activity’).
Others can be proxied well (eg, ‘increase alignment within the network participants’ ≈ ‘more of the referenda submitted pass’).
Others open new questions in definition which allow us to better iterate our aims (eg ‘Ensuring only “heavily” aligned referendums get approved’ - does this mean that more submitted referenda: ‘get high support from token-based voting’; or ‘get the support of a high number voting participants’; or ‘have more positive engagement’ ? - all of these are possible to measure and with the 3 measurements we can compare success on each of these 3 aims against each other).
While many of these results are possible without Squidsway, the Squidsway tool should significantly reduce the time it takes to find them and encourage data-driven (rather than vibes-driven) assessment of outcomes.
We can additionally scan for unintended consequences - for example, we may find that increasing the decision deposit significantly reduces the number of small treasury proposals, or those that concern development but not those that concern marketing, or those from first-time proponents.
Technical quality of proposal norms:
A contributing factor to voter fatigue is the proportion of proposals which don’t abide by recommended norms, such as previous forum engagement or ‘no retrospective funding’. These can necessitate an expenditure of time by OpenGov participants in repeatedly pointing out the norms. They are even more of a burden for proponents, who often don’t know which ‘norms’ really are norms, which are widely ignored, which are given importance by some voters but not others (there is often a lack of consensus even amongst big voters on norms, like ‘don’t request in DOT’).
We can define these norms and set an LLM on assessing compliance of each completed proposal with them, and the results (compared with Aye/ Nay) should allow a single set of comparators for proponents to quickly separate signal from noise, and thus improve the quality of their proposals.
Monetary policy:
Monetary policy is an area in Polkadot governance which has been given only cursory attention in the last few years, all of which has been based on assertion. With the new focus on the utility of the DOT token, we can expect more tweaks to monetary policy to become more regular.
Without a framework to measure the resulting effects, we risk repeating the same fundamental mistake we made in 2023 - assessing ROI based on hot air and argument, and thus taking many times longer to agree on the truth (in the case of 2023, significantly delaying us from stopping the bleed).
In national economies, second order measurements such as the velocity of money (the degree to which money in the economy is respent on productive activity - thus increasing GDP) are important but only measurable by proxy. On a public blockchain, we can measure, rather than infer, such measurements.
As an example: We can measure the types of routes taken by DOT disbursed via different routes (eg Events Bounty, incentives, public goods product teams). Perhaps we find that money paid out via hackathons takes a variety of routes around the DOT ecosystem, but money paid out as marketing goes straight to exchanges. Right now, without data, we can speculate about whether that is what happens. But we don’t know. And if we don’t know, the best can we do is slowly argue our way to consensus or stalemate.
These are just a few ideas - the possibilities are extremely wide (paradoxically, this makes it difficult to drill down on specific uses)
All suggestions welcome - whether it is a particular dataset you wish existed, an issue you feel the community should be investigating with data, or even a new direction for the tool/ project which you haven’t yet seen mentioned.