Nothing to sign up for
Prebuilt evaluation stack: no SDK, no source access, no account. Docker and curl are the only prerequisites.
The platform
The financial-state runtime, part by part.
TulaDB brings ledger semantics close to the write path. Balanced mutations, idempotency, the reservation lifecycle, rejected outcomes, deterministic ordering, and replayable recovery are treated as core system concerns — not conventions your services have to remember.
- Integer amounts
- Deterministic ledger mutation by default
- Two reference modes
- ISO-style or full SHA3-256 digest
- 2-phase value
- Reserve, commit, rollback, reject
- WAL-backed
- Restart and replay review
Double-entry core
Value moves in balanced pairs, or it doesn't move.
Every mutation is an atomic pair: a debit and its matching credit, applied under account-level sequencing. Posted and pending balances are tracked distinctly, account limits are enforced in the core, and duplicate operations resolve deterministically rather than double-applying.
Invariant: across any consistent read, the sum of debits equals the sum of credits. The balance isn't reconciled after the fact — it's a property of the write.
Atomic debit & credit
Both legs post together or not at all — no half-applied transfers.
Posted vs. pending balances
Available balance reflects holds; posted balance reflects settled value.
Account-level sequencing
Deterministic ordering per account keeps concurrent activity explainable.
Enforced account limits
Limit checks live in the core, not in whichever service happened to write.
Reservation lifecycle
Holds are a state, not a flag.
A reserve holds the debit side without posting the credit. A commit releases the hold and posts the credit. A rollback releases the hold and posts nothing. Each transition is a durable, ordered outcome — so a hold can never quietly leak into an unbalanced state.
TransitionDebit sideCredit sideOutcomeGuarantee
reservehold placednot postedPENDINGAvailable balance drops; posted balance unchanged
commithold releasedpostedPOSTEDExactly one settlement, idempotent under retry
rollbackhold releasednoneVOIDEDFunds return to available; trail preserved
rejectunchangedunchangedREJECTEDDurable record of the declined decision
RequestEffect
transfer · op-id 7f3a…
First delivery
transfer · op-id 7f3a…
Retry after timeout
transfer · op-id 7f3a…
Duplicate from queue
One operation identity → one financial effect, however many times it arrives.
Idempotency
A retry is not a second transaction.
Durable operation identity makes retries safe. The same stable caller identity returns the same outcome instead of creating duplicate effects — so timeouts, at-least-once queues, and client retries don't turn into double charges or phantom credits.
Deterministic duplicate checks derive financial identity from source identifier, ledger, currency, and transaction reference — using SHA3-256 with Base62 encoding for compact references, or the full digest when that mode is selected.
See it run
A local ledger, a transfer, and a retry that doesn't pay twice.
The evaluation stack — engine, REST gateway, and dashboard — comes up from one installer that verifies its own checksum before it does anything. Below is the quickstart as it runs on a laptop: post a transfer, submit the byte-identical request again, and watch the engine replay the original result instead of moving value a second time.
# 1 — bring up engine, gateway, and dashboard
$curl -fsSLO https://raw.githubusercontent.com/TulaDB/tuladb-install/main/install.sh && sh install.sh
Dashboard http://localhost:3000 · REST gateway http://localhost:8080 · Engine localhost:7700 / 7800
# 2 — move 100 minor units from account 1001 to 1002
$curl -s -X POST http://localhost:8080/v1/transfer \ -H 'Content-Type: application/json' \ -d '{"source_id":1, "ledger_id":1, "currency":840, "debit_account_id":"1001", "credit_account_id":"1002", "amount":100, "txn_id":"quickstart-000001"}'
{ "ok": true, "result": { "status": 0, ... } }
accepted — the response also carries the transfer's permanent id and both balances after applying
# 3 — submit the exact same request again
$!! # the identical request, submitted again
{ "ok": false, "result": { "status": 1, "status_name": "OK_DUPLICATE", ... } }
ok:false because this submission didn't apply · status 1 because the effect already exists · the balance is still 100
# 4 — read it back
$curl -s "http://localhost:8080/v1/accounts/1002/balance?ledger_id=1¤cy=840"
posted, pending, and available components — holds are visible state, never a hidden flag
mTLS even in the demo
The installer generates local certificates because the engine hard-refuses privileged anonymous access on an exposed port.
Idempotency you can test
Duplicate detection is durable in the engine, not a cache in your application — so step 3 behaves the same after a crash.
Reference & amount modes
Identity and value follow explicit ledger policy.
TulaDB supports two reference-identity modes and deterministic amount handling. Payment-message standards stay at the integration edge; the resulting financial state stays deterministic, balanced, and recoverable in the core.
ISO-style references
35-character financial references for ISO 20022-oriented systems, derived compactly with SHA3-256 and Base62 encoding.
Full SHA3-256 digest
Digest-native reference identity when a deployment prefers the full SHA3-256 digest as the reference form.
Integer amounts
Amounts are stored as integers by default for deterministic ledger mutation and exact arithmetic.
Currency-scaled amounts
Decimal interpretation follows a per-currency scale policy of up to 8 fractional places, applied deterministically. The core does not parse ISO 20022 messages or ISO decimal formats.
Multi-tier value movement
Position and settlement movement can be applied atomically inside one ledger transaction.
Control-account funding
Funding and defunding seed or remove value while preserving double-entry correctness.
Positioning note: TulaDB can start with ISO 20022-compatible ledger semantics by default. It does not claim ISO 20022 certification, parse ISO messages in the core, or replace payment-network message validation.
Write path
Narrow to write, wide to read.
The mutation surface stays small and ordered. The read surface is broad and safe: balances, history, pending reservations, rejected records, and account search all come through a read-only path that never opens the ledger to mutation.
Validate
Request shaping and idempotency on a stable operation identity.
Order
Deterministic, account-level sequencing of the balanced mutation.
Persist
Durable, append-only outcome written ahead of acknowledgement.
Project
History, holds, and rejected records surfaced to the read path.
Accounting kernel vs. ledger system
How much of the ledger do you want to build yourself?
If you need the fastest possible double-entry atom and your team will build the reservation lifecycle, deduplication, rejected-record visibility, and settlement coordination above it, a minimal accounting kernel can be the right choice.
TulaDB is for teams that want those responsibilities built, tested, and owned below the application — closer to the financial state itself.
Minimal kernel
You own the lifecycle
A small accounting primitive; your services own lifecycle state, retries, reconciliation visibility, settlement choreography, and operational tooling.
TulaDB
The runtime owns the lifecycle
Holds, commits, rollbacks, rejected outcomes, deterministic duplicate checks, and atomic position-plus-settlement updates are part of the runtime contract.
Scope boundary
What TulaDB owns — and what stays above it.
TulaDB is not a payment switch, ISO 20022 parser, fraud engine, compliance workflow, or customer orchestration system. Those stay above the ledger. TulaDB owns deterministic financial state: balances, holds, postings, rejected outcomes, idempotency, and recovery.
Not a message parser
Payment and ISO message handling stay at the integration edge; the ledger receives validated financial intent.
Not workflow orchestration
Customer journeys, compliance flows, routing, and approvals stay in application services above the core.
A financial-state runtime
Durable balances, holds, postings, rejected records, deterministic retries, and recovery evidence.
Private preview
Evaluate the engine against your workload.
Review the write path, reservation lifecycle, idempotency, and recovery behavior with a controlled integration pilot.