777 Ecosystem Whitepaper

Version: 29 April 2026

This document is not legal, tax, accounting, or financial advice. It describes the intended design of the 777 ecosystem, the relationship between the Sodora protocol and the Colour League competition platform, and the token, governance, competition, and reward mechanics.

Executive Summary

The 777 ecosystem is a two-layer crypto and competition platform.

The first layer is Sodora, a governance-token protocol launched through a 777-round public auction. Sodora is designed to become the governance layer for the wider platform. It governs protocol-level decisions, future host approval, and reward-distribution policy. Its issuance model is intentionally narrow: phase-1 auction settlement, treasury minting for failed or skipped auction rounds, and conditional reward emissions when auction or post-auction checkpoint conditions are met. Exactly 28% of total USDC raised through the Sodora auction is predetermined for Colour League team-token purchases, split 7% per team token. No additional Sodora issuance path is defined outside those mechanisms.

The second layer is Colour League, a four-team competition platform built around the team tokens COLRED, COLBLUE, COLGREEN, and COLYELLOW. Colour League hosts weekly official competitions across multiple browser game formats. Players choose a team, acquire team tokens through a public sale, use team tokens for official competition entry, and may become eligible for USDC tournament rewards based on team and player results.

The two layers are connected, but they are not interchangeable. Sodora is the governance and auction layer. Colour League is the team-token, competition, website, and game layer. This whitepaper therefore treats them as one ecosystem with two clear product surfaces:

• sodora.xyz: the public home for Sodora, the auction, protocol information, and governance.
• colour-league.com: the public home for team-token sales, schedules, competitions, wallet flows, match handoff, and reward claims.

The first launch window is hosted by Colour League. The intended post-bootstrap direction is for approved hosts and reward policy to move under Sodora governance. The current contract set already includes governance-aware primitives such as CompetitionRegistry, RewardDistributor, and HostCompensationVault; however, official match execution, player ranking, validation, and reward-tree generation still happen through Colour League platform services.

Product Map: sodora.xyz vs colour-league.com

sodora.xyz

sodora.xyz is the public protocol surface for Sodora. It is responsible for:

• explaining the Sodora protocol and auction mechanics;
• displaying the phase-1 auction countdown and auction state;
• supporting bid, refund, claim, and holder-reward flows where applicable;
• presenting phase-2 checkpoint and governance information after launch;
• directing users to the canonical governance-token experience.

Sodora does not host Colour League matches, calculate tournament results, sell team tokens, or operate the games. Those concerns belong to Colour League.

colour-league.com

colour-league.com is the public competition surface for Colour League. It is responsible for:

• team-token sale flows for COLRED, COLBLUE, COLGREEN, and COLYELLOW;
• competition schedules and weekly reveal pages;
• wallet, registration, entry, lock, and claim flows;
• match and attempt handoff into supported games;
• player-facing tournament results and reward claims;
• public explanation of team-token utility inside official competitions.

Colour League does not own Sodora auction mechanics, Sodora holder-reward emissions, or the Sodora checkpoint engine.

Shared Ecosystem Relationship

The intended long-term relationship is:

1. Sodora launches first as the governance token.
2. Exactly 28% of total Sodora auction USDC raised is allocated to Colour League team-token purchases, split 7% per team token.
3. Colour League opens the team-token sale on a weekly cadence.
4. Colour League runs official weekly competition weekends.
5. Colour League hosts the initial competition weeks.
6. After bootstrap, Sodora governance approves hosts and reward policy.
7. Colour League contracts and platform services enforce the approved host and reward-budget decisions.

Part I: Sodora Protocol

Purpose

Sodora is the governance-token layer of the 777 ecosystem. Its core responsibilities are:

• launch a governance token through a public auction;
• keep protocol issuance rules explicit and narrow;
• distribute holder rewards only when defined auction or checkpoint conditions are met;
• support post-auction checkpointing against a canonical Sodora/USDC market;
• provide governance infrastructure for future platform decisions.

