FIG.00 · LANDING
// V0.1 · Working draft · TS-BG-001

Coming soon,
very soon.

We are working hard for you. Lets meet again in Q4 2026. Have a great day, my friend.

Sign up
// 01 · Thesis
§ 2.1 · TS‐BG‐001

Most businesses run two ledgers without admitting it.

One ledger lives in your processor: cards, ACH, wires. Another lives in your custodian or wallet: USDC, BTC, ETH. A third — the spreadsheet — exists to make the first two agree by Friday afternoon. The spreadsheet is not a feature of your business. It is a bug you have not yet been able to engineer away.

Reconciliation is not a back-office task. It is a load-bearing system. We build it as one.

// 02 · What we operate

Three layers. One signed ledger.

We replace the integration sprawl you've been maintaining between your processor, your custodian, your wallet provider, and your fulfillment vendor — with one contract that covers all four.

01Acceptance

Accept any rail. Reconcile against one ledger.

Cards, ACH, wires, SEPA, and stablecoins on nine chains. Inbound funds land in a single signed event stream — no parallel books, no end-of-month bridge.

9 chains14 fiat
02Settlement

Median 11.4 seconds. Audited at every step.

Pre-funded liquidity pools settle on-chain transactions to your treasury in under thirty seconds at p99. Every state transition is signed, time-stamped, and queryable through one API.

p50 · 11.4sp99 · 28s
03Fulfillment

Trigger systems on confirmed state — not optimistic events.

Webhooks fire on confirmed settlement, not pending. Inventory release, KYC, payouts to suppliers — all keyed to a single canonical event with idempotency built in.

WebhooksgRPC
// 03 · Topology

Three loose ledgers.
One signed surface.

Most businesses keep three books in parallel: what their processor reports, what their custodian holds, what their fulfillment system has actually shipped. The triangle is a closed figure. So is ours.

60° 60° 60° b a c LEDGER AcceptanceCards · ACH · wires · on-chainCustodyFiat float · digital assetsFulfillmentInventory · payouts · KYC A B C FIG.01 · CLOSED LEDGER · △ABC
  • AAcceptance. Cards, ACH, wires, on-chain — every inbound rail normalizes into a single signed event shape.
  • BCustody. Pre-funded fiat float and segregated digital-asset wallets. Treasury holds the value; we operate the surface.
  • CFulfillment. Idempotent events fire on confirmed state — never optimistic, never replayed, never double-spent.
  • Ledger. The centroid. One canonical history shared across all three vertices. SQL, gRPC, webhook — same data, same signatures.
// 04 · Live ledger

One signed timeline.
Queryable from anywhere.

Every settlement, every fulfillment event, every reconciliation lives in a single tabular surface. SQL, gRPC, or webhook — same data, same shape, same signatures.

/v1/ledger · stream
last 90s·region eu-west-1·Live
timestampid · amount · raillatency · state
10:42:01 UTCtx_0x4f2a   €12,480.00   BTC ⇄ EUR12.4s · confirmed
10:42:14 UTCtx_0xa1c8   $980.00   USDC ⇄ USD8.1s · confirmed
10:42:29 UTCtx_0x3d77   £2,040.00   ETH ⇄ GBP14.9s · confirmed
10:42:48 UTCtx_0x8e02   €56,200.00   EUR ⇄ EUR0.4s · confirmed
10:43:02 UTCtx_0xb472   $320.00   BTC ⇄ USD11.2s · pending
10:43:18 UTCtx_0xc5e1   $8,400.00   USD wire0.2s · confirmed
SELECT * FROM ledger WHERE confirmed_at > now() - interval '90s'6 rows · 0.18ms
// 05 · Mechanism

What happens between the receipt and the books.

