How We Built a Unity Mobile Game with Solana Blockchain Integration
Web3 studios keep hitting the same wall. The gameplay works, the wallet ruins it, and new players quit at the seed phrase. Solana game development fixed that here: a player signs in with an email, gets a wallet in about a second, and buys in-game items the way they would buy coins in any free-to-play title.
- → 98% of blockchain transactions cleared during testing
- → ~1.2 s to create a player wallet at first login
- → ~85 ms round-trip inside 8-player multiplayer rooms
- → 40+ backend endpoints shipped with Swagger docs
Project Details
Building games on Solana takes a team that reads both sides of the problem: the gaming industry and blockchain architecture. Most game development shops stop at the engine, and most blockchain shops have never shipped a game. Solana game development sits in that overlap, and it’s thin. This studio came to us with a playable Unity build, a token plan, and no backend for either.
Business Challenge: Creating a Smooth Blockchain Gaming Experience on Solana
The studio arrived with a Unity build that already looked good. Characters ran through a neon city, bikes drifted around race tracks, and the art direction held up on a phone screen. But every value that mattered sat on the device. Currency balances, in-game assets, race results: a determined player could edit all three, and none of that state was worth anything on the Solana blockchain.
They had also been watching the gaming space closely. Several Solana-based games had launched that year with strong art and thin backends, and the same thing sank most of them. A wallet flow that asks a casual player to think like a crypto trader kills the funnel at signup. Their own first attempt at Solana game development had the Unity client talking to an RPC node directly, which works in a desktop web wallet and falls apart on a mid-range Android phone. Successful Solana games separate on-chain logic from latency-sensitive gameplay.
The gaming industry has watched this pattern repeat for years. This case is for studios, Unity teams, and blockchain product owners trying to add Solana to a mobile game without turning login, payments, or ownership into friction. It covers the business challenge, wallet and backend architecture, smart contracts, NFT assets, tokenomics, multiplayer constraints, UI/UX, testing, launch, and post-launch impact.
Two of the Solana-based games they studied are still live, and both moved to custodial wallets in their second year. Gaming is a retention business before it is a crypto one, and blockchain games live or die in the first ten minutes. The ones that survive hide the wallet. The rest keep explaining it, and the gaming industry has plenty of examples of both.
Real-Time Performance Requirements
A race that stutters is a race nobody replays. Every call to the Solana blockchain had to run off the render thread, and the multiplayer layer needed room for 8 players at 20 updates per second while a transaction settled in the background.
Player Asset Ownership
In-game assets bought with real money had to belong to the player, not to a database row the studio could quietly edit. That meant NFTs minted per item and a wallet the player controls, without asking a casual player to memorize 12 words.
Sustainable Game Economics
In the first economy draft, $PRGC paid out faster than players could spend it. The token needed sinks tied to market demand and utility, plus a daily cap, or the in-game currency would inflate within weeks of release.
Technologies Behind Solana Game Development
Our Solana Game Development Solution
One question shaped the architecture: what belongs on the phone, and what belongs on the server? The Unity client renders the world, runs the game logic, and reads state. Everything with money attached moved behind a Node.js backend where a transaction can be signed, retried, and audited: wallet keys, store purchases, $PRGC rewards, NFT ownership.
Roughly 40 REST endpoints, documented in Swagger inside the studio’s own GitHub repo, running on AWS with immutable containers and a managed PostgreSQL database.
Custody was the hard part. Players on a phone will not manage a seed phrase, and a Solana game that asks them to loses most of its funnel at signup. Keycloak handles registration, login, and password reset. A custom HashiCorp Vault plugin derives a Solana keypair from the bearer token Keycloak issues, so private keys never touch the device, and a reinstall or password reset never loses a wallet. Nothing off the shelf did this, so we developed the plugin from scratch.
The Solana blockchain fit this game for two reasons. Low fees keep a single mint under a cent, so per-item ownership becomes a design option rather than a whitepaper promise, and this game writes something on-chain roughly every 40 seconds per active player.
Speed covers the rest: a purchase confirms in about 1.4 seconds while the player is still looking at the store screen. On other blockchain platforms with slower blocks, we would have needed an optimistic interface that shows an item and then takes it back.
Tooling made the Solana blockchain accessible to a team that had never written Rust. Anchor Framework, Metaplex Protocol, and Solana Web3.js cover programs, NFTs, and the client, backed by a growing community and good developer resources.
Rust runs the programs, TypeScript the signing service, C# the client, and one engineer can follow a feature across those programming languages from store screen to mint. RPC access goes through Alchemy rather than a public node. And since $PRGC sits inside Solana’s ecosystem next to various DeFi protocols and decentralized exchanges, a token earned in a race can move elsewhere without a bridge, an option this NFT game keeps open.
Multiplayer runs through Photon Cloud. Room logic lives on the Unity side, authoritative match records live on the backend, and the server writes a race result that pays $PRGC after the room closes. Eight players per room, 20 updates per second, around 85 ms round-trip. Players interact in real time, the game logic settles the race, and the Solana blockchain hears about it afterward, which is the only ordering that keeps gameplay honest.
High-Performance Smart Contract Development
Four Anchor programs cover minting, transfers, reward claims, and the item registry, at roughly 2,400 lines of Rust and 91% test coverage. Only the backend holds mint authority, so no client build can create a token or an NFT on its own.
Unity and Unreal Engine Integration
The Unity C# layer wraps every blockchain call in an async request to the backend, so nothing blocks the render thread. The same REST contract works for an Unreal client if the studio ports the title later.
NFT Asset Management System
Three collections, about 240 item templates, four rarity tiers. Metaplex holds metadata, the backend keeps a mirrored index, so the inventory loads player assets from Postgres in milliseconds while ownership of those in-game assets stays on chain.
Crypto Wallet Integration
The backend can create a wallet in roughly 1.2 seconds at first login, derived inside HashiCorp Vault from the player's auth token. Players top up with fiat through in-app purchase, and 12 IAP SKUs map to $PRGC bundles and starter packs.
Play-to-Earn Tokenomics Design
Six earn events feed the economy, and five sinks drain it, with a daily cap per account. Race wins and quests pay $PRGC tokens. Upgrades, repairs, and cosmetics pull them back out, which ties the token to utility rather than to speculation alone.
Cross-Platform Multiplayer Architecture
Photon Cloud rooms hold 8 players at 20 Hz with high performance on mid-range hardware, and iOS and Android players share the same room. Match results are written server-side before any transaction is signed, so a disconnect at the finish line cannot pay a reward twice.
Advanced Security Implementation
Private keys stay in Vault. Keycloak issues short-lived bearer tokens; the signing service checks ownership on every request, holds per-account rate limits, and refuses a claim already paid. Security protocols were reviewed at prototype stage and again before mainnet, and about 300 QA cases exist only to break the transaction path.
Role-Based Access Control
We developed three user roles with separate rights: player, moderator, and admin. That split lets the studio ban a cheating account without touching anyone else's in-game assets, and keeps mint authority off every client build.
Agile Development Methodology
Project Journey
Five people: a backend lead, a Unity engineer, a blockchain developer, a DevOps engineer, and a QA specialist. The first three weeks went to discovery and produced two documents the studio still works from: the in-app purchase architecture and the wallet key-derivation spec. Discovery also settled the awkward question early: what the game client is allowed to know about Solana, and the answer shaped every sprint of game development that followed. Resources went to the wallet first, because every other feature we had to develop depended on it.
How Solana Game Development Works
- We map earn events, sinks, and daily caps before a line of Rust exists. The economy sets the rules that the smart contracts enforce, and creating that model early keeps token supply predictable.
- Smart contracts split by responsibility: token, mint authority, item registry, reward claims. Anchor handles accounts and instruction validation, and mint authority never leaves the backend.
- The Unity client talks to the backend over REST, never straight to an RPC node. Network latency stays away from the render thread, so the game keeps its frame rate at speed.
- The backend asks Metaplex to create an item with metadata and rarity, mirrors ownership of those assets for fast reads, and pays $PRGC tokens out from a server-signed claim.
- Devnet first, then a soak test at 5,000 concurrent sessions and roughly 120 transactions a minute. Failure paths get as much attention as the happy path, since high performance means nothing if a stuck transaction costs a player real assets.
- Smart contracts go to mainnet, the store opens, and monitoring watches transaction success, RPC latency, and claim volume from the first hour onward.
Smart Contract Development Process Flow
Backend development for a blockchain game rarely survives a big-bang release, so smart contract development ran one sprint ahead of the client work: programs went to Solana devnet first, the Unity team integrated against them while QA hammered the failure paths, and only then did anything move to mainnet. After launch, we stayed on for support, runbooks, and two weeks of paired work, and the studio’s own developers went on to develop and ship their first item drop alone six weeks later.
How We Delivered Game with Solana Blockchain Technology
- We define the project goal together, agree on priority features, and set a realistic delivery date and budget.
- We build a ranked list of everything the product needs, starting with what matters most to the business.
- Work is broken into 2-week cycles. At the start of each, we select the next set of features to deliver.
- The team builds, tests, and integrates features throughout the sprint.
- At the end of every sprint, you see working software and give feedback that shapes the next cycle.
- Each sprint produces a shippable piece of the product. We review what worked, adjust, and move forward.
UI/UX Design: Keeping the Wallet Out of the Player’s Way
The design brief had one line at the top: a player should be able to finish the game without ever learning what a blockchain is. The world of the game is a neon city at night, so the interface stays dark and out of the way. So the wallet has no screen of its own. It shows up as a balance in the top corner, and a confirm button in the store, and that is the entire surface.
Purchases follow a pattern players already know. Tap an item, see the price in $PRGC tokens or a fiat bundle, confirm once, and about 1.4 seconds later it is in the inventory. The palette runs dark around the studio’s #6C60F4 purple, race and delivery HUDs stayed untouched, and characters carry their in-game items across both gameplay modes, so the jacket bought in the store shows up in the race. Ownership feels real without a single screen explaining it, which is what keeps conversion in a free-to-play store rather than in a wallet tutorial.
Failure states took the most design time. A declined purchase, an RPC timeout, a claim that lands twice in the queue: each one gets a plain sentence and a retry button, never an error code. Players read “That didn’t go through, your $PRGC is safe” and tap again.
Timeline
Five phases, clearly defined
Discovery & Architecture
- Reviewing the Unity build and the direct-to-RPC design it shipped with
- Writing the IAP architecture document and the key-derivation spec
- Naming 3 user roles and the rules for what each one may sign
Backend Prototyping
- Keycloak auth returning bearer tokens for register, login, and reset
- A custom Vault plugin that can create a Solana keypair from that token
- First 18 Swagger endpoints scaffolded in the studio's own repo
Agile Development
- Building the store, the claim service, and the NFT mirror index
- Integrating Photon Cloud rooms with server-side match records
- Balancing 6 earn events and 5 sinks against live playtest data
QA & Testing
- Running ~1,400 test cases, ~300 of them on transaction failures
- Soak testing at 5,000 concurrent sessions, ~120 transactions a minute
- Rehearsing the full mint, claim and purchase path on devnet
Launch & Support
- Mainnet deployment, then 500 beta players before the public release
- Watching transaction success, RPC latency and claim volume daily
- Handover: Swagger docs, runbooks and two weeks of paired work
Results
Before
- ✕A Unity build with no backend. Currency, in-game items and race results all lived on the device.
- ✕The client called the Solana blockchain directly, so RPC waits blocked the render thread on every purchase.
- ✕Private keys sat in app storage, and a password reset meant a lost wallet.
- ✕No multiplayer at all. Race results were local, unverifiable, and worth nothing on the Solana blockchain.
- ✕In-app purchases existed as a spreadsheet plan: no store, no SKUs, no receipt validation.
After
- ✔98% of blockchain transactions cleared during testing, with an automatic retry covering the rest.
- ✔~1.2 s to create a wallet at first login, derived in Vault from the player's auth token.
- ✔~1.4 s purchase confirmation on device, with the chain call handled off the render thread.
- ✔8-player Photon rooms at roughly 85 ms, with match results written server-side before payout.
- ✔One platform for auth, wallets, store, NFTs and match records, across 40+ documented endpoints.
Impact of Solana Gaming Platform After Launch
Verified Reviews
Our Reputation on Top Platforms
LITSLINK holds a 4.8 rating on top platforms. Clients writing about our blockchain gaming and software development work most often mention technical depth, steady communication across long engagements, and a willingness to push back on a requirement when the architecture says otherwise.
Have a Solana Project in Mind?
Looking for a Solana game development company for a Unity build that already plays well, or a blockchain layer for a title that is already live? Tell us what exists today: engine, backend, token plans, and target stores, and our specialist gets back to you within 48 hours.
