Design Philosophy
Every decision in Monsuta Core traces back to one of these principles. Understanding them explains why things work the way they do — and why certain common blockchain gaming patterns are deliberately excluded.
The Core Rule
Only economically meaningful events go on-chain.
This is the single rule from which everything else follows. It sounds obvious, but it cuts against the instinct of most blockchain game designs, which try to put as much as possible on-chain to signal decentralization.
The reality is that putting things on-chain has real costs: latency, gas fees, wallet friction, and cognitive overhead for players. Every on-chain interaction is a moment where someone might quit. The question isn't can we put this on-chain — it's does this actually need to be on-chain?
┌──────────────────────────────────────────┐
│ OFF-CHAIN │
│ │
│ • combat resolution │
│ • matchmaking & queue management │
│ • movement / player input │
│ • inventory and deck state │
│ • AI and physics │
│ • per-match actions │
│ • authentication and sessions │
│ │
└──────────────────────┬───────────────────┘
│ only when economic finality
│ is actually required
▼
┌──────────────────────────────────────────┐
│ ON-CHAIN │
│ │
│ • tournament prize payouts │
│ • staking reward claims │
│ • crafting permanent items │
│ • achievement minting │
│ • token bridging between chains │
│ • NFT ownership transfers │
│ │
└──────────────────────────────────────────┘
Real-time multiplayer games produce thousands of events per second. A blockchain cannot process this without destroying the player experience. The only events that genuinely benefit from immutability are economic outcomes — who gets paid, what was created, what moved between chains.
The 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, and neither should try to.
This is actually how competitive games already work — a game server decides who wins; Monsuta Core just extends that model so the payment step is also trustless. You're not changing how the game works. You're making the money part safe.
In practice: Combat, matchmaking, and state management stay on the server. Prize payouts, crafting, and token claims go on-chain.
2. No Wallet Required to Play
Players use standard authentication — username, email, or social login — to play. A wallet is only required when:
- Claiming a prize from a pool
- Bridging tokens between chains
- Crafting or minting an on-chain item
- Staking NFTs
This is a non-negotiable constraint. Requiring a wallet before a player can start their first match kills onboarding. Web2 usability must be preserved for the gameplay layer.
What happened when games ignored this: Wallet setup became a prerequisite for fun. New players arrived, saw a MetaMask prompt, and left. The games that survived had the highest technical barrier to entry in gaming history and wondered why their DAUs were low.
3. No Passive Yield by Default
Gameplay currency is not a yield token. Staking does not produce emissions by default. Currency enters circulation through gameplay activity — not through holding.
This is the most commonly violated principle in blockchain gaming, and the consequences are consistent every time:
- Players optimize for accumulation, not for playing
- Bot farms emerge because "playing" is just holding
- Token supply grows with no corresponding demand
- Price drops, rewards are worth less, the cycle accelerates
Monsuta Core supports multiple staking reward models, but they are all explicitly configured and funded. Nothing emits tokens by default just because someone holds an NFT.
4. Configurable, Not Opinionated
The staking system supports multiple reward models (fixed emissions, pooled, hybrid). The competition layer supports multiple formats (seasonal, event-based, leaderboards). Prize splits, epoch durations, lock periods, and settlement tokens are all deployment-time parameters.
No economic logic is hardcoded to a specific game's needs.
Why this matters: A fixed staking curve or prize formula would force every adopting project to fork the contracts instead of configuring them. Forks mean diverging security, missing upstream fixes, and duplicated auditing effort. Configuration is always better than forking.
5. Trustless Fund Custody
Prize pools are held by smart contracts. Winners claim directly. The game operator cannot redirect, withhold, or access prize funds.
This exists because competitive gaming — especially with external sponsors, guilds, and third-party prize contributions — requires trust that the prize money will actually reach the winners. Smart contract custody removes the need to trust any individual with that money.
In practice: PrizePool.sol has no admin withdrawal function for prize funds. The only way money leaves the contract is through claim() by a verified winner, refund() when cancelled, or sweepUnclaimed() after the claim deadline expires (to treasury — not to the developer).
6. Modules Are Independent
A game can use crafting without staking. It can use prize pools without the NFT bridge. Each module has its own contracts and interfaces with no hard dependencies on others.
A casual puzzle game doesn't need tournament infrastructure. A competitive FPS doesn't need crafting. Monolithic systems create forced dependencies that make adoption harder and security harder to reason about. Modularity allows selective adoption and isolated reasoning.
The Decision Framework
When deciding whether something should be on-chain or off-chain, apply this test:
Does this event involve any of the following?
□ Transfer of value (tokens, NFTs)
□ Permanent record (achievement, crafted item)
□ Trustless verification (payout, claim)
□ Third-party interaction (sponsorship, external funding)
YES to any → ON-CHAIN
NO to all → OFF-CHAIN
Examples
| Event | On-Chain | Off-Chain | Reason |
|---|---|---|---|
| Player moves in a match | ✓ | No economic value, happens hundreds of times per match | |
| Player wins a match | ✓ | Result tracked internally — no payout yet | |
| Player claims a season reward | ✓ | Token transfer — requires trustlessness | |
| Player crafts a legendary item | ✓ | Permanent NFT with trade value | |
| Matchmaking queue update | ✓ | Ephemeral, latency-sensitive | |
| Sponsor funds a tournament pool | ✓ | Third-party value transfer into contract | |
| Player authenticates | ✓ | Standard login — no economic finality needed |
Anti-Patterns
These patterns appear frequently in blockchain games and are explicitly avoided in Monsuta Core:
| Anti-Pattern | Why It Fails |
|---|---|
| Every action on-chain | Wallet popups, gas per move, seconds of latency — the game becomes unplayable |
| Passive NFT staking with emissions | Rewards accumulation over play, invites bots, inflates supply with no demand counterpart |
| Uncapped token emissions | Supply grows indefinitely; token price falls; rewards are worth progressively less |
| Developer-held prize pools | Requires players and sponsors to trust a human with their money — a single point of failure |
| Mandatory wallet to play | Destroys onboarding; excludes the entire Web2 player base before they see a single game screen |
| Monolithic smart contract | Upgrading one feature means redeploying everything; one bug touches all systems |
| Burning NFTs in bridges | Assets permanently destroyed on failure; players lose things they can't recover |