LayerX Network: a deterministic execution and accounting network for autonomous agents

The problem LayerX Network solves, and who it is for

Autonomous agents that transact with each other need two things that ordinary APIs do not give them: a total order over concurrent actions, and a receipt that a third party can check without trusting the agent. LayerX Network is built around that pair. Every state-changing operation enters the system 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 narrower than the description suggests. This is infrastructure for teams writing agent runtimes, marketplaces, or paid endpoints where the accounting has to be replayable. The repository is a monorepo holding both LayerX Network and the Paxeer Network, which the README justifies on auditability grounds: the protocol, settlement network, contracts, and developer surfaces sit in one place, while each subsystem keeps its own build, release, deployment, and trust boundary. If you only want to charge a credit card from an agent, nothing here is aimed at you.

The append-only log is the authority, indexes are disposable

The design decision that shapes everything else is stated plainly in the README: the append-only activity log is the authority, and database indexes are disposable projections that can be rebuilt by replaying that log. That inverts the usual relationship between a database and its write-ahead log. Here the log is the system of record and the queryable state is derived.

Consensus-critical execution excludes floating point, local clock decisions, database iteration order, and other sources of nondeterminism. The Makefile backs this up at the compiler level: the core runtime builds with -std=c17 -pedantic -Werror -Wall -Wextra -Wconversion -Wshadow -Wvla and -ffp-contract=off, and on x86_64, i386, i486, i586, i686, aarch64 and arm64 targets it adds -mgeneral-regs-only to the consensus flags. Disabling floating-point contraction and restricting the register file is how the build tries to make two machines produce identical results from identical inputs.

Accounting is similarly constrained. `402LXP` is the only component allowed to write balances, and protocol modules emit validated transfer sets rather than mutating funds themselves. That is a strong invariant, and it is also a bottleneck: any new module that wants to move value has to route through 402LXP rather than doing it locally. The README does not describe what happens when a transfer set fails validation mid-batch, so treat that as an open question for your own testing.

LayerX executes, Paxeer settles: what crosses the boundary

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 common path stays cheap and the expensive path is reserved for settlement.

That split is the most consequential thing to understand before adopting. Custody, disputes, and exits are Paxeer concerns, not LayerX concerns. The Solidity side lives in `contracts/` for custody, checkpoints, guarantor bonding, claims, disputes, and exits, and is pinned to Solidity 0.8.27 in `foundry.toml`. The checkpoint contract configuration is generated from `contracts/config/checkpoint-settlement.json` into `build/generated/lxp_checkpoint_settlement.h`, which means the settlement parameters are compiled into the C runtime rather than read at startup. Changing them is a rebuild, not a config edit.

The repository layout reflects the same boundary. `src/` and `include/` hold the C17 protocol runtime, state machine, storage, sequencing, replay, and settlement integration. `cmd/` holds native daemons and tools including `layerxd`, `layerxctl`, genesis, and verify. `paxeer-network/` is a separate node with its own EVM/RPC compatibility, storage engines, modules, and subsystem-local builds.

Installing the layerx CLI and submitting a first activity

The README points to `docs/wiki/Quickstart.md` as the full path, and describes the sequence: 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 CLI is the only entry point documented for this flow.

Start by creating a credential. The README gives this exact command:

layerx key create quickstart

After sourcing `build/beta-cluster/env`, that environment supplies `LAYERX_TEST_SOURCE_DID`, `LAYERX_TEST_SOURCE_PUBLIC_KEY`, `LAYERX_TEST_CA_FILE`, `LAYERX_TEST_AUTH_TOKEN_FILE`, and `LAYERX_FAUCET_URL`. The faucet claim is a plain HTTP POST with an idempotency key, which is what makes a retry safe:

jq -n --arg did "$LAYERX_TEST_SOURCE_DID" --arg public_key "$LAYERX_TEST_SOURCE_PUBLIC_KEY" \
  '{did:$did, public_key:$public_key}' > faucet-request.json
curl --fail --silent --show-error --max-time 30 --cacert "$LAYERX_TEST_CA_FILE" \
  --header "Authorization: Bearer $(tr -d '\r\n' < "$LAYERX_TEST_AUTH_TOKEN_FILE")" \
  --request POST "$LAYERX_FAUCET_URL/v1/faucet/claims" \
  --header "Idempotency-Key: faucet-quickstart-01" \
  --header 'Content-Type: application/json' --data-binary @faucet-request.json

With funds claimed, submit a payment activity. Note that the CLI is invoked with `--json`, and the idempotency key is passed on the command line rather than in a header:

layerx --json payment test \
  --from "$LAYERX_TEST_SOURCE_DID" \
  --to "$LAYERX_TEST_DESTINATION_DID" \
  --currency "$LAYERX_TEST_ASSET" \
  --amount "$LAYERX_TEST_AMOUNT" \
  --idempotency-key paymentquickstart1

The step that distinguishes this from a payments API is receipt verification. The receipt is checked against the batch id, the asset, both state roots, and the sequencer public key:

layerx --json receipt verify \
  --receipt receipt.hex \
  --batch-id "$batch_id" \
  --asset "$asset" \
  --previous-state-root "$previous_root" \
  --resulting-state-root "$resulting_root" \
  --sequencer-public-key "$sequencer_key"

Program deployment follows the same shape. The README shows a WebAssembly artifact built for `wasm32-unknown-unknown`, deployed with an explicit account sequence, a not-before and expiry window, and the previous state root:

