How to build a cheat-proof in-game economy for a football manager

FOOTDRAFT's economy has two currencies, coins and gems, and a lot of ways to spend them: transfer fees, Scout Packs, draft spins, bundles and trades between managers. None of them can be faked by a modified client, because FOOTDRAFT runs on the Metaplay SDK's server-authoritative model: every action a player takes runs again on the server, against the server's own copy of the player's state, and the server's result is the one kept. We built FOOTDRAFT, a live service football manager, on that model, and its economy code shows what it takes to keep currency safe.

This post explains how the Metaplay model works, then walks through FOOTDRAFT's real code from metaplay-shared/footdraft: spends, server-rolled draft spins, refunds and player-to-player trades.

What a football manager asks of its in-game economy

A football manager's economy is busier than most because so much of it is competitive and shared:

• Managers pay transfer fees and gem costs to act inside a league that other managers are playing in.
• Some operations need the league to agree, not just the player's wallet: a transfer only happens if the league accepts it.
• Managers trade players and coins with each other, so one player's spend is another player's income.

Any game where players trade or compete for scarce items has the same three problems. FOOTDRAFT solves each one in code you can read.

How Metaplay's server-authoritative model prevents cheating in a game economy

The Metaplay SDK keeps the game state on both the client and the server and runs every player action on both sides. The client runs an action first, so the game responds at once. The action is then sent to the server and run a second time, and the server's copy of PlayerModel is always the authoritative one. A hacked client can change its own state in memory, but those changes never reach the server.

Three parts of the SDK make this hold:

• Shared, deterministic game logic: PlayerModel and every PlayerAction are the same C# on both sides, and they produce identical results, so the server can validate each action by running it rather than trusting a reported outcome.
• Checksums: the SDK computes a checksum of the player's state on the client and on the server. If they differ, the SDK flags a desync and the client starts a new session from the server's state, so tampered state never carries forward.
• Server-side randomness: random results the player must not predict or choose, such as loot rolls, can be generated on the server only.

The Metaplay docs on the game logic execution model go into the details. The rest of this post is how FOOTDRAFT puts each part to work.

Charge-in-action: every spend in the in-game economy runs on the server

In FOOTDRAFT every change to a player's state is a PlayerAction. Each action's Execute(PlayerModel player, bool commit) first checks whether the action is allowed and returns an error result if it is not. Only when commit is true does it change anything.

The spend happens inside that action. A transfer fee or a gem cost is taken from the wallet as part of the action itself, so there is no separate "report the new balance" step for a client to tamper with. SharedCode/Player/PlayerActions.cs defines 67 actions this way, from quest claims and pack openings to World Cup entry fees. The repo calls it a charge-in-action pattern.

Cheat-proof randomness: rolling draft spins on the server

Every pick in FOOTDRAFT's draft starts with a spin that lands on a random club and season, which makes the spin worth cheating on. So the roll never happens on the client. PlayerSpinForSlot checks that the slot is open, that no other offer is pending and that the manager has a reroll left, then hands the roll to the server. The server rolls the spin and writes the offer back into the player's state.

The reroll limit is enforced in the same action: free rerolls up to a cap, then one Scout Pack reroll boost per extra spin. A client that skips the check still has its action rejected on the server.

Refunds in a cheat-proof game economy

Some operations need the league's agreement as well as the player's money. FOOTDRAFT charges the wallet up front, and if the LeagueActor then rejects the operation, the server has to give the coins back. In Metaplay the server cannot just edit the player's state, because the client's copy would no longer match and the checksums would flag a desync. It issues a synchronized server action instead, which runs on both sides at the same point in the game's timeline:

/// Server action: return a league charge (transfer fee / elite-spin Gems) after the LeagueActor rejected the
/// operation the player already paid for. Server-issued only — a client cannot submit this, so the refund
/// path is not a currency faucet.
[ModelAction(ActionCodes.PlayerRefundLeagueCharge)]
public class PlayerRefundLeagueCharge : PlayerSynchronizedServerAction
{
    public override MetaActionResult Execute(PlayerModel player, bool commit)
    {
        if (Amount <= 0)
            return PlayerActionResults.InvalidAmount;
        if (commit)
            player.Wallet.Earn(Currency, Amount);
        return MetaActionResult.Success;
    }
}

Being a PlayerSynchronizedServerAction is what makes this safe. A refund hands currency back to a player, which makes it an obvious thing to fake, and an action only the server can send cannot be faked by a client.

Escrow for player-to-player trades in a cheat-proof economy

Trades between managers were added in the June 24 commit. When a manager proposes a player-and-coins trade, the coins leave their wallet into escrow and the LeagueActor holds the offer. If the proposer cancels or the other manager declines, the escrow is refunded. If the other manager accepts, the league re-validates both players, swaps them into each other's squads and pays the escrowed coins to the recipient.

Because the coins are taken when the offer is made, a manager cannot promise the same coins to two trades, and because the league re-checks both players at acceptance, a player sold in the meantime cannot change hands twice. For more on why the server has to hold the state, see our post on server-authoritative games.

Try the FOOTDRAFT in-game economy yourself

The project runs on Metaplay SDK Release 38, which is publicly available. Give this prompt to an AI coding agent such as Claude Code and it clones the repo, installs the Metaplay Agent and opens a local copy of the game in your browser:

Clone this repo and install Metaplay Agent using the Metaplay CLI, and open a playable version of the game locally in my browser so I can start building on top of it

You can also play the live game and spend some coins.