Roadmap
What we are building, in what order, and why each piece matters.
The Single Sentence
We are building the economic settlement layer for competitive games, starting with the contracts that handle real money, and working outward to the SDK and integration layer.
The Core Claim
The game server for Faded Monsuta can put AVAX into a prize pool, run a tournament, submit results, and players can claim their prizes — all in a way where the game developer literally cannot steal the money.
That is the central value proposition. Everything else is scaffolding.
System Components
The platform is built in layers, from on-chain infrastructure up to game integration:
Layer 1 — On-Chain Contracts
The foundation. Smart contracts deployed on Avalanche C-Chain that handle all trustless settlement:
| Contract | Purpose |
|---|---|
FadedMonsutaTHC.sol | ERC-20 gameplay token with bridge mint/burn mechanics |
MonsutaNFT.sol | Upgradeable ERC-721 — batch minting, locking, royalties |
CraftingRecipes.sol | Recipe-based item creation — trustless + server-gated |
AchievementsRegistry.sol | On-chain achievement attestations — EIP-712 issuance |
NFTBridge.sol | Vault-based NFT bridging with threshold oracle signatures |
PrizePool.sol | Tournament prize escrow with no admin withdrawal |
PrizePoolFactory.sol | Pool deployment and registry |
NFTStaking.sol | Non-custodial NFT staking with Merkle epoch distribution |
WAX-side contracts:
| Contract | Purpose |
|---|---|
teleporteos | Token bridge — deposit, teleport, oracle signing |
nftbridge | NFT bridge — vault locking, oracle release |
Layer 2 — Oracle & Worker Network
Off-chain processes that bridge the gap between chains and handle computation:
| Worker | Purpose |
|---|---|
| Token Bridge Oracle | Bidirectional WAX ↔ Avalanche token attestation |
| NFT Bridge Oracle | WAX ↔ Avalanche NFT translation and signing |
| Metadata Router | Dynamic NFT trait generation via mathematical token IDs |
| Staking Distributor | Ownership scanning, weight computation, Merkle tree publishing |
Layer 3 — SDK
The JavaScript layer that game servers use to interact with contracts:
| Client | Purpose |
|---|---|
FactoryClient | Deploy and manage prize pool instances |
PrizePoolClient | Fund, register, activate, submit results |
EventListener | Real-time contract event streaming |
Layer 4 — Game Server Integration
The connection point between Monsuta Core and the game:
Match ends
→ game server records result internally
→ if match was a prize pool match:
→ server calls pool.submitResults(winners)
→ if it was a ranked match:
→ season module updates ELO + leaderboard internally
→ at season end: server calls pool.submitResults(seasonStandings)
Layer 5 — Competition Library
Pure JavaScript modules for competitive game infrastructure:
| Module | Purpose |
|---|---|
calculateElo() | ELO rating adjustments |
Season | Season lifecycle, match recording, finalization |
League | Promotion/relegation between tiers |
Leaderboard | Real-time standings |
The Build Order (And Why)
Phase 1 — Deploy Contracts
Deploy all smart contracts to Avalanche Fuji testnet. Verify on Snowtrace. Grant roles.
Why first: You cannot build the SDK against contracts that aren't deployed. You cannot do end-to-end testing without real contract addresses. Deploy first, everything else unblocks.
Phase 2 — Economy SDK
Build the JS layer that wraps contract calls into a clean developer API:
const factory = new FactoryClient({ provider, signer, factoryAddress });
const pool = await factory.createPool({ entryFee, prizeSplit, ... });
const pool = new PrizePoolClient({ provider, signer, poolAddress });
await pool.fund('10.0');
await pool.submitResults(winners);
Why: Every integration point with the game server needs this. It's the missing piece between "contracts exist" and "game server uses them."
Phase 3 — Game Server Integration
Wire the Faded Monsuta game server to use the SDK:
- Tournament creation flow: server deploys pool via
FactoryClient - Match end flow: server calls
submitResults()for bracket finals - Season end batch: server calls
submitResults()for season pool - Player claim notification: game UI shows claimable prize, links to wallet
Why: This is what proves the system works end-to-end.
Phase 4 — Competition Library
Extract ELO/season/league logic into a testable, installable module.
Why: The game server already handles this internally. This phase is about making it clean, reusable, and independently testable.
Phase 5 — Bridge to Mainnet
Production deployment with correct oracle configuration:
- Raise oracle
thresholdto ≥ 3 - Register 3+ independent oracle accounts
- Move oracle keys to KMS
- Set
CONFIRMATIONS_REQUIRED = 12
Why: The bridge code works. Mainnet just needs correct security config.
Phase 6 — NFT Staking Integration
Deploy staking contract, whitelist collections, fund the reward pool, launch distributor worker.
The Dependency Graph
Phase 1: DEPLOY CONTRACTS
│
▼
Phase 2: BUILD SDK ──────────────────────────────┐
│ │
▼ │
Phase 3: GAME SERVER INTEGRATION │
│ Phase 6: STAKING INTEGRATION
▼
Phase 4: COMPETITION LIBRARY (parallel with 4+)
Phase 5: MAINNET BRIDGE (security config, parallel anytime)
Phases 4, 5, and 6 can run in parallel once Phase 3 is done.
What Success Looks Like
A working system means all of the following are true:
- Token bridge works end-to-end: WAX → Avalanche and Avalanche → WAX with real tokens
- NFT bridge works end-to-end: WAX NFTs vault-locked, minted on Avalanche, reversible
- MonsutaNFT and CraftingRecipes functional — batch minting, trustless and server-gated crafting
- AchievementsRegistry functional — type registration, direct and signature-based issuance
- PrizePool and Factory deployed and verified
- Game server can create a prize pool, run a tournament, and submit results to chain
- At least one player successfully claims a prize from the contract
- NFT staking deployed — at least one player staked and claimed epoch rewards
- All of the above documented with transaction hashes
The core claim is proven: trustless economic settlement for a competitive game, without a centralized fund custodian.
What We Are NOT Building (Yet)
| Feature | Why Not Now |
|---|---|
| Treasury routing contract | Can manually collect treasury fees initially |
| npm package registry | SDK can be local import — package publishing isn't required |
| Multi-game support | One game first — prove it works, then generalize |
| Analytics dashboard | Read chain directly — no need for aggregation layer |