Designing a Web3 Game

In GameFi, an average on-chain transaction on Polygon costs $0.01, but if you put all smart contracts on-chain, the game becomes unplayable due to 15-second block delays. The right Web3 game architecture is a clear boundary between what should be on-chain and what should remain off-chain. Without this, the game is either unplayable or the blockchain part is decorative. Our 10+ years of experience in GameFi development ensures robust smart contracts and tokenomics. 95% of gameplay should be off-chain to ensure responsiveness. Assess your project — get a developer consultation.

Why Games Need Blockchain

Blockchain adds trustless ownership and transparent economics. Players truly own their assets, can trade them outside the game, and participate in project governance. But simply adding blockchain to a game is a bad idea. It's important to correctly separate on-chain and off-chain logic. Assess your project — contact us for a consultation.

How to Split On-Chain and Off-Chain

Here are clear criteria:

A good model: the game server is the source of truth for gameplay, the blockchain is the source of truth for ownership and economy. Synchronization occurs at defined checkpoints.

Architecture: Servers, Contracts, Client

Game Backend

Game Client (Unity/Unreal/Web)
        ↓
Game Server (authoritative)
    └── Game State DB (Redis for real-time, PostgreSQL for persistence)
        ↓ (at significant events)
Blockchain Sync Service
        ↓
Smart Contracts (Assets, Economy, Rewards)
        ↓
The Graph (indexing for UI/leaderboards)

Authoritative server model — the client never makes final decisions. The client sends input, the server verifies and applies it. This prevents cheating without any blockchain. The authoritative server model is 100 times more effective than client-side anti-cheat because the client does not control the outcome.

The Blockchain Sync Service is a separate service that listens to game events and broadcasts significant ones as on-chain transactions. It works asynchronously, not blocking gameplay.

NFT Assets: Standards and Metadata

According to ERC-1155 (EIP-1155), the multi-token standard allows managing multiple NFT types in one contract. We use a combination of ERC-721 for unique items and ERC-1155 for stackable items. Metadata: on-chain (maximum permanence, but 10 times more expensive than IPFS), IPFS (compromise), or centralized server (fast, cheap, but dependent on us).

contract GameItem is ERC1155 {
    struct ItemType {
        string name;
        uint8 rarity;        // 1=Common, 2=Rare, 3=Epic, 4=Legendary
        uint16 baseAttack;
        uint16 baseDefense;
        bool tradeable;
    }

    mapping(uint256 => ItemType) public itemTypes;
    mapping(uint256 => uint256) public itemMaxSupply;
    mapping(uint256 => uint256) public itemCurrentSupply;

    bytes32 public constant MINTER_ROLE = keccak256("MINTER_ROLE");

    function mintItem(
        address to,
        uint256 itemTypeId,
        uint256 amount,
        bytes memory data
    ) external onlyRole(MINTER_ROLE) {
        require(
            itemCurrentSupply[itemTypeId] + amount <= itemMaxSupply[itemTypeId],
            "Max supply exceeded"
        );
        itemCurrentSupply[itemTypeId] += amount;
        _mint(to, itemTypeId, amount, data);
    }

    function _beforeTokenTransfer(
        address operator,
        address from,
        address to,
        uint256[] memory ids,
        uint256[] memory amounts,
        bytes memory data
    ) internal override {
        for (uint i = 0; i < ids.length; i++) {
            if (from != address(0) && to != address(0)) {
                require(itemTypes[ids[i]].tradeable, "Item is soulbound");
            }
        }
        super._beforeTokenTransfer(operator, from, to, ids, amounts, data);
    }
}

Game Token: Tokenomics

Most failed GameFi projects failed due to poor tokenomics, not the game. Common mistakes: inflationary spiral (token emitted without sufficient sink — example Axie Infinity); two-token model without proper peg. The right approach is to balance emission and sink.

