
Hold funds, move money, see settlement
Human control plane for owners
A hosted service and web app where you control funds and agents without running a node.
Deposit, move, withdraw and exit run as durable journeys that advance only against a verified receipt, so a restart never loses your place. Your keys stay inside the service keystore and the browser never signs anything. Sensitive operations ask for a fresh passkey ceremony bound to that exact operation. The withdrawal screen derives its wait from declared checkpoint interval, block time and confirmations, and shows no number when an input is missing.
What it does
layerx-human-service carries the owner-facing journeys (deposit, move money, withdraw and emergency exit) as durable state machines that only advance against a verified receipt, backed by four provider processes: KMS, identity, security and movement. human/apps/web is the Next.js front end over that service, with owner routes for activity, agents, approvals, deposits, moves, withdrawals, journeys, notifications, security and settings, plus launchpad, exchange, bridge and explorer surfaces. The service and its providers run inside the node pod of the beta cluster, and the front end forwards /v1/* and /readyz to the service over HTTPS. The browser holds no signing power: every signature is produced by the KMS behind the service.
Key capabilities
- Four durable journeys (deposit, move, withdraw, exit) whose action keys survive service restarts unchanged.
- Withdrawal wait is computed only from declared checkpoint interval, block time and required confirmations.
- Sensitive operations need a fresh passkey ceremony bound to one exact operation digest.
- Signing keys stay in the human-service KMS; no API surface returns key material.
- Emergency exit sits in Settings behind a typed confirmation phrase and an irreversibility notice.
- Logs, metrics and spans are built from a closed schema registry that bans sensitive field names.
Who it's for
People and organisations who hold funds and run agents on Paxeer X and want to see and control both.
Why it matters
Owners get one place to deposit, move, withdraw and exit without running a node or handling a private key. The withdrawal screen explains the settlement wait from the configuration that causes it (checkpoint interval plus block time times confirmations) and refuses to display a wait at all if any of those inputs is zero, so the number shown is never an invented estimate.
Differentiators
Three properties are checked in the code rather than asserted. The settlement expectation is derived solely from declared timing configuration and refuses zero values and arithmetic overflow (human/crates/layerx-human-service/src/journeys/withdraw.rs:73-94). Redaction is by construction: every emission is validated against a closed schema registry, and no schema may declare a field named account, address, amount, balance, email, iban, key, memo, name, owner, payload, phone, preimage, secret, token or value (human/crates/layerx-human-service/src/redaction.rs:29-32). The front end ships a copy catalog with a ten-term banned vocabulary, including DID, session key, nullifier, checkpoint and proof, enforced in the lint step so protocol jargon cannot reach owner surfaces (human/apps/web/copy/catalog.ts:3-14).
Outcomes
- Deposit, move, withdraw and exit from one owner account.
- Sign nothing in the browser; the service keystore holds your keys.
- Read a settlement wait computed from configuration, never an estimate.
Technical notes
- Hosting: the
layerx-humanService selectslayerx-nodeand forwards HTTPS to port 9447. Providers run as UID/GID 4020 over sockets under/run/layerx/human/, the owner process as UID 4021, KMS as UID 4026. The pod is one trusted local boundary; same-UID processes are not isolated from each other. - Movement requires agreement from both the
paxeer-boundaryandpaxeer-observer-boundaryHTTPS Services, minimum agreement 2. - Durable state lives on the retained
layerx-human-statePVC. Retained encrypted state requires its matching cryptographic material; cluster-wide secret regeneration is not a key migration mechanism. human/apps/webis a separate website and is not deployed by the Human pod. It reaches the service throughLAYERX_HUMAN_SERVICE_URL, which must be an HTTPS origin with no credentials, path, query string or fragment, or the build fails.- Not yet implemented: self-custody key export. Human and managed-agent primary keys are generated and held inside the human-service keystore, there is no export path, and qualification verifies that no API surface returns key material.
- Kubernetes execution of the Human provisioning path remains unqualified on the build server, and no public deployment of this plane is declared in source.
More in Interface
Explorer with a joined account page
One account page, four spellings
ExploreManaged agent wallets and approval inbox
Cap what your agents can spend
ExploreMoney journeys and cross-domain intent routing
State the movement, not the mechanism
ExploreOnboarding and team-allocated funding
Register a signer, claim one grant
ExploreBuild on Paxeer.
Give your agent a wallet, set its policy, and settle your first call on LayerX.