Learn/Settlement Rails
NH7 — Programmable Settlement Rails

Programmable Settlement Rails

Settle bilateral contracts automatically when pre-agreed conditions are met — time, price threshold, or event — with a cryptographic proof for every settlement. Double-settlement is mathematically impossible.

Explore settlement rails →

What is this?

Traditional bilateral OTC settlement involves emails, confirmation matching, and manual payment instructions. It's slow, error-prone, and leaves a compliance gap between trade execution and cash movement. Settlement Rails automates that last step. You define the conditions under which a bilateral payment should execute — a fixed date, a price crossing a threshold, an observable event — and the system watches for the trigger. When it fires, settlement executes with a unique SHA-256 proof, and both parties can verify it independently.

How it works

1

You define settlement conditions

Specify the trigger: a fixed date, a price crossing a threshold, or an observable event (index fixing, SOFR publication, binary outcome). Conditions are agreed bilaterally and attached to the contract record.

2

The condition sweep checks for triggers every 10 minutes

A background process runs every 10 minutes, evaluating all active settlement conditions against current market data and event feeds. When a condition is met, settlement is initiated.

3

Settlement executes — idempotency key generated, proof stored

A deterministic SHA-256 idempotency key is generated for the settlement. The system checks for duplicates (double-settlement impossible), then executes and stores a hash-chained receipt.

4

Counterparty verifies the proof independently

Both parties receive the settlement receipt with its SHA-256 hash. Either party can verify the proof in the Settlement Proof Explorer at any time — no Tomorrow intermediary required.

Trigger types

Time-based

Payment date fixed at contract inception (e.g., "T+2 from SOFR fixing on 15 June")

Price-triggered

Settles when a reference price crosses a pre-agreed level (e.g., SOFR > 5.25%)

Event-triggered

Settles on an observable binary outcome (e.g., index publication, election result, weather reading)

Manual confirmation

Both parties confirm settlement eligibility — system handles the rest automatically after confirmation

Key facts

SHA-256 idempotency key

Every settlement has a unique deterministic key. Double-settlement is mathematically impossible.

Bilateral — no custodian

Tomorrow does not hold margin or escrow. Funds move on your existing banking rails.

Hash-chained receipts

Each receipt is chained to the prior one. The chain is your regulatory evidence.

10-minute condition sweep

Conditions are checked every 10 minutes around the clock. No manual monitoring needed.

FAQ

How does the system prevent double-settlement?

Every settlement attempt generates a deterministic SHA-256 idempotency key derived from the contract ID, trigger type, and trigger timestamp. The system checks for an existing settlement with that key before executing. If one exists — even from a retry or a race condition — the duplicate is silently dropped. The same settlement cannot execute twice.

Is there a central custodian?

No. Settlement Rails is bilateral — funds move directly between you and your counterparty. Tomorrow does not hold margin, escrow, or act as an intermediary for the cash. The system coordinates the trigger and records the proof; the actual payment instruction runs on your existing banking rails.

How can my counterparty verify a settlement?

Every settlement receipt includes a SHA-256 hash of the settlement record, hash-chained to the prior receipt. Your counterparty can independently verify the hash against the Settlement Proof Explorer — no Tomorrow involvement required. The chain is the evidence.