Infrastructure

One infrastructure layer. Jurisdiction-aware deployment.

Intermittent connectivity creates state divergence, delayed synchronization, and reconciliation risk. CubeShackles treats degraded-network operation as an architectural condition, not an exception — and integrates alongside existing institutional systems rather than replacing them.

BuiltCapability exists and can be demonstrated.

PilotBeing evaluated with an authorized counterparty.

ResearchTechnical or market hypothesis.

PlannedRoadmap only.

The five components

Offline State Engine

Built

Maintains a locally durable, cryptographically verifiable transaction state on any node, connected or not.

Every node holds a complete, append-only local record of the transactions it has processed. State transitions are signed at the point of creation rather than at the point of network confirmation, so a node operating without connectivity produces the same auditable record it would produce online. The engine treats "no network" as a normal operating condition, not a failure mode: writes never block on synchronization, and the local state is always internally consistent even while it is externally unsynchronized.

Reconciliation Engine

Built

Merges divergent node states back into a single canonical ledger once connectivity returns, deterministically and without silent data loss.

When a previously offline node reconnects, its local transaction log is compared against the canonical ledger using ordered, content-addressed transaction identifiers. Reconciliation is deterministic: given the same set of divergent logs, the merge always produces the same canonical result, and every merge decision is recorded rather than applied silently. Conflicting transactions are never auto-resolved by discarding one side — they are surfaced to institutional controls for explicit handling.

Institutional API

Research

The integration surface institutions use to connect existing core banking and payment systems to the reconciliation layer without replacing them.

The institutional API is the boundary between an institution’s existing core systems and the CubeShackles reconciliation layer. It is designed to be additive: an institution connects a read/write interface for its existing ledger rather than migrating that ledger onto CubeShackles infrastructure. This surface is currently in architectural and technical design, validated against integration scenarios rather than a live institutional counterparty.

Audit / Observability Layer

Built

Produces a continuous, tamper-evident audit trail of every state transition, reconciliation decision, and access event.

Every write to the transaction state, every reconciliation merge, and every administrative or institutional access event is recorded in an append-only audit log with cryptographic linkage between entries, so that removing or altering a past entry breaks verifiably from the entries after it. Observability tooling surfaces reconciliation lag, divergence windows, and node health as first-class signals rather than as a retrofit on top of the ledger.

Jurisdiction Adapter

Planned

A configuration layer that maps the core infrastructure onto the reporting, compliance, and settlement requirements of a specific jurisdiction.

Rather than encoding one jurisdiction’s regulatory model into the core system, jurisdiction-specific requirements — reporting formats, settlement windows, disclosure rules — are intended to live in an adapter layer above the shared infrastructure. Angola is the reference jurisdiction the first adapter is being designed against. This layer is roadmap work: the core infrastructure it sits on top of is built first.

System guarantees

Four properties the infrastructure is engineered to hold regardless of network condition.

Canonical state restoration

After any partition — a single offline node, a regional outage, a full reconnection after an extended offline period — there is exactly one canonical state, derived deterministically from the reconciled transaction logs. No node holds a "final" answer on its own; canonical status is a property of the reconciled ledger, not of any individual replica.

Replay protection

Every transaction carries a unique, monotonic identifier scoped to its originating node. Reconciliation rejects any transaction identifier it has already merged, so a resubmitted or duplicated message — whether from a retry, a network replay, or a reconnected node resending its log — cannot be applied twice.

Idempotency

Write operations are designed so that submitting the same operation more than once produces the same end state as submitting it once. This matters specifically in degraded-connectivity conditions, where a client cannot always confirm whether a prior submission was received before it retries.

Degraded-connectivity behavior

The system does not distinguish "slow network" from "no network" — both are treated as degraded-connectivity operation. Nodes continue accepting and recording transactions locally, queue outbound synchronization, and reconcile opportunistically as connectivity allows, rather than requiring a persistent connection to remain correct.

Integrate before replacing.

CubeShackles is designed as a reconciliation and integrity layer that sits alongside an institution’s existing core banking, payment, or ledger systems — not a replacement for them. Institutions connect the Institutional API against their own systems of record; CubeShackles does not require migrating balances, accounts, or transaction history off an existing core to participate. This reduces the operational and regulatory surface area an institution has to accept to evaluate the system.