01 Introduction

The problem

An online casino asks you to trust it on the only thing that matters: the draw. The player sees a result and nothing else. They can neither recompute it nor prove it was not picked after the fact. Nearly every gaming platform, including the ones that call themselves on-chain, simply asserts its own honesty.

The second problem is economic. Most gaming tokens have no real source of revenue: they fund rewards by inflating the token itself. The loop holds while new buyers arrive, and stops when they don't.

How SWOGE answers

SWOGE treats these as two separate problems, and answers both in ways that can be checked.

• On the draw. Every round is produced by HMAC-SHA256(server_seed, client_seed:nonce). The hash of the server seed is published before; the seed itself is revealed after. Every line of your history carries its seed, its client seed and its nonce: you recompute the result yourself. Confirmed
• On the economy. The protocol earns a 3 % mathematical edge on games against the house and a 5 % rake on player-versus-player duels. That revenue is measured, booked month by month, and it is what funds the rewards — all of which are expressed as a share of revenue, never as a fixed amount. Confirmed

What separates SWOGE from a meme coin

A meme coin is a line in an ERC-20 contract and a community. SWOGE is an application that produces revenue every day, whose token is the unit of account, the betting medium, the staking asset and the object of the burn.

Vision

To be the gaming layer of Robinhood Chain: where the chain's playful activity concentrates, and the infrastructure other teams launch their own tokens and games on.

The chain is new. On a new chain, the first service that genuinely works becomes the default reference — not on merit, but because there is nothing else to point at. That window is short and does not reopen.

02 The ecosystem

Ten components, eight of them live. The arrows show where value moves, not just where you click. $SWOGE sits under all of it: the games are played with it, the satellite tokens are bought with it, and their liquidity is made of it.

                        $SWOGE  ERC-20 · 1,000,000,000 · Robinhood Chain
                           │
        ┌──────────────────┼──────────────────┐
        │                  │                  │
    MARKET             VAULT            LAUNCHPAD
   Uniswap v3       deposit contract    SwogeFun V2
        │                  │                  │
        │                  ▼                  │
        │          GAMING BALANCE              │
        │            off-chain ledger           │
        │                  │                  │
        │      ┌───────────┼───────────┐      │
        │      ▼           ▼           ▼      │
        │   GAMES     DUELS     STAKING    │
        │  20 titles  1v1 · rake   locked   │
        │      │           │           │      │
        │      └─────┬─────┘           │      │
        │            ▼                 │      │
        │        REVENUE  3 % / 5 %      │      │
        │            │                 │      │
        │   ┌────────┼────────┐        │      │
        │   ▼        ▼        ▼        ▼      ▼
        │ LEADERBOARD REFERRALS LEVELS   TREASURY
        │   │        │        │        │      │
        └───┴────────┴────────┴────────┘      │
                     │                        │
                     ▼                        │
                 WITHDRAW  ─── 1 % ────▶ BURN ◀┘
                     │                    0x…dEaD
                     ▼
                SWOGE WALLET  self-custody · send, receive, swap, bridge

The satellite rule

A second token shipped in September: $SWOGEBET, the chip the sportsbook is played with. It is not a separate project, and the reason is one rule that every future satellite will follow.

   ETH (RH)
      │  a buyer pays in whatever they hold…
      ▼
   $SWOGE ─────────────────────────────────▶ held, staked, played
      │
      │  …and the only pool that quotes the satellite is paired with $SWOGE
      ▼
   $SWOGEBET/$SWOGE  Uniswap · the liquidity IS $SWOGE
      │
      ▼
   $SWOGEBET ──▶ BET VAULT ──▶ BET BALANCE ──▶ SPORTSBOOK
                    on-chain      off-chain ledger   real fixtures
                                                          │
                       winnings return in $SWOGEBET  ◀───┘

There is no $SWOGEBET/ETH market and there will not be one. Buying the satellite buys $SWOGE first, its price is written in $SWOGE, and the liquidity backing it is $SWOGE locked in the pool. Three consequences, and they are the whole point:

• every user a satellite brings in is a $SWOGE buyer before they are anything else;
• every satellite pool takes $SWOGE out of circulation and holds it as liquidity;
• the satellite's market capitalisation is quoted in $SWOGE, so it rises with $SWOGE and cannot be decoupled from it.

The intent is to repeat this: one utility, one team, one pool paired in $SWOGE. A sportsbook is the first. A trading product around SWOGE AI is the obvious second. Each one adds volume that must pass through $SWOGE to exist, which is a far more durable demand than attention.

