# LayerX Network: deterministic execution for autonomous agents

> LayerX Network is a Sidiora Labs monorepo where every state change enters as a signed Activity, is ordered on a single global sequence, and returns a receipt tied to a state root, with determinism enforced in the compiler and the append-only activity log treated as the sole authority over a set of rebuildable indexes.

**Sidiora-Labs/LayerX-Network** — LayerX Network is a deterministic execution and accounting network for autonomous agents.

- Repository: https://github.com/Sidiora-Labs/LayerX-Network
- Website: https://layerxnet.ai
- Stars: 574 · Forks: 90
- Language: Go
- License: Apache-2.0
- Published: 2026-09-10 · Updated: 2026-09-10 · Language: en
- Canonical page: https://hysenlabs.com/projects/sidiora-labs-layerx-network

## Every state change is a signed Activity with a receipt

The unit of work is an Activity: a signed, canonically encoded record, and every operation that changes state arrives in that form. From there the protocol does five things in a fixed order. It verifies the actor and that actor's authority. It consumes the account sequence, which is what stops one actor from forking its own history. It orders the activity onto a single global sequence shared by everything in the network. It applies a deterministic state transition. And it returns a signed receipt tied to the resulting state root. That last step is the part with real consequences for anyone building on top, because a receipt is not a log line, it is a signed statement that this transition produced this root. Two parties can therefore disagree about what happened and compare receipts rather than trusting each other's database. The naming also carries a wrinkle worth noticing up front: the repository is named for LayerX while the readme titles the system Paxeer X Network, and the two are not the same layer.

## The activity log is the authority, indexes are disposable

The data architecture is built around a single claim: the append-only activity log is the authority, and everything else is a derived view. Database indexes are described as disposable projections that can be rebuilt by replaying that log. That framing has an obvious benefit, which is that a corrupted or stale index is a recoverable inconvenience rather than a loss of truth, but it also sets a discipline, because it means no component is permitted to treat a query result as authoritative. The balance rule enforces the same idea from the other direction. A single component, named 402LXP, is the only one permitted to write balances, and protocol modules are required to emit validated transfer sets rather than mutating funds themselves. So the path from a decision to a movement of value is separated from the path that makes the decision, which is what lets the execution layer be replayed and audited without granting it the ability to lose money on its own.

## Determinism is enforced by the compiler

The stated design excludes floating point, local clock decisions, and database iteration order from consensus-critical execution. What is striking is that this is not left to code review discipline but pushed into build flags. The runtime compiles as C17 in pedantic mode, with warnings promoted to errors and a set of extra warnings enabled for conversions, shadowing, and variable length arrays. Strict aliasing is turned off, and so is floating-point contraction, which is what stops the compiler from fusing multiply-add operations into something with different rounding than the source implied. On the common architectures the target is further restricted to general-purpose registers only, keeping vector and floating-point units out of consensus code. Source file ordering for the build is pinned by sorting with the C locale rather than whatever the developer's environment produces. The effect is that a consensus bug caused by undefined or environment-dependent behaviour becomes a build failure rather than a fork.

## LayerX executes, Paxeer settles

The two names in the readme title are two layers with different jobs, and the split is the architecture. Ordinary agent activity is executed and ordered inside LayerX, which is the hot path. Periodic checkpoints settle to Paxeer, and Paxeer is where the slower, heavier machinery lives: custody, checkpoint registration, guarantor bonds, challenges, withdrawals, disputes, and emergency exits. The consequence worth holding onto is that an ordinary LayerX action does not require a Paxeer transaction. So the common case, an agent paying for something, does not pay the latency or the governance cost of the settlement layer, while the exceptional cases, a disputed withdrawal or an emergency exit, are handled by the component that holds the funds. This is why the monorepo keeps both together despite the layering, on the argument that co-locating the protocol, the settlement network, the contracts, and the developer surfaces keeps them auditable in one place, with each subsystem still keeping its own build, release, deployment, and trust boundary.

## The wallet and token command lines are not here yet

There is an unusually blunt admission in the documentation about what is missing, and it is worth reading before planning an integration. Native Asset issuance, the public JSON-RPC post endpoint, and the payment-required commitment extras are all served by this tree. However, the wallet and token command lines, and the LXT-20 program token interface, are explicitly not in it yet. Everything around the edges is documented in depth regardless: an encodings page, an RPC methods page, a page on evidence levels, a payments quickstart covering wallet, faucet, assets, programs, and the payment-required path, and what is described as an exact real-process transcript of the public payment flow. So the reference material is thorough and the surface area is partial. For an integrator that means you can read your way to a correct understanding of the protocol now and expect to assemble the final tooling later, rather than discovering gaps after committing to a design.

