Technology
Enough technical depth to establish how the system works, without publishing internals that would compromise security posture. Architecture diagrams and links point only to intentionally public repositories or documentation.
System topology
The visualization is deliberately architectural rather than promotional. Each boundary corresponds to a distinct responsibility and can evolve independently.
01
Bank, processor or market operator
02
Controlled external boundary
03
Deterministic canonical restoration
04
Durable local-first transaction state
05
Tamper-evident evidence and observability
Failure sequence
The system is designed around continuity through degradation. The sequence below describes the intended control flow without exposing private implementation details.
Nodes share canonical state under normal network conditions.
A node becomes isolated while retaining its last durable state.
Permitted writes continue locally with causal dependencies preserved.
Divergent state becomes available to the reconciliation service.
Deterministic rules restore an auditable shared state.
01
BuiltA layered system: a local-first state engine at the edge, a reconciliation service that merges node states into a canonical ledger, an institutional integration boundary, and an audit layer that observes every layer beneath it. Layers communicate through defined interfaces rather than shared internal state.
02
BuiltTransaction state is append-only and content-addressed: each state transition references the transitions it depends on, so the causal order of events is recoverable independent of wall-clock time or network arrival order. This is what allows a node to operate correctly while disconnected.
03
BuiltSettlement is coordinated by the Reconciliation Engine, which sequences merges deterministically and records the outcome of every settlement decision in the audit layer. Orchestration logic is separated from the state engine so settlement rules can evolve without changing how state itself is recorded.
04
ResearchThe Institutional API is being designed around a small set of primitives — submit, query, reconcile, observe — rather than a broad surface mirroring every internal capability. An SDK layer on top of that API is planned but not yet published; the API contract is being validated against integration scenarios first.
05
BuiltReconciliation lag, divergence windows, node health, and audit-log integrity are exposed as structured signals rather than derived after the fact from logs. Observability is treated as part of the infrastructure contract, not an operational add-on.
06
BuiltNode failure, network partition, and reconnection are handled as expected operating states rather than exceptions requiring manual intervention. A node that fails mid-write recovers to its last durable state on restart; a partitioned node continues operating locally and reconciles on reconnection.
07
BuiltThe Institutional API is the only externally reachable boundary into the system; internal layers do not accept direct external input. Every write is signed at its point of origin, and every access to the audit layer is itself audited. Security disclosure follows the process on the Contact page.
08
BuiltReconciliation correctness is tested against generated divergence scenarios — partitioned nodes, out-of-order delivery, duplicate submission, conflicting concurrent writes — rather than only against the happy path. Financial-integrity behavior is treated as a release gate, not a post-hoc check.
CubeShackles maintains a public technical and institutional root at github.com/CubeShackles. Not every internal repository is public — repository visibility reflects what is appropriate for external review at each stage, not the full scope of engineering work.
Developer resources
CubeShackles