03 The journey, end to end

Eighteen steps, from landing on the site to leaving the ecosystem. For each: what the player sees, what actually happens, the fees, and where mistakes are possible.

04 The wallet

The architecture, and what it implies

SWOGE combines an external, non-custodial wallet for identity and token ownership with a platform-held gaming balance for executing rounds.

What this model buys: instant, gas-free rounds with game state complex enough for poker, multi-card blackjack and turn-based duels — impossible to hold on-chain at that cost. What it demands in exchange: the safeguards described in section 31, and honesty about what it is.

What the player sees in their profile

05 How to deposit

PLAYER ─▶ Connect ─▶ Deposit ─▶ amount ─▶ sign the transaction
                                                  │
                                                  ▼
                                        VAULT CONTRACT
                                        Deposit(player, amount, …) event
                                                  │
                             the server watches the chain continuously
                                                  │
                                                  ▼
                                     GAMING BALANCE CREDITED
                                     + journal entry, + notification

Step by step

1. Open Deposit. The player is already connected; the page knows the vault address, received when the session opened.
2. Token and network are fixed. $SWOGE on Robinhood Chain (4663), and nothing else. The page checks the wallet's chain and offers to switch. That removes the single biggest cause of lost funds in Web3: the wrong network. Confirmed
3. Approve, then deposit. As with any ERC-20, two transactions on the first deposit: approve the contract, then deposit.
4. Confirmation. The server listens for the Deposit event. Every transaction is de-duplicated: the same hash can never credit twice. Confirmed
5. Credit. The balance is credited and state written to disk immediately, not at the next periodic save — a deposit is the one event you cannot afford to lose in a restart. Confirmed
6. History. The line appears under Deposits with a link to the transaction, and a notification goes out on the Telegram channel.

What can go wrong, and what prevents it

06 How to withdraw

The mechanism: a signed, cumulative voucher

This is the most important piece of the financial architecture, and it is worth understanding. The contract exposes:

withdraw(uint256 cumulative, uint256 deadline, uint8 v, bytes32 r, bytes32 s)

The server does not sign "pay 5,000". It signs "this player is entitled to have withdrawn 42,000 in total, ever". The contract remembers what it has already paid and sends the difference. Three properties follow:

• A replayed voucher pays nothing. It states a cumulative already reached, so the difference is zero. Replay is harmless by construction, not by maintaining a list of spent vouchers.
• A lost voucher is not a problem. The player asks for another; the new one states the same cumulative or more.
• The deadline bounds the window. A voucher expires after an hour. Confirmed

PLAYER ─▶ Withdraw ─▶ amount
                       │
                       ▼
           server checks: minimum, balance, fee
                       │
                       ▼
   GROSS DEBITED   ·   CUMULATIVE AUTHORISED += NET
                       │                        │
                       │                        ▼
                       │              SIGNED VOUCHER (1 h)
                       │                        │
                       ▼                        ▼
                1 % FEE → TO BURN        player signs the transaction
                       │                        │
                       ▼                        ▼
                 DEAD ADDRESS            PLAYER'S WALLET

Live parameters

The player also pays chain gas for their withdrawal transaction, as with any on-chain operation. That gas does not go to SWOGE. Confirmed

What does not exist yet

07 Buying $SWOGE

ETH (RH) — the native gas of Robinhood Chain
 │
 ▼
UNISWAP V3 on Robinhood Chain
 │
 ▼
$SWOGE ─▶ wallet ─▶ deposit ─▶ GAMING BALANCE

08 The gaming wallet

A player does not hold one number but four, and they do not behave the same way. Confusing them is the first source of misunderstanding and support tickets.

The sum of these five, across all players, plus the jackpot reserve, is what the protocol owes. That figure is compared to the vault's actual contents continuously (see section 26). Confirmed

09 The games

Thirteen titles live, in two economically distinct families: against the house, and between players.

Finding an opponent

A bubble in the bottom-right corner of every page opens the list of open 1v1 tables, with a badge showing how many players are waiting. It stays visible even when nobody is waiting — a feature that disappears when empty is never discovered. Confirmed

Provable fairness

The server seed rotates every 168 hours, and the old one is revealed at that moment. The last 104 seeds are kept — two years of verifiable history. Rotation is refused while a round is in flight: rotating mid-blackjack-hand would make it unverifiable, which is the exact opposite of the point.

