HoneyFlow

Demo

About

The problem it solves ## The Unfortunate Problem Open source software is worth an estimated $8.8 trillion to the global economy. 96% of commercial software depends on it. Yet 60% of the people who maintain it are unpaid, and the better they do their job, the more invisible they become. We've seen what happens when this breaks down. OpenSSL secured two-thirds of the world's web servers on $2,000 a year in donations before Heartbleed exposed millions of private keys. Log4j, a logging library embedded in hundreds of millions of devices, was maintained by a handful of volunteers before Log4Shell scored a perfect 10.0 severity rating and set the internet on fire. The pattern is always the same: a critical dependency goes unfunded, something breaks catastrophically, and then the industry scrambles to respond. The current funding model, when it exists at all, sends donations to a single top-level maintainer while the hundreds of contributors, transitive dependencies, and upstream researchers that actually built the foundation never see a cent. ## How HoneyFlow Solves This Our platform, HoneyFlow, traces the full contribution graph of any GitHub repository, npm/PyPI package, or arXiv paper, then distributes crowd funding proportionally across everyone who actually built it. When you submit a repository URL, HoneyFlow's backend recursively walks the dependency tree, parsing `package.json`, `requirements.txt`, `Cargo.toml`, and other manifests, while simultaneously pulling contributor data from the GitHub API (commit counts, additions, deletions). For arXiv papers, it traces citation graphs via Semantic Scholar. Each layer of the graph gets analyzed: OSS models (Llama, Qwen, Deepseek) running on 0G's decentralized compute network classifies each repository's purpose, determines how much of its value comes from custom code versus dependencies, and ranks every dependency by importance using both LLM analysis and actual import frequency in the source code. The result is a weighted directed graph where every edge. From project to dependency, from repository to contributor, from paper to citation, each carries a score. Attribution is calculated via leaf tracing: a depth-first traversal from the root that accumulates weights along each path down to the actual humans at the leaves. A contributor maintaining a transitive dependency three levels deep gets credited proportionally to how much that dependency matters to the projects above it. But pure algorithmic allocation is gameable. As Vitalik Buterin argued in his writing on "info finance and human juries"(https://vitalik.ca/general/2021/08/16/voting3.html): *"If you use an AI to allocate funding, people WILL put a jailbreak plus 'gimme all the money' in as many places as they can."* HoneyFlow addresses this with a human jury system. Real people review AI-generated attribution weights through plain-language questions ("How much did library X contribute to project Y?"), adjust them based on their expertise, and earn ETH for participation. These corrections are stored as jury priors that adjust future AI decisions, creating a self-correcting feedback loop where human judgment anchors the system against manipulation. When someone donates ETH, the funds go to a per-project vault managed by Privy. From there, disbursement follows the attribution graph: every contributor receives their calculated share, sent on-chain directly to their wallet. The entire pipeline – from tracing to attribution to payment – should be transparent and verifiable. ## What People Use It For - **Trace a project** – Paste a GitHub URL, npm package, or arXiv paper. Watch the dependency and contribution graph build in real-time via streaming logs. See exactly who built what and how value flows through the stack. - **Donate with attribution** – Send ETH that gets split across the entire contributor graph, from the lead maintainer down to the person who maintains a transitive dependency three levels deep. - **Earn as a contributor** – Check your profile to see every project you are attributed to and the percentage of value you have earned across the ecosystem. - **Serve on the jury** – Answer plain-language questions about whether the AI got its attribution weights right. Earn ETH for honest participation. Your votes make the system more accurate for everyone. Open source funding has always been a good intention with no practical mechanism. We built HoneyFlow to turn it into an automated, transparent, on-chain pipeline that follows the code all the way down to make everyone's contribution heard. Sources: https://www.library.hbs.edu/working-knowledge/open-source-software-the-nine-trillion-resource-companies-take-for-granted https://opensourcefundingsurvey2024.com/ https://www.bankinfosecurity.com/openssl-gets-funding-after-heartbleed-a-6893 https://developers.redhat.com/articles/2024/10/23/log4shell-vulnerability-shook-world-software-development Vitalik's article: https://vitalik.ca/general/2021/08/16/voting3.html Use of AI tools and agents ## 1. 0G Compute Network Reliability The biggest challenge was integrating with 0G's decentralized inference network. Responses would sometimes come back with malformed JSON, time out at 90 seconds, or fail silently during provider acknowledgment. We built a 3 level JSON extraction fallback consisting of direct parse, stripping markdown fences, and regex extraction, and added exponential backoff retries. When LLM inference fails entirely, the system gracefully degrades to heuristic based attribution such as a 60/40 custom code to dependencies split so the pipeline never breaks. --- ## 2. Recursive Dependency Graphs and Cycle Detection Real world package ecosystems have circular dependencies. Our graph builder had to handle cycles mid traversal without infinite loops. We implemented adjacency based cycle detection before adding edges and added a hard cap of 1,000,000 traversal steps as a safety net. Tuning the decay multiplier and max_depth parameters to produce fair attribution weights without exponential blowup took significant iteration. --- ## 3. Academic Citation Data Is Fragmented For paper based projects, citation data does not live in one place. We built a 4 stage fallback chain. Parse LaTeX source first, fall back to PDF citation extraction, merge both if available, and finally query the Semantic Scholar API. Each stage is wrapped in error suppression so a single failure does not kill the full analysis. --- ## 4. arXiv Rate Limiting arXiv's API enforces strict rate limits and requires a minimum 3.1 second gap between requests. We implemented a process wide global lock, respected Retry After headers, and added a 300 second cooldown when rate limited. This serialization was tricky to get right in an async Python backend without deadlocking. --- ## 5. Stitching Together Unreliable APIs The core product depends on GitHub, arXiv, Semantic Scholar, npm, and PyPI, all with different rate limits, authentication schemes, and failure modes. The main engineering challenge was making the system resilient enough that any single API being down does not break the user experience, while still producing accurate contribution graphs when everything works. --- ## 6. Human Active Recall and Model Feedback Another challenge was integrating the human jury layer without slowing the system down. After AI proposes attribution, a bonded juror reviews the result during a fixed window. Once the community accepts the juror’s decision, that outcome feeds back into the model as active recall training data. Designing this loop required careful state management so that reviewed allocations become canonical, juror stakes can be slashed if necessary, and approved decisions improve future inference. Balancing automation with accountable human feedback was a core architectural challenge.

