Blackperp Earns a 36 Proof of Usefulness Score by Building a Real-Time Decision Engine for Crypto Perpetual Futures

In this interview, we sit down with Mike, the creator of Blackperp, to discuss their innovative trading platform. Blackperp is a real-time decision engine tailored for crypto perpetual futures, utilizing self-learning loops to process 173 live signals and deliver actionable trade setups.

What does Blackperp do? And why is now the time for it to exist?

Blackperp is a real-time decision engine for crypto perpetual futures. It fuses 173 live signals from 11 sources into actionable trade setups — direction, entry, stop loss, and take-profit targets — across 21 symbols and 3 timeframes, updated every 10 seconds. A self-learning loop recalibrates signal weights daily based on measured outcomes, so the engine continuously improves itself. Now’s a good time for Blackperp to exist because crypto markets move at a blistering pace, and traders desperately need automated systems capable of synthesizing complex, high-frequency data into actionable decisions rather than just staring at overwhelming dashboards.

What is your traction to date? How many people does Blackperp reach?

We just started so we don`t have any customers yet. We use it ourselves to trade and learn the engine.

Who does your Blackperp serve? What’s exciting about your users and customers?

Active crypto perpetual futures traders — scalpers, day traders, and swing traders — who want a system that synthesizes data into decisions, not just dashboards.

What technologies were used in the making of Blackperp? And why did you choose ones most essential to your techstack?

To build a lightning-fast and highly reliable decision engine, we utilized a robust modern tech stack featuring TypeScript, Node.js 20, Next.js 14, and Fastify. For data persistence, rapid caching, and live market integrations, we rely on PostgreSQL, Redis, and Binance WebSockets, while incorporating Claude Opus for advanced AI-driven analysis and continuous feedback loops.

What is traction to date for Blackperp? Around the web, who’s been noticing?

While Blackperp is in its earliest stages regarding user adoption and doesn't have active external customers yet, the project is already building awareness through educational content marketing. Articles discussing the pitfalls of single-indicator trading and dashboard fatigue in perpetual futures have been published across platforms like Publish0x, Vocal, and Medium.

Blackperp scored a 36 proof of usefulness score (https://proofofusefulness.com/reports/blackperp) - how do you feel about that? Needs reassessed or just right?

It's honest. A 36 reflects a technically complete product with zero public users — and the algorithm is right to weight traction heavily. We built the engine, the self-learning loop, the content footprint, and 12 free tools, but none of that matters until traders are actually using it. We'd rather come back in a few months with verifiable timestamps from our autonomous X/Twitter engine and real traffic data than argue for a higher score we haven't earned yet.

What excites you about this Blackperp's potential usefulness? *

Every crypto trading tool today shows you data and leaves you to figure it out. Blackperp closes that gap — it tells you what to do, why, and measures whether it was right. The self-learning loop means the engine gets smarter every day from its own outcomes, not from backtested assumptions. That feedback cycle doesn't exist anywhere else in retail crypto tooling.

Walk us through your most concrete evidence of usefulness. Not vanity metrics or projections - what's the one data point that proves people genuinely need what you've built?

The engine caught a win-rate measurement bug that would have fooled any human operator. Our self-learning loop was reporting 63.9% win rate, but when we audited the win classification logic, actual win rate was 8.8%. The system was counting MFE-based proxy wins instead of realized P&L. A human looking at a dashboard would have shipped a broken product with confidence. The feedback loop's architecture — paper-trading every signal tick-by-tick against live Binance prices — made the discrepancy visible and fixable. That's the usefulness: a system that catches its own lies before users pay for them.

How do you measure genuine user adoption versus "tourists" who sign up but never return? What's your retention story?

We haven't launched publicly yet, so we don't have retention data to share. What we can say is that the product is architecturally built for retention: the engine produces 63 fresh decisions every 10 seconds across 21 symbols and 3 modes. It's not a tool you check once — it's a live feed that changes with every market tick. Our retention thesis is that traders who see the engine get a call right with evidence they can verify will come back because no other tool gives them that. We'll measure retention by daily active decision views per user, not signups.

If we re-score your project in 12 months, which criterion will show the biggest improvement, and what are you doing right now to make that happen?

Traction. Right now the engine is live and the content footprint is 550+ pages across 3 languages, but we have zero public users. In 12 months, the X/Twitter social engine (autonomous signal posts, liquidation alerts, daily recaps with public timestamps) will have built a verifiable track record. Traders can look back at 365 days of calls and check every one against the chart. That's the acquisition flywheel we're building now — credibility through radical transparency, not ad spend.

How Did You Hear About HackerNoon? Share With Us About Your Experience With HackerNoon.

Through research into platforms that reach technical builders and crypto-native audiences. HackerNoon's editorial model — long-form, no-gatekeeping, SEO-indexed — aligns with how we're building Blackperp's content strategy: publish what we actually build, let the work speak.

Since you are currently the only users of Blackperp to trade and learn the engine, what is your go-to-market strategy to acquire your first 100 active scalpers or day traders?

Public timestamps on X/Twitter. The autonomous social engine posts every signal flip, every liquidation alert, and a daily recap — all timestamped and verifiable against price charts after the fact. Crypto traders trust receipts, not promises. Month one is conservative engagement to avoid shadowban risk on a new account. Telegram launches in parallel — same data pipeline, different distribution channel. After X traction, we add Reddit (comment-first karma building before posting links), then a 24/7 YouTube live stream of the dashboard. The first 100 users come from traders who verify our calls were right before they ever sign up.

Once you launch publicly, how do you plan to scale your backend infrastructure to support the continuous self-learning loop across a growing user base running high-frequency 10-second updates?

The architecture already separates concerns: the worker (data ingestion, 173 cards, decision engine) runs independently from the API layer (Fastify reading from Redis) and the web layer (Next.js). Redis handles all real-time state. The self-learning loop runs once daily against PostgreSQL — it's a batch job, not a per-user computation. Scaling to more users means scaling the API and web layers horizontally, which is straightforward since they're stateless readers. The expensive part — ingesting 11 data feeds and computing 63 decisions every 10 seconds — runs once regardless of user count. We don't recompute per user. The architecture was designed this way from day one.

With the engine recalibrating signal weights daily based on measured outcomes, can you share an example of a specific trade setup where Blackperp successfully learned from a mistake and corrected its own logic?

The clearest example is the win-rate correction itself. The learner was using MFE (maximum favorable excursion) as a proxy for wins — meaning if price ever touched a favorable level during a trade's lifetime, it counted as a win, even if the trade ultimately lost money. This inflated reported win rate to 63.9%. After correcting to realized P&L (actual outcome after partial exits at 50/25/25), true win rate dropped to 8.8%. The learner then recalibrated category weights based on accurate data — which is the entire point: the system measured, detected that its own scoring was wrong, and the correction propagated through the next recalibration cycle. We also discovered that 83 historical rows in the database had been corrupted by the old logic and cleaned those manually to prevent future training on bad data.