Hi everyone,
I’ve been working on UTXOPlay over the weekend, and the alpha is now live at utxoplay.io.
There are currently 13 games listed. It’s still early, and there’s plenty to improve, but I’d love for people to try it and share what works, what breaks, and what feels missing.
I also wanted to put the broader idea in writing: how the platform is structured, how it could bring together technology from across the Nervos community, and how we could work toward community-driven development and DAO governance.
The Nervos community has built a lot of useful technology. UTXOPlay is an attempt to bring some of that work together in something people can play.
Games give us practical problems to solve. A login, a match, a purchase, or an earned item raises questions about identity, execution, verification, payments, and ownership. Players also give us honest feedback. If a game takes too long to load or the controls feel wrong, they leave.
I hope this can become a place where developers try their tools in real applications, learn from players, and contribute integrations that others can reuse.
Community-driven, from the beginning
I’d like participation to extend beyond writing game code. Playtesting, artwork, music, translation, documentation, and maintaining shared infrastructure all matter.
Player feedback should influence development priorities. Creators should be able to bring their own games. People working on ecosystem tools should have a place to test whether those tools are useful and approachable in practice.
That also means giving contributors room to work independently. The platform architecture reflects this:
- UTXOPlay handles shared platform services: discovery, accounts and wallet connections, game libraries, creator publishing, and community features.
- Each game owns its implementation: rules, rendering, state, runtime, and game-specific services.
The current source separates the store and games into independent repositories. Games can be built and deployed separately and can run without the store. The code is available in the UTXOPlay repository.
A creator should be able to use the platform’s common services while continuing to maintain their own game. Platform development and game development can then move at their own pace.
Myelin first, Fiber next
The first batch of games is Myelin-based.
In UTXOPlay today, Myelin supports off-chain execution, signed records, and replay verification. The aim is to retain a game’s execution history so it can be checked against the exact rules and application profile under which it ran.
There is a boundary worth making explicit: a verified Myelin replay is not a CKB settlement receipt. The current games still have trust assumptions around their hosts and signing authorities. On-chain payments, asset issuance, and transfers require separate integration and verification.
Game updates also need to preserve the meaning of existing records. Old saves and signed sessions should remain bound to their original rules; an update should not silently reinterpret them.
Starting with Myelin lets us work on these foundations through actual games.
We plan to support Fiber-based games as the relevant support and tooling mature. In our earlier community discussion, I mentioned user onboarding, bootstrapping, and LSP support as areas to work through for this direction. Those integration questions will help determine when and how we introduce it.
Fiber opens up possibilities around channel payments and frequent, small transactions. We could explore pay-per-session experiences, payments between players, or games designed around those interactions. The specific design should follow the game and what we can reliably support.
Myelin and Fiber could also be used together: a game might need replayable execution records alongside channel payments. Payment support still leaves game-specific questions about result verification, interrupted sessions, and disputes to resolve.
This is how I’d like to approach ecosystem integration more generally. Wallet connectivity already uses CCC. Where there is a useful collectible, cosmetic, or achievement use case, we could explore Spore and DOB as well. Each integration should make something better for a player or developer.
Two questions from truth that deserve proper answers
In our recent community conversation, truth raised two questions that get to the heart of how a platform like this should work: how publishers and vendors are governed, and whether games can involve staking or winner-takes-all mechanics.
These deserve a place in the design from the start.
Who develops a game, who publishes it, and who is accountable?
truth also asked whether the developer and publisher would always be the same person.
For many small games, they will be. Developers can self-publish. But I’d like UTXOPlay to support third-party publishers too, so the roles should remain distinct.
Teeworlds is a useful example: I’m operating and publishing it on UTXOPlay, while the original game was developed by other people. A listing should make that distinction clear and preserve proper credit. It should also identify who is responsible for the hosted service, support, and any commercial commitments.
truth suggested exploring Vellum as a way to give publishers and vendors evidence-backed reputations based on delivery history, player complaints, and dispute outcomes. I think that is worth investigating as a possible future integration.
For that to be useful, we also need a way to challenge inaccurate claims. A complaint, a documented incident, and a resolved dispute should be distinguishable. Publishers need an opportunity to respond, and players need a credible path to raise problems.
A starting proposal would be to make the basis of reputation claims visible, allow supporting evidence and responses, record dispute outcomes, and provide a way to correct or appeal decisions. We would also need rules for conflicts of interest among reviewers.
Those records could inform listings and recommendations. The community would still need to decide how evidence is assessed and what consequences follow. A reputation system should be something people can question and inspect.
Can players stake funds, or play winner-takes-all games?
My proposal is that the store itself should not directly provide staking or winner-takes-all mechanics. Individual games could propose their own models, with clear responsibilities and an appropriate listing review.
truth pointed out the immediate risk: a malicious publisher could steal players’ staked funds. That concern remains even if the mechanic belongs to an individual game.
For any game involving funds at risk, players should be able to understand who controls the funds, what determines a payout, how the result is verified, and what happens if the host disappears or a dispute arises. A listing or a good reputation score cannot, by itself, establish that a game’s fund-handling design is safe.
I suggested light-touch screening for scams, exploitative mechanics, and ethical or regulatory concerns. Games asking players to put funds at risk would need closer scrutiny than a free arcade game. The criteria and the reasons behind listing decisions should be public and open to challenge.
The exact policy needs community discussion. For now, the boundary I’m proposing is that game creators are responsible for their game’s mechanics and fund-handling design, while UTXOPlay remains responsible for its listing standards, disclosures, and response to reported harm.
Working toward DAO governance
I’ve also been thinking about forming a UTXOPlay DAO to coordinate development and governance, bringing together contributors from different parts of the CKB ecosystem.
This is a direction to build toward. The governance mechanisms still need to be worked out together.
I’d start by identifying which decisions should become shared:
- Public funding: Which games, tools, and infrastructure should receive support, if a shared budget is established? How are spending and delivery reported?
- Platform policy: How are listing standards, revenue sharing, recommendations, publisher reputation, and disputes handled?
- Maintainer authority: Who runs day-to-day operations? How are permissions granted and revoked? What can maintainers do in an emergency?
- Accountability: Who carries out an approved proposal, when is it due, and how is the outcome reviewed?
A practical starting process could be: publish a proposal, discuss it, reach a decision, assign responsibility, and report the result. Voting rules, treasury controls, and delegation can develop as participation and shared resources grow.
Maintainers need room to fix bugs and keep services running. Changes to public spending, platform rules, and significant permissions need a clear community process. Emergency actions should have defined limits and a record that can be reviewed afterward.
Voting eligibility, voting weight, quorum, appeals, and conflicts of interest are all questions we should address explicitly.
For me, community-driven and DAO-governed should eventually be visible in everyday practice: people can contribute, their work is taken seriously, decisions have a public rationale, and the people carrying them out report what happened.
Come try it and help shape it
The immediate priority is to improve the alpha: make the games more enjoyable, make integration easier for developers, and explain clearly what the execution, verification, and payment systems each guarantee.
Alongside that work, I’d like us to develop the publishing and governance framework in the open. The questions truth raised are a good place to begin.
Please try UTXOPlay and share your thoughts here. I’d especially like to hear:
- What games would you like to play or build?
- Which community tools would be useful to integrate?
- What evidence would help you assess a publisher or game operator?
- What listing requirements should apply to games involving player funds?
- Which decisions should move to community governance first?
Working alpha demo: https://store.utxoplay.io/
Github Repo: GitHub - UTXOPlay/UTXOPlay: UTXOPlay game store: CKB wallet login, four playable games, Myelin replay integration and developer tools. · GitHub
TG Group :Telegram: Join Group Chat