Get funded, see what your keys did, and receive events without polling. The faucet issues one bounded allocation per identity per window behind a hosted identity session. The webhook service signs every receipt and checkpoint delivery with Ed25519, retries eight times, then dead-letters so nothing disappears quietly. The read-only dashboard shows keys, usage counters, request logs and delivery attempts. The program registry journals versions and reproducible builds. None of the four runs publicly yet.

What it does

Four hosted services sit beside the Paxeer X gateway to support developer work. A faucet issues bounded beta funding grants behind a hosted identity session, a webhook service delivers signed receipt and checkpoint events to registered endpoints, a read-only dashboard API and web front end show keys, usage counters, request logs and delivery logs, and a program registry records program versions and reproducible builds against a durable journal. All four ship as container images with Kubernetes manifests under platform/hosted/.

Key capabilities

• Faucet grants one bounded allocation per identity per window, keyed by a required idempotency header.
• Gateway lx_requestFunds reaches the faucet over a service token, capped at 30 claims per minute.
• Webhook deliveries carry an Ed25519 signature, event kind, subject, sequence and attempt as headers.
• Deliveries retry eight times, back off from ten seconds to one hour, then dead-letter.
• Dashboard API serves overview, keys, usage, requests, webhook health and receipt reads per session.
• Program registry lists programs, reads one version, returns its interface and accepts source submissions.

Differentiators

Each webhook event states the evidence behind it as a verification level (unverified, receipt-verified, checkpoint-finalised or paxeer-finalised), and a receipt-backed fact must carry the receipt digest or the event is refused. Retry backoff is spread deterministically from the delivery's own digest, so a replayed schedule reproduces the original timing.

Outcomes

• Claim one bounded funding allocation per identity, keyed by an idempotency header
• Verify each delivery's Ed25519 signature and deduplicate on its webhook id
• Replay dead letters instead of losing failed deliveries

Technical notes

• The limited beta has not opened, so none of the four run as public services. There is deliberately no general-use faucet: this is a mainnet beta on real value, and approved developers receive one bounded allocation directly from the team.
• Faucet claims need a hosted identity session bearer token, Content-Type: application/json and an Idempotency-Key; a quota refusal returns 429 with the seconds left in the window. The default window is 86,400 seconds and idempotency records are retained for 604,800 seconds. The service terminates TLS itself, needs LAYERX_FAUCET_LISTEN, DER certificate and key paths, an identity introspection URL, a funding URL and a Redis URL with username and password files, and caps concurrency at 128 connections and requests at 16 KiB.
• The gateway side is configured with LAYERX_GATEWAY_FAUCET_URL and LAYERX_GATEWAY_FAUCET_SERVICE_TOKEN_FILE, and derives its idempotency key from the principal digest, the DID and the public key.
• Webhook receivers must verify layerx-webhook-signature over "<layerx-webhook-id>.<layerx-webhook-timestamp>." followed by the exact body bytes before reading the body, reject a timestamp outside the window, and deduplicate on layerx-webhook-id before applying side effects. The scheme is LayerX/webhooks/v1, signing keys are prefixed whk_, tolerance is 300 seconds with 30 seconds of future skew, and event families are journey, payment, approval and program. An endpoint is suspended after twenty consecutive dead letters; a dead-letter replay requires an idempotency key.
• The dashboard API is read-only (any non-GET is refused), so key issuance and rotation are not write routes on it. Pages default to 50 rows and cap at 200. The web front end is a single Next.js 16.3.5 page and declares Node.js 24 or newer.
• The program registry runs as a single-replica StatefulSet on port 9420 with a 1 GiB journal volume, and depends on a systemd node boundary: a provisioner unit, cgroup v2 with cpu, memory, pids and io, and loop-backed ext4 build images. kubectl exec into the registry container is refused by design. It is a deployment journal and a build service, not service discovery.
• All four are Kubernetes-shaped (Deployments or StatefulSets, Services, Ingress, NetworkPolicies), and no single-container developer path is declared for them. Hosted rate limits, a status page and a scheduled beta reset are declared in platform/docs/capabilities.kvx but are not confirmable from source.

POST /v1/faucet/claims HTTP/1.1
Authorization: Bearer <session-token>
Content-Type: application/json
Idempotency-Key: <client-generated-identifier>

{"did": "<did>", "public_key": "<32-byte-hex>"}

More in Developers