Private-preview ledger database for value exchange systems

Financial state that stays balanced.

TulaDB gives payment, wallet, treasury, and settlement teams a dedicated system for balances, holds, reversals, rejected transactions, financial reference modes, and immutable financial history — without forcing those guarantees into a generic transaction table.

Request private preview Explore the engine

Private preview: available for architecture review, performance review, and controlled integration pilots. Production use still requires deployment-specific security review, operational drills, and validation.

private preview scope

tuladb review package

runtime       = deterministic ledger engine
model         = transfer, reserve, commit, rollback, reject
write path    = validate → order → persist → project
visibility    = balances, holds, rejected outcomes, history
recovery      = WAL-backed restart and replay review
integration   = SDK and gateway evaluation path
status        = private preview

review focus:
  - balanced financial state
  - explicit hold lifecycle
  - durable idempotency
  - explainable recovery
  - operational visibility

Reference modesISO-style or full SHA3-256 digest

2PCReserve, commit, rollback, reject

Multi-tierPosition + settlement flows

Private previewArchitecture review and controlled pilots

What users get

A ledger core for systems where balances must stay explainable.

TulaDB is designed for teams that need more than “insert a row and reconcile later.” It owns the balanced state transitions, durable operation identity, pending holds, rejected outcomes, and queryable history that value-movement systems depend on.

Double-entry mutation core

Move value with atomic debit and credit updates, posted and pending balances, account limits, ordered mutation, and deterministic duplicate handling.

Explicit reservation lifecycle

Use reserve, commit, and rollback as first-class operations. A reserve holds the debit side; commit posts the credit; rollback releases the hold.

Tiered settlement model

Model position and settlement flows together, so direct and indirect settlement patterns do not split correctness across separate services.

Rejected transactions are records

Failed business decisions remain visible as durable records for audit, duplicate protection, customer support, and operational reconciliation.

SDK integration path

Private-preview evaluators can review integration patterns through SDK and gateway-oriented access surfaces.

Read path separated from write path

Read balances, history, pending reservations, rejected records, and accounts through a read-only path that does not open the mutation surface.

Financial reference and amount modes

Financial references and value movement follow explicit ledger policies.

TulaDB supports two reference identity modes: ISO-style financial references for ISO 20022-oriented systems, or full SHA3-256 digest references when a deployment wants digest-native identity instead.

Amounts are stored as integers by default. When ISO 20022 mode is enabled, TulaDB applies currency-based decimal-scale interpretation for ISO-style amount handling, including 18,5 scale support where required.

Deterministic duplication checks can derive financial identity from source reference, currency, and source identifier using SHA3-256 with Base62 encoding for compact ISO-style references, or use the full SHA3-256 digest representation when that reference mode is selected.

Payment-message standards can remain at the integration edge; TulaDB keeps the resulting financial state deterministic, balanced, and recoverable in the core.

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.

Reference modeISO-style

FinX-style 35-character financial references for ISO 20022-oriented systems.

Reference modeFull SHA3-256

Digest-native reference identity when a deployment wants the full SHA3-256 digest as the reference form.

AmountsInteger

Amounts are stored as integers by default for deterministic ledger mutation.

ISO amountsCurrency scale

When ISO 20022 mode is enabled, decimal interpretation follows currency-based scale policy, including 18,5 support where required.

Value movementMulti-tier

Position and settlement movement can be applied atomically in one ledger transaction.

Funding flowsControl accounts

Funding and defunding seed or remove value while preserving double-entry correctness.

How this differs from a generic ledger

Why not just a transaction table?

Generic databases let you insert rows. TulaDB enforces the financial lifecycle beneath the application: reservations move through explicit states, rejected transactions remain visible, position and settlement can update atomically, and retries resolve deterministically.

Those guarantees live below your application code, so product teams do not depend on every service, job, migration, and support tool remembering the same accounting rules.

TulaDB is for teams that want ledger correctness to be a platform guarantee, not an application convention.

The product difference: TulaDB is not a table pattern. It is a mutation runtime for financial state that should not be accidentally bypassed.

Generic transaction tableApplication-owned safety

Rows can represent intent, but lifecycle, ordering, duplicate handling, rejected visibility, and cleanup live in services above the database.

TulaDBLedger-owned safety

Transfer, reserve, commit, rollback, and reject are first-class durable outcomes enforced by the ledger runtime.

Scope boundary

What TulaDB is not.

TulaDB is not a payment switch, ISO 20022 parser, fraud engine, compliance workflow, or customer orchestration system. Those systems can remain 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 can stay at the integration edge while the ledger receives validated financial intent.

Not workflow orchestration