Sodora is not the team-token sale, does not run games, and does not determine tournament results.

Token

The Sodora token is an ERC-20 token with:

• name: Sodora;
• symbol: Sodora;
• decimals: 18;
• role-gated minting;
• reward-controller integration that can be set and then frozen.

The protocol design includes only the auction, failed or skipped round treasury minting, and conditional holder-reward emission paths described here.

Phase 1 Auction

The first phase of Sodora is a 777-round auction sequence.

Core phase-1 rules:

• auction start: Unix second 1777777777, which is 3 May 2026 03:09:37 UTC;
• round count: 777;
• base round duration: 777 seconds;
• winners per successful round: 7;
• token bundle per winning bid: 7 Sodora;
• base issuance per round: 49 Sodora;
• payment asset: USDC;
• clearing model: uniform-price, using the seventh-highest valid price per Sodora as the clearing price;
• soft close: bids placed with 3 seconds or less remaining can extend the live round;
• maximum extension per round: 20 seconds.

A successful round mints 7 Sodora to each of the 7 winners. Each winner pays the round clearing price for a fixed 7-token bundle. If a winner bid above the clearing price, the difference is credited for refund.

If a round fails or is skipped because there are not enough active bids, the same round amount, 49 Sodora, is minted to treasury. This keeps phase-1 base issuance explicit across both successful and unsuccessful rounds.

Successful-round USDC proceeds settle to the Sodora treasury. Across the completed phase-1 auction, exactly 28% of total USDC raised is used to purchase Colour League team tokens, split as 7% into each of COLRED, COLBLUE, COLGREEN, and COLYELLOW.

Losing bids can remain active across rounds until they win, are replaced upward, are cancelled for a future round, or phase 1 ends. Cancellation requests remain binding for the current round and take effect after settlement. Settlement can be processed across multiple sync() calls when cancellation queues are large.

Auction Reward Emissions

The auction can emit 77 Sodora to the reward controller when a successful round clears strictly above the previous successful clearing price.

This mechanism is conditional. It is not a scheduled emission. A successful round with a clearing price that does not exceed the previous successful clearing price does not trigger that auction reward emission.

Rewards Controller

The Sodora reward controller is pull-based and non-rebasing. It does not iterate through holders. It uses principal-indexed reward-share accounting:

• reward emissions are minted into the controller;
• eligible wallet-held principal participates in newly minted reward shares;
• unclaimed rewards remain inside the controller and continue participating while active;
• the reward controller supports exclusions for treasury, protocol-owned addresses, and other addresses designated by governance or authorized administrators;
• exclusion freezes already earned claimable rewards but stops future active participation for that address.

Users claim rewards manually through the reward controller. Claims transfer the claimable Sodora amount to the recipient selected by the claimant.

Phase 2 Checkpoints

After phase 1, the checkpoint engine compares a canonical Sodora/USDC pool over time.

Core phase-2 rules:

• checkpoint interval: 777 seconds;
• TWAP window: 777 seconds;
• reward emission per qualifying checkpoint: 77 Sodora;
• first checkpoint is blocked until phase 1 has actually settled;
• the first phase-2 comparison bridges from the last successful auction clearing price;
• later comparisons use checkpoint-to-checkpoint movement;
• a reward is emitted only when the new comparison point is strictly higher than the previous baseline.

Checkpoint execution is permissionless, but it depends on the configured canonical pool. The guardian can pause checkpoint execution if the market reference is invalid. Timelocked governance can later replace the canonical pool.

Governance

Sodora governance is implemented with a governor and timelock architecture. The intended production posture is:

• governor and timelock control protocol administration;
• temporary deployer admin rights are removed after setup and validation;
• pause and guardian powers are narrow and operationally scoped;
• governance can expand beyond Sodora contracts into Colour League platform policy over time.

The default governance configuration used for launch is:

• proposal threshold: 777 Sodora;
• quorum numerator: 777, corresponding to 7.77% of claimed supply;
• timelock delay: 77777 seconds;
• voting delay and voting period configured through published deployment settings.

Issuance Summary

Sodora issuance comes from:

• successful phase-1 auction settlements;
• failed or skipped phase-1 round treasury minting;
• conditional auction reward emissions;
• conditional phase-2 checkpoint reward emissions.

The 28% auction-proceeds purchase rule affects USDC treasury use only. It does not alter Sodora issuance or bypass the public team-token sale mechanics.

The base phase-1 round issuance is:

777 rounds x 49 Sodora per round = 38,073 Sodora

Conditional reward emissions are additional and depend on qualifying auction and checkpoint outcomes.

Part II: Colour League Platform

Purpose

Colour League is the competition and team-token layer of the 777 ecosystem. It owns:

• the four team tokens;
• the fixed-price public team-token sale;
• tournament entry and token-locking contracts;
• competition registry and reward distribution contracts;
• host compensation contracts;
• tournament orchestration services;
• the public website;
• browser game services;
• shared software components used by the website, platform services, and games.

The platform runs one hosted competition weekend every week. Colour League hosts the initial launch path. Later hosting is intended to move toward governance-approved hosts.

Architecture

Colour League is split into five layers:

1. On-chain contracts on Base.
2. A centralized tournament service.
3. A Next.js public website.
4. Browser game services.
5. Shared software components for tokenomics constants, contract interfaces, and launch-program data.

The website is the main experience for token sales, schedules, tournaments, wallet flows, claims, and supported match handoff routes. The games remain independently hosted services.

On-Chain Components

The core Colour League contract set includes:

• TeamToken: one ERC-20 token per team;
• TeamSale: fixed-price public team-token sale;
• PlatformPolicy: competition fee, minimum escrow, weekly sale pricing, and policy reads;
• InflationController: disabled-by-default future supply policy surface;
• TournamentEscrow: token locking and official match or attempt entry;
• CompetitionRegistry: approved hosts, competition windows, and approved reward budgets;
• RewardDistributor: Merkle-root based USDC reward claims;
• HostCompensationVault: approved host compensation after competition windows end.

The contracts do not calculate official game outcomes. They provide custody, gating, budget validation, claim finality, and governance-aware settlement primitives.

Platform Service Responsibilities

Colour League platform services are authoritative for:

• Sign-In With Ethereum authentication;
• tournament catalog generation;
• registrations and queueing;
• game launch-session issuance;
• game-session authorization;
• official match or attempt ingestion;
• validation and approval of official results;
• ranking and reward computation;
• Merkle-tree generation;
• payout reports;

For official prize-bearing Cell Arena matches, the platform service keeps the official record used for settlement. Game-server summaries are audit artifacts, not the settlement record.

Website Responsibilities

The Colour League website handles:

• public launch messaging;
• team-token sale flows;
• wallet connection and SIWE login;
• token approval and tournament entry in deployed mode;
• competition schedules and detail pages;
• queue and match launch handoff;
• reward claim and locked-token withdrawal flows;
• payout reporting for authorized administrators where applicable.

Game Services

The initial public launch set begins with:

• cell-arena: realtime scheduled team matches;
• later-week competition slots announced before entries open.

Part III: Team-Token Economy

Team Tokens

Colour League has four canonical team tokens:

Each team token uses 18 decimals and is freely transferable after purchase. Minting is restricted to approved minters.

Primary Sale

The public team-token sale is a fixed-price weekly tranche sale.

Launch parameters:

• minimum price: $0.01 per team token;
• price unit: 10,000 micro-USDC per token at the floor price;
• public sale target per team: 100,000,000 tokens;
• weekly sale amount per team: 12,500,000 tokens;
• bootstrap sale duration: 8 weekly tranches;
• first public sale start: 4 May 2026 12:00:00 UTC;
• later sale tranches open every 7 days from the first sale start.
• predetermined Sodora auction-proceeds purchase: exactly 28% of total auction USDC raised, split 7% per team token.

