The response from the Hive community has been far greater than I was expecting with Hivepredict. Understandably, it's a bit of a gamble when someone builds something new and says, "Hey send me Hive and I promise the app will do what I say it will" especially with crypto in the toilet right now and Hive down from record highs.
So thanks for the trust and support: https://hivepredict.app
But progress keeps on marching forward and I've shipped some considerable updates to the app in the past few days.
Oh, and worth mentioning is one of the first auto-resolving markets on Hivepredict just closed. All winning participants were immediately paid after API data source resolution for a crypto market which I wrote about here: @beggars/hivepredict-just-paid-out-its-first-auto-resolving-markets
Community feedback highlighted a fairness concern: users could place predictions right before a market closes, when the outcome may already be apparent (e.g., a crypto price near its resolution target). This gives late participants an unfair advantage over early bettors who took on more risk.
The fix: HivePredict now enforces a proportional trading cutoff that automatically stops predictions before bettingClosesAt. The buffer equals 5% of the market's total duration, clamped between a 3-minute floor and a 72-hour (3-day) ceiling.
No schema changes were needed — the cutoff is computed dynamically from each market's createdAt and bettingClosesAt timestamps.
| Market Duration | 5% Buffer | Applied Buffer | Cutoff Before Close |
|---|---|---|---|
| 30 minutes | 90 seconds | 3 min (floor) | 3 min |
| 1 hour | 3 min | 3 min (floor) | 3 min |
| 2 hours | 6 min | 6 min | 6 min |
| 24 hours | 72 min | 72 min | ~1.2 hours |
| 7 days | 8.4 hours | 8.4 hours | ~8 hours |
| 30 days | 36 hours | 36 hours | 1.5 days |
| 60 days | 72 hours | 72 hours (ceiling) | 3 days |
| 90 days | 108 hours | 72 hours (ceiling) | 3 days |
Predictions submitted after the cutoff (via direct blockchain transactions) are automatically refunded.
For markets with auto-resolution via CoinGecko (e.g., "Will BTC hit $150k by March 1?"), HivePredict now displays live cryptocurrency prices directly on the market detail page.
coingecko: resolution source.This helps participants make more informed predictions and adds transparency to auto-resolution markets.
The original 5% trading cutoff was a good start, but markets with public data feeds such as live crypto prices, sports scores need a wider buffer because outcomes become increasingly predictable near the close.
The fix: Trading cutoff percentages are now category-aware:
| Category | Cutoff Buffer |
|---|---|
| Crypto | 10% |
| Hive | 10% |
| Sports | 8% |
| Tech | 5% (default) |
| Other | 5% (default) |
The same floor (3 minutes) and ceiling (72 hours) still apply. Crypto and Hive markets get the widest buffer because on-chain price data is publicly available and continuously updating.
To further discourage last-minute gaming, HivePredict now applies early bird time weighting to payout calculations. Predictions placed earlier in a market's life receive a larger effective share of the winnings.
Each prediction is assigned a time fraction between 0 and 1:
When payouts are calculated, each winner's effective stake is adjusted:
effectiveStake = stake × (1 - timeFraction × discountFactor)
With the default discount factor of 0.50:
Two users each bet 50 HIVE on YES in a 200 HIVE total pool:
| User | Stake | Time Fraction | Effective Stake | Share |
|---|---|---|---|---|
| Early | 50 HIVE | 0.0 | 50.0 | 66.7% |
| Late | 50 HIVE | 1.0 | 25.0 | 33.3% |
Despite equal stakes, the early predictor receives 2x the payout of the late predictor.
To keep payouts fair in one-sided markets, platform and burn fees are now treated as targets and can become variable at resolution.
targetFees = totalPool * (platformFeeRate + burnFeeRate) (default 8%)losingPool = totalPool - winningPoolactualFees = min(targetFees, losingPool)This means fees can be lower than the configured 3% + 5% when the losing-side pool is small.
Without this cap, a market could resolve correctly for a user, but still produce a net loss if fees were high relative to the losing side. The cap prevents "won but lost money on principal" outcomes.
200 - 36)Winners receive principal plus their share of the 164 profit pool (weighted by effective stake timing).
Result: winners break even on principal instead of losing despite being correct.
The market creation wizard received several improvements focused on reducing input errors and generating better market titles.
Numerical fields that represent currency or token amounts now use a custom formatted input component. Instead of plain number inputs (which are error-prone for large values), the fields display formatted values when not being edited:
$75,000 with dollar prefix and comma grouping — no more wondering if you typed the right number of zeros.1,500 with comma grouping for larger caps.When you click into a field, the formatting is stripped so you can type freely. On blur, the value is reformatted. The input uses inputmode="decimal" so mobile users get a numeric keyboard.
Previously, creators had to set both "Betting Closes" and "Resolves At" separately. This was redundant and error-prone — the proportional auto-cutoff system already computes when betting effectively stops based on the category-aware buffer (10% for crypto, 8% for sports, 5% default).
Now there's a single "Outcome Date" field. The platform automatically derives the betting close time:
This also moved the date field to Step 1 (before the title), so auto-generated titles include the timeframe:
The auto-generated titles for price markets now accurately reflect the chosen operator:
| Condition | Generated Title |
|---|---|
| at or above (>=) | Will BTC be at or above $65,000 by Mar 1, 2026? |
| at or below (<=) | Will BTC be at or below $65,000 by Mar 1, 2026? |
| above (>) | Will BTC be above $65,000 by Mar 1, 2026? |
| below (<) | Will BTC be below $65,000 by Mar 1, 2026? |
Previously all operators used generic wording like "reach" or "drop below" which didn't match the actual resolution condition.
The three-step wizard is now:
For manually resolved markets, not only can creators submit proof, but all bettor participants can now submit proof as well, and these submissions are recorded on-chain. This is designed to ensure creators do not control market outcomes on their own, and that participants can verify or counter proof claims to keep resolution fair and transparent.
HivePredict now supports manual markets with more than two outcomes, designed for events where many participants compete and exactly one winner is expected.
This enables markets for tournaments and competitions across sports and events, not just binary YES/NO questions.
O1, O2, O3, ...), with labels mapped to participant names.Markets still activate only when:
yesPool/noPool for binary compatibility, with outcomePools added for generalized outcome tracking.Market cards received a UI refresh to make multi-outcome markets easier to scan and to keep the homepage/market grids visually consistent.
+N more outcomes to keep cards compact.These changes improve scan speed and visual parity between binary and multi-outcome markets without changing market logic or API behavior.
The market detail page now includes a significantly more transparent Distribution & Proof tab for resolved markets.
totalPool - (winners + platform + burn))Each payout row now includes:
For payout types tied to participants (winnings, creator bonus, loss notifications, refunds), users now see linked prediction evidence:
This gives users a clear, auditable line from prediction placement to payout distribution on-chain.
To prevent partial audit displays on high-volume markets, the frontend now fetches all pages of predictions and payouts (paginated up to API limits) before rendering this tab, rather than relying on a single-page subset.
Manual market outcome submissions are now restricted to the resolution phase only.
pending.active markets, the tab and actions are shown only when allow_early_resolution is enabled.locked, suspended, and resolved history view).locked/suspended, and optionally in active when early resolution is enabled.resolved, voided, cancelled), outcome history remains visible but new submissions are blocked.The indexer handler for submit_market_proof now enforces the same status gate:
locked or suspended.active submissions only when allow_early_resolution=true.This keeps UI behavior and blockchain/indexer validation consistent.
Manual markets can now opt in to proof-based early resolution before expiry.
allow_early_resolution (manual markets only).active, locked, or suspended.active (in addition to locked/suspended).locked or suspended.resolved, voided, cancelled) remain closed to new proof and votes.HivePredict now supports on-chain voting on submitted market proofs so higher-confidence evidence can rise to the top.
hivepredict_vote_market_proofmarket_idproof_idvote (up or down)voteScore (descending)createdAt (descending)/api/markets/:id/proofs now returns vote metadata per proof:
voteScoreupvotesdownvotesmyVote (for requesting user)market_proof_votes table with uniqueness constraints for:
(proof_id, hive_username)(tx_id, hive_username, proof_id)There were also smaller and miscellaneous bug fixes, performance optimisations and improvements made to the app as well.
Give it a try if you haven't already: https://hivepredict.app and as always, feedback/suggestions and anything else is always welcomed. Many of the improvements made to the app have been because of the community.