Decentralized infrastructure for entertainment that deserves to keep living

Forked.gg is decentralized infrastructure for keeping games and live entertainment alive, built by people who worked inside large web3 gaming companies and watched the usual failure modes up close. We would rather run a smaller system that holds than a bigger one that impresses for a quarter and breaks.

What it is

One network, and the things that run on it. The network is the product: independently owned machines doing real, paid infrastructure work for games, content delivery, storage, live game hosting, oracle data, AI inference and GPU compute, running live today. This is decentralized physical infrastructure, the category the market calls DePIN, pointed at an industry that needs it badly and currently rents it from three hyperscalers.

Everything else in this document sits on top of that network. The products a player touches without knowing a chain is involved: hosted game servers, a cross-store game library, browser games, media streaming, and one account across all of it. Aegis, open-source governance where it is one node, one vote, never weighted by token holdings. A DAO Launchpad so a community can take over a game that lost its stewards and keep it alive. FORKcast, a live prediction engine that runs on any stream you can link. And a marketplace with a free genesis collectible drop for the community.

What we are trying to do

Raise the floor for how web3 games are built, governed, and kept alive. We sell infrastructure that games genuinely need, priced in ordinary money and set below the major cloud providers, and we let a token fund and settle that work without being anyone's payday.

Why the economics are clean

Forked.gg picks up where an earlier project, Helix Games, left off: new people, new technology, a token model designed from a blank page. The team holds no token at all. Its only upside is equity in the operating company, so no insider is ever a structural seller of $FORK. Holders from the Helix community are honored at a fixed 50 LIX to 1 FORK, vesting over six months, because they backed the same cause and the cause is worth championing.

Where the value comes from

Node operators are paid in $FORK for verified work, never in cash, with the reward sized to the value of the work they do. Most of every service payment is used to buy $FORK on the open market and route it to the operators who did the work, so real network usage, rather than speculation, is what supports the token over time. The company buys $FORK and never sells it to fund itself. That demand grows as the network earns; it is not a promise about price.

What is live now

The metering backbone runs in production today, against 3,278 legacy licenses of which roughly 800 have been online. On top of it: hosted Minetest and Factorio game servers that community members pay credits to run, a cross-store game library of about nineteen thousand titles, uploaded browser games, encrypted media sharded across the fleet and streamed back, and a single account spanning all of it. FORKcast is live and cred-only. The price oracle is live. The whole token economy, including Aegis governance and operator settlement, is deployed and proven end to end on a public test network, with mainnet and an independent audit still ahead. What is planned, and what is still uncertain, is marked plainly throughout this document.

I am an advisor to Forked.gg, and I will be honest that I have had more influence on the tokenomics here than an advisor usually does, or usually should. I have been called the give-it-all-away-for-free guy more than once, and I understand why it sounds that way. What you are reading is the result of more than twelve years in this industry, across more projects than I can count, watching them rise and watching them fall.

For a lot of those years I was the person screaming silently in the background while bad tokenomics shipped anyway, again and again, with the same predictable ending. Tokenomics are hard. Getting this right is hard. I am not going to pretend otherwise. What I will say is that by building something that genuinely aligns everyone, the team, the operators, and the people holding the token, we give ourselves a better shot at lasting than anything I have seen put in front of the market so far.

I am not interested in dominating this space. If we stay focused on building what games and gamers genuinely need, we can lift the whole ecosystem rather than try to own it. That is the bet, and I am willing to put my name on it.

To their real credit, the Forked team has been remarkably open to trying something new here. Everyone on this team has seen the wreckage of the last few cycles, and everyone is willing to try a radical answer rather than live through it one more time. That willingness is rarer than it should be, and it is part of why I think this one has a chance.

Jason "BitBender" Brink

Chief Advisor, Forked.gg

Note on this document

This is Version 1 of the Forked.gg white paper, published for community and public review. It describes the direction of the ecosystem and the thinking behind it. Figures, timelines, incentive structures and system models remain provisional and will change as the system is built and reviewed, and the numbers that are fixed at the token generation event are named as such where they appear.

Forked.gg picks up where an earlier project, Helix Games, left off. It is a separate effort with different people, technology built from scratch, and its own economic design. The one thing carried forward is a commitment to the Helix community, whose node operators and backers are honored in $FORK. Section 2 explains what does and does not carry over.

Legal notice

Participation involving digital assets and tokens carries risk, including total loss. This document is for general informational purposes only. It is not financial, legal, tax, or investment advice, and it is not an offer or solicitation to buy any asset. Nothing here is a promise of profit, yield, or future value. Do your own research and consult qualified professionals before participating. Forked.gg makes no representations or warranties and disclaims responsibility for losses. See the Risk Factors section for a fuller disclosure.

The corporate entity is being formed and is with counsel now. The structure that will hold the operating business, the intellectual property, and any token issuance is not complete, so this document deliberately does not name it rather than print something that changes. No node licenses are offered or sold until that formation is finished. The entity appears here once it is settled.

Forked.gg is built by people who worked inside large web3 gaming organizations and watched the failure modes up close. The operating philosophy is stewardship over ownership: keep the core infrastructure healthy, provide continuity for the games and communities that depend on it, and move decision-making toward the community over time.

Jared Dillinger · CEO

Jared Dillinger is a gaming entrepreneur, publisher, and ecosystem builder whose background spans professional sports, gaming, AI, creator media, and web3. As CEO, he leads Forked's focus on building the infrastructure that games run on, and on the partnerships that bring studios and communities onto it. Before Forked he held leadership and advisory roles across gaming and blockchain, including work with Gala Games, The Sandbox, and emerging gaming ventures across Asia, covering ecosystem growth, creator economies, partnerships, esports, and community-led product. A nine-time professional basketball champion and former member of the Philippine national team, he has built one of the largest athlete-driven digital communities in the country.

Christos Segkos · CMO

Christos Segkos is a fintech and web3 executive with over six years of leadership experience across digital banking, blockchain infrastructure, and decentralized finance. He has held C-level roles in high-growth ventures at the point where traditional finance meets the next era of digital assets. Since entering crypto in 2017, he has helped launch and scale multiple projects with token valuations surpassing $100 million, combining technical fluency with strategic market insight and a blend of institutional discipline and startup agility.

Levi Hansen (ChairBandit) · COO

Levi (ChairBandit) is co-founder of Forked, a platform designed to merge the best of web2 and web3 gaming. He brings more than ten years in blockchain and web3, across decentralized systems, tokenomics, and community building. His earlier background as a Director of Customer Support and a Product Manager in traditional game development gives him a clear view of what mainstream players expect, which drives Forked's approach of weaving ownership, rewards, and interoperability into familiar gaming experiences.

Advisors

Jason Brink

Patrick Bergman

Two further advisors

