Skip to main content

Philosophy

Design rules that govern every decision in Monsuta Core.

Core Rule​

Only meaningful economic events go on-chain.

┌──────────────────────────────────┐
│           OFF-CHAIN              │
│                                  │
│  • combat resolution             │
│  • matchmaking                   │
│  • movement / input              │
│  • inventory state               │
│  • AI behavior                   │
│  • per-match actions             │
│  • chat                          │
│                                  │
└──────────────┬───────────────────┘
               │ only economic finality
               ▼
┌──────────────────────────────────┐
│           ON-CHAIN               │
│                                  │
│  • tournament payouts            │
│  • reward claims                 │
│  • crafting permanent items      │
│  • achievement minting           │
│  • token bridging                │
│  • staking deposits/withdrawals  │
│                                  │
└──────────────────────────────────┘

Why: Real-time multiplayer games produce thousands of events per second. Blockchain cannot process this without ruining the player experience. The only events that benefit from immutability and trustlessness are economic outcomes — who won, who gets paid, what was created.

Design Principles​

1. Server Authority, Blockchain Settlement​

  • The game server is the source of truth for gameplay.
  • The blockchain is the source of truth for economic outcomes.
  • Neither replaces the other.

Why: This is how competitive games already work. Adding blockchain to the settlement step introduces trust without introducing latency.

2. No Wallet Required to Play​

  • Players interact with the game using standard login (username, email, social).
  • Wallet connection is only needed when:
    • claiming rewards
    • entering funded tournaments
    • minting or transferring assets

Why: Requiring a wallet before a player can even start a match kills onboarding. Web2 usability must be preserved.

3. No Passive Yield by Default​

  • Gameplay currency is not a yield token.
  • Staking does not produce emissions unless explicitly configured.
  • Currency enters circulation through gameplay activity, not holding.

Why: Passive yield creates sell pressure with no demand-side counterpart. Games that rewarded holding over playing universally experienced:

  • Botting
  • Token inflation
  • Rapidly declining DAUs

4. Configurable, Not Opinionated​

  • The staking system supports multiple models (emissions, pooled, hybrid).
  • The competition layer supports multiple formats (seasonal, event-based, leaderboards).
  • Projects define their own parameters.

Why: Every game has different economic needs. A fixed staking curve or reward formula would force projects to fork the system instead of configuring it.

5. The Developer Is Not the Bank​

  • Prize pools are held by smart contracts.
  • Rewards are claimable by winners directly.
  • The game operator cannot redirect, withhold, or seize reward funds.

Why: Third-party tournament funding (guilds, streamers, sponsors) requires trust. Smart contract custody removes the need for players or sponsors to trust the game developer with prize money.

6. Modules Are Independent​

  • A game can use the competition layer without the staking system.
  • A game can use crafting without the identity layer.
  • Each module has its own contracts and interfaces.

Why: Monolithic systems create forced dependencies. A casual puzzle game does not need tournament infrastructure. A competitive FPS does not need crafting. Modularity allows selective adoption.

Decision Framework​

When deciding whether a feature should be on-chain or off-chain, apply this test:

┌─────────────────────────────────────────────────┐
│  Does this event involve:                       │
│                                                 │
│  □ Transfer of value (tokens, NFTs)?            │
│  □ Permanent record (achievement, trophy)?      │
│  □ Trustless verification (payout, claim)?      │
│  □ Third-party interaction (funding, trading)?  │
│                                                 │
│  YES to any → ON-CHAIN                          │
│  NO to all  → OFF-CHAIN                         │
└─────────────────────────────────────────────────┘

Examples​

EventOn-ChainOff-ChainReason
Player moves in match✓No economic value, high frequency
Player wins match✓Result tracked internally, no payout yet
Player claims season reward✓Token transfer, requires trustlessness
Player crafts legendary item✓Permanent NFT, tradable
Matchmaking queue✓Ephemeral state, latency-sensitive
Sponsor funds a tournament✓Third-party value transfer into contract

Anti-Patterns​

These are patterns Monsuta Core explicitly avoids:

Anti-PatternProblem
Every action on-chainWallet popups, gas costs, 3-second latency per move
Passive NFT stakingRewards without gameplay, incentivizes botting
Uncapped token emissionsInflation with no demand sink
Developer-held prize poolsTrust dependency, single point of failure
Mandatory wallet for gameplayKills onboarding, excludes Web2 players
Monolithic smart contractUpgrading one feature requires redeploying everything