Operator questions, answered.

A market-powered payout engine that sits behind your existing operator stack and resolves recurring, time-boxed sessions into player payouts — without putting house-risk on your balance sheet.

Two integration surfaces against the same engine: a REST API for operators that already have a front-end, and a drop-in Shadow-DOM widget (Solo and Versus bundles) for operators that want a ready-made player surface. You keep full ownership of the player relationship, branding, wallet and KYC.

No. It is engine-powered payout generation for casino, betting, gaming and prediction-market ecosystems. The end-user does not open a position, does not hold an instrument and does not receive a financial product. They participate in a branded game session whose outcome is generated by the engine layer.

No. The player surface is fully white-labelled — no instrument names, no charts, no broker UI, no engine references. The operator-side views shown in the demos exist only for due diligence and are not exposed in production.

Solo is player-vs-engine: the player stakes on a single session and the engine resolves it into a payout multiplier. Versus is two-sided: players pick one of two opposing sides on the same engine round and resolve together — operators choose preset matchups (Red vs Blue, AI vs Crowd) or set custom side labels. Both modes share session cadence, settlement, and integration shape.

Three productised cadences, all UTC-aligned: 24 sessions per day (1h windows), 6 per day (4h windows), or 1 per day (24h windows). Cadence is fixed per widget instance — the player cannot change it. Operators pick the cadence per product or per cohort.

Autoplay is additive-only. A player can queue N upcoming sessions at a chosen stake; each upcoming session is debited up-front through the operator proxy with an Idempotency-Key. There is no cancel-upcoming flow by design — once enqueued, a session participates. This keeps autoplay liability deterministic for both operator and engine.

Win-rate is configurable per product and per cohort, with a documented operating band up to ~55%. It is enforced at the engine-mapping layer (session P&L → payout multiplier tiers from 0× through 4×), not by post-hoc adjustment of balances.

When a Versus round resolves with winningGroup = "tie", every participant is refunded at 1.00× — a push. Operator and engine both surface this in the participation history with the same idempotency semantics as a normal payout.

Either flavor against the same engine. (A) Pure API — server-to-server REST for session lifecycle, bets, autoplay, and participation polling. (B) White-label widget — a self-contained JS bundle (Solo or Versus) that mounts inside a Shadow DOM for full style isolation. Both ship from /integrate behind a download password.

Every call carries X-Operator-Key (server-side only, never browser-exposed), X-User-Id, and X-Session-Type ("1h" / "4h" / "24h"). Write endpoints (/bets, /autoplay) additionally require an Idempotency-Key — replays within a 24h window return the original response instead of double-charging.

Because the operator key must never reach the browser, and because the operator wallet must debit player funds before the bet is forwarded. The proxy: (1) holds the operator key, (2) inspects POST /{solo|versus}/bets and /autoplay bodies, (3) debits the wallet, (4) forwards to MPPE, (5) refunds on any non-2xx response. /integrate ships a reference proxy.

By poll, not push. The operator backend polls GET /{solo|versus}/ops/participation/past on a schedule (typically once per cadence window) and credits any new winning rows to player wallets. Credits are idempotent on sessionId, so re-poll is safe. There is no MPPE→operator webhook by design — fewer moving parts, no signature verification surface.

Yes. The widget ships with six visual variants (minimal, arcade, casino, degen, terminal, wheel) plus auto / mobile / desktop layouts. The minimal variant additionally respects a light/dark theme flag. All chrome lives inside a Shadow DOM so host-page CSS cannot leak in or out.

No. The operator wallet retains custody end-to-end. MPPE only sees stake metadata (user_id, amount, currency, side, mode). All debits and credits happen inside the operator stack, gated by the operator proxy.

Off the operator's balance sheet. The engine generates the player payouts directly out of session P&L. The operator runs recurring gaming revenues — and earns a revenue share on every resolved session — without warehousing payout risk internally. That is the core economic shift versus traditional house-risk models.

USD, USDT, USDC plus the top-10 cryptos (BTC, ETH, SOL, BNB, XRP, ADA, DOGE, TON, AVAX, LINK). Operator and engine revenues settle in stablecoin; player wins are paid out in the same native currency the player bet in.

Stablecoin settlement to the operator typically completes within ~30 minutes of session resolution. Per-player payouts are available for crediting as soon as the relevant participation row appears in /ops/participation/past.

All operator-side responsible-gaming primitives — deposit limits, session limits, cool-off, self-exclusion, reality checks — sit at the operator wallet/account layer and are unaffected. The engine layer additionally respects per-player and per-session caps configured by the operator.

The operator, in their respective jurisdictions. MPPE is a B2B software platform licensed to regulated operators — we are not an operator, broker, exchange, casino, sportsbook or prediction market, and we do not offer, accept or settle wagers with end users.

Every event — bet placed, session opened, round executed, session resolved, payout generated, settlement transferred — is captured and exposed via the reporting API and an operator dashboard. Full audit trail per user, per session, per cohort.

Recurring revenue share on resolved sessions. The operator earns gaming revenues without house-risk; we earn a share of the engine-generated payout flow. Concrete economics are shared under NDA during procurement — see /commercials for the structural overview.

Widget flavor: days, not weeks — drop the script, point it at your proxy, configure cadence and variant. Pure-API flavor: typically 2–4 weeks including operator-proxy wiring, wallet debits, participation polling, and reconciliation tests.

Request a demo from /contact. We share the spec, the widget bundles, the reference proxy, and a sandbox API key so your team can wire a Solo or Versus session end-to-end in a staging environment before any commercial discussion.