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: https://hive.blog/hivepredict/@beggars/hivepredict-just-paid-out-its-first-auto-resolving-markets
Proportional Auto-Cutoff for Last-Minute Predictions
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.
How It Works
| 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 |
What Users See
- Market cards now count down to the trading cutoff instead of the raw betting close time.
- The market detail page shows a "Trading Cutoff" stat card with a live countdown.
- The prediction form disappears once the cutoff is reached, with a message indicating betting is closed.
Predictions submitted after the cutoff (via direct blockchain transactions) are automatically refunded.
Live Crypto Prices on Market Pages
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.
How It Works
- The API fetches the current price from CoinGecko for any market with a
coingecko:resolution source. - Prices are cached server-side for 1 hour to stay within rate limits while keeping data reasonably fresh.
- The market detail page displays the live price alongside the resolution criteria target, so users can see at a glance how close the market is to resolving.
- This is independent of the resolution logic for determining an outcome, it's just a UI data point.
What Users See
- A "Live Price" card on the market detail sidebar showing the current asset price (e.g., "$97,432.15").
- The resolution target displayed below (e.g., "Target: BTC >= $150,000 USD").
- A timestamp showing when the price was last updated (e.g., "Updated 23m ago").
This helps participants make more informed predictions and adds transparency to auto-resolution markets.
Category-Aware Trading Cutoffs
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.
Early Bird Time Weighting
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.
How It Works
Each prediction is assigned a time fraction between 0 and 1:
- 0 = placed at market creation (earliest possible)
- 1 = placed at the trading cutoff (latest possible)
When payouts are calculated, each winner's effective stake is adjusted:
effectiveStake = stake × (1 - timeFraction × discountFactor)
With the default discount factor of 0.50:
- A prediction at market creation (tf=0) keeps 100% of its stake weight
- A prediction at the cutoff (tf=1) keeps only 50% of its stake weight
- A prediction at the midpoint (tf=0.5) keeps 75% of its stake weight
Example
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.
Key Properties
- Backward compatible: Existing predictions without time fraction data default to 0 (full weight), so historical markets are unaffected.
- Conservation: Total payouts never exceed the distributable pool — time weighting only changes the distribution among winners, not the total.
- No progressive fees: Late bettors aren't charged extra fees; they simply receive a smaller share of winnings per HIVE staked.
Variable Fee Cap to Protect Winner Principal
To keep payouts fair in one-sided markets, platform and burn fees are now treated as targets and can become variable at resolution.
Rule
targetFees = totalPool * (platformFeeRate + burnFeeRate)(default 8%)losingPool = totalPool - winningPoolactualFees = min(targetFees, losingPool)- Winners always receive at least their original stake back.
This means fees can be lower than the configured 3% + 5% when the losing-side pool is small.
Why This Change
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.
Example: Winning 250 vs Losing 200
- Total pool = 450
- Target fees = 36 (8% of 450)
- Losing pool = 200, so cap does not bind
- Actual fees = 36
- Profit pool to winners = 164 (
200 - 36)
Winners receive principal plus their share of the 164 profit pool (weighted by effective stake timing).
Example: One-Sided Market
- Winning side = 125
- Losing side = 10
- Total = 135
- Target fees = 10.8
- Actual fees = 10 (capped by losing pool)
- Profit pool to winners = 0
Result: winners break even on principal instead of losing despite being correct.
Redesigned Market Creation Flow
The market creation wizard received several improvements focused on reducing input errors and generating better market titles.
Currency-Formatted Inputs
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:
- Price Target (USD): Shows
$75,000with dollar prefix and comma grouping — no more wondering if you typed the right number of zeros. - Stake Cap: Shows
1,500with comma grouping for larger caps. - Opening Bet: Shows token amounts with up to 3 decimal places.
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.
Single "Outcome Date" Replaces Two Date Fields
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:
- Non-sports markets: Betting close = outcome date. The trading cutoff (which stops predictions early) is computed from the market duration and category.
- Sports auto markets: When you select an event, betting close is set to 1 hour before event start, and the outcome date to 4 hours after. The cutoff system adds an additional buffer on top.
This also moved the date field to Step 1 (before the title), so auto-generated titles include the timeframe:
- You set the asset, condition, price target, and outcome date first.
- The title auto-generates with the full context: "Will BTC be at or above $65,000 by Mar 1, 2026?"
- You can then tweak the title before proceeding.
Improved Title Wording
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.
Updated Wizard Steps
The three-step wizard is now:
- Market Details — Type, configuration, outcome date, title/description, category, labels
- Resolution — Resolution criteria and source (auto-generated for price/sports auto markets)
- Stake & Confirm — Stake cap, opening bet, side selection, summary
Manual Market Proof Transparency
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.
Multi-Choice Single-Winner Markets (Manual)
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.
What Changed
- New market type in the creation flow: Multi-Outcome Winner (Manual).
- Creators enter participants as a list (one per line or comma-separated).
- The platform generates internal outcome keys automatically (
O1,O2,O3, ...), with labels mapped to participant names. - At least two unique participants are required to create this market type.
- Creator opening bet side is selected from the generated outcomes (not limited to YES/NO).
Resolution and Proof Flow
- Manual proof submissions now support any configured outcome key, not just YES/NO.
- Admin approval/resolution actions support resolving to any configured market outcome.
- Market proof and decision history displays use each outcome's label so users see participant names, not raw keys.
Pooling and Display
- Pool aggregation and snapshots now track all configured outcomes dynamically.
- Market detail pages show outcome-by-outcome pool percentages for multi-choice markets.
- Market cards show leading outcomes for non-binary markets while preserving existing binary pool bars.
Activation Rules (Unchanged, Generalized)
Markets still activate only when:
- Minimum participant threshold is met.
- At least two outcomes are represented by placed predictions.
Backward Compatibility
- Existing binary markets continue to work unchanged.
- YES/NO constants and binary displays are preserved for legacy and binary market types.
- API responses still include
yesPool/noPoolfor binary compatibility, withoutcomePoolsadded for generalized outcome tracking.
Market Card Redesign (Homepage + Markets)
Market cards received a UI refresh to make multi-outcome markets easier to scan and to keep the homepage/market grids visually consistent.
Multi-Outcome Card Presentation
- Non-binary markets now use a dedicated Outcome Split block with ranked outcome rows.
- Each row shows:
- outcome label
- thin momentum/probability bar
- right-aligned percentage pill
- Cards show top outcomes first and summarize the remainder as
+N more outcomesto keep cards compact.
Grid and Spacing Improvements
- Removed forced full-height stretching so smaller cards no longer expand to match the tallest card in a row.
- Grid items are now top-aligned, reducing large blank regions caused by mixed card content lengths.
- Verbose forming-market helper text was removed from cards; status is still clearly indicated by the FORMING badge.
These changes improve scan speed and visual parity between binary and multi-outcome markets without changing market logic or API behavior.
Resolved Market Distribution and Chain Proof View
The market detail page now includes a significantly more transparent Distribution & Proof tab for resolved markets.
What Users Can See
- Fund distribution summary for the market pool:
- Total sent to winners (winnings + creator bonuses)
- Platform fee amount
- Burn amount
- Pool accounting delta (
totalPool - (winners + platform + burn))
- Resolution-level chain proof:
- Direct link to the market resolution transaction
- Total amount distributed from the resolved pool
- Loss-notification memo totals (when present)
Per-Payout Audit Details
Each payout row now includes:
- Recipient and payout type
- Payout status (pending/processing/sent/confirmed/failed)
- Created/confirmed timestamps
- Source transaction (resolution tx) link
- Transfer transaction link (when sent) or pending state
- Matched history tx (if replay-safety reconciliation found a prior transfer)
- Stored payout memo (when available via payout forensics metadata)
Prediction Evidence Per Recipient
For payout types tied to participants (winnings, creator bonus, loss notifications, refunds), users now see linked prediction evidence:
- Prediction outcome label
- Stake amount and token
- Prediction timestamp (blockchain UTC display)
- Prediction transaction link
- Allocated prediction payout amount (when applicable)
This gives users a clear, auditable line from prediction placement to payout distribution on-chain.
Data Completeness Improvements
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.
Outcome Submission Phase Gating (UI + Indexer)
Manual market outcome submissions are now restricted to the resolution phase only.
What Changed
- The Outcome tab is hidden on manual markets in
pending. - For
activemarkets, the tab and actions are shown only whenallow_early_resolutionis enabled. - The tab is always shown during resolution/finalization phases (
locked,suspended, and resolved history view). - Proof submission and admin review actions are enabled in
locked/suspended, and optionally inactivewhen early resolution is enabled. - On finalized markets (
resolved,voided,cancelled), outcome history remains visible but new submissions are blocked.
Server Enforcement
The indexer handler for submit_market_proof now enforces the same status gate:
- Accepts proof submissions only when market status is
lockedorsuspended. - Accepts
activesubmissions only whenallow_early_resolution=true. - Rejects submissions for all other statuses, preventing client-side bypasses.
This keeps UI behavior and blockchain/indexer validation consistent.
Early Manual Resolution Before Expiry (Proof-Based)
Manual markets can now opt in to proof-based early resolution before expiry.
What Changed
- New create-market flag:
allow_early_resolution(manual markets only). - If enabled:
- proof submission and proof voting are accepted while status is
active,locked, orsuspended. - admin manual resolution is allowed while
active(in addition tolocked/suspended).
- proof submission and proof voting are accepted while status is
- If disabled (default):
- proof submission, proof voting, and admin resolution are allowed only in
lockedorsuspended.
- proof submission, proof voting, and admin resolution are allowed only in
- Frontend now surfaces this capability clearly with a Can Resolve Early badge on market cards and market detail pages.
- The create-market flow includes an explicit toggle so creators can choose whether participants can exit early based on proof.
Guardrails
- Pending markets are still blocked from proof submission and proof voting.
- Resolution still requires valid matching proof for the selected outcome.
- Finalized markets (
resolved,voided,cancelled) remain closed to new proof and votes.
Participant-Only Proof Voting and Ranking
HivePredict now supports on-chain voting on submitted market proofs so higher-confidence evidence can rise to the top.
New Capability
- New custom_json operation:
hivepredict_vote_market_proof - Vote payload:
market_idproof_idvote(upordown)
Voting Rules
- Only market participants can vote:
- market creator, or
- any account with at least one prediction in the market
- Users cannot vote on their own proof.
- One active vote per user per proof:
- voting again updates the prior vote (upsert behavior)
Proof Ranking + API Response
- Proof lists are now sorted by:
voteScore(descending)createdAt(descending)
/api/markets/:id/proofsnow returns vote metadata per proof:voteScoreupvotesdownvotesmyVote(for requesting user)
Frontend UX
- Proof cards now show score and vote counts.
- Participant users can upvote/downvote directly from the market detail Outcome tab.
- Buttons reflect the user’s current vote state and block disallowed actions.
Schema + Migration
- Added
market_proof_votestable with uniqueness constraints for:- one vote per
(proof_id, hive_username) - replay-safe tx uniqueness on
(tx_id, hive_username, proof_id)
- one vote per
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.
This does not make sense for sport bets.
I don't think I made this clear in the post, but the time weighting is for crypto markets to avoid people coming in right before close and winning when someone who entered the market earlier gets effectively penalised for being early. Sports don't have this. The concern was a market could say "Will Bitcoin be X by Y", the market runs for a month, someone comes in the day before when it's a little more clearer the direction Bitcoin is going and can make a more data-driven prediction using information someone didn't have 2 weeks prior or whenever. I'm currently working on templates for the site so markets are configurable by the end user for all markets for the criteria of outcome predictions anyways. I'm moving away from the platform deciding the rules for everything.