Gold Coins vs Sweeps Coins: How the Dual-Currency Model Works

Gold Coins and Sweeps Coins are the two virtual currencies of a sweepstakes casino. Gold Coins are an entertainment currency that players can buy but never redeem. Sweeps Coins are a promotional currency that players can never buy but can redeem for prizes once the operator’s play and verification rules are met. Everything else in the dual-currency model, including the wallet design, the ledger, the event flow and most of the risk, comes from keeping those two properties apart.

This guide compares the two currencies the way a product or engineering team has to. It covers how each currency enters and leaves the system, which operator rules vary and why that matters for code, how a dual-currency ledger is structured, and which implementation errors create the costliest problems.

Key Takeaways

• Gold Coins are sold and never redeemed; Sweeps Coins are never sold and can be redeemed. A platform must enforce both properties in the ledger, not only in the interface.
• Sweeps Coins are not one balance. A working design tracks unplayed, redeemable and redemption-locked SC as separate accounts, because each follows different rules.
• Operator rules that look identical are not. Chumba Casino counts its 60-day Sweeps Coin expiry from the last login; Pulsz and McLuck define dormancy as 60 days without gameplay. Default playthrough ranges from 1x to 3x in published rules, and minimums can differ by prize type.
• Currency units and currency rules belong in different layers. The ledger records amounts. Playthrough, minimums, ratios and expiry triggers belong in versioned configuration.
• A correct dual ledger proves what happened. It does not make a model lawful. Legal status depends on the model, the jurisdiction and current legal advice.

Gold Coins vs Sweeps Coins: The Key Distinction

The key distinction between Gold Coins and Sweeps Coins is the direction value is allowed to travel. Money can flow into Gold Coins but never out of them. Value can flow out of Sweeps Coins as prizes, but money never flows into them. A sweepstakes casino platform is, at its core, a system for keeping those two one-way doors from ever connecting.

Chumba Casino’s Sweeps Rules (version 8.0, December 2023) state that Gold Coins cannot be redeemed for prizes and that Sweeps Coins are received free, for example as a bonus when purchasing Gold Coins. High 5 Casino’s Sweepstakes Rules (version 43.0, June 26, 2026) state that Sweeps Coins “cannot be purchased under any circumstances.” Those two statements set the boundary that the software has to defend.

For a build team, the verdict is simple. Gold Coins behave like a game currency with one account per player. Sweeps Coins behave like a promotional liability with several states, a provenance requirement and an exit path through identity checks and external payment rails. Treating them as two fields on one balance table is a common and costly design error.

Gold Coins vs Sweeps Coins Comparison Table

A Gold Coins vs Sweeps Coins comparison shows that the two currencies differ on every dimension that matters to the platform: how they are acquired, what play does to them, how they leave the system and what the operator must record. The table separates structural properties, which hold across the standard model, from operator-set parameters, which do not.

The last row is where teams underestimate the work. Sweeps Coins carry twice as many operator-set parameters as Gold Coins, and each one changes ledger and event behaviour. How GC sales are recognized and how outstanding SC is provisioned are accounting-policy decisions for the operator’s finance team and auditors. The platform’s job is to make both numbers measurable at any time.

Operator Rules That Vary and Must Stay Configurable

Sweepstakes operator rules vary on exactly the parameters that guides often present as industry standards: playthrough, redemption minimums, prize value per coin, inactivity expiry and even the names of the currencies. The table below records what each operator’s own published document said when checked on October 9, 2026. It is a dated snapshot, not a benchmark.

Sources for the table: Chumba Casino Sweeps Rules v8.0, High 5 Casino Sweepstakes Rules v43.0, the Stake.us help center article on redemption progress, Pulsz Terms of Use v5.2 and McLuck Terms of Service v2.6.

Five contradictions in this snapshot have direct engineering consequences.

The same 60 days, two different clocks. Chumba’s rules count 60 days from the last login. Pulsz and McLuck count 60 days without gameplay. A player who logs in daily but never plays keeps Chumba Sweeps Coins and loses Pulsz Virtual Coins. An expiry job with the day count as its only setting cannot represent both. The trigger has to be configurable too.

Playthrough is a ledger model, not a number. A 1x rule can be enforced by moving winnings straight into a redeemable account. A 3x rule cannot. In Stake.us’s own example, a 10 Stake Cash bonus must be played through at least 30, which requires per-grant wagering progress (covered below).

Minimums can depend on the prize type. High 5 sets 50 SC for non-cash prizes and 100 SC for cash. Chumba sets one US$100 threshold. A single min_redemption field cannot represent both.

One coin is not always one dollar. Chumba and High 5 value one redeemable Sweeps Coin at US1.FortuneWins(formerlyFortuneCoins)isreportedinindependentreviewcoveragetoredeemat100FortuneCoinsperUS1. If the dollar value is hardcoded into the ledger, a second ratio means rewriting core code.

