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 the contract exposes box configs and reward rules, how rewards are written after settlement, and which payout steps still rely on backend bookkeeping or admin review.

OFFICIAL TECHNICAL NOTE

How to build a transparent on-chain blind box, and how Minto implements it in production

Transparency in on-chain gaming is not a marketing line. It should be a verifiable interface between product claims and cryptographic evidence. This note explains what a transparent blind box must publish, where Minto made practical engineering tradeoffs for gas and operability, and how users can independently verify core facts.

1) Minimum public information every transparent blind box should expose

  1. Runtime contract bindings: active contract per box type, effective block, and historical rotations.
  2. Rule commitments: on-chain rule hash, rule document hash, rule URI, and versioned binding policy.
  3. Randomness/settlement path: exact formula, entropy commit path, anti-replay and expiry constraints.
  4. Request traceability: request transaction/event identifiers and settlement sync trail.
  5. Payout transparency: public withdrawal lookup with auditable status transitions.
  6. Build provenance: prod/test code fingerprint visibility plus owner-control snapshot.

2) How Minto implements this today

  1. On-chain request with anti-replay: user wallet sends requestOpenLite(boxTypeId, roundId, requestRef, expiresAt, signature). Contract checks signature, uniqueness, expiry, and that roundSeedHash is already committed.
  2. Commit-reveal style rounds: current runtime mode is commit_reveal_v1, with round partitioning configured by CHAIN_OPEN_ROUND_SIZE (current default: 16384).
  3. Deterministic result formula: randomWord = keccak256(roundSeed, requestRef, userAddress, boxTypeId).
  4. Public trust endpoints: Minto publishes Transparency, Build Provenance, and payout lookup under /api/v1/payout-ledger/{withdrawNo}.

3) Engineering tradeoffs and gas best practices

  1. What Minto optimizes: keep user path lightweight with requestOpenLite, use round-level commitments, and avoid heavy per-request on-chain storage.
  2. Why this matters: a fully heavy on-chain settle path increases gas quickly; round-level commitment plus deterministic off-chain projection reduces user-side gas while preserving replayability.
  3. Honest boundary: this is a transparent, auditable implementation with anti-replay guarantees, but it is explicitly documented as not equivalent to final VRF-grade trust minimization.

4) Simple user verification workflow (2-5 minutes)

  1. Open Transparency and confirm runtime contract address + effective block.
  2. Check rule commitments (reward hash, doc hash, doc URI) for the active contract.
  3. Verify your request tx contains the expected BoxRequestedLite event.
  4. Confirm the referenced round has a committed roundSeedHash on-chain.
  5. If withdrawing, query payout status by withdrawNo and review its audit trail.
  6. Open Build Provenance to inspect code fingerprint and owner snapshot.

Transparency is not “everything on-chain or nothing.” The practical standard is whether users can independently verify what materially impacted their request, reward mapping, and payout path. That is the standard Minto is shipping toward.

BOX RULES

Public box lineup and purchase behavior

Standard1.00 USDC · regular inventory box · also used for signup and invite rewards
Variant5.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 requestOpenLite(boxTypeId, roundId, requestRef, expiresAt, signature) to the active contract.
  3. The contract verifies signature and anti-replay constraints, checks that roundSeedHash has been committed for the round, then emits BoxRequestedLite.
  4. The backend derives randomWord with the committed round seed and request tuple, resolves reward by the bound rule version, and syncs the result to platform ledgers.
  5. Each request keeps its own contractAddress, requestRef, and roundId, so historical requests remain traceable after contract switches.
  6. Because requestRef is unique and each round is hash-committed on-chain before requests are accepted, the backend cannot replay a request or silently swap a round seed without leaving a mismatch.
Current entropy sourcekeccak256(roundSeed, requestRef, user, boxTypeId).
Who submits settlementThe platform sets round seed hashes on-chain with setRoundSeedHash, and request-level reward sync is completed by the backend listener/runtime path.
Current integrity boundaryThis is a transparent commit-reveal style flow. It is auditable and anti-replay, but it is still not equivalent to production-grade VRF.

REWARD MAPPING

How a settled random result becomes a reward balance

  1. Each request binds to a concrete rule version and uses a deterministic randomWord, so one request maps to one reward outcome without hidden per-request overrides.
  2. Reward token code, name, amount, decimals, and display USD value are written into platform ledgers from the synced settlement result.
  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 reward balance page are deterministic projections from the synced request result and the rule version already bound into each request.
Fixed on-chainrequestId, user, boxTypeId, roundId, requestRef, and the committed roundSeedHash for that round.
Projected off-chainReward balances, reward history, token quantity display, and withdrawal eligibility.
What this meansRequest identity and round commitments are public, and reward projection follows a deterministic runtime path; the backend does not have a hidden per-request reward override.

RULE HASH VERIFICATION

Verify the published rule markdown against the on-chain hash

Enter a contract address, box type ID, and probability version. The page reads the on-chain rule document URI and hash, downloads the markdown file, computes keccak256 over the UTF-8 text, and checks whether both hashes match.

Rule document URI-
On-chain ruleDocHash-
Computed markdown keccak256-
Verification status-

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. Withdrawal requests enter admin review first. The current target SLA is within 8 hours, and payout is released only after approval.
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.
Review queueEach request is queued in the admin console and remains unpaid until approved.

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 requestOpenLite() transaction and its BoxRequestedLite event.
Round commit and sync trailThe on-chain setRoundSeedHash() commits plus each request tx hash and sync record used to write reward ledger entries.
Rule bindingEach contract address is bound to an explicit reward-rule set and jackpot-rule set so historical requests keep their own rule context.
Payout trailWhere applicable, request tx, round-commit tx, contract address, and jackpot payout tx can all be linked to the explorer.

EDGE CASES

Request expiry, retries, and user protections

  1. If a request is not fully synced in time, 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 sync aggressively, but a request still has a bounded lifecycle to avoid indefinite resource lock.
Why expiry existsExpiry prevents inventory or reserved balance from being locked forever when a request is dropped, not submitted, or cannot be synced in time.
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 implementation rather than final anti-cheat infrastructure.

SUPPORT

Need help, feedback, or a manual review?

Visit the dedicated Support & Feedback page if you need customer support, payout follow-up, wallet troubleshooting, or want to report a bug.

Open Support & Feedback