diff --git a/pages/docs/games_overview/Orbirium.mdx b/pages/docs/games_overview/Orbirium.mdx
new file mode 100644
index 0000000..8ad1516
--- /dev/null
+++ b/pages/docs/games_overview/Orbirium.mdx
@@ -0,0 +1,111 @@
+---
+title: 'Orbirium'
+description: 'Orbirium'
+---
+
+import Image from 'next/image';
+
+## Orbirium
+
+### Description
+Orbirium is a web3 ide crafter and the prequel to Wizard Battle.
+
+It introduces the celestial forge of Arcane Orbs (named Orbirium), combining idle gameplay mechanics with zk-verified fairness and a unique multi-layer architecture.
+
+This section breaks down the gameplay, architecture, and developer tools behind Orbirium.
+
+Network layer: Sui + Zeko
+
+### Overview
+
+At the dawn of magic, before wizards dueled in the Arena, there was the Forge of Orbirium - a mystical construct that created the first Orbs.
+
+Each Orb embodies a branch of magic: chaos, fire, water, light, nature, and illusion. Crafted within Orbirium, they channel unique abilities that shape the future of Wizard Battle.
+
+The core crafting loop of Orbirium is built around:
+
+- Collecions resources through active taps and passive upgrades.
+- Unlocking and crafting new items to progress through the resource tree.
+- Upgrading and refining your production flows to optimize output
+- Crafting as many Black Orbs as possible to climb the leaderboard.
+
+Orbirium is idle yet strategic: your choices in crafting and upgrades determine your long-term progression.
+
+### Architecture
+
+Orbirium is built on a three-layer architecture:
+
+1. Application Layer - User-facing interface with multi-chain wallets and optimistic UI for instant feedback.
+2. Sui Layer - Execution layer that verifies actions and manages game state every Sui block (~2s).
+3. Zeko Layer - Settlement layer that finalizes game results with zero-knowledge proofs for cryptographic integrity.
+
+**Application Layer**
+
+- Optimistic UI: User actions update instantly before on-chain confirmation. If a transaction fails, progress reverts to match the verified on-chain state.
+- Multi-Chain Wallets: Supports Mina, Sui, and EVM networks through:
+    - *Mysten dApp Kit* - Sui wallet integration
+    - *Reown AppKit* - Multi-chain onboarding (EVM, Solana, Bitcoin)
+    - *Mina Signer* - Mina transaction signing
+    - *Wagmi* - EVM wallet & contract interactions
+
+This enables seamless cross-chain play, flexible wallet options, and smooth user onboarding through social or email accounts.
+
+**Sui Layer**
+
+The Sui Layer acts as the execution engine for Orbirium.
+
+Each player’s state consists of three arrays (21 values each):
+
+- Resources: Current resource quantities
+- RPS (Resources per Second): Resource generation rates
+- Storage: Maximum capacity per resource
+
+*Rules and Actions*
+
+Every in-game action (click, upgrade, craft) applies a rule represented as three arrays that update the player’s state via simple addition:
+
+```
+new_resources = resources + rule_resources
+new_rps       = rps + rule_rps
+new_storage   = storage + rule_storage
+```
+
+For example:
+
+- Click Rule: `[+1 wood]`
+- Upgrade Rule: `[+1 orb, +0.1 stone/sec]`
+
+**Anti-Cheat Protection**
+
+To ensure fairness:
+
+- One-Time Upgrades: Each upgrade can be used only once.
+- Admin-Signed Rules: Every valid rule must be signed by Orbirium’s admin to prevent arbitrary state changes.
+
+### Zeko Layer
+
+The Zeko Layer serves as the settlement and verification layer.
+
+All Sui actions are mirrored as zkPrograms that produce zero-knowledge proofs, confirming that every state update is valid without revealing sensitive data.
+
+**Recursive Proofs**
+
+Multiple actions are merged into a single, compressed proof (“proofs of proofs”) drastically reducing verification costs while maintaining full traceability.
+
+Example:
+
+```
+p1, p2, p3 → P12 (validates p1 & p2) → P (validates P12 & p3)
+```
+
+Now, verifying `P` ensures all previous actions are valid.
+
+### Silvana API Integration
+
+The Silvana API connects Sui and Zeko by:
+
+1. Collecting verified events from Sui,
+2. Generating zk proofs that these actions occurred correctly,
+3. Submitting those proofs to the Zeko zkApp for settlement.
+
+This process transfers the game state securely from Sui to Zeko, ensuring final, tamper-proof results.
diff --git a/pages/docs/games_overview/Wizard_Battle.mdx b/pages/docs/games_overview/Wizard_Battle.mdx
new file mode 100644
index 0000000..8aa0ab1
--- /dev/null
+++ b/pages/docs/games_overview/Wizard_Battle.mdx
@@ -0,0 +1,207 @@
+---
+title: 'Wizard Battle'
+description: 'Wizard Battle'
+---
+
+import Image from 'next/image';
+
+# Wizard Battle
+
+## Description
+
+Wizard Battle is a web3 strategy game where players engage in PvP and PvE duels to reclaim lost knowledge of this magic world. It combines tactical combat, crafting, and character progression within a provably fair, on-chain environment.
+
+**Core Features**
+
+- **PvP & PvE Combat** - Turn-based tactical battles with real-time state verification.
+- **Hero Classes** - Each hero has unique passive skills and active spells.
+- **Crafting & Gear Systems** - Players can forge Orbs, armor, and items that enhance abilities and stats.
+- **Provable Fairness** – All randomness and critical rolls are verified with zkProofs, guaranteeing fairness.
+
+**Gameplay Loop**
+
+1. **Prepare** – Equip gear, select a hero, and choose skills.
+2. **Compete** – Enter the Arena (PvP or PvE) or Expeditions for rewards.
+3. **Earn** – Gather materials, loot, and crafting components.
+4. **Evolve** – Upgrade Orbs, craft new equipment, and progress in rank.
+
+## Architecture
+
+**Wizard Battle (WB)** is our experiment in bringing true verifiability and fairness to multiplayer gaming through cryptography.
+
+The project’s architecture is built around two main layers:
+
+- **Battle architecture** – where players interact, move, and cast spells.
+- **Non-battle architecture** – where items, crafting, and the in-game economy live on-chain.
+
+![1](WBArch_1.svg)
+
+While the current implementation still uses some centralized components, the entire system is designed for future decentralization and full zero-knowledge validation.
+
+### Battle Architecture
+
+At the core of Wizard Battle lies an **optimistic approach**: during the match, we trust players’ local states.
+
+Each player keeps their **entire game state** on their device and only shares partial information — the *public state* — depending on gameplay visibility rules.
+
+For example, a wizard is always invisible, meaning their position doesn’t appear in the public state.
+
+This model preserves both privacy and integrity, enabling mechanics that would be impossible in traditional transparent blockchain games.
+
+**Player State**
+
+A player's state includes:
+
+- Selected wizard
+- Chosen skills and their cooldowns
+- The map
+- Current position
+- Character attributes (HP, max HP, strength, agility, etc.)
+
+The public portion of this state is automatically derived from game logic and visibility rules.
+
+Everything else remains private and verifiable only through post-match checks.
+
+**Turn Sequence**
+
+Each turn follows this universal sequence:
+
+1. Players apply **local spells** (which don’t require network sync).
+2. They send their actions to the server.
+3. The server broadcasts all actions to every player.
+4. Each client applies those actions locally.
+5. Players send their **updated public state** back.
+6. The server shares all new public states among players.
+7. Clients synchronize and prepare for the next turn.
+
+All players perform actions at the same time, ensuring fairness while keeping deterministic logic.
+
+![Без имени.svg](attachment:daf6b9d7-ed72-4cd7-8d46-9a8d39d26ef0:Без_имени.svg)
+
+**Timeout Manager**
+
+To prevent deadlocks, we introduced a **Timeout Manager**.
+
+It acts as a central authority that gives every player **2 minutes** to submit their turn.
+
+If a player fails to respond in time, the Timeout Manager ends the match and marks that player as the loser.
+
+This system prevents griefing and ensures that matches never stall indefinitely.
+
+![Без имени.svg](attachment:fa8d0f26-63c6-41ad-9a6b-0057b8b6b310:Без_имени.svg)
+
+**State Commit and Verification**
+
+Every turn, players submit a **state commit** — a cryptographic hash of their entire game state (public and private) signed with their session key.
+
+These commits become proof checkpoints used for post-match validation.
+
+Because the full state remains private during gameplay, WB relies **entirely on post-match verification**.
+
+Only after the game ends can players reveal their data and confirm that all actions were valid and rule-compliant.
+
+**Session Keys**
+
+Each match uses a **locally generated session key**, signed by the player’s main wallet once at the start.
+
+These keys are stored and used locally throughout the match, eliminating the need to sign every action on-chain and keeping gameplay fluid while maintaining cryptographic authenticity.
+
+**Randomness and Fairness**
+
+Some spells rely on **pseudorandom behavior**.
+
+WB uses a **hash-chain–based random source**: the server generates a chain of hashes and reveals them in reverse order, one per turn.
+
+This approach makes outcomes both *unpredictable* and *provable* after the game.
+
+For now, we don’t plan to replace this system — it’s deterministic, lightweight, and easy to verify.
+
+**Number of Players and Scalability**
+
+While WB currently focuses on **1v1 battles**, the architecture scales naturally to **NxM matches** or even **PvE** modes.
+
+Each player essentially operates on their own board, without collisions or shared line-of-sight, which makes simultaneous turns trivial to extend to multiple participants.
+
+**Game Completion and Verification Paths**
+
+![Без имени.svg](attachment:04239e0c-9960-4507-8072-0547b9e4dacd:Без_имени.svg)
+
+At the end of a match, players can finalize results through two possible verification modes:
+
+**1. Optimistic Path**
+
+For most players, performance and UX come first.
+
+The optimistic path lets players submit all their actions to the server, which checks validity and finalizes the match.
+
+If fraud is detected, a single invalid transition is enough to prove cheating.
+
+**2. ZK Path**
+
+Advanced players can choose the **zero-knowledge path**, using **o1js** to generate recursive proofs verifying that all turns followed the game’s rules — without revealing private data.
+
+We’d love to make the ZK path the default, but proof generation is still too heavy for many players, so we currently let users toggle between both modes manually.
+
+![Без имени.svg](attachment:6df5a451-44e0-4e2a-bb92-c381cd184b2e:Без_имени.svg)
+
+**Deposits and Slashing**
+
+Before a match begins, each player deposits a small amount (e.g., **1 MINA**) into a smart contract.
+
+This deposit partly covers transaction fees and acts as a **stake** for honest behavior.
+
+If no fraud is found, players keep their deposit.
+
+If cheating is detected — through either verification path — the entire deposit is forfeited.
+
+This system economically enforces fairness.
+
+**Post-Match Disputes and Replays**
+
+After the game, players enter a **dispute window** (initially one day, later one hour or less).
+
+During this period, they can reveal all submitted states and actions.
+
+Any other player can verify the integrity of those actions or challenge suspicious data.
+
+A full **replay system** will also be introduced, allowing anyone to re-simulate a match from the disclosed actions and seeds — useful for tournaments, audits, or community-driven anti-cheat checks.
+
+**Data Storage and Availability**
+
+In the first version, all game data — actions, commits, and results — is stored **centrally** on the game server.
+
+Later, we plan to introduce a **data availability layer**, where match proofs and commits could be stored in decentralized storage such as IPFS or Arweave, with only essential hashes anchored on-chain.
+
+### Non-Battle Architecture
+
+Outside of combat, WB runs on **EVM-compatible smart contracts** that handle crafting, trading, and item management.
+
+![Без имени.svg](attachment:28e9c6ec-e819-45ac-a28b-35438bc593a9:Без_имени.svg)
+
+**Items and Crafting**
+
+All items and resources follow the **ERC-1155** standard.
+
+There are two main types:
+
+- **Crafting resources** – used purely for crafting or trading.
+- **Wearable items** – equipment that can be attached to a character to enhance stats such as HP, damage, or agility.
+
+In the current version, a centralized server fetches on-chain data, signs it, and provides verified item information to the battle client.
+
+This bridge ensures that items remain authentic while keeping battles fast and seamless.
+
+**Framework and Technology**
+
+Wizard Battle is built on **o1js**, chosen for its **convenience** and **support for recursive proofs**, which allows chaining multiple turns into a single compact proof.
+
+Proof generation times and hardware benchmarks are still being measured, and future updates will include optimizations to improve the player-side experience.
+
+### Development Roadmap
+
+Upcoming development milestones:
+
+- Smart contract deployment for crafting and combat.
+- Loot drops and marketplace implementation.
+- Expedition systems and cross-chain payment integration.
+- Testnet → Mainnet transition on Mina (Q1 2026).