An instant rail on your roadmap
You are joining, sponsoring, or routing across a real-time rail — or managing the liquidity behind one — and the posting layer is the part that worries you.
Design partner program
Prove it on your payments before anything depends on it.
We are taking our first design partners: institutions preparing for an instant rail — credit unions, sponsor banks, payment providers, hub vendors — that want to prove a real-time posting layer before anything depends on it. Each runs TulaDB in shadow mode in its own environment on replayed or anonymised rail traffic, compares it with its existing books, and shapes what comes next: the Real-Time Rail reference adapter and the liquidity layer above the ledger.
- Shadow mode
- Nothing customer-facing depends on it
- Daily reconciliation
- Every disagreement is a finding
- Your rail first
- The adapter is scoped against your message flows
- Direct access
- A line to the engineering team
A mutual commitment
A pilot with commitments on both sides.
Design partnership works because both sides put something real in. Here is the exchange.
What you get
A line to the engineering team
Talk directly to the people building the engine — not a ticket queue.
Influence over the roadmap
Your workload's needs weigh directly on what we prioritise next.
Early access to new capabilities
Evaluate what's next before it's broadly available.
Hands-on integration support
Help modelling your accounts and limits, and connecting your services to the ledger.
Evidence for your review board
Correctness and recovery artifacts you can take to architecture and security review.
What we ask
A real workload to model
Actual value-movement patterns from your system — not a toy example.
Regular, candid feedback
Tell us what works, what's missing, and what would block adoption.
A named technical contact
Someone on your side who owns the evaluation and can make decisions.
Willingness to run drills
Participate in controlled recovery and correctness exercises.
Time from your team
A working cadence across the engagement, not a one-off review.
How the engagement works
From first conversation to a working pilot.
A design partnership moves through four stages. Each one has a clear purpose, so both sides know whether to continue.
Fit conversation
Your rails, your core, and the problem that hurts most — posting, multi-rail balances, or intraday liquidity.
Model & map
Your accounts, settlement positions and limits modelled on the ledger; each rail's messages mapped onto holds, postings and refusals.
Shadow pilot
Replayed or anonymised rail traffic fed to TulaDB in your environment, and its balances and refusals compared with your existing books from the Iceberg export.
Decide on evidence
A record of every disagreement and its cause — the material your risk committee needs to go further, or not.
Who it's for
A good design partner looks like this.
Traffic you can mirror
Payment traffic you can replay or anonymise into a shadow ledger in your own environment, and existing books to compare it against.
You'll engage closely
A named technical owner and a team ready to give candid feedback across the engagement.
Still a developer preview: a design partnership is for architecture review, performance review, and controlled integration pilots. It is not a statement of general availability, production certification, or deployment approval — production use still requires deployment-specific security review, operational drills, and validation.
Questions buyers ask
Before the first call.
Design partner program
Bring your rail, your core and your liquidity problem.
Tell us which rails you're on or joining, how your core posts today, and which problem hurts most. Write from your work address — we reply within one business day — and we'll scope a shadow pilot.