Jason Brink serves as Chief Advisor to Forked.gg and Patrick Bergman as a founding advisor, joined by two further advisors who are named once their agreements with the new entity are executed. Neither Jason Brink nor Patrick Bergman holds any token allocation.

A license is the right to operate a node on the network. It is a piece of software, priced in dollars. Buying one grants no tokens, no yield and no revenue share. The only way any token reaches an operator is by doing real work for a paying customer and having that work measured, proved and audited. No work, no payment, however many licenses are held. No license is offered or sold until the corporate entity is formed; that work is with counsel now. The company can afford to wait, and it is worth saying why: nobody is drawing a salary, the operating cost is servers, and that cost falls as node operators take the work over. A design that releases nothing until demand arrives only works for a company that does not need the sale, and that is the position we are in today rather than a claim about the future.

† SEC Division of Corporation Finance, DoubleZero no-action letter (September 29, 2025): sec.gov/rules-regulations/no-action-interpretive-exemptive-letters/division-corporation-finance-no-action/doublezero-092925. SEC statement on the letter: sec.gov/newsroom/speeches-statements/peirce-092925-deep-statement-doublezero-no-action-letter.

What they cost. The price starts at $1,700 and rises only as the network proves it is being used. It is tied to utilisation, on the same on-chain measure that governs release: at launch utilisation the price sits at the $1,700 floor, and at the 80% target it reaches a $5,000 ceiling, moving in a straight line between the two on a trailing twelve-month average. The price can fall, in two ways, and neither is at our discretion. If utilisation settles below the level that set the current price, the price drifts down toward what current use justifies, closing a tenth of the gap each month. It never goes below what use supports, so this is not a price that collapses on a bad quarter; it just stops charging for a busy period that is over. Separately, any month with no licenses sold at all takes 5% off, which can carry the price below the utilisation line and stops at the $1,700 floor. Rising utilisation always wins: the second rule only applies when use is flat or falling. It is not a date ladder and not a volume ladder. What you pay depends on how much work the network is actually doing when you buy, which is the only thing that determines what a license is worth. The price you pay is fixed at purchase.

Where the money goes

65% of every purchase goes back into the network, not into our pocket. Where it lands depends on one thing. Until the liquidity fund reaches $500,000, that 65 splits 35% into the Emissions Reserve, the same pool operator rewards are emitted from, and 30% held in stablecoin to make a market in $FORK, because a token nobody can trade at a fair price serves no one. Once the fund is full the slice stops and all 65% goes to the reserve. The fund fills as licenses sell, and not before. We are not going to promise a date for it, because that would be promising our own sales. At the 25 available each month and the $1,700 floor, the 30% slice raises $12,750 in a month where all of them sell, so $500,000 takes about 39 months at full take-up and longer at any rate below it. It is not funded out of the company's 33%, which is what builds node services and is thin already. Read that against the release schedule on the previous pages, because the two do not line up. The honored Helix layer completes inside six months, and on that day the fund holds around $76,500 even in the case where every license sells, which is roughly 15% of the target. The market-making side is thin exactly when the largest release lands, and it fills slowest in the case where demand is weak, which is the case where a thin book hurts most. We would rather set that out here than let it be discovered. It is the sharpest unresolved tension in this document.

Why the release rule is shaped this way

A calendar ladder charges more as time passes whether or not anything has been built, and it issues capacity on the same schedule. This one cannot do either. If demand does not arrive, the price stays at $1,700 and the network does not put nodes into service that nobody is paying to use. Supply follows demand, and so does price. They run off the same measured number, so there is only one thing to verify and only one thing to argue about.

That leaves one case to answer for. If demand grows faster than 5% of the fleet a month, the ceiling holds supply back, the network runs at its limit, and customers get turned away while licences that would serve them sit unreleased. A rule that cannot handle its own success is not finished.

The capacity vote

When the network is at capacity and the ceiling is what is blocking release, a vote opens automatically. Not when we decide to call one: the trigger is measured on-chain, so the timing is not ours to choose. It asks node operators one question, whether to release more licences than the ceiling would otherwise allow.

This is deliberately outside the Aegis governance structure described in Section 8. Aegis governs the platform. This governs the one thing operators have a direct financial stake in that the platform does not touch, which is how many of them there are.

Most workloads need no bond. A node that goes offline earns nothing, so failure already punishes itself and there is nothing to add. A handful of workloads are different: if they go wrong quietly, they damage other people. An oracle that signs a bad price corrupts every settlement in that window, and the operator who did it may not even notice. Those workloads require a stake to activate, and that stake is at risk.

Stakes are shown in $FORK and hold a constant economic value, so the token amount is re-struck once a quarter against the volume-weighted average price across the deepest venues over the preceding thirty days, computed by the settlement agent and published with the inputs. Disputes go through the slashing-dispute route, holding at the prior amount until resolved, and no re-strike may move a bond more than 25%. An observed market rate, not a price we publish. The oracle bond is sized against settlement volume rather than a flat figure.

What happens when it goes wrong

• First failure: no slash. The capability is suspended and the operator re-qualifies before it switches back on. Most failures are a bad disk or a bad week, not malice, and treating them as theft would be both wrong and a good way to lose operators.
• Repeat inside 30 days: a partial slash of 10% of the bond, and the capability stays suspended until re-qualified.
• Provable malice, such as signing a price the node knew to be false or colluding on a challenge: the full bond.
• Sustained one-sided drift: a statistically significant one-sided deviation from the independent reference feeds, held over a stated window, is slashable in itself even when no single reading ever breaches the review band. A small persistent bias is profitable, because operators receive more $FORK for every dollar of service revenue when the printed price is low, and it is neither an accident nor a single provable lie.
• Slashed stake goes to the Emissions Reserve, never to the company. We should not profit from punishing an operator, and this way the value returns to the people still doing the work.
• Appeals run through Aegis once governance is enacted. Until then, any slash above the partial tier requires published evidence.
• When the oracle gate halts settlement, the procedure is published rather than improvised. A named reviewer is on call, operator accrual continues throughout the hold so nobody loses earnings to a pause they did not cause, the maximum time to clear is fixed in the operator agreement in advance, and every trip is logged publicly with its cause and duration.

The node software is real and running today across two fleets plus the coordinators that drive them. Those are our own machines. The operator base they grow into is a separate and larger population: 3,278 licenses were issued under the earlier project, and roughly 800 of those machines have been online. The model in Section 13 ramps from the 800 toward the 3,278. Every node runs the same agent, and the agent is ours: a single program with no external dependencies that measures the work a node does, signs the measurement, and settles it. Earnings come out of one formula, units of work multiplied by the weight of that workload, and the credit ledger behind it is hash-chained and re-executed from the beginning every time the coordinator boots, so code that has drifted cannot quietly change history.