The exact formulas, including each game's own suffix, are published on the public /fairness endpoint. Confirmed

10 The 1v1 economy

Five possible models. C is what runs today; the others are described because they will come up in product discussions.

PLAYER A              PLAYER B
    │  stakes 10,000      │  stakes 10,000
    └──────────┬──────────┘
               ▼
        POT · 20,000
               │
               ▼
             GAME
               │
    ┌──────────┴──────────┐
    ▼                     ▼
5 % RAKE              WINNER
1,000 → house        19,000

11 Fees

Where the money goes

MONTHLY REVENUE  = bets − returns + rake
      │
      ├── 1 % ─────────▶ LEADERBOARD POOL  to the top 10 by volume       Confirmed
      ├── 10 to 20 % ──▶ REFERRALS  of the revenue each invitee produces  Confirmed
      └── the rest ────▶ TREASURY
                               │
                               ├── staking yield
                               ├── development
                               ├── liquidity
                               └── marketing            split UNDECIDED

WITHDRAWAL FEES ──── 100 % ───▶ BURN   0x…dEaD, public transaction   Confirmed

12 Staking

Live parameters

Yield accrues from the first second and can be claimed whenever, even while locked. Only the principal is held. Confirmed

Why a global cap

At 100 % a year, every token staked commits the protocol to returning two within a year. That debt is invisible on the day it is taken on: it shows up twelve months later. Without a cap, a single large holder can commit the vault to an amount nobody would discover until it came due.

The cap puts a known bound on it: at most 20 % of supply staked, therefore at most 20 % of supply in yield over the year. It is not a closed door but a full room — space frees up as soon as someone leaves, and the gauge is shown on the page before the player types an amount. Confirmed

Where the yield comes from — four models

13 The staking flow

PLAYER
   │  types an amount · sees the room gauge BEFORE confirming
   ▼
CAP CHECK  before any debit
   │
   ├── full ─────────▶ refused, with the exact amount of room left
   │
   ▼
POSITION OPENED  principal + start date + unlock date
   │
   ▼
YIELD BY THE SECOND
   │
   ├──▶ CLAIM ──▶ available balance ──▶ play, re-stake, or withdraw
   │
   ▼
EXIT — WHENEVER YOU WANT
   │
   └──▶ UNSTAKE: the whole principal returns, plus accrued yield

The cap check happens before the balance is debited. A refusal placed after the debit would leave the player with neither their tokens nor their stake — the kind of hole you only find through a complaint. Confirmed

14 The burn

The path, end to end

WITHDRAWAL  100,000 gross
   │
   ├──▶ 99,000 authorised to the player
   │
   └──▶ 1,000 TO THE BURN PILE
             │  the amount stays in the vault, counted separately
             ▼
      BURN TRANSACTION  vault → 0x…dEaD, in a single transaction
             │
             ▼
      PUBLIC ANNOUNCEMENT  Telegram channel, with the transaction link
             │
             ▼
      VERIFICATION  anyone reads the dead address balance

The burn goes from the vault straight to the dead address, in one transaction. Routing it through the owner's wallet would make it two, and leave a moment where the tokens belong to them — which is no longer quite a burn. Confirmed

Burn sources

15 Token sinks

A sink removes tokens from useful circulation without destroying them; they can come back. A burn destroys them for good. Conflating the two overstates real scarcity.

16 Rewards

17 The launchpad — SwogeFun V2

Contract 0x4De26D120A4fF2d7c1875E6C7D611262b9cA426d, deployed on Robinhood Chain. 23 tokens launched to date. Confirmed

Two launch modes

Contract parameters, read from the chain

What is unusual about this launchpad

Holder redistribution is implemented in the contract: each holder accrues a share of trading fees proportional to their holding and claims it whenever they want. This rarely exists at the launchpad level rather than inside each individual token. Confirmed

CREATOR
   │  name · symbol · mode · max wallet · fee destination
   │  + Telegram / X / website / logo
   ▼
createToken()  one transaction
   │
   ├── CURVE mode ──▶ curve sale ──▶ GRADUATION ──▶ Uniswap v3 pool
   │
   └── INSTANT mode ──▶ UNISWAP V3 POOL IMMEDIATELY
                                 │
                                 ▼
                     FREE TRADING · aggregators · scanners
                                 │
                    ┌────────────┴────────────┐
                    ▼                         ▼
          1 % → SWOGE TREASURY     creator fee → dev or holders

