
Samples that cannot go stale
Runnable samples and reference apps
Thirteen build-checked samples and four cloneable reference applications, extracted straight from compiled source.
Copy code out of the documentation and you get the same lines that continuous integration compiles and measures. The site build re-extracts every published block from its named sample file and region, so a page that disagrees with its sample fails the build. Thirteen samples cover TypeScript, Python, Go, Java, C#, Swift and Rust across Express, FastAPI, Spring Boot and Next.js. One runner drives four reference applications through a buyer, seller, merchant and marketplace journey on a local emulator.
What it does
Thirteen sample projects sit under platform/docs/samples, each declared in platform/docs/samples.kvx with its install, build and run commands, the environment it needs, and a hard budget for how many lines of LayerX integration code it adds. The documentation site build extracts every published code block straight from the named sample file and region, so a page that disagrees with its sample fails the build. Separately, platform/examples/reference-apps.json declares four complete Node.js applications (a buyer agent, a paid API, a merchant shop and a programs marketplace), each with one command for a local emulator and one for beta. One runner, platform/examples/run-reference-apps.mjs, checks that manifest and drives all four through a single end-to-end journey.
Key capabilities
- Samples cover TypeScript, Python, Go, Java, C#, Swift and Rust, plus Express, FastAPI, Spring Boot and Next.js.
- Two mobile samples show the same first payment on iOS and Android, holding no long-lived credential.
- Every documented code block is re-extracted from its sample file, so page and code cannot drift apart.
- Each sample declares a nine-line integration budget; the docs build fails a sample that exceeds it.
- Four reference applications each carry one emulator command and one beta command, declared in one manifest.
- The runner's emulator scenario starts a local emulator, derives its inputs from real receipts, then tears it down.
Who it's for
Developers adding LayerX payments to an application or service they already run.
Why it matters
The code a developer copies out of the documentation is the same code that is compiled and measured in continuous integration, so it does not go stale silently. The emulator scenario runs the whole buyer, seller, merchant and marketplace journey on one machine without any issued credential.
Differentiators
The published integration line count is enforced rather than advertised: platform/docs/build/build_site.py fails the docs build when a sample's measured region exceeds its declared budget, and the generated index records the current samples at four to nine lines against a budget of nine. The reference runner refuses drift it finds in the manifest, including a changed command shape, a missing start: script, a protocol version other than 3, or a source file that has lost its declared symbol, and it rejects a reference application that carries fixture or browser secret surfaces.
Outcomes
- Each sample keeps its LayerX integration within a nine-line declared budget.
- Run the full buyer, seller, merchant and marketplace journey on one machine.
- Clone a reference application with one emulator command and one beta command.
Technical notes
- Runtime floors: Node.js 22 or newer, Python 3.11 or newer. Other samples need Go 1.21, JDK 21 with Maven, Swift 5.9, .NET 8 or a Rust toolchain.
- No
first-payment,paid-endpointorpaid-routesample targets the emulator. Each needs issued values in the environment:LAYERX_API_URL,LAYERX_API_TOKENand the move inputs for the payment samples, or the twenty-one declared seller keys for the paid-endpoint samples. No sample runs credential-free. - The line budget counts only the LayerX integration region. It excludes the application's own error-handling idiom, data model, storage adapter and reporting.
- Only
first-payment-typescript,paid-endpoint-expressandpaid-route-nextare npm workspace members. The rest build with their own native toolchain, all driven bymake platform-test-docs. - The reference applications are npm workspaces that build from the repository root (
npm ci, thennpm run build). The emulator scenario also needs thelayerxCLI, resolved from$LAYERX_BIN,build/bin/layerxorPATH; the beta scenario needs operator-suppliedLAYERX_TESTNET_*values. merchant-checkoutis a workspace compatibility name formerchant-shop.platform/examples/agent-spendandplatform/examples/agent-program-callexist beside the four applications but are not in the manifest, and the runner does not drive them.
npm ci
npm run build
node platform/examples/run-reference-apps.mjs --check
node platform/examples/run-reference-apps.mjs --scenario emulatorMore in Developers
Repo build system and developer tooling
One command set builds the whole network
ExploreTest, conformance, load and benchmark runners
See exactly what Paxeer X exercises
ExploreClient SDKs in seven languages
Call the network from seven languages
ExploreCore protocol and verification CLIs
Run, control and verify nodes from a shell
ExploreBuild on Paxeer.
Give your agent a wallet, set its policy, and settle your first call on LayerX.