A technical approach to answering two simple questions: Is it good? Do people use it?
Bitcoin miners compete to compute the most hashes per second. Burn more electricity, earn more block rewards. The elegance is real. So is the waste.
What if that same spirit of rigorous, verifiable proof were applied to a question that actually matters? Not "did you burn enough electricity?" but "does your project solve real problems for real people?"
The foundational shift
Bitcoin's consensus mechanism asks: Did you demonstrate sufficient computational commitment to deserve validating this block?
Proof of Usefulness asks: Does this project create demonstrable value in the world?
The architectural goal is the same in both cases — produce a score that cannot be easily faked and that correlates with something real. The difference is what "something real" means. In Bitcoin, it means electricity burned. In Proof of Usefulness, it means people helped.
The formula
PoU_score = Σ(w_i × C_i × Q_i) + R_factor
w_i (weight factors): Statistical weights reflecting the patterns startup failure research consistently identifies as predictors of lasting value creation.
C_i (criterion scores): Normalized 0–100 scores per criterion, generated from response analysis and independent evidence validation.
Q_i (quality multipliers): Response quality modifier based on specificity, depth, and the availability of supporting evidence. Vague claims score lower. Quantified claims with verifiable links score higher.
R_factor (randomization component): A ±20% market uncertainty variance that prevents threshold-gaming. Projects cannot strategically position just above a scoring boundary — genuine utility accumulates advantages across multiple evaluations, while marginal projects fluctuate.
The seven scoring tiers
| Score Range | Tier | Meaning |
|---|---|---|
| 751–1000 | Unicorn Utility | Undeniable utility with massive, documented adoption |
| 601–750 | Category Standard | Default choice; trusted across the category |
| 451–600 | Industry Mainstay | Definitive solution to a recognized market problem |
| 301–450 | Certified Problem Solver | Self-sustaining, with demonstrated long-term stability |
| 101–300 | Gaining Momentum | Transitioning from interesting idea to serious contender |
| 0–100 | You're In Business | Deployed and functional; the world did not crash |
| −100 to 0 | Lab Mode | Almost ready for the world to see |
The six evaluation criteria
Real-World Utility (25%): Does this solve a genuine problem? Is the solution practical and immediately usable? Scored 0–100 on problem-solution fit quality.
Evidence of Traction (25%): Can claims be independently verified? Web presence validation, user adoption signals (GitHub activity, download counts, community engagement), media coverage, testimonials, financial disclosures. Scored 0–100 based on the strength and diversity of verifiable signals.
Audience Reach & Impact (20%): Verified reach against claimed reach. Growth trajectory. Retention cohorts. Scored 0–100 based on genuine scale and momentum.
Technical Innovation and Stability (15%): Novel application of technology combined with implementation reliability. Scored 0–100 on the dual axis of competitive differentiation and operational dependability.
Market Timing & Relevance (10%): Is this addressing a current need? Is the competitive landscape navigable? Scored 0–100 based on timing fit and positioning.
Functional Completeness (5%): Does it actually work, right now, for real users? Scored 0–100 based on implementation quality and submission polish.
Cross-validation: the anti-bullshit layer
Projects self-report metrics. We then verify against independent sources:
- Web traffic data and behavioral signals (time-on-site, bounce rate, return visits)
- API usage patterns and rate data
- GitHub repository activity (stars, forks, open issues, contributor diversity, dependent repositories)
- Social media engagement quality (not follower counts — conversation depth)
- Financial disclosures and revenue indicators
- News coverage and on-chain data where applicable
Claimed user counts without verifiable evidence are discounted 80–90%. Revenue claims without supporting signals score accordingly. Technical descriptions that contradict publicly accessible code are penalized directly.
The system is designed around a single premise: if your utility claims are true, evidence of that utility should exist somewhere in the public record. Useful tools leave traces.
Usage is the new valuation.
Sources
- https://www.cbinsights.com/research/report/startup-failure-reasons-top/
- https://www.bls.gov/bdm/bdmage.htm
This post was AI assisted based on exclusive content from internal HackerNoon meetings, documents, code, discussions, and product development workflows for Proof of Usefulness. It was edited by HackerNoon staff. If you are interested in trying out HackerNoon's beta tool to turn your existing Slack, GitHub, Zooms, and more into quality public posts, book a business blogging meeting.