Thesettlementlayerforthemachineeconomy.

LayerX agent domain

Budget and gate every agent activity

Agent daemon with policy engine

A local daemon evaluates each write against policy, capability and spending limits before signing.

Run layerx-agentd beside your agent. It evaluates every write request against a versioned policy set, a bounded capability and a spending limit before the activity is prepared, signed or submitted, and returns a deterministic allow or deny with the policy version, the matched rules, the deciding rule and a stable reason. Dry-run a request down the same path without creating a signature. The daemon stays non-authoritative: bypass it and you bypass its restrictions.

What it does

layerx-agentd runs beside an agent and evaluates every write request against a versioned policy set, a bounded capability and a spending limit before the activity is prepared, signed or submitted to the LayerX agent domain. Each evaluation returns a deterministic allow or deny with the policy version, the rules that matched, the deciding rule and a stable reason. The daemon is explicitly non-authoritative: its capabilities are checked against the authority the agent domain granted, and every local restriction it records carries the notice that bypassing the daemon bypasses the restriction.

Key capabilities

  • Policy rules match on activity type, counterparty, asset, amount, purpose, capability, session, agent and tenant.
  • Capabilities carry seven mandatory bounded dimensions; no dimension may be left open or zero.
  • Derived child capabilities are refused if any dimension is wider than the parent.
  • Spending limits reserve atomically across every applicable scope and survive daemon restarts.
  • Approval holds queue the exact prepared activity for a person to grant or reject.
  • Durable outbox, idempotency cache and proof-gated finality records track each submission.

Who it's for

Operators and teams running agents that spend on Paxeer X without a person in the loop.

Why it matters

An agent can run unattended and still be held to a written mandate, because each request either matches a permitting rule or is denied with a reason an operator can read. Spending ceilings are reserved before signing and reconciled afterwards against verified receipts, so local accounting does not drift from what the chain recorded. A rejected request names the exact dimension that failed rather than failing silently.

Differentiators

Every decision can be emitted as a stable machine-readable explanation carrying a schema version, the evaluation mode, the matched rules, the deciding rule, the reason and an authority statement, so two runs of the same policy version can be diffed. A request can be dry-run through the same evaluation path without creating a preparation, a signature or a submission. Capability narrowing is proved against granted protocol authority, and the daemon labels its own restrictions as daemon-only rather than as protocol enforcement.

Outcomes

  • Agents run unattended and stay held to a written mandate
  • Spending ceilings reserve atomically across scopes and survive daemon restarts
  • A denial names the exact dimension that failed, with a reason

Technical notes

  • Policy outcomes are Allow or Deny. Reasons are PermittedByRule, ExplicitDeny, ApprovalRequired, NoPermittingRule, InvalidContext and EvaluationFailure. An allow is never protocol authorisation.
  • Evaluation is fail-closed and takes no ambient input: an input without a complete opaque cumulative-use result is invalid, and cumulative totals supplied by the caller are not accepted.
  • Capability refusal names the first failing dimension in a fixed order: expiry, activity type, counterparty, asset, amount, rate, purpose.
  • Policy sets are validated before activation; an empty version, a zero evaluation step limit, a step limit below the rule count, a duplicate rule identifier, an empty purpose or an inverted sequence window is rejected.
  • Startup is fail-closed. Eight settings have no defaults: network_id, node_endpoint, expected_protocol_version, tenants, policy_sources, signer_configurations, verification_defaults and sequencer_authority_source. Exact LAYERX_* environment values override the named configuration file. The file is at most 65,536 bytes with lines at most 4,096 bytes. The per-tenant maps must cover every declared tenant or startup fails.
  • Per-tenant verification defaults accept sequencer-signed, batch-included, state-proven, checkpoint-finalised or settlement-anchored.
  • Signing is external by default: the daemon returns a key-free package with the canonical bytes, the signing preimage and the disclosure digest. The alternative is an in-daemon protocol session key bounded to its issued authority, permitted activity types, expiry and revocation sequence.
  • The operator interface is a Unix-socket peer authenticated by kernel uid. Each accepted uid maps to one immutable principal and tenant; an unmapped uid is refused before framing. The socket mode is restricted to the 0o770 bits and the endpoint must not already exist.
  • Session key material lives in an encrypted registry whose directory must be a real directory owned by the daemon uid with no group or other permission bits, and the operator secret must be at least 32 bytes.
  • Budget reconciliation against protocol state is not yet complete: it authenticates the candidate state, verifies receipts, binds them to activities and rejects replays, then returns ProtocolStateSchemaUnavailable because the agent domain defines no canonical budget record or key schema.

More in LayerX agent domain

Build on Paxeer.

Give your agent a wallet, set its policy, and settle your first call on LayerX.