How it's made

Challenges we ran into ## 1. 0G Compute Network Reliability The biggest challenge was integrating with 0G's decentralized inference network. Responses would sometimes come back with malformed JSON, time out at 90 seconds, or fail silently during provider acknowledgment. We built a 3 level JSON extraction fallback consisting of direct parse, stripping markdown fences, and regex extraction, and added exponential backoff retries. When LLM inference fails entirely, the system gracefully degrades to heuristic based attribution such as a 60/40 custom code to dependencies split so the pipeline never breaks. --- ## 2. Recursive Dependency Graphs and Cycle Detection Real world package ecosystems have circular dependencies. Our graph builder had to handle cycles mid traversal without infinite loops. We implemented adjacency based cycle detection before adding edges and added a hard cap of 1,000,000 traversal steps as a safety net. Tuning the decay multiplier and max_depth parameters to produce fair attribution weights without exponential blowup took significant iteration. --- ## 3. Academic Citation Data Is Fragmented For paper based projects, citation data does not live in one place. We built a 4 stage fallback chain. Parse LaTeX source first, fall back to PDF citation extraction, merge both if available, and finally query the Semantic Scholar API. Each stage is wrapped in error suppression so a single failure does not kill the full analysis. --- ## 4. arXiv Rate Limiting arXiv's API enforces strict rate limits and requires a minimum 3.1 second gap between requests. We implemented a process wide global lock, respected Retry After headers, and added a 300 second cooldown when rate limited. This serialization was tricky to get right in an async Python backend without deadlocking. --- ## 5. Stitching Together Unreliable APIs The core product depends on GitHub, arXiv, Semantic Scholar, npm, and PyPI, all with different rate limits, authentication schemes, and failure modes. The main engineering challenge was making the system resilient enough that any single API being down does not break the user experience, while still producing accurate contribution graphs when everything works.