Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.uniblock.dev/llms.txt

Use this file to discover all available pages before exploring further.

​
Gaming and In-App Assets

Games and consumer apps often need a fast asset layer more than they need chain-specific infrastructure. Uniblock is useful here because the same integration can expose fungible rewards, NFT inventory, transfer history, and event-driven updates across multiple chains.

​
Best-fit workflows

  • Player inventory views
  • Reward token balance displays
  • NFT item ownership checks
  • Real-time notifications for item or reward transfers
  • Backend services that read contract state or submit transactions

​
Suggested implementation flow

​
1. Build the player asset view

Use token and NFT balance endpoints to show:
  • soft currency balances
  • premium token balances
  • inventory items and collectibles
If players can own assets on multiple chains, normalize them into one account view in your backend. Transfer and transaction endpoints are useful for:
  • reward claim history
  • marketplace purchases
  • item transfers between wallets
  • contract interactions tied to gameplay

​
3. Use webhooks for live state changes

Games benefit from event-driven updates more than most app categories. Use webhooks to trigger:
  • inventory refreshes
  • reward claim confirmations
  • contract event processing for on-chain game logic

​
4. Use JSON-RPC for game-specific contract reads

If your backend needs custom contract methods, use JSON-RPC for direct reads and writes while keeping the Unified API for account and asset views.

​
Why this pattern works

For most games, the hardest part is not a single chain integration. It is keeping asset state, user-facing balance views, and event processing coherent as the product grows. Uniblock reduces that surface area by giving you a single data layer for the read path.

​
Common pitfalls

Do not make the gameplay loop depend on a single polling endpoint. Use webhooks or queued refresh jobs for state changes that matter to the user experience.
Separate display balances from execution-critical contract reads. Your UI can use normalized APIs while your write path can still use JSON-RPC where needed.