The configured weekly sale price cannot drop below $0.01. Purchases cannot exceed the weekly tranche.

Conversion formula:

tokenUnits = floor((usdcMicro * 1e18) / priceMicroUsdc)

At the $0.01 floor:

tokenUnits = usdcMicro * 1e14

Inflation

Launch default monthly inflation is 0. No active team-token inflation is part of the initial launch tokenomics.

Disabled periods do not accrue retroactive catch-up mints. Any future nonzero supply policy requires a governance decision and updated public documentation before activation.

Competition Entry

The base competition fee is:

777 whole team tokens per official match, attempt, or entry

For Cell Arena:

• one official match entry costs 777 team tokens;
• players may join multiple matches, including across regions;
• optional extra locked tokens can increase starting size for one match only;
• used entry credits and posted extra locked tokens count toward prize-bearing match weight.

For later-week competitions, the base fee remains 777 team tokens unless a future public update says otherwise. Any game-specific lock, entry, and return rules will be published before entries open.

Tournament Rewards

Tournament rewards are funded in USDC from platform revenue and are based on official competition results. The reward contract pays claims from published Merkle roots. It does not recompute gameplay outcomes on-chain.

Budget model for initial 8 weeks:

weeklyPrizeBudgetUsdc = 10,000,000 x configuredTeamTokenPrice
weeklyHostCompensationUsdc = 1,000,000 x configuredTeamTokenPrice

At the $0.01 floor price:

weeklyPrizeBudgetUsdc = 100,000 USDC
weeklyHostCompensationUsdc = 10,000 USDC

The launch program models eight weeks. At the floor price, the eight-week launch model therefore represents:

8 x 100,000 USDC = 800,000 USDC in modeled prize budgets
8 x 10,000 USDC = 80,000 USDC in modeled host compensation

Actual publication and claims depend on the relevant competition being configured, funded, validated, and finalized.

Part IV: Governance and Host Approval

Bootstrap Phase

The first competition weeks are hosted by Colour League. This bootstrap phase lets players join official competitions while the governance-controlled host approval process matures.

For users, this means:

• official launch competitions are run by Colour League;
• published competition pages identify entry rules, schedules, and reward terms before entries open;
• host approval and reward-budget decisions are designed to move under Sodora governance after bootstrap.

Governance Direction

The intended long-term direction is for Sodora holders to govern:

• host approval;
• reward-budget policy;
• reward-distribution policy;
• competition policy parameters where appropriate;
• future platform governance expansion.

The Colour League contracts are designed to support this path through governance-aware administration and registry checks. The preferred governance admin for four-colour deployments is the Sodora timelock, so sale and settlement policy can eventually be controlled by Sodora governance.

Host Approval

CompetitionRegistry stores approved hosts and approved competition budgets on-chain, including:

• approved hosts;
• competition windows;
• game identifiers;
• approved reward amounts;
• approved host compensation amounts;
• whether a reward root has been published.

RewardDistributor can validate published reward amounts against CompetitionRegistry. HostCompensationVault prepares and releases approved host compensation only after the relevant competition window has ended and the required registry conditions are satisfied.

Reward Publication

Reward roots are published after official results are validated and finalized. During bootstrap, authorized Colour League accounts may publish reward roots so eligible players can claim rewards.

Public guardrails:

• administrative control is intended to sit with a controlled Safe, governance timelock, or explicitly controlled admin account;
• reward-root publishing authority should be limited to the authority needed for bootstrap operation;
• reward distribution contracts should be funded per match or per week rather than carrying a large standing USDC balance;
• each reward root should match an approved reward budget in the registry;
• after bootstrap, root-publishing authority is intended to move to governance, timelock, or a governance-approved publisher.