Storage does not lean on anyone else's network either. A file is split into shards, compressed, encrypted, spread with erasure coding so it survives lost nodes, and committed to a Merkle tree. Operators are paid for gigabyte-months they can prove they are actually holding, and a damaged shard can be healed by nodes that never see the plaintext. The same shard machinery, taken down to the fragment, is what streams media across the fleet over the open internet today. The control plane below is the content-availability view of that fleet, with each node's status, pin count, and last-seen heartbeat.

Forked Node Control · the live fleet, content-availability view

Beyond keeping content available, a node can take on optional, opt-in workloads. The network is a two-sided marketplace: games and developers need real work done, operators have spare capacity to do it, and putting that capacity to use is the whole point. An operator runs only the workloads their hardware supports and that they choose to accept.

The power ladder

Workloads sort onto a hardware ladder, from the light base tier up to heavy compute. Operators climb it as far as their machine and their appetite allow.

The workload catalog

Ordered from lightest to heaviest: content delivery (game clients, patches and media served close to players); preservation (sunset or community game data on durable decentralized storage); identity and social services; web3 and economic services (indexing, settlement helpers, on-chain data); live game hosting (dedicated multiplayer servers near players); AI inference; and streaming and heavy compute (transcoding and other GPU-bound work).

Four of these carry real traffic today: storage with proof of possession and paid gigabyte-months, media streaming across a twenty-city fleet, live game hosting running paying customer worlds, and the price oracle. An RPC workload and adaptive-bitrate video are built and waiting on deployment gates; the rest sits behind opt-in flags reporting an honest zero until switched on.

Live example: the Price Oracle

One of these has run the longest. Each node independently pulls prices from many venues, discards stale or manipulated quotes with a deviation filter, blends the survivors into one liquidity-weighted number, and signs it. A second pass across the fleet takes a stake-weighted median of those signed reports, so no single broken or dishonest node can move the published price. If that fleet price lands more than 2% away from the broad market, settlement stops and a person reviews it before anything clears. That gate is temporary, there to prove the machinery behaves while the network is young, and we expect to retire it after about twelve months of running clean. It is the template for how every heavier workload plugs into the network.

The node network runs as a real business. Games, studios, and developers pay for the work nodes do, and operators are paid for doing it.

Settled cleanly, paid in token

Customers pay in ordinary money or stablecoins for storage, content delivery, live hosting, RPC and oracle data, AI inference, and GPU compute, so a buyer never has to hold a token to use the network. Customers who do pay in $FORK get a 10% discount on node services, which rewards using the token and adds to its demand. Prices are set to what the market will absorb, which sits well under the major cloud providers, and each operator decides whether that return is worth running a given workload. Each service payment splits four ways: 65% buys $FORK on the open market and routes it to the operators who did the work, 23% stays with the company in fiat to run operations, 10% is bought back into the Emissions Reserve, and 2% goes to the operator-controlled DAO in fiat. That 10% is the company putting a tenth of every service dollar back into the pool that pays operators, which is the same thing 65% of every license sale already does. Operators are paid entirely in $FORK, never in cash, and the company never sells the token to fund itself. The economics are strongest on a home machine you already pay to run, where the marginal cost of an extra workload is close to nothing. A rented VPS works too, though its fees come out of what the operator nets. Home hosting is the intended model.

Credits go one way, on purpose

A customer buys credits with ordinary money or with $FORK, and spends them on services. Credits never travel in the other direction. They cannot be converted back into $FORK, cannot be cashed out, and cannot be transferred between accounts. This is the Steam Wallet model, and it is a wall in the ledger rather than a policy we could quietly relax. It keeps credits a closed-loop utility for buying compute instead of something that behaves like a deposit or an investment, and it is the reason operators are paid in $FORK bought on the open market with service revenue rather than out of a credit balance. The two systems never touch.

Operator pay arrives through two separate channels that stack on top of one another. A node has to be live to earn from either.

• Availability rewards pay for being a live, healthy node and for standing ready to serve heavier work. Every node earns a base reward for uptime, and each additional capability it can prove it is ready to serve adds a multiple on top, so a machine that keeps more capacity ready earns more. These come from a declining draw on the Emissions Reserve and run on an earn-then-claim-then-vest cycle: an operator earns while the node runs, claims when they choose, then waits out a fixed vesting window during which the node must stay online and no new rewards accrue. Section 13 sets out the window and what taking it early costs. Readiness is checked, not taken on trust: nodes challenge one another on an unpredictable schedule, and a capability that fails its challenge stops earning its multiple.
• Workload rewards are the 65% of each real service payment, recycled into $FORK and routed to the operators who did the verified work, paid straight through on top of availability rewards. This channel carries no separate multiple, the payment itself already reflects what the work was worth, and it scales with real paid service, so the network is paid mostly by customers as it matures.

Each capability's multiple is weighted by what it costs an operator to keep ready and how much it is worth to the network. Base availability is the reference point at 1.0×. Heavier and scarcer capabilities earn a higher multiple for staying ready to serve them, and because the multiples are additive, a well-provisioned machine stacks several at once. The chart shows every workload in the catalog, grouped by power tier.

The table on the previous page runs from 1.0× for base availability to 40× and beyond for anchor-class work. That spread is the whole of this section. A node earns the multiple of the work it actually performs, and the 65% passthrough is paid on verified work per node, so a node doing heavier work already earns more without anything new being built to make it happen.

Work goes to the nodes that can carry it

Heavy workloads are routed to nodes that can serve them. Render and pixel streaming need a GPU. Archive and oracle work need storage and uptime that ordinary hardware does not hold. Rather than spreading that work thinly across a fleet that mostly cannot do it, the network sends it where it can actually be served, and the operator who serves it is paid for it directly.

Nothing about this is compulsory. We set the specification for each tier and publish it. An operator who meets it is eligible for that work. An operator who does not keeps their license, keeps their node, keeps earning base availability, and can upgrade whenever they choose or never. No node is switched off, downgraded or bought out for failing a specification introduced after it was purchased.

What we are not going to pretend

Two things follow from this that are worth stating rather than leaving to be discovered.

An operator who never upgrades earns base rates. Base availability is the bottom of a table that reaches 40×, and for some operators base rates will not cover what the machine costs to run. The choice stays theirs and the license stays theirs, but choosing not to upgrade has a real cost and we are not going to describe it as neutral.

Reward concentrates toward capable hardware. The heaviest tiers carry a large share of total service revenue, so if only a small part of the fleet can serve them, a small part of the fleet earns a large share. That is in tension with what a distributed network is for, and it is a live design question rather than a settled one. So we will publish the distribution monthly, showing what share of workload reward the most capable nodes take, alongside the rest of the network's reporting. We are not going to name a threshold at which it becomes a failure, because the heaviest tiers carry most of the revenue by design and a number set today would be arbitrary. It sits with us, and it gets reviewed every time a capacity vote fires. We would rather name it here than have it read off the payout data later.

A game library that spans the stores