Pending requests have their own clock. Pulsz’s Terms state that a redemption request pending for more than 90 days is automatically declined and the coins are returned. The ledger has to support that timed transition as a first-class event.

Operator rules also change: High 5’s rules are on version 43.0 and list dated end-of-access changes for specific states. Treat every parameter in this table as configuration with an effective date, never as a constant.

The Dual-Currency Lifecycle: Five Stages

The dual-currency lifecycle below is OmiSoft’s framework for modelling how Gold Coins and Sweeps Coins move from creation to exit. It is derived from the operator rules above and the ledger patterns in this guide, and it is an analytical model, not an industry standard. Its purpose is to show where the two currencies run the same path and where Sweeps Coins add controls.

The Gold Coin lifecycle

The Gold Coin lifecycle is a closed loop. The payment provider authorizes a purchase, the platform credits the player’s GC account, and wagers and wins move GC between the player and the game. Gold Coins leave only by being wagered away, expiring or being forfeited. With no exit to value, the GC side needs accuracy and an audit trail, not a review gate.

The Sweeps Coin lifecycle

The Sweeps Coin lifecycle is an open path with gates. SC enters only from a promotional source and lands as unplayed. Play moves it toward redeemable under the playthrough rule. A redemption request locks the amount, review decides whether it proceeds, and only a confirmed payout removes it from outstanding exposure. Every gate needs an event and a ledger record.

Gold Coins and Sweeps Coins share stages 1 to 3 in shape but not in rules. Sweeps Coins add the Clear stage and the gated part of Exit, where almost all sweepstakes-specific engineering sits. If you are scoping sweepstakes casino software development, those two stages need the most precise requirements.

Balance, Wallet, Ledger, Transaction, Event and Settlement

Balance, wallet, ledger, transaction, event and settlement are six terms that product, engineering and finance teams use loosely and differently. In a dual-currency sweepstakes platform the differences carry real weight, because each term names a different layer with different rules about what can change and who can change it.

Settlement is the term that causes the most bugs. In game integration, settlement means a round’s result is final and the win can be credited. In payments, it means an external rail has confirmed delivery. A Sweeps Coin redemption should leave outstanding exposure only on the second meaning, after the payout provider confirms delivery and the record reconciles. Burning SC when the payout is sent rather than confirmed leaves no clean way to handle a failed transfer.

Dual-Ledger Architecture

A dual-ledger architecture for a sweepstakes casino keeps Gold Coins and Sweeps Coins as separate currencies inside an append-only, double-entry ledger, where balances are derived from entries and every movement has a matching source and destination account. “Dual ledger” describes currency separation. It does not have to mean two databases, but it does mean no transaction ever spans both currencies.

Our guide to what a sweepstakes casino is introduces this split at a high level. The structure below is OmiSoft’s reference design for the account layer: one sound way to build it, not a legally required pattern.

Player accounts (one set per player)

System accounts (shared)

A worked example under a 1x rule, using illustrative amounts:

1. A player buys a GC package carrying 20 bonus SC. The purchase event produces two transactions: GC from gc.sales_issuance to gc.available, and 20 SC from sc.promo_issuance (purchase-bonus channel) to sc.unplayed, with the purchase ID stored as a reference. No money flows into the SC side.
2. The player wagers 2 SC: sc.unplayed → sc.game.
3. The round settles with a 5 SC win: sc.game → sc.redeemable.
4. Later, the player requests a 100 SC redemption: sc.redeemable → sc.locked.
5. After review and confirmed payout: sc.locked → sc.redeemed. The cash or gift-card payout is recorded on the payments side and linked by reference.

The structure produces five invariants a build team can test automatically:

• No cross-currency transaction. No transaction debits a GC account and credits an SC account, or the reverse.
• No SC from a payment account. SC can only originate from sc.promo_issuance. A purchase can be referenced by a bonus grant but can never fund it.
• Balances are derived. No code path writes a balance directly.
• Every transaction has a source event and an idempotency key. Nothing enters the ledger without a traceable cause.
• Valuation lives outside the ledger. The ledger stores coin units. The prize value per unit, and any ratio such as 100:1, is applied by the redemption service from versioned configuration.

Two playthrough models

The 1x model above clears SC by routing winnings straight into sc.redeemable, which matches rules like Chumba’s “played once.” A multiple such as Stake.us’s 3x needs a different structure: each grant becomes a tracked lot with a wagering requirement (10 SC × 3 = 30 SC) and a progress counter. Wagers are allocated to open lots in a defined order, and a lot moves to redeemable only when its counter completes.

The two models are not interchangeable after launch. Switching means introducing lots and migrating every open unplayed balance. A platform that may need both should implement lots from the start and treat 1x as a lot with a multiple of one.

Draw order is a rule, not an optimization. When a player holding both unplayed and redeemable SC places a wager, the platform must decide which balance pays first. Unplayed-first speeds clearing; redeemable-first preserves the chance to clear bonus coins later. Either changes player outcomes, so it should follow the published rules and live in configuration.