Trust Boundary

The governance layer can approve policy and hosts, but official match execution is still off-chain. Colour League platform services and game services remain responsible for running official competitions and producing auditable results. On-chain contracts validate custody and claims, but they do not independently verify every game action.

Part V: Launch Timeline and Rollout

Canonical Launch Moments

The 1777777777 launch second belongs to the public Sodora auction opening on sodora.xyz. The team-token sale begins later on a Monday cadence at colour-league.com.

Public Reveal Policy

The public site reveals Week 1 on 29 April 2026. Weeks 2 through 8 are announced through public site and whitepaper updates before their entries open.

Eight-Week Launch Program

The initial public launch program is:

Weeks 6 through 8 are planned return slots decided by player voting on X and Discord during weeks 4 and 5.

Week 1: Cell Arena

Current Week 1 parameters:

• match day: 9 May 2026;
• regions: EU and NA;
• scheduled matches: 10;
• first scheduled start in the catalog: 13:05 UTC;
• queue opens: 25 minutes before each match;
• scheduled match duration: 15 minutes;
• entry fee: 777 team tokens per match;
• reward split: 50% winning team pool and 50% top-3 overall player pool;
• top-3 player weights: 50% / 30% / 20%.

Later Weeks

Later-week dates, formats, rules, and schedules are announced before entries open. Each future competition week will publish its entry rules and reward split before players commit tokens.

Fairness Posture

The launch is early, public, and clear. In practice, this means:

• no private allocation replaces the public sale;
• no hidden presale or insider-only early window is part of the launch;
• the disclosed 28% Sodora auction-proceeds purchase rule is a treasury-use allocation, not a private allocation or extra mint;
• the exact Sodora auction second is announced in advance;
• the exact team-sale opening time is announced in advance.

Part VI: Risks, Limitations, and Trust Boundaries

Smart Contract Risk

The ecosystem relies on smart contracts for token balances, auctions, sale settlement, escrow, registry gating, reward roots, and claims. Smart contracts can contain bugs, implementation errors, integration mistakes, or deployment configuration mistakes. Non-upgradeable contract design reduces some governance risk but makes deployment correctness more important.

We do not assert that the contracts have completed any independent security audit unless such audit reports are later appended.

Administrative and Governance Risk

Administrative roles exist during deployment, bootstrap, and operational setup. These roles can affect minting permissions, pause controls, policy settings, reward-root publication, host approval, and deployment finalization. The intended direction is timelock and governance control, but bootstrap operation still requires careful role management.

Market and Liquidity Risk

Sodora phase-2 checkpointing depends on a canonical Sodora/USDC market reference. Invalid, thin, manipulated, or unavailable market data can affect checkpoint behavior. The guardian pause and timelocked pool replacement mechanisms are designed to manage invalid reference conditions, but they do not remove all market-reference risk.

The auction-proceeds purchase rule creates a disclosed treasury purchase flow into all four Colour League team tokens. It should not be presented as a guarantee of secondary-market price, liquidity depth, automatic holder payments, or any team-token holder entitlement.

Platform and Game Service Trust

Colour League official competitions rely on off-chain platform and game systems. Colour League platform services are trusted to authenticate users, issue launch sessions, bind official matches to canonical records, validate results, rank players, compute rewards, and publish reward data. Game services are trusted to execute official matches or attempts according to the rules for the relevant game.

The on-chain contracts do not independently replay or verify every game action. They enforce custody, settlement gates, approved budgets, and one-time claims.

Oracle and Price Reference Risk

Sodora checkpoints use a canonical pool reference. Team-token reward budgets depend on configured sale prices. If references, policy values, or configured prices are incorrect, stale, or mismanaged, user-facing calculations and reward budgets can be affected.

Regulatory and Compliance Risk

Crypto assets, token sales, governance systems, competitions, and rewards can be treated differently across jurisdictions. This paper is an architecture and product disclosure, not a regulatory approval. Users should consider the rules that apply where they live or access the platform.

