Parameters
A QuantumRaffle V2 game is configured by eight parameters, all of which
are locked into gameConfigRecord[gameId] at the moment the game starts and
cannot be changed mid-game. The host updates parameters for the next game
via setNextGameConfig(...); the change takes effect when the next game
starts.
Parameter table
| Parameter | Description | Default | Range |
|---|---|---|---|
entryAmount |
Cost per entry in wei | configurable, e.g. 1e15 (0.001 ETH) |
> 0 |
deadline |
Inactivity timeout, in seconds | 600 (10 min) |
> 1 |
grandPrizeLogBase |
Log base for Power Slot selection | 7 |
> 1 |
viralityBonusLogBase |
Log base for cohort grouping | 3 |
> 1 |
grandPrizeProportion |
Weight for the grand-prize pool | 7000 |
any |
viralityBonusProportion |
Weight for the adoption-bonus pool | 3000 |
any |
depositFeeBps |
Host fee in basis points (1 bp = 0.01%) | 0 (disabled) |
0 – 1000 |
minTicketsBeforeEnd |
Minimum tickets that must be sold before the deadline can expire | 0 (disabled) |
≥ 0 |
The proportions are weights, not percentages — they're used as
p / (p + p) so the absolute scale doesn't matter. The 7000 / 3000
default produces a 70/30 split.
Effect of each parameter
| Configuration | Effect |
|---|---|
Lower grandPrizeLogBase |
More Power Slots, smaller individual prizes |
Higher grandPrizeLogBase |
Fewer Power Slots, larger individual prizes |
Lower viralityBonusLogBase |
More cohorts, more granular bonuses |
Higher viralityBonusLogBase |
Fewer cohorts, larger per-cohort pools |
Higher grandPrizeProportion |
More to grand prizes, less viral incentive |
Higher viralityBonusProportion |
More viral incentive, less to grand prizes |
Shorter deadline |
Faster games, less accumulation |
Longer deadline |
Slower games, more accumulation |
Higher depositFeeBps |
More host revenue, smaller pools |
Higher minTicketsBeforeEnd |
Guarantees a minimum entrant pool before game can end |
Hard guarantees
- Locked at game start. Every field above is captured into
gameConfigRecord[gameId]when the game starts. The host cannot mutate any of them on an active game. - Bounded fee.
depositFeeBpsis enforced in both the constructor andsetNextGameConfigto be≤ MAX_DEPOSIT_FEE_BPS = 1000(10%). - No zero-proportion divisor. The constructor and
setNextGameConfigrejectgrandPrizeProportion + viralityBonusProportion == 0withZeroProportions. - Both log bases > 1. Enforced; otherwise no Power Slots or cohorts could be computed.
Setter signature
function setNextGameConfig(
uint256 _entryAmount,
uint256 _deadline,
uint256 _grandPrizeLogBase,
uint256 _viralityBonusLogBase,
uint256 _grandPrizeProportion,
uint256 _viralityBonusProportion,
uint256 _depositFeeBps,
uint256 _minTicketsBeforeEnd
) public;
Both depositFeeBps and minTicketsBeforeEnd are the trailing fields of
the struct, in that order.
Reading the active config
There is no depositFeeBps() or minTicketsBeforeEnd() standalone getter.
Read them from the structs:
gameConfigRecord(gameId).depositFeeBps // active game
nextGameConfig().depositFeeBps // queued next game
gameConfigRecord(gameId).minTicketsBeforeEnd // active game
nextGameConfig().minTicketsBeforeEnd // queued next game
Detailed pages
- Deposit Fee — the optional host fee skimmed from every entry
- Minimum Tickets Before End — the optional floor that pauses the inactivity countdown
- Cold-Wallet Prize Routing — how
fallback()redirects payouts to a separate cold wallet