A cross-store discovery portal covering roughly nineteen thousand titles from Steam and Epic on a single catalog spine, with a filter for whether a game touches web3 at all and a per-player switch for adult content that is off by default. It exists because the wall between web2 and web3 gaming is mostly an artifact of where things are listed, and because a player looking for something to play should not have to care which storefront it came from.

One account across all of it

A single profile carries a player across every surface here. Sign in once, link the accounts you want to link, and your credits, your standing, and your history follow you. Linking a wallet is done by signing a challenge rather than by pasting an address, so the link is proven rather than claimed, and a linked wallet is what lets service payments and rewards find the right person. A player who never links a wallet loses none of the products.

The proof anyone can watch

The clearest demonstration is a public page that plays a feature film while showing you which nodes on six continents are serving each fragment of it as it arrives. Kill nodes and the film keeps playing, because the erasure coding means the missing fragments are rebuilt from the ones that survive. It takes a claim that is usually made in a diagram and makes it something a person can sit and watch for ninety minutes.

Underneath the consumer products sit the pieces a third-party studio builds against. These are the composable layers, not standalone products.

• Marketplace infrastructure. The marketplace (Section 11) is built by Forked.gg: a lazy-mint drop contract for settlement, NFT data indexing, wallet connection, and decentralized media storage on the node network, with fiat and compliance handled through a regulated merchant-of-record partner when a paid path opens. The initial integration chain is BNB Smart Chain, and we intend to stay as chain-agnostic as possible: expansion to other EVM chains should follow quickly, while non-EVM chains are a much larger engineering lift and will take more time.
• Developer marketplace API. The interface behind Section 11's second stream. A game lists its items here, on-chain or off-chain, from the systems it already runs. The API and the developer console are built and deployed behind a login, with the money and asset rails deliberately stubbed until counsel and the token audit clear.
• Game Integration SDK. A modular toolkit for embedding blockchain functionality into existing or new games without rewriting them. In-game trigger points map to on-chain actions; the chain runs in the background while players keep the systems they know.
• Content Marketplace (UGC). Players capture, package, and distribute in-game experiences as reusable digital content, valued by contribution quality rather than follower count. The same ownership primitives that back collectibles back creator content, so a clip, a level, or a cosmetic is something its maker actually holds and can trade.

A framework for games that have lost active stewardship, so a community can take one over and keep it alive: hold the rights, maintain the code, run the servers, and fund the people who do the work.

The frame

We are gamers first. We use blockchains only where they earn their place: holding a shared treasury no one can quietly walk off with, coordinating maintainers who do not all know each other, keeping a tamper-evident record of who owns and agreed to what, and funding long-horizon work in the open. Anywhere a normal company, contract, or database does the job better, we reach for that instead. If a revival needs no token and no chain at all, that is a perfectly good outcome.

Three machines in one

A revival is a legal vehicle that can hold the IP and sign things, a technical commons that keeps the game buildable and runnable, and a governance layer that funds and steers the work. The order matters and it is the whole point: rights first, a runnable build second, community and money last. Most attempts die because they build the token before anyone has confirmed the right to touch the code.

Reference cases

When Knockout City was sunset in 2024, its studio released self-hosting server software so communities could keep playing, proof that an owner sometimes will cooperate. Clean-room projects like OpenRA and OpenMW keep older games alive by reimplementing the engine and owning none of the original assets, proof of the path that needs no permission at all.

Layer 1, the legal vehicle (do this first)

There are three clean paths to a legitimate revival: the owner grants a license or open-sources the game (fastest, when you can get it); you acquire the rights outright (cleanest end state, hardest to close); or a clean-room reimplementation that owns none of the original assets and needs no permission (the most engineering). Nothing technical or financial counts until one of these is true for the title. Once rights are settled, the DAO needs a real legal wrapper, a Wyoming DAO LLC or a foundation, so it can hold IP, sign contracts, hold a treasury, and shield contributors from personal liability.

Layer 2, the technical commons

This is mostly ordinary software preservation. A reproducible build, so a clean machine can compile a working binary years from now. Decoupling from dead infrastructure, replacing auth, matchmaking, and backends with community-runnable equivalents. Repo custodianship, where a small trusted maintainer group holds merge rights while the DAO votes on direction and budget rather than on individual pull requests. And asset durability, where huge game assets live on normal plus durable storage with only manifests and content hashes recorded on-chain.

Layer 3, funding and governance (done safely)

A token can fund the work, coordinate governance, and reward contribution. It must not be sold as an investment tied to the game's revenue, which creates an unregistered security and the wrong incentives. It must not pre-sell governance over an IP no one controls yet. It must not become pay-to-win. The model that fits is a non-financial membership and contribution DAO, governed cred-only or by contribution rather than by a tradeable speculative asset, the same posture locked for FORKcast. For many titles the right answer is no token at all, just a grant pool and a maintainer multisig.

The DAO Launchpad is built in stages, and most of its hardest parts are structure and tooling rather than new technology. The components below are what it takes to carry a revival from a confirmed right all the way to a funded, running, community-governed game. Each one leans on infrastructure Forked.gg is already building, so the Launchpad assembles existing pieces rather than starting from zero.

Phase 1, the legal toolkit and intake

Standardized DAO legal wrappers, a Wyoming DAO LLC and a foundation template, alongside rights-intake and licensing templates and a contributor-agreement set. A rights-first assessment checklist sits in front of all of it, so no work begins on a title before a right is confirmed in writing.

Phase 2, governance and treasury

A cred-only or contribution-based governance module running on Aegis, a grant pool and maintainer-multisig pattern, and contribution tracking so funding reaches the people actually doing the work. This is where a revival gets a transparent treasury and a way to steer it without handing control to a tradeable token.

Phase 3, the technical commons

A reproducible-build pipeline so a clean machine can compile a working binary years from now, drop-in replacements for dead auth, matchmaking, and backend services running on the Forked.gg node network, and an asset-durability layer that keeps large game files on durable storage with manifests and content hashes anchored on-chain.

Phase 4, the self-serve launchpad

An end-to-end flow that carries a confirmed revival from intake through entity formation, repo custody, funding, and hosting, proven out on a first reference revival run start to finish. At that point a community that holds the rights to a game can stand one up without rebuilding the scaffolding every time.

Forked.gg provides the tools and the framework. We are not the ones who run a revival for a game. The structure described in this section is something a community stands up and operates for itself, using what we build, not a service we perform on anyone's behalf.

We are not lawyers, and nothing here is legal, financial, or tax advice. We cannot and will not form your legal entity, draft your binding agreements, run your governance, or hold or manage your treasury. We have no interest in taking on those roles. Those are decisions a community makes with its own qualified counsel and its own people.

What we can do is give you a roadmap and a clean way to integrate a rebuilt game into the Forked.gg ecosystem: the node network for hosting, the marketplace for assets, and Aegis for cred-based coordination. Everything in this section is offered as a general framework and a set of starting instructions, not as specific advice for any particular game, project, or jurisdiction.