What is missing for a curated launchpad

18 Launchpad security

19 Volume and liquidity

The legitimate levers

20 Bots and automation

Infrastructure bots

Trading bots

A bot trading on Uniswap is no different from a human trading on Uniswap: the pool does not know who is calling. There is nothing to permit or forbid, and claiming otherwise would be false. What is true: the damaging strategies are sandwiching and launch sniping, and the launchpad already carries a buy limit for the first blocks. Confirmed

Game bots — not allowed

A program playing on the player's behalf against the house gains nothing: the result is drawn by HMAC and depends on no reflex. It is simply rate-limited like everyone else.

In player-versus-player games it is the opposite: a Connect 4 or checkers solver beats a human almost every time. That is the only place where automation genuinely takes something from someone, and therefore the only place where detection matters. See section 21. Undecided — detection is not implemented.

Rate limiting

Every connection gets a token bucket: 20 messages per second, a burst of 40, and the connection closes past 400 refused messages. Measured: 498,200 hostile messages sent, 39 served, socket closed, and another player served in 50 milliseconds during the attack. Confirmed

21 Anti-cheat

DETECTION ─▶ FLAG ─▶ HUMAN REVIEW ─▶ RESTRICTION ─▶ APPEAL ─▶ RESOLUTION
  automatic    queue     no automation    graduated     deadline   explained

22 The leaderboard

Why volume and not winnings: a winnings leaderboard rises and falls with luck, without anyone changing how they play. Volume is measurable, never goes down, and every unit of it has paid the house edge — so farming the leaderboard funds the very pool you are trying to win. Confirmed

23 Tournaments

Entirely undecided. Nothing is implemented. What follows is a proposal, to validate before any development.

ENTRY (fee) ─▶ PRIZE POOL ─▶ BRACKET ─▶ ROUNDS ─▶ FINAL ─▶ PAYOUT
                    │                                                   │
                    └──── protocol share ───────────────────────────────┘

Decisions first: do entry fees go entirely to the pool or partly to the protocol; what happens when a player abandons mid-bracket; who arbitrates a dispute; do tournaments count towards the monthly leaderboard.

24 Digital items

25 Community

PLAY ─▶ COMPETE ─▶ WIN ─▶ SHARE ─▶ INVITE ─▶ NEW PLAYERS ─┐
   ▲                                                                       │
   └───────────────────────────────────────────────────────────────────────┘

The loop is not a figure of speech: every arrow maps to something that exists. You play, you find an opponent through the duels bubble, you win, the win is announced on the Telegram channel, your referral link pays for life, and your invitee arrives with a gift.

26 Treasury

What exists and is measured

The admin dashboard compares these three continuously, warns when the margin drops below 10 %, and turns red when the vault no longer covers what is owed. It also computes the daily cost of staking, the daily revenue, and how many days the surplus still covers at the current rate. Confirmed

What is not formalised

27 Tokenomics

Supply allocation

Circulating supply over time: total supply is fixed and can only fall. Two forces reduce it: the burn, permanently, and the staking lock, temporarily. A projected curve would only be meaningful once the allocation table and unlock schedule are published. Undecided

28 Revenue model

Revenue is booked month by month, line by line: bets, returns, net revenue, staking paid, bonuses, referrals, jackpots, deposits, withdrawals, burned. This is not an estimate: it is accounting kept at the single choke point every round passes through. Confirmed

29 The economic flywheel

                     NEW PLAYERS
                          │
                          ▼
                   BUY $SWOGE  real demand, not speculative
                          │
                          ▼
                      DEPOSIT
                          │
                          ▼
                   VOLUME PLAYED
                          │
              ┌───────────┼───────────┐
              ▼           ▼           ▼
       3/5 % REVENUE  LEVELS   BURN ON WITHDRAWAL
              │           │              │
    ┌─────────┼─────────┐ │              ▼
    ▼         ▼         ▼ │       SUPPLY REDUCED
LEADERBOARD REFERRALS TREASURY          │
    │         │         │                 │
    │         │         ▼                 │
    │         │    DEVELOPMENT            │
    │         │         │                 │
    │         │         ▼                 │
    │         │     NEW GAMES              │
    │         │         │                 │
    └─────────┴─────────┴─────────────────┘
                        │
                        ▼
                MORE PLAYERS  ──▶ the loop repeats

Three properties separate this loop from the usual diagram.

