Security Model

Trust boundaries, threat model, and security guarantees of Monsuta Core.

Trust Boundary Summary

┌──────────────────────────────────────────────────┐
│              TRUSTED (Server-side)                │
│                                                   │
│  • Game server decides match outcomes             │
│  • Server calculates rewards                      │
│  • Server manages inventory state                 │
│  • Server signs claim data                        │
│                                                   │
│  Players trust the game operator for gameplay     │
│  fairness, just like any multiplayer game.        │
│                                                   │
└───────────────────────┬──────────────────────────┘
                        │
              economic settlement boundary
                        │
┌───────────────────────▼──────────────────────────┐
│             TRUSTLESS (On-chain)                   │
│                                                   │
│  • Smart contracts hold funds                     │
│  • Rewards are claimable by winners               │
│  • Developer cannot redirect prize pools          │
│  • Bridge requires oracle consensus               │
│  • Claimed status is immutable                    │
│                                                   │
│  Players do NOT need to trust the game operator   │
│  for payouts, ownership, or token custody.        │
│                                                   │
└───────────────────────────────────────────────────┘

Key Insight: The game server is trusted for gameplay, but the blockchain removes the need to trust the developer as a financial custodian.

Threat Model

Threat 1: Game Server Manipulation

Threat	A compromised game server submits false match results
Impact	Incorrect rewards distributed
Mitigation	Server-side result validation, replay logging, audit trails
Residual risk	The game operator must be trusted for gameplay correctness
Note	This is the same trust model as every competitive game

Threat 2: Oracle Collusion (Bridge)

Threat	Oracle operators collude to forge bridge attestations
Impact	Unauthorized token minting on Avalanche
Mitigation	Multi-oracle threshold signatures (configurable `threshold`)
Contract ref	`FadedMonsutaTHC.sol` — `require(valid >= threshold)`
Current config	Threshold = 1 (testnet), should be ≥ 3 for production

Threat 3: Replay Attack (Bridge Claims)

Threat	An attacker replays a valid claim transaction
Impact	Double-minting of bridged tokens
Mitigation	`claimed[claimHash]` mapping prevents re-use
Contract ref	`FadedMonsutaTHC.sol` — `require(!claimed[claimHash])`
Additional	`signed[td.id][signer]` prevents per-oracle replay

Threat 4: Expired Claim Exploitation

Threat	Attacker uses an old signed packet after the window expires
Impact	Stale claims processed
Mitigation	30-day expiry enforced in `verifySigData`
Contract ref	`require(block.timestamp < td.ts + 30 days)`

Threat 5: Wrong Chain Submission

Threat	Attacker submits WAX→BSC data to the Avalanche contract
Impact	Token minting on wrong chain
Mitigation	`thisChainId` checked against packet's `chainId`
Contract ref	`require(thisChainId == td.chainId, "wrong chain")`

Threat 6: Prize Pool Rug

Threat	Developer drains tournament prize pool
Impact	Players and sponsors lose funds
Mitigation	Prize pool contract has no admin withdrawal for prize funds
Design rule	Only verified winners can call `claim()`

Threat 7: Client-Side Cheat

Threat	Modified game client sends fabricated game actions
Impact	Unfair match outcomes
Mitigation	Server-authoritative architecture
Design rule	Client sends inputs, server resolves all state transitions

Smart Contract Security Properties

Bridge Contract (`FadedMonsutaTHC.sol`)

Property	Implementation
No admin minting	Tokens only created via `claim()` with signatures
Oracle threshold	Configurable, must meet `threshold` valid sigs
Domain separation	`DOMAIN_SEPARATOR` prevents cross-contract replay
No selfdestruct	Contract cannot be destroyed
Stuck token recovery	`transferAnyERC20Token()` — owner only, cannot withdraw THC itself
Ownership transfer	Two-step: `transferOwnership()` + `acceptOwnership()`

WAX Contract (`teleporteos`)

Property	Implementation
Deposit-before-teleport	Users must transfer tokens before initiating teleport
Oracle registration	Only contract owner can add/remove oracles
Oracle deduplication	Each oracle can only sign/approve once per teleport
Cancellation window	Unclaimed teleports can be cancelled after 30 days
Confirmation threshold	`ORACLE_CONFIRMATIONS` required before token release

Oracle Network

Architecture

WAX Blockchain ──── event ────► Oracle 1 ──► signs attestation
                                Oracle 2 ──► signs attestation
                                Oracle N ──► signs attestation
                                                    │
                                                    ▼
                                          Signatures stored on
                                          WAX (teleports table)
                                                    │
                                                    ▼
                                          Player calls claim()
                                          on Avalanche with
                                          sigData + signatures
                                                    │
                                                    ▼
                                          Avalanche contract
                                          verifies threshold
                                          reached, mints tokens

Oracle Responsibilities

Direction	Oracle listens to	Oracle acts on
WAX → Avalanche	WAX `logteleport` events via Hyperion/SHIP	Signs the teleport data, stores sig on WAX
Avalanche → WAX	Avalanche `Teleport` events via WS/RPC	Calls `received()` on WAX with confirmation
Avalanche claims	Avalanche `Claimed` events	Calls `claimed()` on WAX to mark as complete

Security Recommendations

Production threshold: ≥ 3 oracles required (currently 1 for testnet)
Oracle key management: Hardware wallets or KMS for oracle signing keys
Oracle diversity: Run oracles on separate infrastructure providers
Monitoring: Alert on unusual bridge volumes or unsigned teleports
Rate limiting: Cap maximum transfer per epoch to limit damage from compromise

For Integrating Games

Games adopting Monsuta Core inherit these security properties:

Prize pool custody — funds are never held by the game server
Bridge security — token migration uses oracle consensus, not admin keys
Replay protection — built into all claim contracts
Server authority — your game server remains the arbiter of gameplay

Games are responsible for:

Game server security — hardened infrastructure, access control
Result integrity — anti-cheat, replay validation
Key management — securing any server-side signing keys
Oracle operation — if running their own bridge instance

Trust Boundary Summary​

Threat Model​

Threat 1: Game Server Manipulation​

Threat 2: Oracle Collusion (Bridge)​

Threat 3: Replay Attack (Bridge Claims)​

Threat 4: Expired Claim Exploitation​

Threat 5: Wrong Chain Submission​

Threat 6: Prize Pool Rug​

Threat 7: Client-Side Cheat​

Smart Contract Security Properties​

Bridge Contract (FadedMonsutaTHC.sol)​

WAX Contract (teleporteos)​

Oracle Network​

Architecture​

Oracle Responsibilities​

Security Recommendations​

For Integrating Games​