Skip to main content

In-Game Currencies

In-game currencies can use closed-loop tokens to create assets that players earn and spend within your game's economy. You mint the currency on Sui, but players can only use it within the workflows you define (for example, buying items, upgrading characters, or trading with other players through a governed marketplace). Common examples include gems, diamonds, credits, and gold.

Closed-loop tokens differ from standard Coin types because they restrict what actions holders can perform. You configure a TokenPolicy with rules that gate minting, spending, and transferring. This lets you control the game economy onchain while preventing players from extracting currency outside the game's intended flows.

This example implements a governance-controlled currency called King Credits. Transferring the currency requires approval from a Crown Council, which you configure as a custom rule. This pattern is useful when you want human or programmatic oversight over currency movement (for example, anti-cheat measures or economy balancing).

Initialize the currency​

To create the King Credits currency, initialize the currency using the coin_registry::new_currency_with_otw module and configure the currency policy with token::add_rule_for_action:

info

init functions run only during the package publish event.

Set custom transfer rules​

In another Move package, implement the add_rule_config function to initialize the rule configuration with initial council members and set a limit on the maximum number of members, including a check to ensure the count does not exceed that maximum.

The add_council_member and remove_council_member functions add and remove members from the council. The prove function checks whether the request sender is a council member and adds an approval for the rule if they are:

Deploy and test​

To deploy the King Credits currency:

  1. Build both packages (the currency and the council rule): 
    $ sui move build
  2. Publish the currency package first, then publish the council rule package (which depends on the currency package).
  3. After publishing, the init function runs automatically and creates the TreasuryCap, TokenPolicy, and initial token configuration.
  4. Add council members by calling add_council_member with the TreasuryCap.
  5. Test a transfer by minting tokens to a user, then having a council member call prove to approve the transfer.

Implementation considerations​

  • Protect the TreasuryCap. The holder can mint unlimited tokens, disrupting the game economy. Store it in a multisig address or dedicated custody (Security Best Practices).
  • Council member management. The add_council_member and remove_council_member functions should be gated by the TreasuryCap holder. Log all membership changes as events for auditability.
  • Supply management. Decide your supply model early. If you mint tokens on demand (for example, as player rewards), monitor the total supply to prevent inflation that undermines your game economy.

When to use this pattern​

Use governance-controlled in-game currencies when:

  • You need human or programmatic approval for transfers (anti-cheat, economy balancing).
  • The currency should not be freely tradable outside the game.
  • You want onchain transparency for all currency operations.

For currencies that do not need transfer approval, use the loyalty tokens pattern instead, which uses simpler spend-only rules.

View the full example on GitHub.