A reward economy that can actually ship.

What the launchpad provides

The GameFi page describes a game-funded treasury: select Casino bankroll, provide a wallet, and pay game prizes from that wallet. Its public frontend selects the Meteora venue and bankroll mode. The observed game list endpoint returned an empty games array. This confirms an available listing surface, not an accepted RuneGambit listing. No public game-registration endpoint or game-results SDK was found in the linked developer documentation.

The live launch configuration reports Token-2022, six decimals, one billion supply, SANTA pairing, and bankroll/rewards modes. The launchpad guide says mint and freeze authorities are revoked. Bankroll buys the game token into the nominated wallet; holder rewards distributes SANTA to holders. A combined team/staking/prize route is not documented.

Verification boundary: these are first-party platform statements and observed public responses. This research did not audit deployed programs, validate every token authority on-chain, confirm treasury control, or independently reconstruct historical payouts. Abram’s identity or platform ownership was not independently established.

The last step is gold exposure

The ecosystem API identifies SANTA rewards as GP and GP rewards as GLDX. The issuer’s GLDx product page describes a tracker certificate linked to SPDR Gold Shares. Detailed RuneGambit copy should say “GLDx gold exposure”; the pathway does not promise physical gold delivery or a fixed return.

Where a 4% tax would go

Published allocation: one percentage point goes to the platform; the remaining tax divides 20% to SANTA/GP liquidity and 80% to the selected mode. Tax applies to transfers, including wallet movements. At 4%, the project mode receives 2.4%, not the entire 4%.

Illustration: $100,000 of taxable transferred token value, valued at the transfer instant. This is an accounting illustration, not a trading-volume forecast. Routing can involve multiple taxable transfers; conversions, price movement, execution fees, and gas reduce realized proceeds.

The owner’s proposed 33% team + 64% stakers totals 97%. One possible completion is 3% for the GP leaderboard reserve. The following split would apply to net distributable project proceeds, after costs. It is an original proposal; Santa Markets has not confirmed it can deliver this routing.

Unfunded component: that split leaves no separate allocation for ordinary AI-win GAMBIT rewards. Fund those from a capped launch reserve, sponsorship, or a revised allocation. Bankroll mode pays in GAMBIT, so distributing SANTA or GP would require an additional conversion or a custom pre-buyback split.

Transaction costs must be visible

Developer docs list a normal 2% pool swap fee, a 1% buy site fee, transfer tax, and an optional opening fee declining from 35% over eight minutes. These are distinct fee layers; do not market 4% as the all-in cost. Show the actual quote, expected receipt, minimum receipt, and maximum slippage before any swap.

A standard transfer-fee token also charges transfers into and out of a staking vault. With a 4% fee each way and no cap hit, depositing 100 GAMBIT credits 96; withdrawing that position returns 92.16 before rewards. 7.84% principal friction is a reason to settle the staking design first. Solana’s TransferFeeConfig documentation explains withheld destination fees; credited stake must use actual tokens received.

Fund the top 500 before promising their payout

The proposed 3% net allocation produces only $72 equivalent in the example above. Dividing equally among 500 produces $0.144 equivalent per person before GP conversion and delivery costs. It cannot justify a meaningful advertised minimum by itself.

Recommended operating model: prefund a minimum GP season pool and a separate capped GAMBIT AI reward reserve. Add fee proceeds as variable bonuses. Publish token quantities and funded balances rather than guaranteed dollar yields.

Use one finalized leaderboard: defined season start/cutoff, server-verified AI wins, eligible account rules, bot review, a published tiebreaker, and an appeals window. Decide whether fewer than 500 qualifying players split the pool or leave the unused portion for the next season. Snapshot allocations once, then distribute idempotently and publish transaction receipts.

The championship is scheduled for Saturday, December 19, 2026 at 9:00 p.m. EST (2026-12-20T02:00:00Z). First, second, and third prizes remain to be announced until their asset, amount, eligibility rules, and funding are set. Championship prizes and the top-500 AI pool should be distinct budgets.

Implementation plan

