MOB · Financial Market Infrastructure — Retail Payments
Mobile Origin Transaction Router
A stablecoin payments router that acknowledges an intent only once it is on disk, is designed to refuse overload with an explicit 503 rather than drop it silently, and attributes the last-mile margin of every settled intent.
Overview
MOTR addresses a failure mode that becomes structural as stablecoin payments scale into retail distribution: payment aggregators receive bursts of simultaneous webhook calls from chat-bots and dynamic QR scanners, and an ingest stack that sheds load without telling the sender loses payment intents with no operator-visible signal.
Its central design property is that an intent is acknowledged only after it is durable in a write-ahead log, and that overload is refused explicitly (503 with Retry-After) rather than dropped. A TLA+ specification of the ingest design, model-checked with TLC on bounded instances, shows that no acknowledged intent is lost and none is recorded twice; Vlaander's kill -9 audits found every acknowledged intent after restart. In Vlaander's 20,000-request burst over 1,000 connections, however, about half the requests failed at the connection level before reaching that logic (see the measurement notes). A second specification covers routing and establishes at-most-one-success, so that a timed-out settlement is never re-sent to another rail; a third covers hedging (one order per currency per epoch, exposure conserved).
Commercially, MOTR gives the operator an instrumented view of where basis points are created across the settlement chain. Every settled intent produces a five-line basis-point margin record — interchange, FX spread, crypto spread, float value and payout FX — computed in exact arithmetic.
The problem
Retail stablecoin distribution produces bursty, non-Poisson ingest load with no back-pressure contract at the origin. An ingest path that fails open loses intents invisibly until reconciliation. Meanwhile, aggregators operating on thin transport economics have no instrumented view of where basis points are created or lost across the settlement chain.
What it does
- Webhook ingest that acknowledges an intent only after its write-ahead-log record is fsynced; overload at the router is refused with 503 and Retry-After (see the burst result for what happened at the connection layer).
- Multi-rail settlement routing with at-most-one-success under timeout: rails are retried with the intent id as idempotency key and changed only after a definitive decline.
- Per-currency treasury with net-position epoch hedging — one order per currency per flush, not one per intent.
- Pre-dispatch compliance gate, fail-closed, positioned ahead of settlement dispatch (reference screen: exact-match sanctions, country, limit and velocity rules).
- Five-line basis-point margin attribution produced for every settled intent.
- Native hot path: Rust NIF (constant-time HMAC-SHA256, simd-json, BLAKE3) feeding a C++ MPSC ring with lock-free producers, drained by a group-commit WAL writer.
- Operational surface: 24 telemetry metric families, twelve SLOs with multi-window burn-rate alerting, OTP supervision-tree self-healing by WAL replay.
Performance
Measured 2026-10-09| Metric | Figure | Basis |
|---|---|---|
| Webhook acknowledgement latency (fsync before 2xx) | p99 7.4–38.9 ms at 2,000 intents/s and 2.7–8.5 ms at 1,000/s across two sweeps on the hardware below (p50 0.5–0.8 ms) | Measured by Vlaander |
| End-to-end saturation | About 3,000–3,100 intents/s (each intent screened, routed, settled and margin-attributed; 4 durable WAL records per intent) | Measured by Vlaander |
| Verify-parse-hash throughput | About 238,000 operations/s on one BEAM scheduler; 463,000/s on two (1.94×, one per physical core) | Measured by Vlaander |
| Acknowledged intents lost after kill -9 | 0 of 45,557 across two audits on the delivered archive (23,084 and 22,473 acknowledged before the kill) | Measured by Vlaander |
| Burst of 20,000 webhooks over 1,000 connections | 10,200 acknowledged (all found on audit); 9,800 failed with client connection errors rather than 503 refusals | Measured by Vlaander |
- Date
- 2026-10-09
- Hardware
- AMD EPYC 7763, GitHub Codespace (shared Azure VM), 4 vCPU (2 cores), 15 GiB
- Toolchain
- Elixir 1.16.3 / OTP 26 (official elixir:1.16-slim image), Rust 1.99.0 and nightly-2026-10-01 installed with rustup, the versions docker/Dockerfile pins
- Source archive SHA-256
- 2f42c204401116549b9faf3251fdf69d30161f1b779ff0924b79601e0d90f4b8
- Method
- bench/vph.exs (verify-parse-hash through the NIF, 1/2/4 schedulers); bench/ack_sweep.sh (open-loop mob-load at fixed rates, 128 keep-alive connections, 30 s each, latency from each request's scheduled send time); mob-load burst; bench/crash_audit.sh (kill -9 of the BEAM mid-load, restart, GET every acknowledged id). Load generator on the same machine; WAL on a local ext4 disk.
- The machine was shared with other workloads (1-minute load average 0.6–6.7 during the runs), and the load generator ran on the same machine. Latency varied between runs: the two sweeps gave p99 7.4 ms and 38.9 ms at 2,000 intents/s.
- Burst: of 20,000 requests sent at once over 1,000 connections, 10,200 were acknowledged and 9,800 failed at the TCP/connection layer; the server returned no 503s and no acknowledged intent was lost. The cause (listen backlog, file-descriptor limits or the co-located load generator) was not established. An earlier run by the builder on 2026-10-07 acknowledged all 20,000; it was not reproduced on the delivered archive.
- Acknowledgement latency is bounded below by the WAL disk's fsync latency; measure your disk first (bench/fsync_probe.c).
- Scaling beyond two physical cores could not be measured on this machine; schedulers 3–4 run on SMT siblings and added 23%.
- At 3,000 intents/s the system is at its knee (p99 108 ms in one sweep; in the other it reached only 2,836/s with p99 2.4 s); above about 3,100/s an open-loop client sees unbounded queueing, but nothing acknowledged is lost.
- The catalogue's earlier statements (p99 under 50 ms; ≈210,000 operations/s per core, scaling linearly; zero dropped intents under burst, TLA+-proven) were not measured; the figures above replace them. TLC checks a bounded model of the design, not the code.
Value in your own metrics
- Last-mile margin visibility
- Five basis-point lines — interchange, FX, crypto spread, float, payout — computed in exact arithmetic for every settled intent. Margin records are held in memory today; persisting them to the WAL is listed as pending below.
- Acknowledged intents lost
- None found: an intent is acknowledged only once WAL-durable and replays after a crash (TLC-checked design; 0 of 45,557 lost across two kill -9 audits). Requests that are not acknowledged — refused with 503 + Retry-After, or failed at the connection, as in the burst test — are for the sender to retry.
- Webhook acknowledgement latency
- p99 7.4–38.9 ms at 2,000 intents/s and about 238,000 verify-parse-hash operations per second on one scheduler, measured by Vlaander on the hardware above.
- Cross-rail double-settle risk
- Refused by design — a timed-out settlement is retried only on the same rail with the same key, never rerouted (TLC-checked at-most-one-success). This relies on each rail adapter being idempotent per intent id and reporting a decline only when no funds moved.
- Treasury hedging discipline
- Net-position epoch hedging: one order per currency per flush, not per intent.
Assurance and build
- Language
- Elixir 1.16 · Rust · C++
- Runtime
- BEAM · OTP supervision tree
- Build
- mix · Credo (strict) · Dialyzer · clippy::pedantic · sanitizers, all run by scripts/ci.sh — passing (a GitHub Actions workflow is included; it has not yet run on hosted CI)
- Formal verification
- 3 TLA+ specifications (ingest · routing · hedging), TLC model-checked on bounded instances, each with negative controls that fail as intended — passing
- Concurrency
- MPSC ring with lock-free producers (no mutexes or system calls) under TSan · treasury invariants property-tested and model-checked — passing
- Memory safety
- Rust NIF and C++ ring under ASan/UBSan · about 8.2 million fuzz executions across 4 targets (60 s each), 0 crashes · HMAC signatures compared with a constant-time comparison (subtle crate), and a dudect-style timing test with a deliberately leaky control shows no detectable leak — passing
- Durability
- Group-commit WAL with pre-zeroed segments · no acknowledged intent lost in two kill -9 audits on the delivered archive — passing
- Dependency surface
- 33 runtime Rust crates, all permissive (MIT/Apache-2.0/BSD/ISC/Zlib/CC0/BSL) · no runtime Hex packages · SBOM included
- Source archive SHA-256
- 2f42c204401116549b9faf3251fdf69d30161f1b779ff0924b79601e0d90f4b8
Releases are not yet cryptographically signed, and no release manifests or external audit summaries are published. Check the source tarball you receive against its SHA-256 in Schedule 1 of your Sale and Assignment Agreement, which you see before you sign.
Scope and maturity
What is real today, what is deliberately excluded, and what is pending — published unprompted.
Included today
- The router and margin-capture core: ingest, multi-rail routing, per-currency treasury, net-position hedging, pre-dispatch compliance, and five-line bps attribution.
- Three separate TLA+ specifications — ingest, routing, hedging — TLC model-checked.
- The native hot path: a Rust NIF (HMAC + simd-json + BLAKE3), a C++ MPSC ring and a group-commit WAL writer.
- The operational surface: 24 telemetry metric families, twelve SLOs with burn-rate alerts, and supervision-tree self-healing.
Explicitly scoped out
- Venue-specific endpoints — settlement adapters, quote sources, hedge venues, compliance screens — are wired by the operator behind well-scoped behaviours.
- v1.2 is the router and margin core; adapters ship with mock and reference implementations (HTTP templates for rails and hedge venues, a static quote source, a reference compliance screen) for tests and benchmarks.
Pending
- Burst handling at 1,000 concurrent connections: in Vlaander's run on the delivered archive, 9,800 of 20,000 requests failed at the connection level rather than receiving a 503; not yet diagnosed.
- WAL-persisted margin records, a custodian reconciler for settlement-uncertain intents, and real fuzzy OFAC matching (v1.3).
- IVMS 101 Travel Rule protocol, NIBSS name-enquiry pre-step, speculative parallel rail dispatch, and hedge cancellation (v1.3).
Who it's for
- Payment aggregators and PSPs moving from transport economics to principal economics.
- Stablecoin issuers and orchestrators building owned distribution rather than renting it.
- Mobile money operators and telco-adjacent wallets facing burst ingest from conversational and QR channels.
- Digital banks seeking last-mile margin attribution.
Before you buy
- Request the three TLA+ specifications and the TLC output; confirm the invariants stated match the invariants checked, and note that the models are bounded designs, not proofs of the code (spec/tla/README.md maps each action to the code).
- The source ships with the benchmark harness (bench/: vph, ack_sweep, crash_audit, under an hour), so after delivery you can rerun the acknowledgement latency, saturation rate and per-core rate on your own hardware and disk. Vlaander's figures come from a shared 4-vCPU VM. Sales are final once delivered, except where a remedy cannot lawfully be excluded.
- Check that each of your rail adapters is idempotent per intent id and reports a decline only when no funds moved; at-most-one-success depends on it.
- Rerun the burst test (mob-load burst) on your own hosts with the load generator on a separate machine, and tune the listen backlog and file-descriptor limits: on Vlaander's shared VM, 9,800 of 20,000 burst requests failed at the connection level instead of receiving a 503.
- Establish which of your settlement venues, quote sources and compliance screens require adapters, and cost that wiring separately.
- Confirm the v1.3 pending items (WAL-persisted margin records, custodian reconciler, fuzzy OFAC matching, IVMS 101) against your own go-live compliance gate.
What transfers
- The asset's sourceSubject to the Sale and Assignment Agreement, Vlaander assigns to the verified Buyer the transferable right, title and interest that Vlaander owns in the specified Asset. The assignment excludes Third Party Materials, open-source components, Vlaander’s pre-existing tools, generic know-how, development methods, trademarks, confidential information and any rights that cannot lawfully be assigned.
- Its testsThe test suite the published assurance claims rest on, as delivered in the source archive.
- Its audit artefactsSpecifications, model-checking output, reviews and the software bill of materials, where the asset has them.
- Not includedThird-party and open-source materials are not sold or assigned by Vlaander. They remain under their own licences, listed in each asset’s software bill of materials (SBOM.md in the archive), and the Buyer is responsible for complying with those licences.
First described in: VLA-GEN catalogue, 3 August 2026, §3.1. Revised by Vlaander against the delivered source; every figure is labelled with its basis.
From test to source
- 01
Check
Read the engine's page: what Vlaander measured and on which hardware, what it has not measured, and the open review findings. Nothing runs before purchase.
- 02
Buy
Verified businesses only. Place the order, give your company's details, have your authorised signatory sign the Sale and Assignment Agreement, then pay the invoice in naira by bank transfer, or in USDC on Polygon. Once the payment is verified, your account shows Paid.
- 03
Receive
We confirm the funds and release the source tarball to you. Delivering, then Download ready. Check it against the SHA-256 in Schedule 1, then rerun the tests and benchmarks yourself.