Libplanet puts a blockchain inside your game process, not beside it

Game state moves into the client process

The usual architecture for a multiplayer game has a server holding the authoritative state, and clients sending it requests. Libplanet attacks that arrangement. The project describes itself as a .NET library for creating multiplayer online games in a decentralized fashion, which it defines as the whole gameplay occurring on a peer-to-peer network among equal nodes rather than an authorized central server. The library is a dependency inside your game, not a service you run.

That framing decides who should care. A studio that already operates a backend and wants to keep it has no reason to replace it with peer-to-peer consensus, and Libplanet will not be a drop-in backend. A studio that wants a game with no operator, where the players' machines are the network, has no off-the-shelf alternative in C# and would otherwise be assembling a blockchain from components.

The repository layout reflects that it is a product library first. The root holds `Libplanet.sln`, `Directory.Build.props`, a `global.json` pinning the SDK, plus `src/`, `test/`, `sdk/`, `tools/`, `scripts/`, `changes/` and a `CHANGES.md` changelog. There is also a `Dockerfile.explorer`, which points at a separate Explorer component, and ruleset files that suggest style enforcement is part of the build culture.

BFT consensus and data replication underneath the game loop

The README states the mechanism at a high level: under the hood, Libplanet incorporates many features of a blockchain, naming digital signature, BFT consensus and data replication. Byzantine fault tolerance is the part that matters for a game, because it is the reason the network can keep a shared state without trusting a majority of its own players.

The data flow implied by that design is the standard one for a replicated state machine. Each node runs game logic locally, produces actions, and those actions are ordered and committed so that every honest node ends up with the same state. The digital signature piece lets the network attribute an action to a specific account, and replication keeps copies of that state on every node rather than on one machine. None of the individual pieces is described in detail in the README, so the cryptographic parameters, the block format and the finality guarantees are not documented there.

For a reader, the honest summary is that this is a general purpose blockchain substrate, and the game specific work happens in the game code. The library does not define how your game scores a match, and it does not define what a player owns beyond what you model in state. A Unity game that puts a card in a state, and a server authoritative game that keeps that card in a database, are making the same modelling decision. Libplanet changes who is allowed to write the state, not how the state is described.

The SQLite comparison, taken literally

The README makes three claims about its advantages over other decentralized gaming solutions, and the first is the most telling. Libplanet is embeddable: a game app does not have to communicate with another running process, so it needs no extra marshaling and no process management. The comparison the project draws is to SQLite rather than to MySQL or PostgreSQL.

That parallel is doing real work. SQLite is embedded in the process, has no daemon, and a distributed version of the problem is solved by replication rather than by a server. Libplanet applies the same shape to game state, except that replication is consensus based, and the equality of nodes replaces the client and server split. The difference from MySQL is the one that matters for planning: there is no separate thing to deploy, secure, monitor or pay for, and there is also no single place where an operator can look to see what the whole network thinks.

The second claim is that Libplanet is isomorphic. It is a .NET library, so game logic is written in the same language, C#, and runs on the blockchain, with no glue code and no smart contracts. The third is token independence. Unlike almost every blockchain system, the documentation says, it does not force users to create and deal with yet another cryptocurrency, and a game can be free to play by regular gamers. For a consumer game that is arguably the feature that decides the architecture, because it removes the question of what a player is paying with.

Adding the package to a C# project

Libplanet ships to NuGet for every stable release, as a .nupkg uploaded both to NuGet and to the GitHub releases page, with the changelog on the releases page. Adding it to a project needs one command. In Visual Studio the documentation uses the Package Manager Console:

`Install-Package Libplanet`

If you prefer the dotnet CLI, the documented command is:

dotnet add package Libplanet

Pre-release packages are published on a much tighter schedule than the stable ones. For every merge commit and for every day, a .nupkg is packed and uploaded with a hyphen suffixed version name. A merge commit build looks like `0.1.0-dev.20181231235959+a0b1c2d`, where the digits are a UTC timestamp of the build and the suffix is the first seven hexadecimals of the Git commit hash, and a daily build looks like `0.1.0-nightly.20181231+a0b1c2d`. That versioning scheme tells you something about the release process, and it also means you can pin an exact build if a nightly is what you tested.