• It does not depend on the market. A player who wants to play buys $SWOGE whether the price rises or falls. That is usage demand.
• It funds itself. The rewards distributed are shares of revenue already earned, not tokens created.
• It contracts cleanly. If activity falls, rewards fall with it and nothing breaks. A fixed-emission model keeps distributing while revenue collapses.

30 Transparency

What is already public and verifiable by anyone, without asking:

What a public dashboard could add:

• Circulating supply, excluding the vault and known addresses Proposed
• Total staked and cap utilisation Proposed
• Rounds played, active players, rewards distributed Proposed
• Protocol revenue by month Proposed — decide the level of detail published

No activity figure is claimed in this document beyond those read from the chain or from the code.

31 Security

32 The contracts

33 On-chain and off-chain

Why a round cannot be on-chain

A Plinko drop needs a random draw and immediate settlement. On-chain that means one transaction per ball, gas each time, several seconds of waiting, and a randomness oracle. The cost would exceed the bet for small amounts — which is to say for most rounds.

Provable fairness is the answer to that trade-off. It does not make the round on-chain, but it makes it checkable afterwards: you can prove a result was determined before the player played, and was not chosen after. That is the best available in an off-chain architecture, and considerably more than most platforms offer. Confirmed

34 Data and analytics

Privacy

The platform collects no name, no email, no identity document. The identifier is a public address, which the player already chose to make public by using it on a chain. Display name and picture are optional and supplied by the player.

Two existing measures follow the same line: the addresses seen during the day for funnel counting are never written to disk, and records that never did anything are not kept. What does not exist cannot leak. Confirmed

35 Roadmap

By phase, without dates. An invented date in a white paper becomes a missed promise six months later.

36 Long term

$SWOGE  the unit of account
   │
   ▼
THE VAULT  the way in and the way out
   │
   ▼
THE GAMES  usage demand — what makes people buy the token
   │
   ▼
COMPETITION  what brings them back: levels, leaderboard, duels
   │
   ▼
TOURNAMENTS  what creates an appointment
   │
   ▼
STAKING  what removes supply — more so if it opens access
   │
   ▼
THE LAUNCHPAD  what brings other teams and their communities
   │
   ▼
THE NETWORK  other games built on the same infrastructure

Each floor reinforces the one below rather than replacing it. The launchpad brings communities who discover the games; the games produce the revenue that funds development; levels and the leaderboard bring back those who came; staking removes supply as usage demand grows.

The most interesting prospect is the last one: opening the gaming infrastructure to other teams. The provable-fairness engine, the vault, the balances, the duels and the leaderboard are all generic. A team launching a game on Robinhood Chain would not have to rebuild them. Proposed

37 Risk analysis

38 Compliance

39 Every flow

Deposit

PLAYER → connect wallet → sign the message (free)
       → Deposit → ERC-20 approval → deposit transaction
       → VAULT CONTRACT → Deposit event
       → server watcher → de-duplicated by transaction hash
       → CREDIT + immediate disk write + journal + notification
       → GAMING BALANCE AVAILABLE

Withdraw

PLAYER → Withdraw → amount
       → minimum check (10,000, lowered by level)
       → GROSS DEBITED · CUMULATIVE += NET · 1 % FEE → BURN PILE
       → SIGNED VOUCHER (cumulative, valid 1 h)
       → player signs the transaction
       → CONTRACT: pays (cumulative − already paid)
       → PLAYER'S WALLET

Staking

PLAYER → room gauge shown → amount
       → cap check before any debit
       → POSITION (principal + start)
       → yield by the second
       → CLAIM → available balance
       → UNSTAKE: everything, at any time

A round of play

PLAYER → game → bet
       → bet debited → nonce incremented
       → HMAC-SHA256(server_seed, client_seed:nonce)
       → result → return credited
       → JOURNAL: bet, return, seed, client seed, nonce
       → conservation check: the total owed must match to the token

A 1v1 duel

A opens a table (stake M) → visible in the duels bubble
B joins (stake M) → POT = 2M → game
       → winner: 2M − 5 % · draw: each gets their stake back
       → rake → revenue → leaderboard, referrals, treasury

Burn

WITHDRAWALS → 1 % of each → BURN PILE (counted apart, stays in the vault)
       → single transaction: VAULT → 0x…dEaD
       → public announcement with the link
       → VERIFICATION: anyone reads the dead address balance

Launchpad