Customer journeys, compliance flows, routing, and business approvals can remain in application services above the core.

A financial-state runtime

TulaDB focuses on durable balances, holds, postings, rejected records, deterministic retries, and recovery evidence.

Mental model

Every outcome has a durable shape.

TulaDB treats financial activity as durable state transitions. A retry should return the same outcome. A rollback should leave an explainable trail. A rejected transaction should still be searchable when operations teams investigate what happened.

Operation identity: stable caller identity makes retries deterministic and lets operations teams investigate the same financial event without creating duplicate effects.

OperationDebitCreditDurable outcomeWithout TulaDB

transferposted debitposted creditPOSTEDApp-level insert, no ordering guarantee

reservepending holdno credit yetPENDINGFlag in a column, easy to orphan

commitrelease holdposted creditPOSTEDSecond write, async failure window

rollbackrelease holdno creditVOIDEDManual cleanup, reconciliation risk

rejectunchangedunchangedREJECTEDDropped error, invisible to ops teams

Accounting kernel vs. ledger system

Minimal accounting kernels vs. TulaDB.

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

Best when the platform team wants a small accounting primitive and is ready to own lifecycle state, retries, reconciliation visibility, settlement choreography, and operational tooling in application code.

TulaDB

Best when the ledger layer should enforce holds, commits, rollbacks, rejected outcomes, deterministic duplicate checks, and atomic position-plus-settlement updates as part of the runtime contract.

Write path

A fast path with a clear ledger contract.

The write path stays narrow and explainable: validate the request, order the mutation, persist the outcome, and project it into queryable history.

Client / SDKstable operation identity

Ingressrequest validation and shaping

Ledger coreordered account mutation

Durabilitypersistent financial outcome

Query viewhistory, holds, rejected records

Architecture preview

Follow a transaction through the runtime.

This static architecture flow maps the private-preview runtime at a high level: SDK ingress, deterministic account mutation, durability, query projection, and replication review.

Gateway / SDK

Stable operation identity enters through SDKs, native access, or an authenticated adapter.

TulaDB Core

Validation, idempotency, reservation lifecycle, tiered transfer logic, and ordered mutation.

Durability

Persistent financial outcomes, recovery checkpoints, and immutable history projection.

Replication review

Leader/follower behavior, quorum progression, and controlled recovery review.

Query Plane

Balances, transaction history, pending reservations, rejected records, and account search.

Client API / SDK layerApplication-facing integration around a stable ledger contract.

↓

TulaDB CoreAccounts, duplicate protection, reservations, tiered flows, and ordered mutation.

↓

Durability planePersistent outcomes, recovery artifacts, and replay review.

↓

Query and audit planeImmutable history, account state, pending reservations, and rejected transactions.

↓

Replication modelLeader/follower operation and controlled recovery behavior for evaluation.

Architecture position

A balance system beneath workflows and above reporting.

Fraud checks, routing, customer orchestration, compliance, and network adapters can remain outside the ledger. TulaDB owns the part those systems should not improvise: durable, idempotent, balanced financial state.

This keeps the ledger core small, deterministic, and reviewable while business workflows remain configurable above it.

Request architecture review

Operations

Built for operators who need clear answers during incidents.

Operators need to answer practical questions quickly: what was accepted, what was rejected, what is pending, what recovered, and which safety posture is running. TulaDB exposes those concerns as explicit runtime and validation surfaces.

Safety posture is explicit

Private-preview review separates conservative operating posture from performance-oriented evaluation modes.

Recovery has artifacts

Durability, recovery, and replay behavior are evaluated through concrete runtime artifacts and controlled drills.

Security envelope is explicit

TLS/mTLS support is part of the private-preview security envelope. Production deployments should still validate authentication policy, rate limits, audit logging, and network boundaries.

Operator visibility

Private-preview evaluators can review the available operational surfaces for account state, transfers, reservations, rejected outcomes, and live runtime status.

Trust posture

Serious ledger systems need evidence, not marketing.

Verification targets are part of the private-preview evaluation package. They exist to produce evidence for correctness, recovery, and operational review without exposing implementation detail on the public site.

Core correctnessbalanced mutation, durable outcomes, reservation lifecycle, and failure handling

Model validationdeterministic correctness gates, restart equivalence, and replay checks

Recovery evidencecrash/restart and replay behavior under controlled validation

Replication reviewleader/follower behavior, quorum progression, and recovery review

Runtime checksmemory and undefined-behavior checks used as release evidence

Store verificationoffline consistency probes for review workflows

Preview status: TulaDB is ready for architecture review, performance review, controlled integration experiments, and design-partner discussions. Production use should follow deployment-specific security review, operational drills, and validation.