Note: the idea of this proposal is for the team to discuss and set a BAL reward and then have someone to pick it up. I’m not proposing that I would build it - I can definitely help from a product management capacity but not from a dev perspective
Balancer statistics portal grant proposal
Historical queryable information about pools on balancer that is usable for both governance and sophisticated traders
What?
Build out some form of publicly accessible db/on chain query by pool for the following (probably should be more but this is a good start) metrics:
- Liquidity
- Trade Volume
- Incentives (the various factors, balFactor, wrapFactor etc)
- Bid price *
- Ask price *
- Bid volume *
- Ask volume *
We could wrap these into 2 different tables but orderbook you’d want to get at least a 5s interval. Or if it’s easier can start with how the charts do it (1m, 5m, 15m, 1hr etc etc)
- Note: given we don’t have a concept of an orderbook due to the nature of things we could try to imitate an order book by pricing through slippage. So for example, 1% slippage = 2nd order book and then we’d have the bid/ask volumes to get to 1% slippage
Why?
There are two fundamental problems that we are trying to solve here:
1. Governance:
The way I see governance right now is similar to how well performing companies in the regular market run. They utilise data to understand cause and effect to then make further judgements and decisions. What we are currently doing is similar to how smart startups run A/B tests - there is a hypothesis, followed by implementation of a test and then analysis to yield insights and prompt further test.
We currently don’t have any solid mechanism to actually understand if what we did from a governance perspective was any good.
An example:
The latest soft peg vote (I’m not dragging this up, this is just a contentious point that was discussed a lot and where a solution like this would be great for). The hypothesis was that liquidity would be kept within the system and be distributed to more useful pairs - i.e. those that aren’t soft pegged together. Now that it has run, how do we know this? We have no idea what the average weighted liquidity of pools were before hand nor after so we don’t know what impact this could have done. We can look at total value locked in the protocol on defipulse which shows that 40m was “lost” from the protocol, but we can’t really understand if that was due to the vote or some other extrinsic factor.
Underlying data would help us solve it and in addition allow fur us in the future to understand better what decisions we could make. If we understood the impact of this example and we had a similar one in the future, we could then have a theoretically more accurate hypothesis than current.
2. Trading liquidity:
There is a lot of people who trade and are interested in trading in crypto. The biggest problem however lies in 2 issues:
- Sophisticated traders (i.e. lots of volume) use lots of historical data to build models and trade for profit. There is no historical data available to allow them to trade
- The format in which data is presented is very different to what regular traders are used to. They are used to the concept of the orderbook which is not available here. If we were able to provide something familiar it could reduce the complexity and “newness” factor and allow people to dip their toes into this world a lot easier
Deliverables
I would propose the following deliverables:
- Historical daily snapshots of key pool statistics storage
- API access (or some other mechanism) for the daily snapshots
- 5s interval orderbook data
Nice to have 4: trade data (people building backtesting models etc)
