Minto

PUBLIC DOCS

Public rules, verifiable flow, and payout boundaries

This page describes the current live blind box flow, what users can verify on-chain, how rewards are written after settlement, how jackpot contracts roll forward, and which payout rules still rely on backend bookkeeping or admin review.

BOX RULES

Public box lineup and purchase behavior

Standard0.50 USDC · regular inventory box · also used for signup and invite rewards
Variant1.00 USDC · paid inventory box · wider reward spread than Standard
Epic10.00 USDC · higher-value paid box · jackpot lane points are intended for ETH-track campaigns
Chase20.00 USDC · higher-value paid box · jackpot lane points are intended for BTC-track campaigns
  1. Buy deducts platform balance and adds one box to inventory. Buying does not auto-open.
  2. Open Now consumes one paid inventory box or one eligible free Standard box and then creates an on-chain open request.
  3. Only Standard can currently be granted by signup reward or invite reward.
  4. The box quantity shown in the UI is the backend inventory balance, not a front-end-only counter.

PUBLIC RANDOMNESS

How the current live contract produces a public result

  1. The frontend asks the backend for a signed authorization tied to one wallet, one box, one request number, and one expiry time.
  2. The user wallet sends requestOpen() to the active contract.
  3. The contract stores requestId, user, boxTypeId, requestHash, and a future settleTargetBlock, then emits BoxRequested.
  4. After the target block is ready, settleOpen() derives randomWord from the target block hash plus request data, then emits BoxSettled.
  5. The backend listener reads the public settlement event and writes a matching reward entry into the platform reward ledger and reward balances.
  6. Because the final randomWord is emitted by the contract first, the backend can project balances but cannot silently rewrite a settled outcome without contradicting the public chain record.
Current entropy sourcekeccak256(blockhash(settleTargetBlock), contract, user, requestId, boxTypeId, requestHash).
Who submits settlementThe platform listener currently auto-submits settlement, but the final output is determined by contract state and target block hash, not by a hidden off-chain reward choice.
Current integrity boundaryThis is publicly auditable testnet randomness, not production-grade VRF. It prevents off-chain reward rewriting, but it is not yet the final mainnet anti-manipulation model.

REWARD MAPPING

How a settled random result becomes a reward balance

  1. The current backend reward mapper uses the settled randomWord to choose a reward token lane and a fixed USD value step.
  2. The selected USD value is converted into token quantity at settlement time and recorded in the reward ledger.
  3. Historical opens keep their own contract address and rule binding, so later contract switches do not rewrite old request context.
  4. The reward history page and the reward balance page are chain-projected views: they are derived from public settlement events plus the currently bound reward rules.
Fixed on-chainrequestId, user, boxTypeId, settleTargetBlock, and final randomWord.
Projected off-chainReward balances, reward history, token quantity display, and withdrawal eligibility.
What this meansThe backend stores and displays rewards after settlement, but it does so from a public on-chain result rather than an invisible manual outcome.

JACKPOT & ROLLOVER

How jackpot lanes are designed, and what is live today

  1. Epic and Chase are the jackpot lanes. The contract already exposes public jackpot configuration, round state, user progress storage, and BTC / ETH price snapshots.
  2. The top-prize rule is a multi-point cycle: users accumulate jackpot points inside one active contract cycle instead of taking the top jackpot in a single spin.
  3. Jackpot lanes now only decide point progression and top-prize payout. Ordinary multiplier-style outcomes remain part of the normal small-token reward layer.
  4. Epic and Chase now use formula-based shared point rules that are fixed for one contract cycle from the stored ETH / BTC price snapshots and box prices. In the current build the point divisor follows ceil(referencePriceUsd / (3 * boxPriceUsd * jackpotEvShare)).
  5. When a top jackpot triggers, the payout is capped at the cycle’s configured top-prize reference value. If the live jackpot pool is still below that cap, the winner receives the full current pool instead of a synthetic fixed amount.
  6. After a top jackpot is finalized, the old contract is marked closing, a prepared standby contract is promoted to active, and new opens are routed to the new contract.
  7. The old contract remains responsible only for requests that were already created before closing. Once those requests settle or expire, the listener marks the old contract closed.
Price snapshotEach jackpot cycle stores BTC / ETH reference prices in the contract and uses them as that cycle’s valuation base, including the cap used for top-jackpot payout.
Top prize ruleFor both jackpot lanes, a winner receives min(current jackpot pool, 1 asset reference value). That means Epic uses the ETH reference cap and Chase uses the BTC reference cap; if the pool is still below that cap, the winner receives the full pool.
Point hit ruleThe contract publishes a divisor for each active cycle. A jackpot point is treated as hit when the public settlement random word falls into the divisor’s winning bucket; with the current snapshot assumptions that is about 2141 ppm for Epic and 214 ppm for Chase.
Rollover pathstandby -> active for the new contract, while the previous contract moves active -> closing -> closed.
Current build noteJackpot point accrual and winner progression are now settled from the public chain result inside the backend listener path. Final jackpot payment still moves through admin review and payout recording before the round is marked paid.

WITHDRAWALS

Minimum withdrawal rules in the current code

  1. The selected asset must have a full withdrawable amount worth at least 5 USDC.
  2. The account must have completed at least a minimal credited deposit requirement. The current code threshold is 0.001 in total credited deposit amount.
  3. Withdrawals always go to the currently connected wallet address and currently withdraw the full available amount of the selected asset, not an arbitrary partial amount.
  4. Users are allowed to withdraw credited funds even if they never open a box. Depositing and then leaving without opening is permitted by the current withdrawal rules.
  5. Jackpot payouts are not instant self-serve withdrawals. They move through admin review and payout recording before final paid status.
Current wallet bindingThe backend overwrites the destination with the connected primary wallet.
Reward withdrawalThe reward balance row is debited when the withdrawal request is created.
Platform balance pathIf the selected asset is a credited platform balance, the endpoint withdraws only the withdrawable portion after frozen funds are excluded.

WHAT USERS CAN VERIFY

Public records available to every user

Runtime contractThe currently active blind box contract address shown in Protocol and Docs.
Request transactionThe wallet-sent requestOpen() transaction and its BoxRequested event.
Settlement transactionThe follow-up settleOpen() transaction and its BoxSettled event with the final randomWord.
Rule bindingEach contract address is bound to a reward-rule version and jackpot-rule version so historical requests keep their own rule context.
Payout trailWhere applicable, request tx, settle tx, contract address, and jackpot payout tx can all be linked to the explorer.

EDGE CASES

Settlement windows, expiry, and user protections

  1. If a request is not settled before the target block window expires, it is marked expired.
  2. When a request expires, the system restores the reserved inventory, free quota, or paid balance for that request.
  3. If a contract is already closing, new requests should not be routed to it; only older pending requests continue settling there.
  4. The listener uses multiple RPC endpoints and retries settlement, but the chain still defines the final settlement window: once the target block is older than 256 blocks, the contract itself can no longer settle that request.
Why expiry existsThe current contract uses a blockhash-based settlement window. After that window, the required block hash is no longer available on-chain.
No silent lossAn expired request should restore the user’s reserved open resource instead of burning it silently.
Honest boundaryThe current build gives users a public request trail and replayable settlement logic, but it should still be described as a transparent testnet implementation rather than final mainnet-grade anti-cheat infrastructure.