Security & trust
Before a financial institution puts a new system in its payment path, its risk committee, its auditors and its third-party-risk team each ask the same thing in different words: show me. TulaDB's posture is built to answer with mechanisms and tests — the most dangerous misconfigurations refusing to start, roles checked on every message, storage that fails closed, an audit trail you can verify offline — not claims you have to take on faith.
The questions you'll be asked
Each answer points at something that runs, with its check on the evidence page.
Nodes bind to loopback unless told otherwise. Beyond loopback, the node refuses to start if its cluster fabric lacks mTLS (that port grants cluster-admin), if credentials would travel without TLS, or if anonymous callers would get anything above read-only.
Denied, read-only, exporter, ledger-operator and cluster-admin, granted by pattern on the authenticated principal, where a deny wins a tie. An unknown message type needs cluster-admin, so new surface fails closed. Clients authenticate by mTLS certificate, API key (only its SHA3-256 digest is stored) or OIDC token, and a connection’s rights expire with its token.
Opt-in at-rest encryption seals the WAL, snapshots, account store and indexes with AES-256 and an HMAC-SHA256 tag, so a modified block is refused rather than decrypted to garbage. Startup fails closed without a key, and a node holding secrets keeps them out of core dumps.
An opt-in audit log records every accepted request — principal, role, operation, a SHA3-256 of the payload and the result — as a hash chain that an offline verifier checks, with HMAC watermarks you can anchor offsite. The operator console keeps its own log of every change.
Vendor due diligence
A bank's vendor-management team will ask these before a pilot. Here is where each stands today, including what is not in place yet. The same answers are in the two-page brief (PDF).
downloads.tuladb.com with a SHA256SUMS manifest, a keyless cosign signature over it from the product's release workflow at the release tag, and a trusted root to verify it offline; CI re-verifies every file before the Downloads page lists it. The server installer also checks its embedded release against the digest recorded at build time. The evaluation-stack installers verify their own SHA-256, refuse to run piped from the network and pin the digests of what they fetch. Container images are pinned by tag, not digest. All seven 0.0.1-preview downloads are published and verified this way.Shared responsibility
The guarantees TulaDB makes in preview, and the controls that remain the deploying organisation's responsibility.
Balanced mutation, durable identity, reservation lifecycle, rejected-outcome records, recovery artifacts — plus mTLS required beyond loopback, role-based authorization, storage encryption, and an opt-in tamper-evident audit trail.
Credential issuance and rotation, role-grant policy, rate limiting, audit-log retention, key management, network boundaries, and operational drills for your environment.
Before production
Preview readiness is for architecture review, performance review, and controlled pilots. Production use should follow deployment-specific work.
Developer preview
A shadow-mode pilot is a low-risk first step for a risk committee: TulaDB runs in your environment on replayed or anonymised traffic with nothing customer-facing depending on it, and every comparison with your books is evidence. We'll scope it with your architecture and security teams.