CashBridge. Reconciling payouts through exchange recovery

Our work

We developed the exchange workflow, financial ledger and custody integration for CashBridge. Our work covered deposit tracking, inventory-backed quotes, payout authorisation and recovery that reconciles an existing transfer before attempting another.

A customer sends BTC and expects USDC at a destination address. Behind that simple exchange, the service has to confirm the deposit, preserve the agreed price, reserve payout inventory and submit an irreversible transaction. If a worker crashes after submission, repeating the operation can send money twice. If it refuses to retry anything, the funded order can remain stranded. CashBridge's architecture makes that uncertainty a recoverable state with a specific transaction to reconcile.

The exchange workflow covers BTC, ETH and native USDC on their supported networks, with fixed and floating rates. CashBridge temporarily controls funds during an exchange, but does not maintain a customer trading balance. Its design connects three responsibilities: durable order execution, custody isolated from application servers and fixed quotes backed by reserved inventory. The first decision was to distinguish a customer obligation from the worker, workflow activity or blockchain submission currently processing it.

The order survives the worker

Each order has a Temporal workflow identified by its stable order_id. Workflow history coordinates deposits, confirmations, review, payout and exceptions. PostgreSQL holds the authoritative financial facts. After a failure, Temporal retries the activity against the same committed financial operation. Durable orchestration alone does not make an external transfer safe to repeat.

The financial core commits the order transition, balanced ledger entries, inventory changes and outbox record in one database transaction. Unique constraints protect operation identifiers and payout obligations. An outbox dispatcher then starts or signals workflows and delivers downstream events. If delivery repeats, consumers record an inbox key together with their local effect. The design accepts repeated messages while preventing those repetitions from independently changing the amount owed.

Accounting uses integer base units and balances entries within each asset. A BTC-to-USDC conversion has separate balanced legs against inventory and clearing accounts. It does not add unlike currency units into one balance. Reservations and pending transactions remain distinct from immediately spendable funds, giving recovery a financial position to reconcile rather than only a workflow status to resume.

A broadcast timeout is an unknown result

Consider an Ethereum payout worker that crashes immediately after submitting a USDC transaction. Before submission, CashBridge has already reserved the sending wallet's nonce and persisted the exact signed bytes and locally calculated hash. A replacement worker can therefore inspect the existing attempt through independent chain sources. If rebroadcast is needed, it sends those stored bytes. It does not allocate another nonce simply because the original RPC response is missing.

The payout intent describes the customer obligation. Attempts describe how that obligation reaches the network, including any authorised replacements. A stuck Ethereum transaction can receive a new fee envelope under the same nonce, recipient and amount, with replacement lineage retained. For Bitcoin, the system reserves specific UTXOs and tracks conflicting inputs across replacements. These are chain-specific controls beneath the shared rule that a retry belongs to the original payout.

The signing broker checks transaction meaning before release. Ethereum checks include the token contract, calldata recipient, amount and native value. Bitcoin checks include the destination, ownership of change and maximum fee. A successful Ethereum receipt also needs the expected token transfer before the payout is treated as delivered. A transaction hash or successful generic call is insufficient evidence of the intended USDC payment.

Finality remains separate from submission. Deposit observations retain block references, and indexers rescan overlapping ranges after restart while deduplicating events. Conflicting chain observations pause the affected eligibility decisions. If an accepted incoming deposit disappears after the customer has already been paid, the system records the resulting exposure or loss. Reverting an order row cannot reverse the outgoing blockchain payment.

Key isolation and payout authority: different problems

CashBridge generates secp256k1 wallet keys inside AWS KMS. Application databases contain key references, public keys, addresses and order metadata rather than private signing material. The configured application roles exclude kms:Sign, custody-role assumption and key-policy changes. Custody has a separate AWS account, private network and deployment boundary. An application host has neither the wallet key material nor authority to call the signing interface.

Non-exportability does not prevent misuse by a caller that already has signing authority. CashBridge separates the order service, payout authorizer and signing broker. The order service proposes a payout. The authorizer checks a funded obligation, its original recipient, risk decision, amount and cumulative limits using independently controlled, versioned evidence. The broker verifies the resulting short-lived authorization and decodes the transaction before invoking KMS.

Authorizations bind the order and payout identifiers, network, asset, destination, amount, reserved nonce or inputs, transaction digest, fee ceiling, policy version, expiry and operating epoch. Changing a fee requires fresh approval of the replacement transaction. The broker's durable registry rejects conflicting attempts for an existing obligation. KMS controls access to the cryptographic key; the authorizer and broker supply the business checks that KMS does not understand.

The residual risk determines treasury policy. A compromised broker with valid signing credentials could misuse its assigned online keys. Online balances and cumulative payout limits are therefore bounded, replenishment needs independent authorization, and reserves beyond operating needs stay in separately controlled offline custody. This makes the protection specific to the compromise boundary rather than claiming that hardware-backed keys make theft impossible.

Dedicated addresses have a lifecycle and a cost

Each order receives a dedicated deposit address, with an immutable mapping retained after expiry. Screening precedes any sweep into treasury, and deposit keys have different roles from payout-wallet keys. A late deposit cannot be ignored because the order's pricing window ended. The address remains monitored, and its funds enter the recorded exception process.

