Gold Coins vs Sweeps Coins: Sweepstakes Dual-Currency Architecture for Operators

A sweepstakes dual-currency architecture is not a feature you switch on. It is a set of guarantees the ledger makes, and the store, the game client, the payout rail and the back office all have to agree with them. The sweepstakes dual-currency model is usually explained from the player's seat; this guide specifies the system instead.

What Gold Coins and Sweeps Coins mean for operators

These are not two products but two ledgers with different obligations attached. Gold Coins are consumed and gone. Sweeps Coins may one day have to be settled, which is why they drive the gates and most of the engineering.

The player-facing version, what a spin costs and what each balance unlocks, belongs with dual-currency game mechanics. The play-only half behaves like the social casino model; the redeemable half is what makes this architecture different.

If the open question is still which shape of business to build, how the sweepstakes and real-money business models differ is the comparison to read first.

Why the two ledgers must be separate, and what separation actually means

Every vendor says the two wallets are kept separate. Few say what that commits them to. A dual-currency wallet architecture for a sweepstakes platform is separate only if it holds four invariants, each visible in the schema rather than in a policy.

The non-fungibility invariant

There is no conversion transaction type in either direction, no admin action that performs one indirectly, and no API parameter that moves value across the boundary. A currency flag on a single balance does not satisfy this: conversion is then a field update that a bug or an over-permissioned tool can perform. With two ledgers there is nothing to call, which is worth confirming when you evaluate sweepstakes casino software.

Tagging every game round with the currency it consumed

Every game round is tagged with the currency it consumed, so that each round belongs to exactly one of the two ledgers and neither ledger can be reconstructed from the other. The tag is written by the transaction that debits the stake. Without it, play volume is one blended number and the play-through gate cannot be evaluated.

Sweeps Coins are an obligation, not revenue

Outstanding Sweeps Coin balances are carried in the platform's reporting model as an obligation that may become payable rather than as recognised revenue, because a Sweeps Coin becomes a cash cost at the point it is redeemed.

The money arrives when a package is sold; the cost arrives later, on a schedule players choose. Package design belongs to how social casinos monetise coin packages; the ledger's job is to keep the two sides distinguishable.

Entries are append-only

A ledger entry, once written, is never updated and never deleted; a correction is a new compensating entry that references the entry it corrects. This is the accounting-entry pattern, and it is what keeps mistakes visible: a reversed credit leaves two entries and a reason.

How Sweeps Coins enter the ledger: the three issuance paths

Bundled with a package purchase. The store sells Gold Coins and attaches a Sweeps Coin allocation. The ledger writes one Gold Coin credit priced against the order, one Sweeps Coin credit priced at nothing, and a link from both to the order.

Alternative method of entry. A request arrives through a defined intake route and credits the Sweeps Coin balance with no order attached. The ledger writes the credit, the intake reference, the rate-limit state evaluated and the outcome. Where this sits in a build belongs to the full launch sequence; the platform side sits with internet sweepstakes software.

Promotional credit. An operator or a campaign issues Sweeps Coins against a rule. The ledger writes the credit, the rule identifier, the actor and the campaign. An issuance with no rule behind it should not be possible.

Tagging every Sweeps Coin with how it was issued

Provenance is an engineering requirement, not paperwork. The system has to answer, for any unit in a balance, which path created it, when, and under which rule. Balances are spent in a defined order, so debits draw down tagged units in that order and record which ones they consumed.

The redemption pipeline, state by state

Most descriptions of redemption are a list of requirements, which says nothing about order, about failure, or about what each step leaves behind.

The play-through gate, enforced at ledger level

The gate compares prize-eligible volume against the requirement in force when the units were issued, using the per-round currency tags. The multiplier is configuration, so the ledger stores the value that applied.

Holds, caps and cooling-off periods belong in the same gate, which is where player-set limits bite; responsible gaming controls covers their design.

Identity verification escalates at redemption

Identity verification escalates by assurance tier at the point of redemption rather than at sign-up, because redemption is the point at which value leaves the platform. The gate demands a stronger tier than sign-up and records which evidence satisfied it. Identity assurance levels is a published framework naming those tiers and their evidence criteria.

Why a payout request has to be idempotent

A redemption request must be idempotent: the same request identifier submitted twice produces one payout and one prize record, never two. Retries are normal on a payout rail. The pattern is the one payment platforms publish, for example idempotent requests keyed on a client-supplied identifier, and wiring it through the stack is covered in how platform APIs are integrated.

What the prize record has to contain

The prize record is the artefact the pipeline exists to produce: the account, the amount, the units debited, the issuance paths they came from, the gate decisions that authorised the payout and the rail reference. Write it once, at dispatch, and make it immutable. A record assembled later from three systems is a reconstruction, and it will disagree with itself.

Configurable availability: switching a jurisdiction on or off

Availability is a capability a platform either has or spends a sprint acquiring at the worst moment. Four switches make it real, and they are separate on purpose.

Availability is configuration. A jurisdiction moves between available and unavailable in a settings record your team can change, with the change logged: who, when, from what to what.

Freezing issuance is not closing redemption. These are two separate switches: a platform can stop issuing the redeemable currency in a jurisdiction on a chosen date while leaving already-issued balances redeemable for a defined settlement window.

Settlement runs on a defined window. The design has to say how long balances remain redeemable, what happens to units still held at the close, and how players are told.

Records survive the market. When a jurisdiction is unavailable the ledger, the provenance tags and the pipeline decisions stay retrievable. Nothing is deleted because a market closed.

Location data feeds the availability check, and not all of it has to be bought. Coarse IP geolocation data can be sourced from operator-published self-published IP geolocation feeds, a format mapping IP prefixes to simplified location information. What to demand from a vendor here is answered in how to evaluate a sweepstakes platform provider.

The records the system must be able to produce

Those six artefacts are the audit trail. Each is a query against records the system already wrote, not a report assembled at quarter end. If one is a spreadsheet, that artefact does not exist.

They surface as screens in back-office reconciliation and reporting, but only the ledger underneath makes those screens truthful.

An append-only ledger rebuilds any past balance

An append-only ledger stores the full series of movements against a balance rather than only the current balance, which is what makes any past balance reconstructable from the record itself. This is the event sourcing pattern applied to a wallet: store the movements, derive the balance, keep a snapshot only as an optimisation.

What the system has to retain, and who decides for how long

Retention is an operator decision and the platform's job is to make it enforceable: set a period per record type, apply it automatically, and demonstrate afterwards what was retained and removed.

Designing the events is the part most often skipped. Consistent names, a reason code on every decision, the actor and a trusted clock separate a trail from a log; application event logging practice is a sound starting point.

If you cannot answer where a unit came from, which gate let it out and who approved it, the platform does not have a dual-currency ledger. It has two numbers.

For the legal questions this design sits next to, retain qualified gaming counsel in each market you intend to serve. This article is a platform specification and is not legal advice.