The conventional wisdom in game economy design is that player value should stay inside a single title. Closed loops are simpler to reason about, easier to balance, and carry less regulatory exposure. For a studio shipping one game, that advice is mostly right. For a studio on its second or third title — or a publisher running several games in the same genre — it's leaving money on the table and creating unnecessary churn friction.
Cross-game currency portability is the ability for a player to carry earned or purchased value from one title to another. It sounds straightforward. The implementation is not. This piece covers the data model, the exchange rate problem, the edge cases that will bite you in production, and the compliance considerations that are easy to miss.
Why Players Lose Value at Title Transitions
When a player finishes a game or loses interest in a title, they typically have two categories of value at risk: earned soft currency (that grinding reward they never spent) and unspent hard currency (premium credits purchased but never used). Both go to zero when they uninstall.
From a pure retention standpoint, this is acceptable — the player has churned, the economic position of that balance is zero either way. But from a studio franchise standpoint, it's a missed opportunity. If that same player picks up your next title — a sequel, a spin-off, a different genre from the same studio — you've just asked them to start at zero despite having invested in your studio's ecosystem.
Carry rates in studios that have implemented some form of cross-title progression incentive are meaningfully higher than cold starts, especially in the mid-core segment where players have established franchise loyalty. We're not suggesting that portability alone drives retention — it doesn't. But it removes friction from a transition that you want players to make.
The Shared Ledger Data Model
The architectural precondition for cross-game currency is a wallet system that exists above the title layer. If your wallets are provisioned per-game in isolated databases with no shared player identity, portability requires a migration or a translation layer — both of which are harder to get right than building the shared model from the start.
A shared ledger model looks like this: each player has a canonical player ID at the studio (or publisher) level. Each title has its own currency definitions — Game A uses "Orbs," Game B uses "Shards." Both currencies are defined in a shared currency registry with a currency_code (e.g., ORBS_A, SHARDS_B), a display_name, and — critically — a base_rate that expresses the currency's value relative to a shared unit of account.
The shared unit of account is the key design choice. You have two options: use real fiat (USD cents) as the unit, where 100 Orbs = $1.00 means each Orb has a stored value of 1 cent; or use a studio-internal point unit (e.g., "Linq Credits") where each game's currency maps to a point rate. The fiat-anchored approach is cleaner for accounting but has regulatory implications — if you're tracking fiat value in player accounts, you're in custodial territory. The studio-point approach is safer for compliance but requires more careful management of purchasing power parity across titles.
The transaction record for a cross-game transfer then becomes:
{
"tx_id": "txn_7f3a...",
"type": "cross_game_transfer",
"player_id": "usr_9c12...",
"from_currency": "ORBS_A",
"from_amount": 500,
"to_currency": "SHARDS_B",
"to_amount": 350,
"rate_applied": 0.70,
"rate_version": "2025-Q3-v2",
"initiated_at": "2025-09-15T14:32:00Z",
"settled_at": "2025-09-15T14:32:01Z"
}Rate version matters. You'll change exchange rates over time. Every historical transaction needs to record which rate was in effect, both for audit trails and for reconstructing a player's economic history in a dispute.
The Exchange Rate Problem
Setting the exchange rate between two game currencies is an economy design decision that most studios underestimate. Get it wrong in one direction and portability becomes a currency arbitrage exploit. Get it wrong in the other direction and no player will bother using it.
The core principle: the exchange rate should reflect the relative purchasing power of the currencies at their primary acquisition point, not their nominal denomination. If Game A sells 1,000 Orbs for $9.99 and Game B sells 1,000 Shards for $4.99, then the economically neutral rate is 2 Shards per 1 Orb (since Orbs are twice as expensive). Setting the rate at 1:1 would let players effectively buy Game B's premium currency at half price by routing through Game A.
In practice, studios apply a conversion discount — typically 10–25% — on top of the neutral rate. This covers the economic cost of the transfer (you're giving up Game A economy stability when Orbs leave), creates a psychological "loss" that makes players think carefully about transferring, and provides headroom for rate adjustments without creating instant arbitrage. A conversion discount is honest and standard; the key is surfacing it transparently in the UI so players understand what they're getting.
We're not saying conversion discounts are manipulative — they're economically justified and they're disclosed. What becomes a dark pattern is hiding the conversion math, presenting a rate without context, or making it difficult for a player to calculate what they'll actually receive before confirming the transfer.
Edge Cases That Hit in Production
A 20-person indie team in Warsaw shipped cross-game currency portability between their two mid-core mobile titles in early 2025. The feature worked in staging. In production, within the first 72 hours, they hit three scenarios they hadn't tested:
Rate change during pending transfer. A player initiated a transfer, the exchange rate updated (scheduled maintenance window), and the transfer settled at the new rate without the player having consented to it. The solution: lock the rate at the time of initiation, give the player a fixed quote valid for a 30-second confirmation window. If the window expires, surface a new rate for reconfirmation.
Balance rounding at fractional rates. At a 0.7 exchange rate, 1 Orb becomes 0.7 Shards — which you cannot represent in whole-unit currency. The studio had rounded down silently, which caused a 1-2% value loss per transfer. Players noticed. The fix is to either enforce a minimum transfer amount that produces whole-unit output, or round to the nearest unit and credit the rounding difference to a reconciliation account you settle periodically.
Transfer to a title the player doesn't own. The currency registry allowed transfers to Game B even if the player had never installed or registered in Game B. Shards were sitting in an account the player couldn't access. Guard against this with a title-registration check before initiating any cross-game transfer — the destination title must exist in the player's account record.
Compliance Considerations for Cross-Game Transfers
If both currencies are non-redeemable virtual currency with no fiat exit path, cross-game transfers are generally treated the same as any in-game currency operation — not money transmission. The moment a redemption pathway exists (player can cash out either currency for real money), the transfer mechanism becomes a potential vector for regulatory scrutiny. A player could, in theory, cycle value between games to obscure the origin of funds.
This is not a reason to avoid building portability. It is a reason to include cross-game transfer volume in your AML monitoring rules. Unusual patterns — high-value transfers followed immediately by cash-out requests, transfers to newly created accounts, transfers that reconstruct balances just below KYC thresholds — should trigger review flags in your transaction monitoring system.
Additionally, if your games are available in the EU, the revised Payment Services Directive (PSD2) and the upcoming application of the Transfer of Funds Regulation to some virtual asset service providers may affect how cross-game value transfers are treated. This area of EU regulation is still evolving. Get qualified legal review before shipping portability in EU markets.
SDK Implementation Pattern
From a Unity implementation standpoint, a cross-game transfer is a two-phase API call with a confirmation step. The initiation call returns a quote object — not a completed transfer — that the player can review and confirm or cancel:
// Phase 1: Get a quote
var quote = await LinqSDK.Currency.GetTransferQuote(new TransferQuoteRequest {
PlayerId = currentPlayer.Id,
FromCurrency = "ORBS_A",
FromAmount = 500,
ToCurrency = "SHARDS_B"
});
// Display quote.ToAmount and quote.RateApplied to player
// quote.ExpiresAt gives you the confirmation window
// Phase 2: Confirm if player accepts
if (playerConfirmed) {
var result = await LinqSDK.Currency.ConfirmTransfer(quote.QuoteId);
}Never execute the transfer in a single call without a player-visible confirmation step. This is both a UX requirement and a consumer protection consideration in several jurisdictions that require explicit consent for value movements.
Cross-game currency portability is a genuine competitive differentiation for studios operating franchises. It requires careful architecture — but the architecture is well-understood. The hard part is the exchange rate design and the production edge cases. Build the quote-and-confirm flow from the start, version your rates, and you'll avoid the class of bugs that hit studios who treat it as an afterthought.