Skip to main content

Seasons & Leagues

Off-chain competitive progression with on-chain prize settlement at finalization checkpoints.

Overview​

Seasons and leagues are the long-horizon structure for competitive play in Monsuta Core.

  • Seasons define time-bounded competitive cycles.
  • Leagues define skill-tiered competition lanes inside each season.
  • Final outputs from each cycle can be settled on-chain through Prize Pools.

This follows Monsuta’s hybrid model:

  • Off-chain: gameplay, ranking, progression, and payout computation
  • On-chain: escrowed settlement, claims, and finality guarantees

Why Seasons and Leagues Exist​

Seasons and leagues solve three core problems:

  1. Progression clarity — players know their current tier and goals.
  2. Match quality — similarly skilled players are grouped.
  3. Economic cadence — payout events happen at predictable checkpoints.

They are designed to keep high-frequency competitive logic off-chain while still producing deterministic outputs for trust-minimized settlement.

Season Model​

A season is a fixed interval with its own ruleset and output policy.

Typical season responsibilities:

  • define start/end window
  • define eligible game modes
  • define league boundaries and transition policies
  • aggregate ranking and performance metrics
  • produce end-of-season standings
  • generate settlement bundles for eligible rewards

Suggested season states​

Draft
  -> Scheduled
  -> Active
  -> Locking
  -> Finalized Off-chain
  -> Settled On-chain (optional per reward track)
  -> Archived

League Model​

Leagues segment players by skill and progression.

Typical tiers:

  • Bronze
  • Silver
  • Gold
  • Diamond
  • Master (optional)

Each league can define:

  • entry criteria (rating threshold, placement history)
  • promotion % / relegation %
  • reward weighting multipliers
  • minimum activity requirements

Leagues are computed off-chain and updated continuously during season runtime.

Hybrid Finalization Flow​

At season end, logic is split cleanly:

Off-chain finalization​

  • freeze match ingestion for season window
  • compute canonical standings per league and global
  • apply tie-break rules
  • compute transition plan (promotions/relegations)
  • compute payout amounts for funded reward tracks
  • generate result hash + settlement bundle

On-chain settlement (when funded pool exists)​

  • submit winners + exact amounts to the corresponding Prize Pool
  • pool finalizes settlement state
  • winners claim directly from contract

This preserves performance while giving players cryptographic settlement assurances.

Settlement Output Contract (Conceptual)​

A finalized season should emit deterministic artifacts similar to:

{
  "seasonId": "season-09",
  "snapshotAt": "2026-06-30T23:59:59Z",
  "poolAddress": "0xPool...",
  "winners": ["0xA...", "0xB...", "0xC..."],
  "amounts": ["3040000000000000000", "1824000000000000000", "1216000000000000000"],
  "resultHash": "0x...",
  "metadata": {
    "scoringModel": "elo",
    "tieBreakPolicy": "wins_then_head_to_head_then_sos",
    "leagueScope": "global+league"
  }
}

Promotion and Relegation (Off-chain)​

Promotion/relegation should be deterministic and policy-driven.

Recommended policy inputs:

  • rank percentile per league
  • minimum matches played
  • anti-abuse checks (smurf detection, forfeits)
  • inactivity filters

Example model:

  • top X% promoted
  • bottom Y% relegated
  • middle cohort retained
  • ineligible/inactive players handled by explicit fallback rules

Persist outputs as immutable season artifacts for auditability.

Tie-Break Policy​

Tie-breaks must be explicit and stable before season starts.

Recommended ordering:

  1. total points / rating
  2. total wins
  3. head-to-head record
  4. strength of schedule (if applicable)
  5. earliest completion timestamp (or deterministic fallback)

Never use ad-hoc manual tie resolution for settlement-bearing ranks.

Reward Tracks​

Seasons can support multiple reward tracks:

  1. On-chain settlement rewards

    • funded via Prize Pool
    • winners claim on-chain

  2. Off-chain gameplay rewards

    • XP, cosmetics, progression unlocks
    • distributed by game backend

  3. Hybrid rewards

    • combined on-chain + off-chain package
    • represented as a single finalized season output

Security and Trust Boundaries​

Off-chain trust assumptions​

  • match results and anti-cheat decisions come from game backend authority
  • ranking calculations and transition logic execute off-chain

On-chain guarantees​

  • pool custody is contract-enforced
  • payout claims are winner-bound
  • cancellation/refund behavior follows contract state machine
  • finalized on-chain payout state is immutable

Operational Recommendations​

For production season settlement:

  • freeze season inputs before computing final outputs
  • compute and store canonical resultHash
  • use signed attestations for settlement payloads
  • enforce idempotency key per (seasonId, poolAddress, resultHash)
  • reject duplicate winner addresses and zero payouts before submission
  • monitor unresolved finalized seasons and claim-deadline windows

Integration Checklist​

  1. Define season schema and league policy
  2. Implement deterministic ranking + tie-break engine
  3. Emit season finalization artifact
  4. Map funded reward tracks to pool addresses
  5. Submit settlement bundle through authorized path
  6. Publish season archive + transition report
  7. Start next season with applied league transitions

Summary​

Seasons and leagues are the competitive backbone of Monsuta’s progression system.

  • They run off-chain for speed and flexibility.
  • They emit deterministic outputs for on-chain settlement when money is involved.

That is the intended operating model:

off-chain competitive execution + on-chain prize finality.