LayerX Network: a deterministic activity log for agent accounting
LayerX Network is a deterministic execution and accounting network for autonomous agents.
At a glance
- What is it?
- LayerX Network is an Apache-2.0 Go monorepo that turns every agent action into a signed Activity, orders it on one global sequence, and returns a receipt bound to a state root. The design is coherent and the qualification gates are unusually explicit, but the build surface spans C17, Rust, Solidity and a cross-architecture replay rig.
- Who is it for?
- Adopt LayerX Network if you need an auditable, replayable record of what an autonomous agent did and you are willing to run a C17 runtime plus Rust tooling to get it. Do not adopt it if you want a drop-in library for a single Python service, or if you cannot commit to the qualification gates in docs/QUALIFICATION.md.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 1 day ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem: agents that act without a receipt
An autonomous agent that moves money, deploys a program or changes shared state leaves behind logs written by whichever service happened to handle the call. Those logs are not verifiable by a third party. They are not ordered against a single sequence. Replaying them later may produce a different result because the code path touched a clock, a float, or the iteration order of a database. LayerX Network is aimed squarely at that gap. The README describes it as a deterministic execution and accounting network for autonomous agents, and the mechanism is stated plainly: every state-changing operation enters as a signed, canonically encoded Activity. The protocol verifies the actor and its authority, consumes the account sequence, orders the activity on one global sequence, applies a deterministic state transition, and returns a signed receipt tied to the resulting state root. The audience is therefore narrow and specific. It is for teams that already run agents making consequential calls and need an independent party to be able to check the result. It is not a framework for building an agent, and it is not a payment rail for one-off transfers. The accounting is the product.
The activity log is the authority, indexes are disposable
The architectural claim that matters most is stated in one line: the append-only activity log is the authority, and database indexes are disposable projections that can be rebuilt by replaying that log. This inverts the usual arrangement. In most systems the database is the source of truth and the log is a diagnostic artifact. Here the log is the source of truth and the database is a cache you are free to throw away. Two consequences follow. First, recovery is a replay rather than a restore, so the correctness of replay is a load-bearing property rather than a debugging convenience. Second, the protocol has to defend determinism aggressively, and the README says it does: consensus-critical execution excludes floating point, local clock decisions, database iteration order, and other sources of nondeterminism. There is a second constraint worth noting. 402LXP is the only component allowed to write balances, and protocol modules emit validated transfer sets rather than mutating funds themselves. That is a chokepoint by design. It makes balance changes auditable in one place, and it means a module that wants to move value has to express the intent in a form the runtime can validate before anything is written.
LayerX executes, Paxeer settles
The split between the two networks is the part most likely to be misread. 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. The README is explicit that an ordinary LayerX action does not require a Paxeer transaction. So the fast path is local, and Paxeer is where the contested and the irreversible live. That is a reasonable division, but it puts a burden on the checkpoint interval. Anything that has not been checkpointed is, by construction, not yet under Paxeer's custody and dispute machinery. The material does not state a checkpoint cadence, a bond size, or a challenge window, so those numbers have to come from the contracts in contracts/ and from spec/ rather than from the README. The repository is a monorepo for LayerX Network and Paxeer Network together, and the stated reason is auditability: co-location keeps the protocol, settlement network, contracts, and developer surfaces in one place. Each subsystem keeps its own build, release, deployment, and trust boundary, which is the right caveat. Sharing a repository is not the same as sharing a trust domain.
Getting to a first receipt
The documented path is docs/wiki/Quickstart.md. You install the layerx CLI from platform/cli, bring up the cluster, source build/beta-cluster/env, then create a credential, claim from the faucet, submit an activity, verify the receipt, and deploy a program. The first command is layerx key create quickstart. The faucet call is a plain HTTP POST to $LAYERX_FAUCET_URL/v1/faucet/claims with a bearer token read from $LAYERX_TEST_AUTH_TOKEN_FILE, a CA file, an Idempotency-Key header, and a JSON body carrying did and public_key. Note the two environment variables that shape every later command: $LAYERX_TEST_SOURCE_DID and $LAYERX_TEST_SOURCE_PUBLIC_KEY. The payment test uses layerx --json payment test with --from, --to, --currency, --amount and --idempotency-key. Receipt verification is a separate command, layerx --json receipt verify, and it takes the receipt plus --batch-id, --asset, --previous-state-root, --resulting-state-root and --sequencer-public-key. Program deployment goes through layerx --json program deploy with a wasm32-unknown-unknown artifact and explicit --account-sequence, --not-before-ms, --expires-at-ms and --previous-state-root flags. The presence of not-before and expires-at on a deploy is a detail worth noticing: activities carry their own validity window, so a queued activity can go stale. Idempotency keys appear on both the faucet claim and the payment test, which suggests retries are expected rather than exceptional.
The build is four toolchains wide
This is where a prospective adopter should slow down. The core runtime is C17, pinned with -std=c17 in the root Makefile. Agent, human, and platform workspaces use Rust 1.91.1 via rust-toolchain.toml. LayerX settlement contracts use Solidity 0.8.27 via foundry.toml. Replay qualification needs GCC 13, Clang 18, Docker, an amd64 musl runner, and an AArch64 cross-compiler plus QEMU, per docs/QUALIFICATION.md. The top-level targets are make build, make test, make test-contracts and make ci. Paxeer has bounded targets that run without changing directories: make paxeer-build, make paxeer-lint, make paxeer-test, make paxeer-ci. What make ci actually runs is stated: public-audit, native tests, a two-build archive comparison, consensus symbol checks, and sanitizer suites. The two-build archive comparison is the interesting one, because it is the mechanism that catches nondeterminism leaking into the binary. make monorepo-ci is a separate cross-subsystem gate. The README also draws a line that matters for anyone planning to ship: a local pass is not authorization to deploy contracts, move custody, or handle real assets. Treat the green CI badge as a starting condition, not a release approval.
Where LayerX is the wrong tool
The honest limitation is the one the project states about itself. If your agent's actions do not need third-party verifiability, the global sequence and the receipt machinery are overhead you are paying for and not using. The same applies if your workload is dominated by high-frequency, low-value calls: an account sequence is consumed per activity, and the README describes each activity as signed and canonically encoded, which is not free. There is a harder boundary too. The material does not describe a permissionless path to running the sequencer, nor does it describe what happens to in-flight activities if the sequencing layer is unavailable. Those are open questions from the README alone, and docs/QUALIFICATION.md is where you would look for the fault and invariant suites that answer them. A third caveat: the repository is a monorepo containing both LayerX and Paxeer, and the release tags shown are hpx-registry-<hash> entries. Nothing in the supplied material maps those tags to a stable, versioned artifact for the layerx CLI, so pinning a version for production is something you will have to work out from docs/MONOREPO.md rather than from the release list.
Against a conventional agent audit trail
The obvious alternative is not another network. It is the ordinary stack: an append-only table in Postgres, a hash chain over rows, and a signing service that stamps each entry. That approach is cheaper to run and uses tooling most teams already have. The difference in approach is where determinism is enforced. In the Postgres design you record what happened and hope replay agrees; the state transition is whatever the application code does when you re-run it, floats, clocks and all. LayerX moves that constraint into the execution layer and treats the log as the authority, with indexes as rebuildable projections. That is a materially stronger guarantee, and it is also a materially larger commitment, because you now have to keep the execution layer deterministic across compilers and architectures, which is precisely why the qualification gates exist. If your threat model is an internal auditor reading a table, the Postgres chain is the right call. If your threat model is a counterparty who does not trust your database, the difference between the two designs is the whole point.
Licence, maintenance and what to check first
The repository is Apache-2.0, which permits commercial use and modification and includes an explicit patent grant. It also requires that you preserve notices and state significant changes; the LICENSE file is the authority and this is not legal advice. The maintenance picture from the supplied material is a monorepo with active pushes and frequent hpx-registry releases, plus a documented contribution rule: protocol changes start in spec/, and suspected vulnerabilities should not be disclosed in a public issue. That last point is a real constraint on how you operate. If you find a sequencing or accounting bug, your first move is a private report, not a pull request. The upgrade cost is the multi-toolchain reality described earlier. Keeping C17, Rust 1.91.1 and Solidity 0.8.27 in step, and keeping the replay qualification rig (GCC 13, Clang 18, Docker, musl, AArch64 plus QEMU) working, is ongoing work rather than a one-time setup. Before committing, read spec/layerx-protocol/design.md and docs/QUALIFICATION.md, then confirm against the contracts in contracts/ what the checkpoint interval, bond and challenge window actually are, because the README leaves those unspecified.
Editorial conclusion
Adopt LayerX Network if you need an auditable, replayable record of what an autonomous agent did and you are willing to run a C17 runtime plus Rust tooling to get it. Do not adopt it if you want a drop-in library for a single Python service, or if you cannot commit to the qualification gates in docs/QUALIFICATION.md. Before anything else, read spec/layerx-protocol/design.md and confirm whether ordinary agent activity truly stays off Paxeer for your workload, because that split decides your operational cost.
Community notes