1. Read-only market adapter. Use the documented public API for market state. Pin the eventual GAMBIT mint, token program, decimals, and pool rather than identifying by ticker. Cache responses, preserve source timestamps, show stale/error states, and respect rate limits. Research addresses below are not approved production configuration.
2. Wallet identity. Connect a Solana wallet; use a server-issued, single-use nonce and domain-bound SIWS message for sessions. A wallet connection alone is not authentication. Keep sign-in separate from explicitly described token transactions. Use new RuneGambit Worker/D1 resources and secrets.
3. Verified gameplay ledger. Port the existing server replay to RuneGambit rules; issue match seeds server-side; bind matches to wallet, season, and simulation version. Settle each match once with command validation, duration checks, rate limits, and anti-farming controls. Never credit a client-supplied “win” directly.
4. Funded claims. Replace the archived mint-on-claim code with transfers from a capped GAMBIT bankroll. Reserve a claim atomically, persist the transaction signature before retries, reconcile confirmation, and enforce uniqueness. In-flight transactions must never be blindly paid again. A launchpad token with revoked mint authority cannot use the legacy minting path.
5. Staking and rewards. Choose an audited, compatible program or commission one with program-owned vaults, per-position accounting, actual-received deposits, SANTA reward funding, deterministic accrual, and permissionless user withdrawals under published terms. Resolve transfer fees, reward-token fees, locked periods, upgrade authority, emergency controls, and audit findings before accepting deposits.
6. Reconcile the money. Separate bankroll, team, staking rewards, and GP season accounts. Track funding source, conversion, costs, allocation, liabilities, and confirmed payout. Cap emissions to available unencumbered treasury; if exhausted, stop new reward accrual and disclose that state.

Local evidence reviewed: 04 Game/docs/TOKEN.md, 04 Game/future/wallet/WALLET.md, and 04 Game/future/wallet/SECURITY.md. These describe an archived, separate game’s integration; they are a starting point, not proof that RuneGambit’s production backend exists.

Public endpoints versus our proposed backend

Source: Santa Markets developer guide and observed first-party frontend. Documented read/quote/build limits are 240/90/30 requests per address per minute. The unsigned swap expires with its blockhash; re-quote after expiry. Before signing, validate the intended mint, amounts, destinations, and allowed programs, then simulate and show a clear transaction summary.

Questions to resolve with Abram

• Can the project’s net fee share be divided in SANTA before bankroll buybacks, using 33% team / 64% staking / 3% GP reserve?
• Is game listing manual? What metadata, review, launch proof, and registration process does RuneGambit need?
• What are the exact treasury/tax authorities, change permissions, payout minimums, and exclusions for vault or pool accounts?
• Can staking avoid transfer-tax friction, and can SANTA rewards be paid to program vaults? What is the supported method?
• Which launch costs and fee rates are authoritative when the website prose, API, and examples disagree?

Decision: prepare the site and adapters now. If custom distribution is unsupported, choose bankroll mode plus separately funded staking, or a custom token/program stack. Holder mode is an alternative only if the product deliberately changes from staking to holding. Keep PvP wagering unavailable until its escrow, settlement, dispute, eligibility, and operating requirements are established.

An actual IP issue in the existing game

The repository uses named RuneScape factions and characters, including Saradomin, Zamorak, Guthix, and Lucien. These appear in 01 Design/Game Design.md, 02 Lore/Lore Bible and Sources.md, and game code. The current configuration also contains an unofficial-fan disclaimer. This is a specific existing dependency on Jagex material, not merely a hypothetical name similarity.

Jagex’s Fan Content Policy makes its ordinary license non-commercial (3.1.4), restricts commercial use (6.1.1), and excludes games/software using Jagex Property except for modifications or plugins within the stated official programs (6.1.3 and 4.1.6). Clause 6.1.5 also prohibits using that property to promote gambling. Sections 14.1–14.2 require a separate agreement for otherwise unauthorized commercial uses; 14.6 says it will not agree to content prohibited under 6.1.5.

That is an implementation recommendation based on the published policy, not a legal determination. Have qualified counsel assess the actual assets, target markets, reward/token design, tournament terms, and planned PvP wagering. Jagex’s licensing contact page describes its commercial inquiry route. No inquiry was sent.

Research evidence and source record

All entries below were accessed October 18, 2026. Short excerpts and observed response fields are retained here for review; these are not complete archived pages. External sources and APIs may change. No private account data or credentials were used.

{"games":[]}