The selected KMS interface does not provide arbitrary BIP32 child derivation, so the design provisions per-address keys in a capped allocation pool. Provisioning ahead of demand keeps key creation outside the immediate order request path. Per-key costs and quotas constrain the allocation pool and route economics. Key retirement cannot delete access to historical addresses while unresolved balances or late-payment obligations remain.

A fixed quote becomes an inventory obligation

A displayed price is not yet a reserved payout. Accepting a quote atomically creates the order and reserves confirmed output inventory in PostgreSQL. Available inventory excludes accepted reservations, pending payout commitments and an operating safety buffer. Moving a reservation into a payout commitment removes it from the first category in the same transaction. Otherwise, the system could count one obligation twice or accidentally offer already committed funds to another customer.

Quote pricing considers executable depth, venue fees, network cost, volatility and inventory concentration. When capacity runs short, the service reduces the accepted size or stops the route. Redis can cache pricing inputs, but cannot decide whether funds are available. Quote acceptance records its inventory reservation in the same database transaction as the order, with stable operation identifiers retained for recovery.

Prefunded output wallets allow customer settlement to proceed independently of each treasury hedge. Treasury replenishes and hedges exposure through approved venues using persistent client order identifiers. An uncertain venue fill is reconciled before retrying elsewhere. A venue outage can consume the existing risk buffer without immediately blocking every eligible order, while new admission tightens as limits approach. This continuity requires committed capital and does not promise unlimited liquidity during a prolonged outage.

Deposit deadlines determine which price applies

An accepted fixed quote records the input and output amounts, observation deadline and maximum confirmation window. A valid deposit observed before its deadline retains its reservation while the recorded confirmation conditions remain satisfiable. Once the deposit is eligible, ordinary market movement and fee changes are the platform's exposure. An internal service outage does not silently convert that obligation into a worse quote.

Late, insufficient or risk-held deposits follow explicit decision paths. The customer can receive a replacement quote or an authorised refund under the accepted terms. Floating-rate orders instead price execution after deposit eligibility, subject to the disclosed fees and any customer-selected minimum output. Orders below that floor enter a decision path instead of executing automatically. Rate limits bound quote acceptance and address allocation, while inventory reservations and the capped key pool limit capacity assigned to unpaid orders.

The customer interface uses these distinctions directly. It separates confirmation waiting, review, payout preparation, broadcast and confirmation. Transaction references appear when available, and the original recipient is immutable after funding. Controlled refund or replacement-order procedures handle exceptions. A public order identifier is not an access credential; guest access uses a separate high-entropy secret exchanged for an authenticated session.

Releases preserve the order's original execution contract

An exchange may be awaiting confirmations while several releases occur. Versioned workflows keep running orders assigned to compatible workers, with old workers retained until their work drains or passes an explicit migration. Shutdown stops new polling and finishes or checkpoints safe activity work. Persisted signed transactions are not reconstructed merely because a newer serializer produces different bytes.

Financial schema changes expand first, backfill and migrate compatible readers and writers, then remove obsolete structures later. Argo Rollouts promotes canaries only while errors, latency, eligible-order age, signing failures, reservation consistency and reconciliation remain within policy. Surge capacity is reserved before deployment so new pods do not evict workers finishing funded orders. Custody releases use a separate protected path with security ownership.

Rollback restores compatible application behaviour, not the earlier financial world. A completed venue trade or chain payout remains real after code is rolled back. Restoring an old database snapshot would erase evidence of those effects, so destructive schema changes cannot be undone that way during ordinary application recovery. The recovery procedure reconciles recorded obligations and transaction attempts before resuming payouts.

Regional failover fences the old signing authority

The primary financial database uses synchronous replication across availability zones and verified single-writer failover. If synchronous durability is unavailable, money-changing writes pause instead of silently accepting a weaker guarantee. A warm recovery region has asynchronous database replication and pre-provisioned KMS replicas. That protects regional availability while leaving a possible gap in recently replicated financial records.

Before promotion, the recovery procedure fences the old region's database writers and signing identities. Changing an operating epoch alone cannot stop an isolated signer that never receives the new value. If fencing cannot be established, payouts remain paused. After promotion, the team measures the replication gap and reconciles deposits, venue fills, signed attempts, nonces and UTXOs across that interval. A missing payout row is not proof that no transaction reached the chain.

Independent attempt evidence and separately administered audit records help resolve the replication gap. Known-safe orders resume first, while ambiguous cases stay held. Database recovery, service availability and permission to resume payouts are separate decisions: restoring a process does not establish whether an uncertain transfer already reached the chain.

Recovery follows the money already committed

We tied recovery to persisted financial records. Deposit events retain their chain identity, quotes retain inventory reservations and payout attempts retain signed bytes, nonces or UTXOs. A restarted worker reconciles those records before advancing the order.

Balanced postings track the obligation within each asset. Reservation transitions keep committed inventory out of new quotes, and the authorisation path checks the original recipient and permitted amount. A payout and a refund resolve the same order obligation rather than creating independent withdrawal paths.

CashBridge connects the customer's accepted quote to a specific obligation and transaction. The ledger preserves what is owed, independent authorisation constrains what can be signed, and recovery resumes from the evidence of what has already happened.