contract GameEconomy {
    function claimDailyReward(
        address player,
        uint256 amount,
        uint256 nonce,
        bytes memory serverSignature
    ) external {
        bytes32 message = keccak256(abi.encodePacked(player, amount, nonce));
        require(
            ECDSA.recover(message.toEthSignedMessageHash(), serverSignature) == GAME_SERVER,
            "Invalid server signature"
        );
        require(!usedNonces[nonce], "Nonce already used");
        usedNonces[nonce] = true;

        require(dailyClaimed[player][today()] + amount <= MAX_DAILY_REWARD, "Daily limit");
        dailyClaimed[player][today()] += amount;

        gameToken.mint(player, amount);
    }

    function craftItem(uint256 recipeId) external {
        Recipe memory recipe = recipes[recipeId];
        gameToken.burnFrom(msg.sender, recipe.tokenCost);
        // mint NFT item
    }
}

Game Server Signature Pattern

A critical pattern for Web3 games: the game server is the trusted source of truth, its decisions are verified on-chain via signature. The user cannot call claimReward themselves — they receive a server-signed voucher. This prevents fabrication, double-spending, and cheating.

// Game Server side (Node.js)
import { ethers } from "ethers";

const serverWallet = new ethers.Wallet(process.env.SERVER_PRIVATE_KEY);

async function generateRewardVoucher(
  playerAddress: string,
  rewardAmount: bigint,
  gameSessionId: string
): Promise<{ nonce: string; signature: string; amount: string }> {
  const nonce = ethers.hexlify(ethers.randomBytes(32));
  const message = ethers.solidityPackedKeccak256(
    ["address", "uint256", "bytes32"],
    [playerAddress, rewardAmount, nonce]
  );
  const signature = await serverWallet.signMessage(ethers.getBytes(message));
  return { nonce, signature, amount: rewardAmount.toString() };
}

Anti-Cheat at the Blockchain Level

On-chain verification using commit-reveal for randomness: the player commits hash(seed) before the game, reveals the seed after the game, the blockchain verifies random = hash(seed, block.hash). Chainlink VRF v2 for on-chain randomness (drops, matchmaking).

import { VRFConsumerBaseV2 } from "@chainlink/contracts/src/v0.8/VRFConsumerBaseV2.sol";

contract LootBox is VRFConsumerBaseV2 {
    mapping(uint256 => address) public requestToPlayer;

    function openLootBox() external returns (uint256 requestId) {
        requestId = vrfCoordinator.requestRandomWords(
            keyHash, subscriptionId, 3, 100_000, 3
        );
        requestToPlayer[requestId] = msg.sender;
    }

    function fulfillRandomWords(uint256 requestId, uint256[] memory words) internal override {
        address player = requestToPlayer[requestId];
        uint256 itemTier = words[0] % 1000;
        _mintReward(player, itemTier);
    }
}

Technical Stack for Web3 Games

Game Engine: Unity (WebGL + native mobile) or Phaser 3 (browser-first). Web3 integration: Nethereum for EVM, Solana.Unity-SDK for Solana. Backend: Go or Node.js for game server, separate TypeScript service for blockchain interactions. Indexing: The Graph for leaderboards and history, custom PostgreSQL for analytics. Networks: Polygon PoS or Arbitrum Nova for frequent transactions, Ethereum mainnet for valuable assets. Gas savings ~90% when using L2.

Step-by-Step Work Process for GameFi Projects

1. Tokenomics design and game design (4-6 weeks).
2. Smart contract development (ERC-1155, marketplace, staking) (4-8 weeks).
3. Authoritative game server development on Go or Node.js (4-8 weeks).
4. Client integration (Unity/Phaser) with Web3 (6-12 weeks).
5. Smart contract audit and testnet (4-6 weeks).
6. Mainnet launch and monitoring (2 weeks).

How to Prevent Cheating Through Blockchain

1. Use authoritative server model: the server makes decisions, the client only sends input.
2. Apply commit-reveal for random events — this prevents players from predicting outcomes.
3. Sign every economic action with the server (server signature pattern).

Scope of Work

