EXECUTION_LAYER
NATIVE ENGINESDETERMINISTIC REDUCERSCONSENSUS-SAFE

HYBRID EXECUTION
ARCHITECTURE.

Exohash ships with a library of parameterized, deterministic game engines. Engines define rules and outcomes; the protocol enforces solvency and settlement.
Two modes: Session engines for independent bets, Arena engines for shared rounds.

TRUST BOUNDARY
minimized
Engines cannot move funds. They only emit transitions and outcomes; x/house settles from escrow.
RNG INPUT
height-based
Randomness is requested and resolved by block height to keep execution reproducible.
SCALE PATTERN
session + arena
1:1 bet reducers for speed; N:1 round reducers for multiplayer and ticked games.

Not all games share the same execution constraints. Exohash splits the world into two deterministic models: independent bet reducers and shared round reducers with scheduled wakeups.

Participants
Bet_1
Bet_2
Bet_3
Each bet has its own state machine and settles independently.

Bet Reducer

Event-driven transition per bet: validate → reserve → schedule RNG → finish.

MAX PAYOUT COMPUTABLE
RNG HEIGHT-BASED
Example Engines
dice_v1 — single-shot settle
mines_v1 — interactive + timeout
more session engines (registry)
Architecture

Engines are pure logic. The chain is the referee.

In the Exohash model, engines describe state transitions and payout intentions. The protocol controls funds, validates constraints, and applies settlement deterministically.

GAME DEFINITIONS
engine + JSON config + enable flag
  • • On-chain game catalog
  • • Parameterized markets
  • • Deterministic selection by id
x/house BOUNDARY
funds + reservation + settlement
  • • Engines never move money
  • • Keeper enforces solvency
  • • Outcomes settled from escrow
x/beacon BOUNDARY
height-based randomness inputs
  • • RNG resolved by height
  • • Wakeups schedule deterministically
  • • Reproducible across validators
NATIVE (GO) EXECUTION
DETERMINISTIC STATE MACHINES
NO CONTRACT SURFACE
DEVNET — ENGINE SET EXPANDING
EXECUTION CONTRACT

Determinism is the product.
Not just a property.

Engines follow a reducer-style contract: given the same inputs, every validator computes the same transition and the same settlement outputs. This makes games verifiable at consensus time.

A game definition provides an engine identifier plus JSON configuration. Players provide an opaque entry payload (their bet layout / action data). The protocol passes that payload to the engine without trusting the client to specify payouts.

Engines must expose a maximum theoretical payout for each entry so x/house can reserve liquidity before outcomes are resolved.

MAX PAYOUT COMPUTABLE
RTP REPORTING SUPPORTED
DEVNET — CONFIGS TUNING
INPUTS → TRANSITION → SETTLEMENT (HIGH LEVEL)
  • 1
    Entry payload
    Player supplies an opaque action/bet blob (e.g., mines layout, dice thresholds).
  • 2
    Config + validation
    Engine validates payload against a JSON config (limits, modes, edges).
  • 3
    Reserve max payout
    x/house reserves worst-case payout before accepting the entry.
  • 4
    Schedule RNG/timeout
    Engine requests RNG at a specific height (and/or timeout height).
  • 5
    Transition + outcomes
    Engine emits next state + payout intentions; keeper settles from escrow.
This page intentionally avoids implementation details. It describes the execution and trust model in a way suitable for diligence and system understanding.
Included in devnet

Engines currently implemented.

The engine set is expanding, but even at devnet stage it already demonstrates both execution models: single-shot settlement, interactive state machines, and tick-based multiplayer rounds.

dice_v1 (Session)
Single-shot reducer: resolves using beacon randomness and finishes immediately. Parameters support multiple modes (over/under/outside/between) with bounded house edge. RTP is explicitly reportable.
mines_v1 (Session)
Interactive reducer: alternates between WAITING_USER and WAITING_RNG. User actions schedule RNG at the current height and resolve on the next block. Includes inactivity timeout behavior for safe termination.
schrodinger_crash_v1 (Arena)
Round reducer with join window + ticks. Cashout intents included in block N settle at BeginBlock(N+1) when tick N is resolved using RNG(N). Designed for deterministic batch outcomes.
Invariants

What engines are allowed to do.

These constraints are deliberate: they keep execution verifiable, keep the solvency model intact, and prevent hidden discretionary controls.

No fund movement
Engines never debit/credit bankrolls directly. They return transitions and payout intentions; x/house validates solvency and applies settlement from escrow.
RNG is an input, not a dependency
Engines request randomness by height. The protocol supplies the seed deterministically from the beacon, making outcomes reproducible for every validator.
Max payout is computable upfront
Each entry must have a worst-case payout computable at admission time. This is mandatory for atomic reservation and solvency enforcement.
Devnet disclosure

Engine configs (limits, edges, join windows, timeout defaults) are being tuned during devnet. The execution contract is stable; the operational envelope is being hardened via adversarial testing.

Navigate the Architecture.

RANDOMNESSHOUSEENGINESECONOMICS
© 2026 EXOHASH PROTOCOL
System Status: Devnet Active