A single settlement, traced through the system. Every step is signed, every transition is logged, every event is replayable from the canonical record.

  1. T+0.0s

    Inbound event

    acceptance

    A customer pays in USDC on Ethereum. Our acceptance node observes the transaction in the mempool, signs an Ed25519 receipt, and writes a pending row to the ledger.

  2. T+0.4s

    Pre-funded credit

    liquidity

    The customer's account is credited against our pre-funded liquidity pool. Your fulfillment systems can act on this state immediately, without waiting for chain confirmation.

  3. T+11.4s

    Confirmation

    settlement

    The transaction is confirmed at the protocol level. The ledger transitions from pending → confirmed atomically. A signed webhook fires exactly once.

  4. T+11.5s

    Fulfillment

    fulfillment

    Your system receives the webhook, verifies the Ed25519 signature, and triggers downstream actions: inventory release, supplier payout, document signing — keyed to the canonical event.

  5. T+24h

    Daily attestation

    audit

    A signed Merkle root of the day's ledger is published to a public log and emailed to your security contact. Reconciliation is not a process — it is a property.

// 06 · Who we build for

Engineering teams operating across rails.

We are not a general-purpose payments processor. We are the layer companies adopt when settlement complexity has outgrown the spreadsheet.

§ProfilePrimary useWhere we fit
01MarketplacesCross-border payoutsYou collect in fifteen currencies, pay out in five chains, and need a single tax-reporting surface for it all.
02Asset platformsFiat ingress + custodyYour customers fund accounts in dollars and hold in stablecoins. We close the loop without a parallel ledger.
03B2B SaaSMulti-rail invoicingEnterprise customers pay by wire. Long-tail customers pay by card or USDC. Your finance team sees one A/R aging report.
04Logistics & supplySettlement-on-fulfillmentFunds release to suppliers when a package crosses a tracking event — not on optimistic invoice receipt.
05Treasury teamsReconciliation as a serviceYour existing rails stay where they are. We become the reconciliation layer above them — read-only or read/write, your choice.
Reconciliation is not a feature. It is the product.
Engineering Principle 01·Brand guidelines · TS-BG-001 · §2.1
// 07 · Engineering surface

The contract is the product.

We document the system precisely because we run it precisely. Our engineers read your tickets. Read the docs first — most questions are already answered there.

01

gRPC + REST

Bidirectional streaming for ledger taps. REST for control-plane operations. Same auth, same idempotency keys.

/v1
02

Idempotency built-in

Every state-changing call accepts a client-supplied key. Exactly-once semantics across retries and partition recoveries.

Idempotency-Key
03

Signed every step

State transitions are Ed25519-signed. Verify the chain end-to-end without trusting our infrastructure.

Ed25519
04

Webhooks on confirmed

No optimistic events. Webhooks fire on settled state with a verifiable signature header. Replay and dead-letter built in.

TS-Signature
05

SQL-shaped exports

Daily exports drop into your warehouse with a stable schema. Versioned migrations, never breaking changes without a deprecation window.

Parquet · CSV
06

Sandbox parity

A full deterministic replica of production. Settlement times can be advanced. State machines are inspectable.

sandbox.api
07

Audit & compliance

SOC 2 Type II. ISO 27001. Independent annual penetration tests. Customer audit logs retained per jurisdiction (≥5y).

SOC 2 · ISO 27001
08

Open observability

OpenTelemetry traces exposed for every customer call. Status page is RSS, JSON, and Atom. No black box.

OTel · status.api
FIG.99 · CONTACT
// 08 · Get started

Closed-loop commerce.
Four points. One ledger.

An engineering call is the fastest way to know if we're a fit. Thirty minutes, an architecture diagram, no slide deck. We will tell you if we are not a fit.

Read the docs
/v1 · contact surfacelast verified 2026-04-29
Sandboxsandbox.tetrahedron-systems.com
APIapi.tetrahedron-systems.com/v1
Statusstatus.tetrahedron-systems.com
SecurityPGP · 0x4f2a · keys.openpgp.org
Disclosures/legal · TS-LEGAL-001