Skip to content

Digital Banking Reference Implementation

Digital Banking is John Whitton's non-production reference implementation for durable digital-asset settlement control planes across local Ethereum and Solana environments.

Problem

Moving a financial instruction through policy, signing, an external network, accounting, and reconciliation creates several different forms of evidence. An authenticated request is not signing authority. A signature is not submission. Submission is not finality. Network finality is not complete financial settlement.

The engineering problem is to preserve those boundaries through retries, ambiguous responses, restarts, and independently observed effects while keeping exact quantities, authority, and business state durable.

Approach

The reference implementation places business truth in a durable Java and PostgreSQL control plane. It uses stable command, workflow, operation, attempt, observation, and reconciliation identities rather than treating a chain response as the complete result.

Provider-neutral ports isolate signing, chain access, synthetic bank effects, and accounting. Explicit local profiles connect those boundaries to private Ethereum and Solana development environments. Default configuration remains fail-closed: local demonstration capability does not silently become a production integration.

Control-plane layers

LayerResponsibility
DomainExact quantities, stable identities, lifecycle transitions, authority rules, and independent finality state
ApplicationUse cases and provider-neutral ports for persistence, signing, chains, bank effects, accounting, and reconciliation
Control planeSpring APIs, composition, authenticated command handling, worker lifecycle, and operational interfaces
Chain and signing adaptersNative Ethereum or Solana transaction semantics and approved signing requests without moving provider types into the domain
Infrastructure and evidencePostgreSQL state, outbox/inbox delivery, observations, accounting entries, reconciliation, and retained local verification

The dependency direction is inward: adapters implement application-owned ports, application coordinates domain rules, and the control plane composes those boundaries. A chain response remains evidence consumed by the control plane; it does not replace durable business truth.

Token-operation lifecycle

  1. An authorized command is accepted with an exact amount, stable identity, policy context, and idempotency binding.
  2. The application durably creates the operation, planned external effects, and delivery evidence.
  3. A worker resolves server-owned asset, route, wallet, and signing context before creating a fenced attempt.
  4. A signer authorizes exact native material; Ethereum and Solana adapters preserve their own nonce, blockhash, submission, and observation semantics.
  5. Ambiguous responses are inquired by the original identity before any retry.
  6. Independently observed network, accounting, policy, and customer-visible evidence advances on separate clocks.
  7. Reconciliation compares those records and names incomplete or contradictory outcomes instead of rewriting history.

Local profiles use deliberately bounded development signers. Production custody remains outside the implementation; a future HSM or MPC provider would implement the same application-owned signer port without putting production keys or provider credentials into domain state.

What John built

John built the system design and implementation across:

  • a Java and Spring control plane with domain boundaries independent of the delivery framework;
  • PostgreSQL persistence, migrations, transactional outbox/inbox delivery, leasing, retry, and recovery;
  • exact-value operation and transfer workflows with versioned idempotency;
  • provider-neutral signing and chain-adapter boundaries;
  • local Ethereum execution through Anvil and local Solana execution through Agave and the SPL Token Program;
  • synthetic bank, accounting, reserve, supply, and reconciliation evidence for bounded demonstrations;
  • API contracts, architecture decisions, runbooks, retained verification records, and four immutable reference publications.

The implementation deliberately keeps API authority, signing authority, native-network evidence, accounting state, and customer-visible finality separate.

Verified scope

The reviewed implementation snapshot, inspected on 2026-07-25, records two bounded product demonstrations on both local Ethereum and local Solana:

  • acquisition, hold, and later redemption for a synthetic user-held flow; and
  • a settlement-only transfer whose recipient is forced through automatic redemption.

The demonstrations use exact synthetic amounts, durable PostgreSQL workflows, local network effects, restart recovery, and reconciliation assertions. This migration did not rerun those implementation gates; it reviewed the repository's retained status and evidence at the pinned commit.

The result demonstrates an executable reference boundary and disciplined delivery approach. It does not establish production readiness, regulatory approval, security certification, real-bank integration, public-network operation, or commercial deployment.

Boundaries and limitations

  • The software is deliberately non-production and must not be used with real funds, production credentials, mainnet accounts, public testnets, or production signing authority.
  • Bank balances, reserves, identities, accounting, policies, and network environments are synthetic local fixtures.
  • Production identity, custody, HSM or MPC integration, compliance operations, banking rails, audited accounting, and operational certification are outside the demonstrated scope.
  • The reference asset and public case-study language do not identify a real issuer, deposit product, reserve, named payment-network service, or announced implementation.
  • Immutable publications may lag the living implementation and must be read with their recorded revisions and limitations.

Go deeper