Any stream, its own page

FORKcast sits on top of any livestream. Paste a link from Twitch, YouTube, or Kick and FORKcast gives that stream its own page, with the video embedded and prediction pools running beside it. There is no partnership requirement and nothing to install, so the engine reaches any public stream rather than a fixed list of games or channels. A game, a match, a tournament, a debate, an awards show, anything you can pull up live becomes something a room can predict on.

Watch parties

A watch party turns that page into a room you share. You invite a group of friends with a single link, everyone lands on the same embedded stream, and you open pools and play them against each other in real time. Someone calls a market, the room takes sides, and the leaderboard settles who read it best. It makes watching together competitive without anyone leaving the stream or installing anything.

The trollbox

Every FORKcast page carries a trollbox, an old-school chat in the spirit of the early crypto communities, running outside the streaming platform's own comments. It gives the people in the FORKcast pools their own shared channel, so the banter, the calls, and the trash talk stay among everyone actually playing instead of getting lost in a creator's chat. A site-wide lobby handles general talk, and each stream gets its own room for whatever is on screen.

Resolution

In v1, a market is resolved by the participant who created it, which is not necessarily the streamer. The creator has a set window to resolve, backed by a full audit log and a dispute path. If they do not resolve in time, the market is automatically voided: every position is refunded and the creator forfeits the points they staked to open it. Once a market is resolved, the pool pays out and everyone moves on. Manual resolution with accountability is more honest than claiming an automated oracle we have not proven, and the roadmap adds AI-assisted and API-based resolution (game telemetry, video, audio transcription, time-stamped stream metadata) where it can be made reliable and auditable, starting with outcomes that have a clean machine-readable source.

AI-assisted market creation (live)

A market is only as good as the questions people put up, so we shipped an assistant that helps create them. On a streamer's page, a "Suggest Pools" action reads the current stream context and returns several ready-to-run market drafts, each with a proposed question, a set of outcomes, and a suggested timer. The streamer accepts, edits, or ignores them, and nothing goes live without that human step. The assistant only suggests. It never opens a market, never resolves one, and never pulls private player data from third-party game APIs, which keeps the system inside the same streamer-controlled, opt-in posture as the rest of FORKcast. It is built on Minds by Animoca Brands and labeled as such in the product. The same human-gated pattern is the model we intend to extend to resolution assistance over time.

For developers

The engine is exposed as a composable primitive other games and tools can build on. Aggregated, privacy-preserving prediction data can become a useful signal layer over time. We anchor market state on-chain by publishing hashes, not individual bet histories, so the system stays auditable without exposing participants. Market and epoch state is anchored hourly as Merkle roots on BNB Chain testnet today, with offline proofs anyone can check.

The first collection is Forked 444, forkhundred and forkty fork, a set of 444 one-of-one collectible characters called Forkies. They are chunky retro-voxel figures in the Forked.gg house style, each a distinct named character with no traits and no rarity tiers. A selection is shown below.

Flametongue #086

Chromalux #081

Lightbringer #015

Spark Wielder #178

Crystal Sovereign #190

Mystic Oracle #308

Starlight Conjurer #362

Solar Jewel #381

Crimson Virtuoso #206

Sky Ace #110

Kitsune Courier #341

Aeon Guard #388

Aurealis, the Radiant Jester #395

Symphonia, the Winged Idol #405

Void Admiral #419

A free mint for the community

Forked 444 is a free claim, one per wallet, open to active community members with a linked wallet, first come first served. There is no sale, no presale, and no cost beyond network fees. It is an origin badge for the people who showed up early.

No utility, on purpose

The Forkies have no planned utility of any kind. They are not tied to the token, the nodes, governance, or any reward, and they carry no promise of value. They are here for one reason: they are cool, and they give the community something real to own before any money is involved.

Next, once the audit clears

The independent audit is the single gate holding the largest block of finished work. Everything in this group follows it directly and in this order.

• Token. $FORK to mainnet with initial liquidity. The LIX conversion claim opens on its six-month vest. Service revenue begins recycling into open-market buys.
• Nodes. The license model live and the first licenses sold, which carry a second gate on top of the audit: none is offered or sold until the corporate entity is formed. Emission live on the earn-then-vest cycle. The workload registry under Aegis control. Paid workloads billed in credits with the discount for paying in $FORK.
• Governance. Aegis on mainnet, one node one vote, the grant pool funded, and the first proposals that decide something real.
• Marketplace. The genesis collection to mainnet, and secondary trading.

After that

• Nodes. The GPU tier opens: AI inference, transcoding, then render and pixel streaming. Behind-the-meter anchor capacity onboards across regions. Staking and slashing go network-wide across every bonded capability.
• Developers. The Game Integration SDK, the developer marketplace rails opened, and the first third-party games integrating through them.
• Players. The UGC content marketplace, and more streaming platforms behind FORKcast.
• FORKcast cash on-ramp. Only if counsel clears it, only where it clears it, and with identity verification and sanctions screening on every participant. This one may never open, and the product is designed so that it does not need to.
• DAO Launchpad. A first community revival carried the whole way, from confirmed rights to a running game.

The long run

The network runs primarily on real service revenue, with the base reward for uptime still underneath it, refilled by the activity it supports. Governance and treasury decisions move further toward operators and the community, and the DAO Launchpad takes on more titles. The measure of whether any of this worked is not the token price. It is whether games that would have died are still being played.

$LIX was the token of Helix Games, the earlier project this one picks up from. $FORK is a new token on a smaller, cleaner supply, and holders from that community are honored in full. The token generation event is gated on the corporate entity being formed, which is with counsel now and is expected to complete before the date below. If formation runs late, the event moves with it. The date is Wednesday 16 September 2026, and every $LIX figure here is measured or projected to that date. The table sets the two side by side: verified on-chain facts for $LIX, and the current proposal for $FORK. (Proposal for review.)

Fixed maximum supply: 1,000,000,000 $FORK, with no mint beyond the cap. Supply splits into two layers: the commitments we chose to honor to the Helix community, redenominated at a clean 50:1 and taken off the top, and a new economy designed underneath. Every figure below is pinned to the token generation event of 16 September 2026. (Proposal for review.)

No team allocation, and a public treasury

The team holds zero $FORK. Its only upside is equity in the operating company, so no team member is ever structurally a seller of the token. The company treasury is 5% and is earmarked for market making, liquidity, and exchange listings, nothing else. Company operations, salaries, audits and business development are funded out of the company's 23% fiat share of service revenue, not out of tokens. The company is owned by the team through equity, so we state plainly that there is an indirect line from treasury value to the team rather than imply the team touches nothing. Every token the company holds sits in a multi-signature wallet whose address is published, so anyone can watch it on-chain and see exactly when it is used and for what, and no single person can move those tokens alone.

