Most blockchain games fail because the economy is designed as a marketing feature, not as a game system. When the incentives collapse, the players leave.
A blockchain game is two systems running in parallel: a traditional game backend (session management, game state, progression, matchmaking) and an on-chain economy (asset ownership, token rewards, marketplace, staking). The hard problem is not the smart contracts — it is keeping these two systems consistent. A player who earns an NFT sword in-game must own it on-chain. A player who sells it on a secondary market must no longer have it in-game. The game economy must be designed so that token rewards are earned through play — not simply printed — and so that the secondary market does not drain players who cannot afford to buy in. PROPELOO approaches blockchain games as an economy engineering problem first and a smart contract problem second.
Frequently Asked Questions
How do you prevent the token economy from collapsing?
There is no guarantee — but the risk is significantly reduced by modelling the economy before deploying contracts. We model daily active player assumptions, token emission rates, sink strength (how much is spent vs earned per session), treasury runway and secondary market sell pressure. This produces a token model that can be stress-tested before mainnet. We also recommend conservative emission rates, strong sinks (crafting, upgrades, entry fees), and staking mechanics that reduce circulating supply.
Do players need a crypto wallet to play?
Not if you use embedded wallets (Privy, Dynamic, Magic.link). Players sign in with email or social login, and a wallet is created for them invisibly — they never see a seed phrase. For players who want full self-custody, external wallet connection (MetaMask, WalletConnect) is also supported. Account abstraction (ERC-4337) enables gasless transactions for both embedded and external wallet users.
How do you keep game state and on-chain state in sync?
The game server is the authority on game state. When a blockchain event occurs (NFT transferred, token staked), the game server receives a webhook from a node service (Alchemy Notify, QuickNode Streams) and updates the game state accordingly. When a player earns a reward or crafts an item in-game, the game server submits the mint/transfer transaction and waits for confirmation before updating the game state. We design these sync pathways explicitly and test failure cases (blockchain confirmation timeout, duplicate event delivery).
What blockchain should we deploy on?
For most games: Polygon. Low gas fees make frequent player interactions economically viable (minting, marketplace trading, staking). Strong ecosystem, widely supported by wallets and marketplaces. If your game involves very high NFT trading volume and gas-free trading is a product requirement, Immutable X is designed specifically for that use case. If you expect millions of transactions per day, a custom subnet (Avalanche, Polygon CDK) gives you zero gas for players and full control.
Can you build the game itself, not just the blockchain layer?
Yes — for web-based and mobile games. We build full-stack blockchain games including the game server, matchmaking, game UI (React or Unity WebGL), and all on-chain components. For console or native mobile games, we build the blockchain and economy infrastructure that integrates with your game engine via API.
How do you handle NFT metadata for upgradeable assets?
For assets that gain XP, levels, or equipped items, we use a metadata API served by the game server that reads the current state and generates the NFT metadata dynamically. The base traits (rarity, class, base stats) are stored on IPFS with the hash committed on-chain for provenance. Dynamic attributes are served by the game server API. This architecture allows assets to evolve through gameplay without on-chain writes per level-up.