Within the project, we provide: documentation (architecture, specifications), full source code, security audit, mainnet deployment, monitoring and support post-launch. We guarantee correct operation of smart contracts and the game server. Assess your project — contact us.

The team has certifications and 10+ years of experience. We ensure a transparent process and audit. Contact us to discuss your GameFi project.

Game Economy, Contracts, and On-Chain Mechanics

We’ve seen this scenario multiple times. Axie Infinity generated substantial revenue monthly at its peak, but within 18 months the token crashed by 98% and the audience by 95%. The cause—lack of sinks: players earned SLP and cashed out, while burn mechanisms were insufficient. An analysis of Axie’s economy (Collins Dictionary) confirmed the model turned into a Ponzi scheme. We provide end-to-end GameFi development: from tokenomics to smart contracts, so your economy doesn’t repeat this mistake. Let’s evaluate your project at a meetup or online.

Play-to-Earn Economy Break Points

Inflationary tokenomics without sinks. Players earn tokens through gameplay. If sinks (burn or consumption mechanisms) are insufficient, supply outpaces demand. Price drops. Player fiat income declines. Players leave. A death spiral.

The right structure is a dual-token model with clear separation: a governance/value token with limited supply and a utility/reward token for in-game economy. The utility token must be actively consumed: item crafting, upgrades, entry fees, breeding. Examples: GODS/FLUX in Gods Unchained, AXS/SLP in Axie (though sinks were insufficient there). Historical data shows that without sinks, token supply inflates by 5–10% monthly, leading to price collapse within 6–9 months.

Effective Sink Mechanisms

• Breeding/crafting — burning utility token to create a new NFT (e.g., Axie). Typical burn costs range from $5–$15 per action, removing 0.5–2% of total supply annually.
• Character upgrades — each evolution requires token burning, consuming 0.1–0.3% of circulating supply per upgrade cycle.
• PvP entry fee — token burn for tournament entry, part goes to prize pool. This can burn up to 0.5% of supply per week in active games.
• Item durability — item breaks after N battles, token spent on repair. Cost per repair ~$0.50–$2.
• Financial mechanics — staking with lock-up, removing tokens from circulation for a period. Typical lock-up periods of 30–90 days reduce circulating supply by 15–25%.

On-Chain vs Off-Chain: Boundary and Trade-offs

It’s not necessary to put all game logic on-chain—each transaction costs gas and takes 12 seconds. A game cycle is milliseconds. Balance:

Gameplay results are transferred to blockchain via signed messages from server or ZK-proof. Verifiable off-chain with ZK: game server generates ZK-proof of session correctness, contract verifies proof and issues rewards. Implementations: Cartridge (Starknet), zkSync game rollups. Gas savings from batching proofs can reach 90% compared to per-action on-chain validation.

How Does Dual-Token Model Prevent Economic Collapse?

Governance token (limited supply) acts as value store and is used for major decisions. Utility token (minted via gameplay) is consumed by sink mechanisms, ensuring deflationary pressure. The ratio of governance to utility tokens in the initial pool should be 1:10 to 1:20. Simulation shows that a 30% burn rate on utility token keeps supply growth below 3% per year, preserving player income and token price.

Implementation of NFT Game Items

Standard: ERC-1155 for fungible items (resources, consumables) + ERC-721 for unique (characters, land). ERC-1155 provides up to 60% gas savings on batch transfers.

How to Implement Dynamic NFTs Without Overloading the Blockchain?

Item attributes change during gameplay (experience, durability, upgrades). Two approaches:

• Fully on-chain: attributes stored in contract mapping, tokenURI generated from attributes via SVG/JSON encoding. Expensive in gas with frequent updates (e.g., $0.50 per update). Used for land and key assets.
• Hybrid: attributes stored off-chain, tokenURI contains state hash. Updates signed by server, verified on-chain during transfer or sale. Cheaper ($0.02 per update) but requires server trust or ZK.