The README does not include a first run sample. There is no snippet showing a node starting, a block being mined or an action being signed, so the first real use is not a copy and paste exercise. The documentation points to docs.libplanet.io for that, and the repository ships a `Docs/` folder alongside `sdk/` and `src/`.

Unity users still have to unpack the DLL by hand

This is the sharpest limitation in the project, and the README does not soften it. Unity does not currently support NuGet. The documentation notes that there are Unity plug-ins to work around the package system and that they seem immature at present, and it tells you that using Libplanet on Unity requires manually extracting `Libplanet.dll` from the `Libplanet.*.nupkg` file and placing it inside your Unity project.

The wording is unusually direct. The authors acknowledge that Libplanet is currently not very usable together with Unity, and promise to make it better in the next few minor releases. The suggested workaround at the time of writing is MSBuildForUnity, described as experimental as of January 2020. A manual DLL drop also means the version you ship is the version you happened to extract, so upgrades become a manual step, and there is no package restore to remind you that something is out of date.

That matters because Unity is where a lot of game development happens, and the repository topics list includes unity and unity3d. The library targets .NET and C#, but the pipeline a Unity team would want, restore, build and test, is exactly the part the documentation concedes is missing.

Building the solution and the yarn workspaces behind it

Building the library from source needs the dotnet command, which the documentation notes is distributed with the .NET Core SDK. One command installs the dependencies and builds the whole solution:

dotnet build

That produces `Libplanet.dll` and `Libplanet.Stun.dll`, the second being a separate assembly for STUN. Contributors are pointed at CONTRIBUTING.md, and the root also holds RELEASE.md, a `hooks/` folder, a `.circleci/` pipeline directory and a `codecov.yml`, so continuous integration and coverage measurement are part of the workflow.

The JavaScript side is worth understanding because it explains the shape of the repository. The root `package.json` is a yarn 4 workspace root that includes the TypeScript packages for accounts, transactions and the tools directory:

  "packageManager": "[email protected]",
  "private": true,
  "workspaces": [
    "@planetarium/account",
    "@planetarium/account-aws-kms",
    "@planetarium/account-web3-secret-storage",
    "@planetarium/tx",
    "tools/Libplanet.Tools"
  ],

The build script in that file carries a warning that `yarn build` is expected to fail on the first run and succeed on the second, because of an unknown issue unrelated to the codebase, tracked as issue #3492, so the build phase runs twice. The same file forbids packing at the project root because it produces an empty package, and points to `yarn pack-all` instead. So the repository is a .NET library with a parallel TypeScript toolchain, and a fresh contributor's first build is expected to fail once by design.

LGPL-2.1 and a release trail that goes quiet after 2025

Libplanet is licensed under LGPL-2.1, which is the licence question to settle before you build a game around it. A weakly copyleft library licence is a common choice for a component that wants to be embedded in closed source applications, but the obligations that come with it are a matter for your own counsel, and the repository's README does not discuss licence obligations for game developers at all. What it does say is that the project wants game logic in the same language and run on the blockchain, with no glue code, which is an architectural statement rather than a licence grant.

The release trail is the other thing to weigh. The versions listed here are 5.5.2 on 2025-09-16, 5.5.3 on 2025-09-17 and a pre-release, 5.5.0-test.2, on 2025-09-03. The last push to the repository was on 2026-10-20, and the project is not marked as archived, so work is still landing. But the tagged releases in this window all sit in September 2025, and anyone planning around a stable NuGet version should confirm for themselves which 5.x tag is the one their game is validated against, rather than assuming the newest published tag matches the current source.

Editorial conclusion

Libplanet fits a team building a C# multiplayer game that wants peer-to-peer authority and has no tolerance for running a central server, and it does not fit a Unity project that expects a normal package manager or a team that wants blockchain features without taking on LGPL-2.1 obligations. Before you commit, read the Unity section of the README yourself: it states that Libplanet is currently not very usable together with Unity, and it still asks you to extract Libplanet.dll by hand from the .nupkg file.

Frequently asked questions

Official sources

1. License: LGPL-2.1
2. planetarium/libplanet on GitHub
3. Project website
4. README
5. Releases