Best Practices
This guide will be updated as the Playtron SDK and additional tooling become available. Check back regularly for the latest recommendations and implementation details.
Follow these practices when developing for SuiPlay0X1:
- Minimize player signing prompts during gameplay by batching operations into programmable transaction blocks (PTBs).
- Use gas sponsorship so players don't need to hold SUI.
- Store onchain only data that must be player-owned or tradeable.
- Check wallet state fresh at the start of every session.
Developing for SuiPlay0X1 requires careful decisions around transaction frequency, gas management, and data storage. Apply these practices to keep gameplay smooth, reduce costs, and protect players.
Handling transactions
Avoid frequent micro-transactions: If players are using their self-custody wallets and transactions require explicit player signatures, then you should avoid frequent micro-transactions, particularly during gameplay. Signing a transaction requires popping up an on-device visual element or an off-device browser dialog to approve, breaking the gameplay flow. This is not a concern if you are managing custodial wallets (wallets your game operates on behalf of the player). See Wallet Integration Options for more information on available wallet integrations.
Many onchain actions do not require explicit user approval. For example, dropping rewards to a user, incrementing their currency, and so on. The game can handle these whenever appropriate, even silently in the background during gameplay.
How do I batch transactions to reduce interruptions?
Use programmable transaction blocks (PTBs) to group multiple operations into a single transaction. This reduces the number of times a player must approve an action and lowers the total gas cost. Grouping related state changes into a single PTB means players approve one transaction instead of several, and the game submits less work to the network overall.
Managing gas
If using a third-party wallet service (Beamable, Shinami), leverage gas sponsorship for custodial implementations to abstract from users. Consider tradeoffs between aggregated and individual wallets and batch transactions whenever possible to reduce gas costs.
How does gas sponsorship work for SuiPlay0X1 games?
Gas sponsorship lets your game pay transaction fees on behalf of players. The player signs the transaction as the sender but does not pay for it. A sponsor address covers the gas and provides its own signature separately as the gas payer. Services like Shinami provide sponsorship APIs that integrate directly into your transaction flow. When you enable sponsorship, players interact with onchain features without needing to hold SUI in their wallets.
Batch transactions whenever possible regardless of whether you use sponsorship. Fewer transactions mean lower cumulative gas costs and a faster experience for players.
Data management
Proper data management design can augment the user experience.
Onchain versus offchain storage
Consider where best to store your data:
- Onchain: Assets and currencies that can be traded or sold.
- Offchain: Game state, progress, and so on using traditional game servers.
While you can store any information onchain, consider whether it's important to your game for that data to exist there. If not, leverage traditional game server backends, which makes data syncing and updating easier.
What data should I store onchain versus offchain?
Store onchain only what needs to be player-owned, tradeable, or independently verifiable. Storing unnecessary data onchain increases gas costs and adds complexity to reads and writes.
| Data type | Recommended storage |
|---|---|
| In-game currency (tradeable) | Onchain |
| NFT items and cosmetics | Onchain |
| Player level and XP | Offchain |
| Match history and replays | Offchain |
| Leaderboard scores | Offchain (or a hybrid with onchain proof) |
| Achievement badges (tradeable) | Onchain |
| Temporary session state | Offchain |
For hybrid scenarios, store a commitment or proof onchain and keep the full data offchain. This keeps costs low while preserving verifiability for items that matter.
Session start protocol
At the beginning of each session:
- Check the player's current wallet state.
- Don't use wallet data cached from a previous session, as assets can change externally.
- Enforce session expiry rather than holding long-lived sessions.
Follow wallet and session security practices to protect players. Confirm that your game meets each of these requirements:
- Wallet state is not cached between sessions, because assets and balances can change externally and stale state can mislead the player.
- There is no blind signing: every signing prompt presents clear, human-readable transaction details so players know what they are approving.
- Sessions expire rather than being held long-lived.
- Sponsored transactions are rate-limited and authorized so an attacker cannot drain your gas budget through abuse.
- When you operate custodial wallets on a player's behalf, the associated custodial risk is clearly disclosed to users.
See the Security Best Practices guide.