Research & engineering

Evidence, not adjectives.

Technical studies on ledger correctness, resilience, and scale, each backed by open data you can inspect independently.

6 published studiesIndependent audit outputsSubscribe via RSS

Latest publication

Inside the system, under pressure.

Our benchmark series follows one question from correctness, through overload, to the next real capacity limit.

Diagram defining one transaction as a full authorize-and-capture payment cycle that commits one balanced double-entry ledger transaction, above a stepped load ladder of plateaus rising from 400 to 2,600 payments per second.

MethodologyAug 27, 20269 min read

How we load-test a ledger, and what a payment per second really means

A benchmark number is only as good as its definition. Here is exactly how we drive load against the ledger, what one transaction per second counts, and why the method maps to real production traffic rather than a lab trick.

Read analysis

From the archive

Foundational studies

Developer guidesSep 15, 202610 min read

From Points to Perks: Build a Loyalty System with WalletD

Use WalletD reward rules to turn captured payments into loyalty points and wallet credit, with practical guidance on rounding, retries, refunds, and launch checks.

Read analysis

Digital wallet connected to API code and transaction panels, illustrating the WalletD API wallet setup guide.

Developer guidesSep 13, 20269 min read

How to Set Up Your Own Wallet with WalletD API

Learn how to set up a digital wallet with WalletD API. Follow curl examples to create users, fund wallets, check balances, send money, and connect webhooks.

Read analysis

Architecture diagram showing payment traffic at 2,600 per second moving through horizontally scalable stateless compute, a removed write-path contention point, and a healthy ledger database at about half capacity, with all payments committed and zero hard or ledger failures.

EngineeringAug 27, 20264 min read

We pushed our ledger until something broke. It wasn't the ledger.

We kept driving the payment path until we found the next limit, removed a database contention point, and left the ledger database running at about half capacity at peak.

Read analysis

Admission-control diagram showing twice the normal request load entering a capacity gate: served work stays fast, excess receives an immediate busy-retry response, and the double-entry ledger remains balanced with zero errors, timeouts, violations, or double-spends.

EngineeringAug 27, 20264 min read

Fast and correct is half the job. The other half is failing safely.

Any system can look good at its rated load. We deliberately pushed the platform to twice its comfortable rate and watched whether it failed safely without moving the books.

Read analysis

Load-test diagram showing 1,600 payments per second, full delivery, equal debits and credits, an independent audit over 1,550,594 transactions, zero ledger violations, and about 26 percent writer processor use.

EngineeringAug 26, 20267 min read

We proved our ledger stays correct at 1,600 payments a second.

A ledger has one job it can never get wrong: the books must balance, always, no matter how much money is moving. We load-tested for speed and correctness, then published every number.

Read analysis