None of the slices above are picked by feel. The honored Helix community (Layer A) comes off the top first, sized by real on-chain balances at the TGE date. The company treasury is then fixed at a deliberate 5%, and everything left over goes to the Emissions Reserve, because the reserve is what pays node operators and the operators are the point of the network. Here is that arithmetic in full.

Inside Layer A, line by line

The ~214M honored layer is itself fully itemized. Every line but one is a real on-chain $LIX balance divided by 50, projected to the 16 September 2026 token generation event. The node-reward line is capped at 151.2M $FORK, struck on end-September accrual rather than the event date so there is headroom if it slips. The pool is still accruing until then at roughly 18M $LIX a day, declining with the latent supply, which is why it is larger than the June snapshot. That rate is measured, not assumed: the pool held 5.869B on 23 June 2026 and the projection to TGE applies the observed daily accrual decaying at 0.15% a day. Re-read on 16 August 2026 the same contract held 6.817B against a predicted 6.823B, a difference of 0.09%.

† Six advisors contracted under Helix at 0.1% of supply each, held together in a single wallet of 300,000,000 $LIX, converting at 50:1. They are, by role rather than by name until their agreements with the new entity are executed: two game industry executives, two web3 industry executives, one platform lead and one capital-markets adviser. They vest over 36 months, monthly, with no cliff, on a schedule of their own rather than the six-month redemption vest. Patrick Bergman and Jason Brink are advisors to Forked.gg and receive no token allocation of any kind. ‡ Two early token purchasers. Their Helix agreements lapsed unexercised, the $LIX behind them never having been distributed, so nothing converts on this line. They hold new standalone Forked.gg agreements for the $FORK shown, vesting 10% at the event and the rest linearly over twelve months. The node-reward line is projected to the 16 September 2026 event and capped at 151.2M $FORK on end-September accrual, so the cap carries headroom.

The allocation table says where the supply is assigned. It does not say when any of it can move, and those are different questions. This is the release schedule for the first two years, generated from the same model as every other figure in this section. Months one to six are shown individually because that is where most of the movement is; after that, quarterly.

The 50M company treasury is deliberately excluded. It is market-making inventory that has to be placed as liquidity to do its job at all, so counting it as distributed supply would overstate what is actually loose in the market, and counting it as locked would understate it. It is disclosed separately and the wallet address is published before the token generation event.

The node-operator reward track that ran under Helix is fully accounted for on-chain. Every reward was earned by verified uptime and recorded in a public registry, so a holder can trace exactly what was earned, what has been paid, and what is still owed.

The chain of record

Each step is reproducible from public data, the on-chain uptime registry and the LIX token contract, with no need to take our word for any of it:

• On-chain uptime registry. Node uptime is committed as daily and hourly Merkle roots. We independently rebuilt all 2,201 roots from the underlying data, and every one matched with zero mismatches.
• Daily points. A node that stays up earns one point for that day, taken straight from those verified roots.
• LIX earned. Each day's operator emission, set by the published schedule, is divided across that day's points to give the LIX earned per node.
• On-chain payouts. LIX paid to operators is visible transfer by transfer from the reward contract.
• Owed. What is earned but not yet paid stays minted in the reward pool, waiting to be claimed.

Every claim on the previous page is checkable by anyone, because node uptime is committed to a public smart contract rather than asserted in a spreadsheet. The registry is the GlobalNodeUptimeMerkleRegistry on BNB Smart Chain, with verified source, at 0x4123933f0250b2966008878dccc00663444be746.

How a Merkle root proves uptime

For each period, every node's record becomes one leaf: a keccak256 hash of the node's network slug, its on-chain address, and its measured uptime in milliseconds, where a perfect day is 86,400,000. All of a period's leaves are combined pairwise up a Merkle tree, and the tree's single root hash is written on-chain alongside an IPFS link to the full underlying list. That root is a fingerprint of the entire set. Change any one node's uptime by a millisecond and its leaf changes, the root changes, and the on-chain commitment no longer matches the data.

What that lets anyone do

Anyone can pull the IPFS list, recompute every leaf, rebuild the tree, and check the root against the chain. A single operator can also prove their own record is included with a short Merkle proof, just the handful of sibling hashes along the path to the root, without needing the whole set. We ran the full check across every committed period, daily and hourly, and all 2,201 roots reproduced exactly from the public data, with zero mismatches, covering roughly 2.72 million verified node-hours. The reward math on the previous page is built on top of that verified record, so the whole chain from uptime to tokens owed is reproducible by an outsider end to end.

Customers buy node services, RPC, hosting, CDN, storage, AI inference, oracle settlement, render, and pay in fiat or stablecoin through ordinary rails. No one has to touch $FORK to buy a service. Each service dollar then splits four ways.

Each service payment splits four ways. 65% is owed to the people who ran the work, and it reaches them as $FORK. The company keeps 23% in fiat to run itself. 10% buys $FORK on the open market and goes back into the Emissions Reserve, the pool the base reward is paid from, so the company funds the operator floor out of its own revenue rather than only out of a fixed starting balance. 2% goes to the operator-controlled DAO in fiat, so the people running the network have an operating budget that does not depend on the token. Operators are paid entirely in token, never in cash, and the company never sells the token to fund itself. The buyer touches no token, the operator touches no cash.

The $FORK buffer, and why we sometimes buy less

Not every customer pays in dollars. Some settle in $FORK directly, and anyone buying network credits can pay for them in $FORK at a discount. Every token that arrives that way lands in a single buffer pool rather than being sold.

That pool is then the first place we look when operators need paying. If a fiat-paying customer generates an obligation to hand operators $FORK, we draw the buffer down to meet it and only go to the open market for whatever the buffer cannot cover. A large buffer never means the company sells; it means the company buys less. Tokens that came in from one customer go straight back out to the operators serving another, and the open-market purchase shrinks by exactly that much. It is the same pool on both sides, so $FORK spent on credits and $FORK spent on services are interchangeable once they land in it.

How the conversion price is set

The price used to turn each fiat payment into $FORK is produced by the Oracle network running on the nodes themselves, which independently pulls from many trading venues, discards outliers, and takes a stake-weighted median across the fleet. That node price is then cross-checked against two further oracles, CoinGecko and CoinMarketCap, which are independent of the node network and are used to validate its output rather than to compute it. If the fleet price diverges from those checks by more than 2%, the system stops and requires manual review before any settlement clears, rather than quietly failing over. This gate is a temporary safeguard for the network's first year and is expected to be retired once the oracle has a long enough clean record to stand on its own. A primary feed plus two independent validators means there is no single point of failure in how the token is priced.

Throughout this document “operators” means the node operators together with the DAO they control. They are one payee class, not two, and the DAO is not a company pool: it is governed one node, one vote through Aegis by the same people running the machines.