Operational Risk

The ecosystem depends on published address data, service configuration, private operational credentials, database availability, game availability, monitoring, and operating procedures. Incorrect address publication, stale contract addresses, mismatched service configuration, or failed services can disrupt sale, entry, match, or claim flows.

User Risk

Users are responsible for wallet security, transaction review, network selection, and understanding that blockchain transactions can be irreversible. Users should verify that they are interacting with the official domains and contract addresses before taking action.

Appendices

Appendix A: Contract Addresses

Official contract addresses are published through the live website address panels and official documentation. Users should verify addresses on the official websites before signing any transaction; this dated paper is not a substitute for checking the current site.

Base Mainnet Publication Table

Appendix B: Token Parameters

Sodora

Colour League Team Tokens

Appendix C: Game Rules

Cell Arena

Cell Arena is a realtime four-team arena game. Players split, consume, and grow from a locked-token starting-mass model. Teammates do not eliminate one another.

Later-Week Game Rules

Rules for later-week competitions are announced before the relevant competition opens.

Appendix D: Reward Formulas

Sodora Auction Clearing

For each successful auction round:

clearingPrice = seventh-highest valid price per Sodora
winnerBundle = 7 Sodora
winnerPayment = clearingPrice x 7
roundWinnerIssuance = 7 winners x 7 Sodora = 49 Sodora

If a winner bid above the clearing price:

winnerRefund = (bidPrice - clearingPrice) x 7

If the round fails or is skipped:

treasuryMint = 49 Sodora

Across the completed phase-1 auction:

teamTokenPurchaseBudget = totalAuctionUsdcRaised x 28%
perTeamTokenPurchaseBudget = totalAuctionUsdcRaised x 7%

Sodora Auction Reward Emission

For a successful round:

if currentClearingPrice > previousSuccessfulClearingPrice:
    emit 77 Sodora to the reward controller
else:
    emit 0

Sodora Checkpoint Reward Emission

For phase 2:

checkpointInterval = 777 seconds
twapWindow = 777 seconds

if newCheckpointComparison > previousCheckpointBaseline:
    emit 77 Sodora to the reward controller
else:
    emit 0

The first phase-2 checkpoint compares against the last successful auction clearing price when that bridge is available.

Sodora Reward-Share Allocation

The reward controller uses an indexed share model rather than per-holder loops. A simplified view of a new reward emission is:

emission = 77 Sodora or another approved emission amount
eligibleSupply = eligible wallet principal + active unclaimed controller rewards

if eligibleSupply == 0:
    skip emission
else:
    allocate emission across eligible principal and active unclaimed rewards by share

Actual implementation uses scaled share indexes to preserve precision and support compounding active rewards.

Team-Token Purchase

tokenUnits = floor((usdcMicro * 1e18) / priceMicroUsdc)

At the floor price:

priceMicroUsdc = 10,000
tokenUnits = usdcMicro * 1e14

Competition Entry Weight

For Cell Arena:

prizeBearingMatchWeight = (777 team tokens x matchesJoined) + extraLockedTokenAmount
returnedLockedTokens = extraLockedTokenAmount

Later-week entry-weight formulas are announced before the relevant competition opens.

Weekly Prize and Host Budgets

weeklyPrizeBudgetUsdc = 10,000,000 x configuredTeamTokenPrice
weeklyHostCompensationUsdc = 1,000,000 x configuredTeamTokenPrice

At the $0.01 floor:

weeklyPrizeBudgetUsdc = 100,000 USDC
weeklyHostCompensationUsdc = 10,000 USDC

Cell Arena Reward Split

Per match:

winningTeamPool = 50% of match pool
topPlayerPool = 50% of match pool

topPlayerWeights = 50%, 30%, 20%

Later-Week Reward Splits

Later-week reward splits are announced before the relevant competition opens.