## Five toolchains and a cross-compilation matrix

The build surface is broad enough to be the first thing a contributor evaluates. The core protocol runtime is C17. The agent, human, and platform workspaces are Rust, pinned by a toolchain file to a specific release. The LayerX settlement contracts are Solidity at a pinned compiler version. The Paxeer node side is Go on a pinned language version, and it is a substantial dependency list spanning a virtual machine implementation, a consensus proof library, keyring support, storage engines, RPC and gRPC plumbing, and profiling. Alongside that sit TypeScript workspaces for the agent software development kit, several middleware roles that look like seller, buyer, merchant, and agent, framework integrations, and payment examples. Replay qualification raises the bar further: it needs a specific pair of compiler versions, a container runtime, a musl target runner, and an AArch64 cross-compiler with an emulator on top. The everyday commands are short, but the qualification matrix is what tells you whether a result is trustworthy.

## A local pass is not deployment authorization

The build entry points are deliberately few, and the CI target is doing more than running tests:

```sh
make build
make test
make test-contracts
make ci
```

The continuous integration target is described as running a public audit, native tests, a two-build archive comparison, consensus symbol checks, and sanitizer suites. The two-build comparison is the interesting one for a deterministic system, because building twice and comparing the results is a direct empirical test of the property being claimed. A separate cross-subsystem gate exists for the whole monorepo, distinct from the subsystem-level CI, and the bounded Paxeer targets can be invoked without changing directories. Underneath all of it sits a warning that deserves to be quoted rather than paraphrased: a local pass is not authorization to deploy contracts, move custody, or handle real assets. The repository also carries configuration for a striking number of coding agents alongside its linters and changelog tooling, which tells you something about the workflow the maintainers expect.

## The root directory is mostly tooling for other tools

One thing the top-level file listing makes obvious is how much of this repository exists to support other people's tools. Alongside the expected pieces, a linter configuration, a pre-commit setup, a YAML lint config, a markdown lint config, a changelog generator config, a code coverage config, and protobuf buffer definitions, the root carries configuration directories for a long list of coding agents alongside their instruction files. That is an unusual amount of surface for a systems repository, and it says two things at once: the project expects contributors to arrive through assistants, and it is maintaining those paths as first-class rather than leaving them to chance. There are also directories whose names point at scope beyond the protocol itself, including a custody proof area, a bridge, an engine, a benchmark suite, and an API surface. Governance, conduct, security, and citation files sit next to the code rather than in a separate community repository. One entry resists categorising: a specification file named for traps, using the same KVX extension as the normative specs under the spec directory, which given this project's emphasis on unexpected behaviour reads as a deliberate marker rather than an oversight.

## Conclusion

LayerX Network suits a team building agent payments who needs a replayable audit trail and a receipt that binds an action to a specific state root, since those two properties are the whole point of the design and are hard to retrofit. It is a poor fit if you need the wallet tooling today, because the wallet and token command lines are stated as not yet present, and a poor fit if you want a single-language codebase, since five toolchains and a cross-compilation matrix sit between you and a local test run. Before building, read the qualification requirements rather than assuming a laptop will do, and treat the note that a local pass is not deployment authorization as binding on your own release process.

## FAQ

### What is LayerX Network?

A deterministic execution and accounting network for autonomous agents from Sidiora Labs, where every state-changing operation enters as a signed, canonically encoded Activity and execution returns a signed receipt tied to the resulting state root.

### What is the difference between LayerX and Paxeer?

Ordinary agent activity is executed and ordered inside LayerX. Periodic checkpoints settle to Paxeer, which holds custody, checkpoint registration, guarantor bonds, challenges, withdrawals, disputes, and emergency exits.

### Which part of LayerX Network is allowed to write balances?

402LXP is the only component permitted to write balances. Protocol modules emit validated transfer sets rather than mutating funds themselves, which separates execution from balance mutation.

### Can LayerX Network be built from source?

Yes, with make build, make test, make test-contracts, and make ci. The core runtime is C17, the agent and platform workspaces are Rust, the settlement contracts are Solidity, and replay qualification additionally needs GCC 13, Clang 18, Docker, and an AArch64 cross-compiler.

## Sources

- [License: Apache-2.0](https://github.com/Sidiora-Labs/LayerX-Network/blob/main/LICENSE)
- [Project website](https://layerxnet.ai)
- [README](https://github.com/Sidiora-Labs/LayerX-Network/blob/main/README.md)
- [Releases](https://github.com/Sidiora-Labs/LayerX-Network/releases)
- [Sidiora-Labs/LayerX-Network on GitHub](https://github.com/Sidiora-Labs/LayerX-Network)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/sidiora-labs-layerx-network