GameFi Project Development

GameFi Project Development

GameFi is the intersection of two very different engineering disciplines: game development with its requirements for real-time, low latency and high event frequency, and blockchain development with its finality, gas costs and immutability. Attempting to simply "add blockchain to a game" almost always fails — either the game becomes unplayable due to transactions, or the blockchain part is decorative and provides nothing to users. Proper GameFi architecture is a clear boundary between what must be on-chain and what should remain off-chain.

The fundamental question: what goes on-chain

Not everything in a game should be on the blockchain. Blockchain is expensive, slow, but trustless and permanent storage. Use it exactly where these properties are needed.

Must be on-chain:

• Asset ownership (NFT characters, items, land)
• Financial operations (buying, selling, staking, rewards)
• Critical results affecting economy (tournament victory, rare loot drop)
• Governance decisions (if applicable)

Must be off-chain (game servers):

• Real-time game mechanics
• Player positions, collisions, physics
• Most gameplay events
• Social functions (chat, guilds)
• Analytics and logging

Good model: game server is source of truth for gameplay, blockchain is source of truth for ownership and economy. Synchronization happens 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)
        ↓ (on significant events)
Blockchain Sync Service
        ↓
Smart Contracts (Assets, Economy, Rewards)
        ↓
The Graph (indexing for UI/leaderboards)

Authoritative server model — client never makes final decisions. Client sends input (move left, attack), server verifies and applies. This prevents cheating without any blockchain.

Blockchain Sync Service — separate service that listens to game events and translates significant ones into on-chain transactions. Works asynchronously, doesn't block gameplay.

NFT assets: standards and metadata

ERC-721 for unique items, ERC-1155 for stackable items (resources, consumables) — GameFi almost always combines both.

Game NFT metadata is a separate issue. On-chain metadata (fully in contract) — maximum permanence but expensive and limited in volume. IPFS — compromise: content-addressed but requires pinning. Centralized server — fast, cheap, but depends on you.

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;

    // Only game server can mint items
    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);
    }

    // Non-transferable soulbound items
    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)) { // not mint/burn
                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 poor gameplay. Main mistakes:

Inflationary spiral — token given as gameplay reward without sufficient sink. More players → more supply → lower price → less incentive to play. This killed Axie Infinity in 2022.

Dual-token model — attempting to separate "governance token" (deflationary) and "utility token" (inflationary) often creates irrational peg between them and even more complex fail modes.

Right approach — balance emission and sink:

contract GameEconomy {
    // Emission: only through game achievements verified by server
    function claimDailyReward(
        address player,
        uint256 amount,
        uint256 nonce,
        bytes memory serverSignature
    ) external {
        // Verify server signature
        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;

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

        gameToken.mint(player, amount);
    }

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

Game Server Signature Pattern

This is a critical pattern for GameFi: the game server is the trusted source of truth, and its decisions are verified on-chain through signature checking.

User cannot simply call claimReward — they must obtain a server-signed voucher. This prevents:

• Fabricating results through direct contract call
• Double spending one result (nonce)
• Cheating through replay attacks

// 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() };
}

Marketplace: P2P asset trading

contract GameMarketplace {
    struct Listing {
        address seller;
        address nftContract;
        uint256 tokenId;
        uint256 amount;    // for ERC-1155
        uint256 price;     // in ERC-20 token or native
        uint256 expiresAt;
    }

    mapping(bytes32 => Listing) public listings;
    uint256 public feePercent = 250; // 2.5%

    function buyItem(bytes32 listingId) external {
        Listing memory listing = listings[listingId];
        require(block.timestamp < listing.expiresAt, "Listing expired");
        require(listing.seller != address(0), "Listing not found");

        uint256 fee = (listing.price * feePercent) / 10_000;
        uint256 sellerAmount = listing.price - fee;

        // Token transfer
        paymentToken.transferFrom(msg.sender, listing.seller, sellerAmount);
        paymentToken.transferFrom(msg.sender, treasury, fee);

        // NFT transfer
        IERC1155(listing.nftContract).safeTransferFrom(
            address(this), msg.sender, listing.tokenId, listing.amount, ""
        );

        delete listings[listingId];
    }
}

Anti-cheat at blockchain level

On-chain result verification is possible through several mechanisms:

Commit-reveal for randomness — game cannot know outcome in advance, but blockchain shouldn't be manipulable:

1. Player commits hash(seed) before start
2. After game reveals seed
3. Blockchain verifies: random = hash(seed, block.hash) — cannot predict in advance

Chainlink VRF v2 — for on-chain randomness (loot 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 // 3 random words
        );
        requestToPlayer[requestId] = msg.sender;
    }

    function fulfillRandomWords(uint256 requestId, uint256[] memory words) internal override {
        address player = requestToPlayer[requestId];
        // Determine drop based on verifiable random
        uint256 itemTier = words[0] % 1000; // 0-999
        _mintReward(player, itemTier);
    }
}

Technical stack for GameFi

Game Engine: Unity (WebGL + native mobile) or Phaser 3 (browser-first). Unity with WebGL — standard for casual GameFi.

Web3 integration in Unity: Nethereum for EVM, Solana.Unity-SDK for Solana. For browser — MetaMask SDK via JSLib bridge.

Backend: Go or Node.js for game server (latency critical), separate TypeScript service for blockchain interactions.

Indexing: The Graph for leaderboards, NFT collections, transaction history. Own PostgreSQL for game-specific analytics.

Networks: Polygon PoS or Arbitrum Nova (ultra-low gas for frequent transactions), Ethereum mainnet for valuable assets.

Phases and timeline

Minimum budget for full GameFi MVP — $200k–400k. Projects with lower budgets usually sacrifice either game quality or smart contract quality — both choices lead to failure.