CREATOR → createToken(name, symbol, mode, max wallet, fees, links)
       → CURVE mode: sale → GRADUATION → Uniswap v3 pool
       → INSTANT mode: POOL IMMEDIATELY
       → free trading · 1 % to the protocol · creator fee to dev or holders

The complete flywheel

BUY → DEPOSIT → PLAY → COMPETE → LEVEL UP
    → WIN → STAKE or WITHDRAW
                                    │
                                    ▼
                              1 % BURNED
    ▲                               │
    │           REVENUE → leaderboard · referrals · treasury
    │              │
    └── NEW PLAYERS ◀── development ◀── new games ◀──┘

40 Critical audit

Nine readings of the same project. Each keeps only what concerns it.

The twenty decisions to settle

41 Sports betting and $SWOGEBET

SWOGE BET is a sportsbook, live on the site. Real fixtures, odds computed from a model and locked at the moment the slip is placed, singles and accumulators of up to eight legs. It is played in $SWOGEBET and in nothing else.

Why a second token rather than one more use for $SWOGE

The honest answer is that it is not a second economy, it is a second door into the same one. A satellite token gives a product its own market, its own holders and its own story without splitting the protocol — because of the pool rule stated in section 02: $SWOGEBET is paired with $SWOGE and with nothing else. Buying it buys $SWOGE first, even when the buyer pays in ETH. Its price is written in $SWOGE. Its liquidity is $SWOGE, locked in the pool.

So the sportsbook cannot grow without $SWOGE growing with it, and a bettor cannot enter without becoming a $SWOGE buyer on the way in. That property is why the model is worth repeating for the next utility, and why it is stated as a rule rather than left to a decision each time.

The bet vault

Bets are funded from a second on-chain vault, deployed on 3 September 2026 at 0x3E70D325DbcA349e37B2030a2aAcD6147B3Ce398 and verified on Blockscout. It is the same contract model as the gaming vault, deliberately: a Deposit event the server watches, and withdrawals paid against an EIP-712 cumulative voucher the player cashes themselves. Two things are worth stating plainly.

• The two balances never mix. A player has a $SWOGE casino balance and a $SWOGEBET betting balance side by side, each with its own vault, deposit, withdrawal and minimum. A bet cannot be paid with $SWOGE, and the engine refuses it in those words.
• Every ticket carries its currency. Slips placed before the bet vault existed were staked in $SWOGE and are settled in $SWOGE — winnings and refunds alike. Nothing was reinterpreted after the fact.

The voucher's EIP-712 domain is SwogeBetVault, not SwogePusherVault. A voucher signed for one vault does not verify at the other, and it is the contract that enforces it.

Live parameters

42 The SWOGE Wallet

Section 04 describes the embedded wallet a player gets by signing up with an email. What shipped in September is the screen around it: a self-custody wallet page where the keys are the player's, reachable from a round button at the bottom right of every page on the site.

The round button does not navigate. It opens the wallet in a panel over the page you are on, so a player can check a balance or top up mid-game without losing their table, their socket or their place in a live round — and the same button folds it away again.

43 SWOGE AI

SWOGE AI is a colony of 13 agents that watches every token launched on Robinhood Chain, judges it, buys what passes and sells on its own rules. It trades paper money — a treasury that started at 1,000 units and has no claim on anyone's funds — and it does so in public: every buy, every sell, every refusal and every result is on the SWOGE AI page and in the Telegram channel, losses included.

How a token gets bought

Each agent owns one question and answers only that one. Scout sweeps the feeds and drops what is already empty. Warden reads the contract: honeypot, taxes, owner powers. Whale-Watch reads the holders. Whisper reads the buying pressure. Oracle reads the market. A refusal at any stage stops the pipeline, so the services the later agents would have called are never paid for. What survives is bought; Sentinel then watches the position, Extender decides whether a winner runs longer, and Closer ends it.

What makes it a colony rather than a script

Every agent keeps a memory of what its own judgements were worth and corrects its thresholds from measured outcomes rather than from opinion. Tokens the colony refused are scored too — they are followed as shadows, and a refusal that keeps discarding winners shows up as such in the audit. That is the part most bots skip, and it is the part that makes the learning honest: a system that only ever measures its own purchases learns that its purchases were good.

Where it goes

When the agents have enough measured history to trade real money, the product opens to users, and it follows the same rule as the sportsbook: a satellite token, $SWOGEAI, paired with $SWOGE and nothing else, required to run the bot with one's own funds. Proposed — the colony runs today, the token does not exist, and no date is committed.

One-page summary