Breeding and crafting. Contract: two parent NFTs → pay utility token (burn) → mint new NFT with attributes dependent on parents + Chainlink VRF for randomness. Without VRF, miners can manipulate randomness via block selection.

// Simplified breeding with Chainlink VRF
function breed(uint256 parent1Id, uint256 parent2Id) external {
    require(ownerOf(parent1Id) == msg.sender);
    require(ownerOf(parent2Id) == msg.sender);
    require(breedingToken.burnFrom(msg.sender, BREEDING_COST));

    uint256 requestId = vrfCoordinator.requestRandomWords(...);
    pendingBreeds[requestId] = BreedRequest(parent1Id, parent2Id, msg.sender);
}

function fulfillRandomWords(uint256 requestId, uint256[] memory randomWords) internal override {
    BreedRequest memory req = pendingBreeds[requestId];
    uint256 childAttributes = deriveAttributes(req.parent1Id, req.parent2Id, randomWords[0]);
    _mintWithAttributes(req.requester, childAttributes);
}

Marketplace and Royalties

An integrated marketplace gives control over fee structure and custom logic (e.g., banning item trading below a certain level). Royalties per EIP-2981 are standard but not enforceable: Blur and other marketplaces ignore on-chain royalties. For enforcement—whitelist-only transfer (only through contracts that pay royalties). Sacrifice composability for rights protection. Typical marketplace fee is 2.5–5% per transaction, generating recurring revenue.

Staking and Rewards Distribution

Staking NFTs is a mechanic for player retention. Problem: distributing rewards with thousands of stakers requires constant transactions (expensive). Solution—reward-per-share pattern (as in MasterChef from SushiSwap): global accRewardPerShare, upon claim or state change, debt is recalculated by formula pendingReward = stakedAmount * (accRewardPerShare - userRewardDebt). O(1) complexity regardless of staker count. Gas savings up to 70% compared to per-element distribution. Over a year with 10,000 stakers, this translates to roughly $40,000 saved in gas.

Why Is Reward-Per-Share Pattern Critical for Scalability?

Direct per-user reward updates cost O(n) per block, consuming more than 200,000 gas for 1,000 stakers. Reward-per-share reduces this to 30,000–50,000 gas per user claim, enabling thousands of stakers. Many early P2E games collapsed under gas costs that exceeded reward value. This pattern scales to tens of thousands without infrastructure overhead.

Process and Timelines

We start with a game economics document: token flows, mint/burn mechanics, projected supply schedule, sink analysis. Before writing code, the economy is modeled (Cadence, Python simulation).

GameFi Building Process: 5 Stages

1. Economic modeling — 1–2 weeks. Develop dual-token model, calculate sinks, outline incentives for long-term holding.
2. Token contract development — 2–3 weeks. ERC-20 for governance, ERC-20 for utility, with configurable mint/burn policy.
3. NFT smart contracts — 3–5 weeks. ERC-721 / ERC-1155 with dynamic metadata, breeding/crafting, Chainlink VRF.
4. Staking + rewards — 2–3 weeks. Contract based on reward-per-share, interfaces for frontend.
5. Marketplace (optional) — 2–4 weeks. Custom marketplace with enforced royalty.

Work Deliverables

• Source code for all smart contracts with tests (Foundry/Hardhat)
• Architecture and economics documentation
• Integration with Chainlink, Tenderly for monitoring
• Code audit and formal verification (Slither, Mythril, Echidna)
• Team training on contract interaction
• Post-deployment support (3 months)

Basic GameFi stack (tokens + NFTs + staking + marketplace) — 8 to 16 weeks. Full game with on-chain randomness, breeding, dynamic NFTs — 4–8 months. ZK-based verifiable gameplay — a separate project from 6 months.

Contact us for an audit of your tokenomics—we’ll assess risks and refine sink mechanisms. Order GameFi project development—receive a ready product with proven economy. We guarantee contract stability and code transparency. Our experience includes dozens of implemented Web3 projects, including audits of 15+ P2E games. Get a consultation to start your project.