DUPED

ECONOMY KERNEL

A globally consistent economy kernel for online games. It makes item & gold duplication unrepresentable in a game's authoritative state.

WHAT AM I LOOKING AT?A live game economy with one legendary item and real gold. Attack it with the controls — the rules never break.
CONNECTING
Aetheria · realm live
settling on TOKYO · 2 regions
THE CONTRAST

Same attack. Two databases.

Watch a dupe happen — then watch it become impossible. Both cards are live against Aurora DSQL.

NAIVE ECONOMYno version guard
× —
one item · one owner — for now
SELECT count(*) FROM legacy_inventory WHERE instance_id = '…';
→ returns —

Two concurrent trades both read "A owns it", both write a new owner — the old row is removed once. One item, many owners. This is the 25-year-old bug.

DUPEDversion-guarded
× 1
one row · one owner · one version guard
exactly one wins · the rest re-read
SELECT count(*) FROM item_instances WHERE template_id = '…';
→ returns 1

One row, one owner, a version guard. Two transfers can't both match — exactly one wins. "Owned twice" has no representation.

GUIDED TOURSTEP 1 OF 6

See what a dupe is

Start with the problem. In the contrast above, the LEFT card is a naive game database with no version guard. Run the trade race and watch the one legendary multiply into ~20 inventories — a real dupe, in a real table. The RIGHT card takes the SAME attack and stays × 1.

02

WORLD ARENA · AETHERIA

ONE LOGICAL DB · STRONGLY CONSISTENT
TOKYO
● SETTLING
SEOUL
Aurelia_Valev0
×1
ONE LEGENDARY
never duped · 25 years of bugs, ended
bot attack
blocked
the one legendary
steady · bots probing
bots deflected · shield holding
03

ECONOMY CONSOLE

WHAT YOU'RE SEEINGEvery economic rule, checked live against the database on each tick. The five headline tiles are the essentials; open the full invariant board for the raw SQL behind each one.

DUPE ATTEMPTS BLOCKED
0
every double-spend rejected at the truth core
OCC RETRIES
0
version-guarded, then re-read
VALID TRADES SETTLED
0
committed, never reversed
GOLD SUPPLY
CONSERVED
6,000
sum(balance) holds to the minor unit
LEDGER DRIFT
= 0
credits − debits, always zero
INVARIANT BOARD · LIVE CHECKS · ALL PASS
04

MILLION-SCALE PROOF

WHAT YOU'RE SEEINGWhy the same kernel that keeps one item unique also scales to millions: the single legendary is serial on purpose, while independent marketplace trades never wait on each other.

THE ONE CONTESTED ITEM
Serial by nature — that's why it can't dupe.

A single legendary is one row. Concurrent claims funnel through one version guard; exactly one wins, the rest re-read. Contention here is the feature.

THE MARKETPLACE
Millions of independent rows → horizontal scale.

Disjoint trades touch disjoint rows, so they never wait on each other. Throughput climbs ~2× per 2× concurrency with zero contention.

MARKETPLACE THROUGHPUT
measured on Aurora DSQL · not simulated
LAST MARKET STORM
— tps
@ — concurrency · 0 contention
05

CROSS-REGION DEFENSE

TOKYOap-northeast-1⇄SEOULap-northeast-2ONE LOGICAL DB · ACTIVE-ACTIVE

Tokyo and Seoul are one logical Aurora DSQL database — active-active, strongly consistent. A trade routed to Tokyo and a trade routed to Seoul on the same item serialize against one source of truth: exactly one wins, globally. No replication-lag window, no split-brain.

482 / 482CROSS-REGION GRABS BLOCKED
MEASURED · REAL PEERED CLUSTER

Proven on the real Tokyo⇄Seoul cluster: 482 simultaneous cross-region grabs of the one legendary — all blocked. The count stayed × 1.

TOKYOap-northeast-1
● ACTIVE · SETTLING
0
trades settled in region
SEOULap-northeast-2
○ STANDBY · WARM
0
trades settled in region
settling on TOKYO. Hit ⇄ Failover region — the other endpoint takes over, count stays × 1.
06

LIVE SETTLEMENT FEED

waiting for settlements…
CONNECTING