Transaction-Event Logic

Transaction-event logic in a dual-currency platform defines which external or internal facts produce which ledger transactions, how duplicates are rejected, and how mistakes are reversed. The taxonomy below is OmiSoft’s working classification. Event names are illustrative and not an industry standard, but the grouping reflects how the lifecycle stages map onto ledger writes.

Four rules make this taxonomy hold under load.

Bind the currency to the session, not the payload. Open each game session in exactly one currency mode and reject any game-server callback whose currency disagrees. Payloads are often generic (an amount and a currency string), so trusting them is how a Gold Coin win gets credited as Sweeps Coins.

Make duplicates harmless. Game servers and payment providers retry when they get no acknowledgement. A unique idempotency key, enforced by a database constraint rather than application code, turns a retried win into a no-op.

Serialize writes per wallet. Simultaneous spins from several tabs or scripts can pass a balance check together and overspend. Routing every debit and credit for one player through a single ordered path removes the race, whatever technology implements it.

Reverse with new entries, and reverse exactly. A rolled-back SC wager that drew 1.5 SC from sc.unplayed and 0.5 SC from sc.redeemable must return 1.5 and 0.5 to those same accounts. Returning the full amount to either one silently changes the player’s eligibility, so the split must be stored on the original transaction.

When these rules are added to an existing real-money or social platform, the gap is usually in the gameplay and corrective families, which is where a casino software development audit of an established wallet should start.

Dual-Currency Implementation Risk Matrix

The dual-currency implementation risk matrix below is OmiSoft’s framework for prioritizing what to test before a sweepstakes platform goes live. Each risk is tied to a lifecycle stage, a concrete failure, the type of exposure it creates, the control that prevents it, and the reconciliation signal that detects it if the control fails.

Exposure types used: Liability (redeemable SC created or released without a valid basis), Revenue (lost purchase value), Audit (cannot prove what happened or which rule applied), Player (wrongful loss or a result that contradicts published rules).

Two patterns stand out. First, six of the nine risks can create Sweeps Coin liability, and four of those six sit in the Play or Clear stages, so game-integration testing deserves as much attention as redemption testing. Second, every detection signal in the last column depends on an append-only ledger. Without immutable history, none of them can be produced.

Detailed operator tooling for adjustments and reconciliation belongs in the planned back-office features guide. The full redemption review and KYC sequence belongs in the planned redemption-flow guide.

What a Dual-Ledger Design Does Not Do

A dual-ledger design separates Gold Coins from Sweeps Coins technically and produces evidence of that separation. It does not determine whether a dual-currency sweepstakes model is lawful in any state, and it cannot make an operator compliant on its own. State treatment of these models varies and has changed rapidly since 2025, and operators need current legal advice.

What the ledger can do is answer evidence questions precisely: where a Sweeps Coin came from, whether any purchase funded it, which rules were in force when it cleared, and who approved any manual change. Those answers support a legal team; they do not replace one. Compliance can still fail outside the ledger, for example if free-entry requests are processed slowly, if marketing implies Sweeps Coins can be bought, or if a purchase becomes a practical prerequisite for redemption. For the wider regulatory context, including statutes that reach software suppliers, see the regulatory section of our sweepstakes casino guide.

Decision Framework: Seven Questions Before You Build

A dual-currency decision framework turns the comparison above into requirements. Each question below has an owner in product, finance, legal or engineering, and each answer changes the ledger or the configuration layer. Answering them before development is far cheaper than discovering them in production.

1. Which playthrough model, and might it change? If a multiple above 1x is possible, require lot-based clearing from day one.
2. Do redemption minimums differ by prize type? If yes, thresholds must be keyed to the payout method.
3. Is one Sweeps Coin always one unit of prize value? If not guaranteed, valuation must sit in the redemption service, not the ledger.
4. What starts the expiry clock: login or gameplay? Make the trigger and the period separate settings.
5. Which balance pays first in SC play? Decide draw order to match the published rules, and make it configurable.
6. What happens to pending redemptions after a chargeback, a failed payout or a timeout? Each outcome needs a defined event and destination account.
7. Which rule changes must ship without a code release? Usually all of the above, with effective dates and a record of which version applied to each transaction.

The Short Version

Gold Coins are an entertainment currency that money can enter but value cannot leave. Sweeps Coins are a promotional currency that value can leave but money cannot enter. A platform makes that boundary real by keeping both currencies in an append-only, double-entry ledger with no cross-currency transactions, by splitting Sweeps Coins into unplayed, redeemable and locked states, and by keeping every operator rule (playthrough, minimums, value per coin, expiry trigger) in versioned configuration rather than code.

Published operator rules show why that last point matters: the same “60 days” or “1x” means different things at different operators, and the rules change. Design the ledger to record coins exactly, the rules layer to change safely, and treat legal status as a separate question for counsel.

By Yevhen Sakara

CBDO & Co-founder

15 mins read | Oct 09, 2026

• 
• 
•