Ship the game. We’ll carry the bandwidth.
Most platforms offer independent studios another blockchain library. Studios do not need one — there are dozens. What ArcadeUnion proposes instead is a distribution network that serves your build, and people who will sit down and do the integration with you.
Your bandwidth bill, mostly gone.
A game is not a web page. It is a large binary downloaded once per player, and again on every patch. For a small studio that is a real line item — and a reason to ship through a store that takes 30% instead.
| Build | Reach | Traffic | At cloud egress |
|---|---|---|---|
| Small 2D / web | 10,000 players | 3 TB | ~$270 |
| Mid-size Unity | 100,000 players | 195 TB | ~$18,000 |
| Larger 3D title | 100,000 players | 781 TB | ~$70,000 |
Illustrative figures from a published model, not a quotation.
What the network absorbs
Pieces of your build are spread across many machines, with several copies of each. Modelled at sixteen copies and machines online around three hours a day, the network answers roughly 88% of requests without touching your servers. The rest falls back to your origin automatically.
It does not have to be perfect to be worth having. Absorbing most of the traffic turns an eighteen-thousand-dollar bill into something closer to two.
Who pays for it
Node operators are paid in $ARCU from token emission — not by you. So the bandwidth is subsidised by issuance rather than being free by magic, and that is worth saying plainly.
It is also the one thing a larger platform cannot copy cheaply: a distribution network whose operators are paid by the protocol rather than by the studio.
People, not just a library.
What a three-person studio lacks is not a library. It is someone on the team who wants to spend six months learning this. Publishing another SDK does not fix that; sitting down and doing the integration does.
Worked examples, not documentation
A real, running example of the whole integration that you can read and copy, rather than a documentation site describing one. It is kept honest by the same automated tests that check the network itself — if the example stops working, the build fails.
Office hours
An hour to look at what you are planning and point you at the right approach. Most of the expensive mistakes in this area are made in the first week, and an hour early is worth a fortnight later.
Hands-on integration
Doing the work with a studio, on a stated number of projects at a time, chosen openly. Rationed because it has to be: this is people-time, and it costs the same for every studio.
Templates, once they are earned
Whatever turns out to be identical across the first few integrations becomes tooling. Not before — building a library for something nobody has integrated by hand is how you end up with forty functions nobody calls.
People who already care.
After money, the thing that sinks a good indie game is that nobody knows it exists. A studio can build something excellent and ship it into complete silence. That problem is rarely on anyone’s list of what a launchpad provides, and it may be the most useful thing here.
What there is to share
- Node operators already running infrastructure for these games
- People holding $ARCU, who have a reason to want games to succeed
- Players who arrive through one game and find the others
- Somewhere to be seen while you are still building, not only on launch day
What that is worth
Early testers who will actually report bugs. A first hundred players who are not strangers. People who turn up on day one because they watched it being made.
None of that is a marketing budget and it is not a substitute for one. It is the difference between launching to nobody and launching to somebody.
What exists today.
One method. It fetches your files through the network, verifies them, falls back to your origin when it has to, and signs for what the operators delivered.
What it does
- Downloads your published assets through node operators
- Verifies every file against a published digest before handing it over, so a bad node cannot poison a download
- Falls back to your origin with no code from you
- Splits builds into content-addressed pieces, so a patch moves only what changed
- Runs leaderboards and prize seasons in any token, paying as many places as you choose
- Records what your game vouches for, so players arrive carrying a history other studios signed
What it does not ask for
- No wallet — it generates a throwaway key for delivery receipts
- No tokens anywhere in the download path
- No accounts, and nothing to sign up to
- No trust in us: the verification is yours, against a digest you can check
Leaderboards, included
Competition is the part of a game most worth rewarding and the most tedious to build properly — ranking, tie-breaks, prize splits, claims and an audit trail nobody can quietly edit. It ships with GameKit: your server signs a score, and the rest is handled.
What each place is worth is fixed before anyone plays, and every entry behind a result is published so the ranking can be rebuilt by anyone. The same machinery records anything else your game vouches for, building each player a history that follows them to the next game on the network. How leaderboards work →
The part everyone asks for first.
It also carries all of the risk, so it is the last thing being built rather than the first. Here is the current thinking, published while it is still thinking rather than presented as a finished product.
What a small game actually costs now
The old assumption — that a game means years and a large team — is out of date. Small teams with AI assistance ship far faster, and the budget follows:
| Team | Rough cost |
|---|---|
| One developer, six months | ~£32,000 |
| Two developers, eight months | ~£72,000 |
| Three developers, a year | ~£164,000 |
Illustrative only. The point is the order of magnitude: a community raise at a realistic size can genuinely fund a small game, which was not true when a build meant three years and five salaries.
The shape being considered
Backers hold $ARCU and use it to support a game, which gives the token a job that is not speculation about itself. Two conditions that would not be negotiable:
- The money reaches the studio. Several well-known launch mechanisms accumulate the raise into a trading pool rather than handing it to the developer. That funds a market, not a game.
- Release is tied to delivery. Funds held and released against milestones that are published and checkable, so backers support the next step rather than a promise.
Advice we would give any studio
Build a game that works without any of this. Playable without a wallet, earning money the ordinary way, with ownership and rewards as a bonus for the people who want them.
A game that needs its token to function gets judged as a crypto product rather than as a game. And a studio that does not need a token to pay the bills is in the only position from which issuing one is a good idea.
What we would take on, and what we would not.
Studios ask for these constantly. Three of them could be built on what already exists, in a narrower form than the name suggests — and the narrowing is the honest part, not a hedge. None of those three is built today. The rest are not ours at any scale.
Relay, not game servers
An authoritative server decides who was hit, who won and what a player now owns. Whoever runs it can simply lie — and node operators are paid from the same treasury that would fund a prize pool. That is not a job to hand to strangers, and no amount of engineering makes it one.
A relay is a different job. It forwards encrypted packets between players and reads none of them: it cannot see the traffic, forge a move or award a win, and it signs for the bytes it carried using the receipts downloads already use. Around a fifth of peer-to-peer sessions cannot connect directly and need somebody in the middle, and some studios relay every session to keep players’ addresses private.
A marketplace, not a storefront
Selling the game itself is a compliance business rather than a technical one, and it is not this one — sales tax and age ratings apply wherever you sell, whatever the payment rail. Paying in stablecoin removes the card processing and the chargebacks; it does not remove the obligations.
Trading items and assets is far narrower: no fiat, no refunds, and royalties enforced by a contract instead of by an agreement someone has to honour. That is what the planned marketplace is for, and it is a different thing from a shop that sells you the game.
Matchmaking, perhaps
Closer than it first appears, because finding a match is not latency-critical the way playing one is — a second spent searching costs nothing, where a second of lag ruins the match.
The coordinator already ranks players to settle leaderboards, which is most of what skill-based matchmaking needs. What it does not yet answer is how to keep automated accounts from being matched against people, and that question would want answering before the rest is worth building.
Not ours, at any scale
No narrower version of these becomes possible later. They are on this list because of what they are, not because of where the project has got to.
Everything above is subject to legal and regulatory requirements that have not been worked through, and none of it is what stops a small studio shipping — which is why none of it comes before getting a build to players.
How a game would move through.
An intended process, described so developers can see what would be expected of them and at what point.
Curated, not a factory
ArcadeUnion is not intended to launch everything that is submitted. Projects would be reviewed against technical, community, security and quality requirements before being accepted, and acceptance would never be automatic.
A permissionless token factory is a different product with different incentives. This one is meant to be a place where being listed means something, which only works if some projects are turned down.
What review would look at
Nothing here is finalised, but the intended criteria are the obvious ones: is there a real game, is the team able to build it, is there a genuine reason for any token or asset involved, and has the code been through security review.
Criteria would be published before any application process opened, so developers know what they are being judged against rather than finding out afterwards.
Where the node network could go.
A longer-term direction, described honestly as a design rather than a plan with dates. None of the architecture below is operational.
Run
A technically capable licence holder may operate infrastructure or validator services directly, and could potentially accept delegated participation from others.
This is the route for people who are comfortable running servers and want to be hands-on with the network.
Delegate
A licence holder without the time or inclination to run infrastructure may eventually be able to delegate participation to an eligible operator instead of maintaining servers themselves.
The intention is that holding a licence should not require becoming a systems administrator.
Built first, handed over gradually.
Decentralisation that is announced on day one is usually theatre. The intended approach is to build something that works, then widen participation in it as there is genuinely something to participate in.
A core development company builds the infrastructure, the tooling and the first games. Decisions are made by the people doing the work.
Network participation and ecosystem ownership broaden as node operators, developers and players join.
Governance capabilities progressively move toward community control where that is appropriate and workable.
Community governance and treasury mechanisms become increasingly active in directing the ecosystem.
Ecosystem treasury
The intention is a transparent multi-signature ecosystem treasury, with its address published before it holds anything and its movements checkable on-chain like everything else ArcadeUnion does.
Where platform or network fees exist in future, they could support ecosystem development, network infrastructure, the community treasury and protocol incentives.
No fee percentages are published, because none have been decided. When they are, they will be published before they take effect.
What this is not
The treasury is not a revenue-sharing scheme. Nothing on this page offers or implies passive income, yield, APY, dividends or any distribution of revenue to holders of anything.
Node rewards follow published rules that tighten in stages: an initial period where holding a licence is enough, then verified operation, then verified work. Each stage is published before it begins.
That is a distribution schedule attached to a licence, not a share of revenue. It carries no promise that the tokens distributed will be worth anything.
Got a game worth building?
ArcadeUnion is being built for the developers who have the idea, the talent and the determination — but not necessarily the funding, the audience or a blockchain team.