Operator pay flows through two channels that work together. The first is a base reward for being a live, healthy node, drawn from the Emissions Reserve on a declining schedule. That emission channel splits 90% to the node operators themselves and 10% to their DAO, so a tenth of every emitted token stays with the operator community to spend on itself through governance. The second channel is the workload reward: the recycled service revenue, paid in full to the operators who performed the verified work and weighted by the demand and cost of that work. The 90/10 applies to emissions only; service revenue passes through whole to the operators who earned it. A node has to be live to earn the base, and live to earn workload pay on top.

The base reward's job changes over time, and it does not end. Early on it carries most of operator pay, while the network is young and real revenue is thin. As service revenue grows the passthrough grows alongside it and becomes the larger share, so what falls away is an operator's dependence on the reserve rather than the base reward itself. The base stays because standing ready has a cost even in a quiet month, and a machine that earns only when a job happens to land is a machine that gets switched off.

Daily emission is a declining draw from the Emissions Reserve, split 90% to node operators and 10% to the DAO Grant Pool governed through Aegis. The company takes none of it. Operator pay has two independent sources and emission is only one of them. The baseline reward for uptime is fixed to the declining curve on the next page and does not move with revenue. The passthrough on real customer spend is paid on top of it and runs on its own track. Emission is never topped up or throttled to hit a target, and it is the baseline channel alone that carries the vesting friction. Nothing is ever minted beyond the cap.

Emission is denominated in $FORK and never in dollars. We will not promise an operator a fixed dollar amount per day, because doing that would quietly make us responsible for the token's price, and we are not. One $FORK is worth one $FORK; what that is worth in any other currency is signalled by a market, not by us. The gross draw is a small fraction of the remaining reserve each day, 0.088%, of which 90% reaches node operators, so the reserve releases on a smooth declining curve and never hits a cliff. Recycled service revenue is paid on top of that base, so operator income grows with real usage instead of depending on how fast the reserve is drawn down.

This rate is lower than the one Helix ran, and the difference does not come out of what node operators earn. It comes from taking the company out of the token. The company draws nothing from emission and is funded only by its portion of real service revenue, so every token released goes to node operators and the community grant pool, with none of it going to the company. What was removed is the company's claim on the token, not the operators' reward.

The reserve is not a closed tank, and this is the part worth being precise about. Four flows put tokens back into it: 65% of every license sale, 10% of every service dollar, stake slashed from an operator who broke something, and any unvested remainder forfeited by an early claim. So the reserve drains when the network is quiet and holds when it is busy. We think that is right in both directions. A subsidy that keeps paying for uptime nobody wants is a token hose. A subsidy that quits on operators while the network is working is a broken promise. The draw never reaches zero in any case, because a fixed percentage of a remaining balance only approaches it. More useful than that arithmetic is where the reserve settles once the flows above are running. Where it settles depends on how fast service demand grows, because that is what governs both how many licences release and what they sell for. The next page traces it. There is no last day of emission. Every figure in this section is stated in the unit it is actually denominated in: token amounts in tokens, dollar amounts in dollars. We do not convert between them anywhere in this document, because that conversion needs a token price and we do not have one to give you.

A fixed rate on a shrinking base falls every day, with no cliff and no governance vote needed to wind it down. The table below is the closed-tank floor: no license proceeds recycled, no buyback, no inflow of any kind. The four flows on the previous page all lift it above this line, by an amount that depends on what the token trades at. The floor is what we print, because the floor is what we can state without inventing a price.

Where it settles, and why we stop there

The table above is the floor and it is stated with no inflow at all: no license proceeds recycled, no company buyback, nothing coming back. It is the closed-tank case, and it is the only version of this curve that does not need a token price to draw.

What actually happens is better than that, because 75 cents of every service dollar buys $FORK on the open market and goes back into the reserve. How much supply those dollars retire depends on what the token trades at, which is not ours to say. A lower price retires more of it; a higher price retires less. We are not going to draw that curve, because every version of it we could draw would be a price forecast wearing a chart's clothing.

What reaches holders, and what buys it

Two quantities matter here and they are denominated in different things. We are going to give you both, and we are not going to combine them.

Reaching holders over five years, in tokens. Emission runs to 392M on the closed-tank floor, of which 353M goes to operators and 39M to the operator DAO. The honored Helix layer releases 214M, of which 202.9M clears inside six months; the advisor and SAFT lines carry the remaining 10.9M on their own longer schedules, running to months thirty-six and twelve. The community pool releases 245M over four years. That is 851M in total, about 85% of the 1,000M supply, reaching holders inside five years.

Buying it, in dollars. 75 cents of every service dollar buys $FORK on the open market: 65 cents passed through to the operators who did the work, and 10 cents the company buys back into the reserve. On top of that, 65% of any license proceeds do the same. On the fleet modelled in Section 6, over five years, that is roughly $9.4M of committed buying, and more if licenses sell.

Includes the honored layer at 80% sell-through and the community pool at 40%, which together account for 269M of every row and are the larger part of the sell side at any operator rate.

Base rewards are not minted the moment they are earned. While your node runs and stays healthy, its base rewards build up as an accumulated, unclaimed balance. Nothing reaches circulation until you decide to claim, which puts the timing in the operator's hands instead of dripping a constant stream onto the market.

The 30-day vest

When you claim, the accumulated balance begins a 30-day vest. Leave it for the full thirty days and the entire amount unlocks and is yours. You can take it sooner, but taking it early means receiving only the portion that has vested so far and surrendering the rest, which returns to the Emissions Reserve to be earned again by someone still working. Forfeited balances never reach the company, and the same rule covers early legacy claims and slashed stake. The closer to day 30 you wait, the more of the balance you keep, and waiting the full window keeps all of it.

Earning pauses while you vest

While a claim is vesting, the node keeps running but stops accumulating new base rewards. That share does not vanish. It goes to the operators who are still accruing, because each day's emission is divided across that day's active nodes. So the cost of claiming is relative rather than absolute, and it is worth being precise about which. If every operator claims on the same cadence, the vest costs nothing in tokens: everyone pauses for the same share of the year and everyone's slice grows while they are active. It bites when you claim faster than the people you are sharing the pool with. An operator claiming monthly against a field that claims annually earns roughly half what the patient operators earn. Every day spent vesting is a day not earning, and someone else is earning it.

Why the friction is there

This is deliberate. It is what stops the daily claim-and-sell cycle that drained most reward tokens straight onto the market in the projects that came before. Each operator picks their own cadence and weighs earning against access, which paces how fast rewards reach the market and keeps reliable nodes online through the wait. Workload rewards paid from real service revenue run on their own track and are not held by this cool-down, so paid service work keeps moving.

Legacy redemptions vest on a separate rule from operator rewards. Every redeemed balance, the node-reward pool and community wallets alike, unlocks linearly over the same six months. Anyone can emergency-claim early: they receive whatever has vested to that point and forfeit the entire unvested remainder, which recycles to the Emissions Reserve. The earmark stays at full par, so no one is shortchanged on value, only on the speed of a panic exit.

