As some people I know in this space were unaware of my original post for this flipstarter, I've re-posted it to pitch it to the BCH community. Some additional Q/A provided below.
Q. Why is this product relevant?
A. Simple answer is that raw UTXO databases by themselves are too "low-level" for anything useful. This is by design, as the data is maximally normalized and compressed for storage and transmission efficiency.
To make use of a UTXO database for layer-2 p2p applications (gambling, social media, etc) it requires de-normalization and processing of this blockchain data. If every single project needs to get kneck-deep in these complexities, it's going to stop a great many of them in their tracks due to cost and time (I've seen this happen personally).
This product alleviates this burden significantly which means layer-2 applications can be rapidly developed for BCH. Lowering the entry-barrier for outsider developers also means more (non-protocol) developers can enter eco-system.
Note that other eco-systems have comparable projects (e.g. BSV's Planaria which is what most of their projects are using).
Q. Why 6-12 months?
A. The existing MVP took 6 months to develop and another 6-12 months are needed for the enterprise-grade finish. For example:
Need to support multiple DBMS's using an abstraction layer for more DBMS's later.
There are all sorts of problems encountered at this scale of data. I call it doing "big data on small data infrastructure". Try out the MVP, cross-join on the TXO table and see if you can break it -- you cannot. It's fully stable and responds even for crash-able queries.
During import, the data is parsed directly from raw BLK files speed up installation process, and this requires LevelDB integration and all sorts of custom core stuff (e.g. they use a different compact integer format in storage than in chain).
Blockchain data tends to be maximally efficient and normalized, however applications consume denormalized data. For example, getting the "fee" of a transaction is a transitive calculation based on input/outputs. Getting the "fee" in USD is then a join to another table. All these things are data-transformations which need to be applied during import. Whilst a node can give you the "fee" there's other things they don't give. Real-world use cases need to parse OP_DATA payloads for Dapps whichl require custom transforms during import (you can't search for this stuff retrospectively in the chain).
The complexities pile on, but nothing that can't be solved.
Q. What guarantees do we get for delivery? Can't you just run off with the raise?
A. If this flipstarter is funded, I will deliver no matter what. The fact that a substantial MVP is provided is evidence of competence and delivery. Also, I am raising through a company structure and publicly identified myself so it's possible for any contributor to launch litigation should I fail to deliver (and I have no problem with that).
Q. It's written in C# and I use <insert favorite language here>.
A. You don't need to integrate with anything C#. The system generates SQL databases which is all that developers integrate with (for both reading and sending data).
However, if you want to add your own custom data-transformations to extract meaningful data out of the blockchain, then these plugins will be built in C# (or .NET supporting language, of which there are many like Python, F#, C++, etc). These plugins will also be open-source and over-time the community will build many out. By default, I will provide "Account" and "SLP" plugins that provide high-level "Account" tables for BCH and SLP tokens (will be like bank accounts).
As new layer-2 protocols are established by BCH community for other use-cases, then plugins can be built so entire community can start getting this data without constantly re-inventing this tooling.