01
Double-entry mutation core
Move value with atomic debit and credit updates, posted and pending balances, account limits, ordered mutation, and deterministic duplicate handling.
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, and immutable financial history — without forcing those guarantees into a generic transaction table.
Private preview: available for architecture review, performance review, and controlled integration pilots. Production use still requires deployment-specific security review, operational drills, and validation.
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 visibilityNative runtimePurpose-built ledger state engine
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.
02
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.
03
Tiered settlement model
Model position and settlement flows together, so direct and indirect settlement patterns do not split correctness across separate services.
04
Rejected transactions are records
Failed business decisions remain visible as durable records for audit, duplicate protection, customer support, and operational reconciliation.
05
SDK integration path
Private-preview evaluators can review integration patterns through SDK and gateway-oriented access surfaces.
06
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.
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 outcome
transferposted debitposted creditPOSTED
reservepending holdno credit yetPENDING
commitrelease holdposted creditPOSTED
rollbackrelease holdno creditVOIDED
rejectunchangedunchangedREJECTED
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.
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.