Different worlds.
A shared economy.

01 / THE FIRST SPARK

Gaming is connected.
Its economies should be, too.

Players move between worlds. Communities grow around servers. Yet discovering and trading game items, currencies, and server-specific products can mean navigating a different experience in every game.

Torch proposes a shared marketplace for supported gaming economies, with $TORCH as its planned gaming ecosystem token. Torch Games adds a recurring layer of seasonal Web3 experiences to the marketplace and supported server communities. The shared token is intended to connect gameplay, eligible commerce and community participation across the ecosystem.

02 / A NETWORK OF WORLDS

Five games. One direction.

The roadmap targets a server network across up to five online games, subject to technical feasibility, operator agreements, and each game’s rules. Torch may operate its own servers and integrate services from independent operators.

Participating servers could make eligible items, currencies, memberships, and access packages available through the marketplace. Each integration would identify the actual operator and the products supported.

No operating server network or game partnerships are being claimed in this edition. Illustrations depict the intended experience.

03 / SEASONAL WEB3 GAMES

New games. A shared ecosystem.

Torch plans to release one new Web3 game per month. Each release is intended to run a single 14-day season, with a published opening time, closing time and game-specific ruleset. The remaining monthly cycle supports settlement, balancing, feedback and preparation for the next release.

The acquisition model connects discovery to sustained participation: trailer and community campaigns introduce each game; onboarding leads into a time-bounded season; eligible players can then explore other Torch games and supported marketplace services. The aim is to attract Web3 players through playable experiences and retain them across the wider ecosystem.

A season ruleset will specify any entry cost, $TORCH uses, progression and scoring criteria, eligibility checks, reward budget and settlement schedule before participation opens. Shared token utility does not mean that character levels, items or balances transfer automatically between games; interoperability must be defined explicitly for each release.

Gameplay rewards depend on player activity, eligibility, published caps and the available season budget. Entry fees buy access to a season; they are not refundable deposits or a promise of repayment. Torch does not guarantee an entry-cost recovery period or daily income.

Reward budgets and token burns are separate allocations. Each season should publish its funding sources, maximum distributable rewards, anti-abuse controls and settlement conditions so that the same tokens are not counted as both player rewards and burned supply.

04 / THE MARKETPLACE

Less fragmentation.
More room to play.

The marketplace is intended to serve both Torch-operated servers and participating external communities. Players would browse supported games, discover eligible products, and purchase through a consistent interface.

Seller verification, product eligibility, delivery methods, and dispute handling are implementation priorities. Conventional payment methods and potential $TORCH payments will be evaluated with payment providers and applicable game policies.

05 / TOKEN UTILITY

Utility begins with use.

$TORCH is designed as the ecosystem-wide asset for Torch Games, eligible marketplace payments and selected community programs. Each game will define supported uses, entry conditions and reward rules within the same ecosystem; token functionality depends on implemented products and published contracts.

06 / PLATFORM ECONOMICS

Activity first.
A transparent economic model.

Torch proposes using a defined portion of actual marketplace commissions to purchase $TORCH and burn the acquired tokens. Eligible transactions could therefore contribute to buybacks even when a customer pays using a conventional payment method.

The final policy must explain operating costs, fee calculations, NFT-holder distributions, buyback execution, and reporting. The same revenue cannot be allocated in full to multiple purposes. No buyback schedule is active, and buybacks do not guarantee token demand, price appreciation, or investment returns.

Gameplay, utility and supply reduction

Torch plans ecosystem-level $TORCH buyback and burn mechanisms funded through disclosed allocations. Emberwild’s current game design instead recycles in-game token spending into its reward budget; it does not automatically burn that spending. Any future game-specific burn must be defined separately in the published game rules before implementation.

The intended feedback loop is player activity → usable game experiences → defined ecosystem revenue or token consumption → disclosed reward and burn allocations. Burn transaction records and season reports should make execution measurable. A supply reduction is not itself a guarantee of market value, profitability or sustainable demand.

07 / THE NFT COMMUNITY

The first 444.

Torch plans a limited community collection on Ethereum, with free distribution directly to selected wallets. Recipients would not need to complete a mint transaction themselves.

Weekly fee sharing would depend on the marketplace being operational and generating eligible fees. Token funding, snapshot dates, distribution currency, vesting, and how benefits change when an NFT is transferred must be defined before implementation.

These are proposed benefits, not active entitlements. An application does not guarantee an NFT, tokens, or rewards.

08 / EARLY ACCESS

A community starts
with a conversation.

The live waitlist asks for an X username, a short explanation of why the applicant wants to participate, and a public wallet address. It does not require payment, a wallet connection, a signature, or access to a social account.

Neither applying nor holding tokens would guarantee whitelist selection. Raffle eligibility, weighting, snapshots, and selection procedures are not finalized.

09 / STAKING & REWARDS

Rewards need a foundation.

Torch is exploring a staking program through which eligible holders could lock tokens and receive rewards from a designated pool. Any rewards must have an identifiable source, such as a disclosed token reserve or an approved revenue allocation.

Staking does not create external revenue by itself. Reward assets, funding, lock periods, withdrawal conditions, and any APR would be published before launch. No fixed yield has been established.

10 / DEVELOPMENT ROADMAP

From first spark
to working ecosystem.

Progress is organized around deliverables rather than unconfirmed launch dates. Later phases depend on the successful implementation of earlier work.

11 / BUILT ON TRANSPARENCY

Proof through progress.

Torch’s long-term ambition is to connect gaming economies through useful commerce infrastructure. Progress should be measured by functioning integrations, completed transactions, reliable delivery, and transparent reporting.

This concept document is not evidence of live trading, issued assets, existing partnerships, or guaranteed benefits. Game policies, technical feasibility, security findings, and applicable requirements may change the roadmap.

Version 0.2 · 25 October 2026. Updated for Torch Games, monthly releases, two-week seasons and shared $TORCH utility. Features, allocations and integrations remain subject to implementation.