No insider view to exploit

A community member known as Free, in the Forked.gg Discord, asked a sharp question: when people claim and vest tokens, can someone with early sight of those numbers trade ahead of everyone else? The answer is that there is no private feed to trade on. Every claim and every vesting balance settles on-chain, so the amounts, the schedules, and the day-by-day unlocks are public to everyone at the same instant. No one at Forked.gg sees this data earlier or in more detail than the rest of the market.

A public read-only endpoint

To make that legible without digging through a block explorer, a public, key-free endpoint will return the same figures straight from the migration and vesting contracts. Exchanges, market makers, and any community member will be able to verify the numbers independently or build their own dashboards on top. It ships alongside the on-chain migration and vesting contracts, and the shape it will return is below. It is not live yet, and the address is published when it is.

Someone holds the keys. Pretending otherwise is how projects get robbed, so here is the arrangement stated plainly.

Every privileged key in this system sits behind a multi-signature wallet, and no single person can move anything. That covers the company treasury, the Emissions Reserve, the administrative functions on the conversion and vesting contracts, and any upgrade authority that exists on the token contracts. There is no personal wallet anywhere in that list.

What it can and cannot do

• It cannot mint. The one-billion cap is enforced in the contract itself, not by policy. No combination of signatures creates a token beyond it.
• It cannot take operator rewards. Earned balances settle to the operator who earned them; the multisig does not sit between an operator and their claim.
• It can move treasury tokens, which is the point of it, and every such movement is visible on-chain the moment it happens.
• It cannot pause the network. There is no emergency stop, no freeze switch, and no contract in the set exposes a pause function to the signers. Settlement either works or it is broken in the open, and we would rather explain a bug than hold a lever that could be used to halt operators mid-earning.

Addresses

The signer set, the threshold, and every wallet address are published before the token generation event, so anyone can watch them from the first day the token exists rather than trusting a description written months earlier. They are pending below because the entity that will hold them is still being formed with counsel, and we would rather print nothing than print an address that changes.

$FORK is the fuel, access key, and integrity bond of the ecosystem, never a passive-yield instrument. Every use below is consumptive, access-granting, or bonded. There is no "stake and the protocol prints you more" mechanic anywhere.

• Infrastructure settlement. Service revenue is recycled into $FORK and routed to operators for verified work. This is the fundamental demand anchor that rests the token on a real service business. Customers who pay in $FORK get a 10% discount on node services.
• Marketplace fees. Marketplace fees can be paid in $FORK at a discount, and a portion of what is paid cycles back to the Emissions Reserve. The discount rate and that portion are not yet set, and neither are the premium SDK tiers below. We would rather mark them undecided than print a number we would have to move. FORKcast is deliberately absent from this list: it runs on points only and no $FORK flows through it.
• SDK & Launchpad access. Premium SDK tiers and DAO activation are priced in $FORK, and what is spent cycles back to the Emissions Reserve rather than to the company. Node licenses are deliberately not on this list: they are priced in dollars and paid in stablecoins, with the split set out in Section 6.
• Integrity bonds. The stakes that activate oracle, settlement and the other critical workloads are slashable $FORK, set out in full in Section 6. They hold an operator accountable for work whose failure damages other people, and they lock tokens away for as long as the capability runs.
• Lock-for-access. Locking $FORK unlocks higher limits and reduced fees. It buys access and discounts only, never minted rewards.
• Buying credits. $FORK spent on network credits cannot be converted back into $FORK, cashed out, or moved between accounts. Those tokens are not destroyed, though: they land in the buffer pool and go back out to operators as payment for work. It is a one-way door for the customer and a supply of working capital for the network, rather than a sink. Section 6 sets out why that wall exists and why it is a property of the ledger rather than a policy.

Selling infrastructure that pays for itself

Node services are priced in ordinary money and set below the major clouds, so a buyer never has to hold a token to use the network. The first customers turned out to be closer to home than the plan assumed. They are community members buying credits to run their own game worlds, which is a smaller sale than a studio contract and a much faster one, and it produced paying usage before any enterprise conversation started. From there the ladder runs outward: the ecosystem's own products, then indie and web3 studios who need cheaper CDN, hosting, and RPC, then the games revived through the DAO Launchpad. The motion is land-and-expand, from one workload to several as an operator base proves it can deliver.

Community and ownership

The Forked 444 free mint is an origin badge that costs nothing and is gated to active community members, which gives people a real reason to show up and pulls Discord growth along with it. Participation programs reward genuine contribution rather than noise. And the Helix community, honored at the 50:1 ratio, is a group of people who already believe in this cause rather than one we have to buy.

Partnerships for reach and credibility

FORKcast already runs a live integration with Animoca Brands' Minds platform for AI market creation, which is both a product feature and a credibility signal. Further platform and brand partnerships are pursued the same way: each one has to bring real reach or real demand, not just a logo on a slide.

Phasing, tied to the roadmap

Grow users first on the cred-only beta, where there is no regulatory gate. Reward and widen the community with the genesis mint. Turn on service revenue with node licenses and paid workloads. Open a cash on-ramp only after counsel clears it. Bring third-party games in through the SDK and the developer marketplace, and make the DAO Launchpad revivals the flagship demand that shows the whole system working end to end.

What we hold ourselves to

Delivery is not demand, so we measure demand directly: weekly active FORKcast players and markets, paying node-service customers and monthly service revenue, and operator count and uptime. Service revenue is the number the token economy actually rests on, so it is the one we report against, rather than downloads or signups that look good and prove little.

• Unaudited contracts. No independent third-party audit of the $FORK contracts has been completed at the date of this draft. The contracts are deployed on a test network only. No mainnet deployment happens before an audit, and an audit reduces but never eliminates smart-contract risk.
• Technology and smart-contract risk. Bugs, exploits, and failures can cause loss. Audits reduce but do not eliminate this.
• User-uploaded content. Several live products accept files from users: uploaded browser games, uploaded media, and community forums. Material that infringes copyright, breaks a platform rule, or is otherwise unlawful can be uploaded despite moderation. We operate a takedown process, and the network is designed so that operators serving a file cannot read it, which is good for privacy and means a node operator is not in a position to police content themselves. The legal treatment of that arrangement differs by jurisdiction and is under review.
• Third-party game licensing. The hosted game-server product runs binaries published by other studios. Whether a given title's license permits hosting it commercially on behalf of a customer varies title by title, and a change of terms or an objection from a publisher could require us to stop offering a specific game.
• Key-person and execution risk. The project depends on its team and may not deliver the roadmap on time or at all.
• Third-party and integration risk. Some described capabilities depend on third-party platforms and partnerships that may change.
• Intellectual-property risk. Any game revival depends on rights that must be confirmed in writing first. Until they are, a title is read-only evidence and not a claim of ownership.
• Liquidity and market risk. Assets may be illiquid or volatile.