layerx --json program deploy \
  quickstart-program/target/wasm32-unknown-unknown/release/quickstart_program.wasm \
  --program-id <program_id> \
  --idempotency-key <idempotency_key> \
  --key quickstart \
  --account-sequence 0 \
  --not-before-ms <not_before_ms> \
  --expires-at-ms <expires_at_ms> \
  --previous-state-root <previous_state_root>

If you would rather build the stack yourself, the root Makefile exposes `make build`, `make test`, `make test-contracts`, and `make ci`. Paxeer targets are bounded and run without changing directories: `make paxeer-build`, `make paxeer-lint`, `make paxeer-test`, `make paxeer-ci`. The README states that `make ci` runs `public-audit`, native tests, a two-build archive comparison, consensus symbol checks, and sanitizer suites, and that `make monorepo-ci` is a separate cross-subsystem gate.

The toolchain is the price of admission

This is not a single-language project, and the build requirements are the clearest obstacle to casual adoption. 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`.

Four toolchains, plus cross-compilation and emulation for replay qualification, is a lot of surface for a team that just wants to call an SDK. The SDKs themselves are broad: Rust at `agent/crates/layerx-sdk`, Python at `agent/sdk/python`, TypeScript at `agent/sdk/typescript`, Go at `platform/sdk/go`, JVM at `platform/sdk/jvm`, .NET at `platform/sdk/dotnet`, and Swift at `platform/sdk/swift`. The npm workspace list in `package.json` shows the TypeScript side is split into middleware for agent, buyer, merchant, seller, and conformance roles, plus integrations for Express, Next.js, and a generic agents package. That breadth is real, but every one of those packages inherits the same protocol assumptions.

The second constraint is stated by the project itself and is worth repeating: a local pass is not authorization to deploy contracts, move custody, or handle real assets. `make ci` passing on your laptop does not mean the code is safe to point at value. If your process cannot accommodate a separate qualification step, this is the wrong layer to build on.

Where LayerX Network is the wrong choice

If your agents only need to call external APIs and pay per request, a conventional metered billing system will get you there with far less machinery. The Activity, sequence, state root, and receipt model exists to make accounting verifiable and replayable by a third party. If nobody is going to verify anything, you are paying the determinism tax for nothing.

The determinism constraints are also a real restriction on what you can run. Floating point is excluded from consensus-critical execution, local clock decisions are excluded, and database iteration order cannot influence results. Programs deployed through `layerx program deploy` compile to `wasm32-unknown-unknown`, so they live inside those constraints. An agent workload that depends on wall-clock timing, native libraries, or floating-point math is a poor fit for the program runtime, even if it fits comfortably in a normal container.

Finally, the settlement boundary means Paxeer is not optional forever. Ordinary activity stays inside LayerX, but custody, withdrawals, disputes, and emergency exits are Paxeer concerns. If you cannot operate or trust a Paxeer deployment, you have no exit path, and the README does not document a fallback for that case.

How it compares to a general-purpose chain with agent SDKs

The obvious alternative is an EVM chain with an agent framework layered on top. The difference is where determinism is enforced and what the receipt proves. On a general-purpose chain, the state transition function is fixed by the VM and your agent logic is a contract; ordering comes from the chain's own consensus, and you inherit its fee market and block timing. LayerX instead treats the agent activity as the unit of ordering, with the account sequence consumed per activity and a global sequence providing the total order. The receipt is bound to the resulting state root and signed by the sequencer, so verification is a local operation against a known public key rather than a check against a chain head.

The Paxeer relationship is not a standard rollup relationship either. The README describes Paxeer as holding custody, checkpoint registration, guarantor bonds, challenges, withdrawals, disputes, and emergency exits, with periodic checkpoints settling to it. Guarantor bonds and challenges suggest a dispute mechanism rather than pure fraud proofs, but the README does not explain the challenge procedure, so that comparison cannot be pushed further from what the README documents. If the dispute design is what you care about, `spec/` and `contracts/` are where to look, and the README notes that protocol changes start in `spec/`.

Licence, maintenance, and what an upgrade costs

LayerX Network is Apache-2.0, and the root `package.json` carries `"license": "Apache-2.0"` with `"private": true`, so the npm workspace is not published as a package set. A `NOTICE` file exists at the top level, which Apache-2.0 users should read alongside the licence text. This is not legal advice; if you are redistributing or embedding the runtime, have someone qualified read both files.

The repository is not archived, and the last push was on 2026-09-10. Recent releases are tagged `hpx-registry-<commit>` with timestamps on 2026-09-07 and 2026-09-10, which suggests the release cadence is tied to the HPX registry rather than to versioned protocol releases. The README does not document a protocol versioning scheme or a rollback procedure, and it does not describe an upgrade path for a running cluster. That gap matters more than usual here: because the checkpoint settlement parameters are compiled into the C runtime from `contracts/config/checkpoint-settlement.json`, and because the append-only log is the authority, an upgrade that changes state transition semantics has to be reconciled against replay. The repository has a `migrations/` directory for genesis, migration, reconciliation, and shadow-replay work, and `docs/QUALIFICATION.md` describes replay qualification, but the README does not present a supported upgrade procedure. Budget for reading those two directories before you commit to running a cluster with real value.

Editorial conclusion

Adopt LayerX Network if you are building autonomous agents that need ordered, receipt-backed accounting and you can work against the documented testnet path in docs/wiki/Quickstart.md. Do not adopt it if you need a drop-in payments API with published operational guarantees, or if you cannot build C17 with the exact toolchain the Makefile pins. Verify first that the faucet, sequencer keys, and CA file in build/beta-cluster/env are still the ones your cluster serves, and read docs/QUALIFICATION.md before treating any local make ci pass as authorization to touch custody.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. Sidiora-Labs/LayerX-Network on GitHub