# Full Mesh Banking Network

## Overview

A payment network architecture built around a fully-meshed core of nodes that act as both routers and regional banks. The topology guarantees exactly three hops per payment, enabling a two-phase protocol with hash locks that replaces Lightning-style chained/decrementing timeouts with staggered deposits and a single timeout on the final hop. Credit clearing between routers uses 3-party novation with the same coordination mechanics as payments.

## Network Topology

The network consists of a **fully-meshed routing core** surrounded by spoke nodes.

- **Routing core:** A set of well-capitalized nodes (routers), each maintaining direct payment channels with every other router. Each router also acts as a regional bank.
- **Spoke nodes:** End users connected to exactly one router.
- **Credit clearing:** Routers run 3-party novation among themselves to net bilateral debts that accumulate from routing payments.

Every cross-bank payment follows the path **spoke → router → router → spoke**, which is exactly three hops. The full mesh guarantees that no routing path ever exceeds this.

- **Intra-bank payments:** When sender and receiver connect to the same router, the path is **spoke → router → spoke** (two hops). The same PREPARE/COMMIT/CANCEL mechanics apply, but with only one intermediary. Deposits are 1:1 — no staggered deposits needed. The first hop uses a CANCEL signature, the second hop uses a timeout.

## Protocol Mechanics

**Path:** Alice → Bob → Carol → Dave (payment amount N)

### Prepare Phase

A PREPARE state is established in the channel for each hop. Its output has two spend paths: COMMIT (requires preimage) and CANCEL (requires an authorized signature).

| Hop | Deposits | Who can CANCEL |
|-----|----------|----------------|
| A → B | Alice N, Bob N (1:1) | Bob |
| B → C | Bob N, Carol 3N (staggered) | Carol |
| C → D | Carol N, Dave 0 (HTLC) | Timeout only |

### Commit

Dave reveals the preimage. This makes the COMMIT spend path valid on all hops. Any party holding the preimage can unilaterally broadcast the COMMIT spend of the PREPARE output — no cooperation from the counterparty is needed.

The preimage propagates backward: Dave reveals it on C→D, Carol now has it and can commit B→C, Bob now has it and can commit A→B.

On C→D specifically: Carol can sign a cooperative commit once she has the preimage. If she refuses, Dave can force it on-chain via the HTLC.

### Cancel

Only the designated party on each hop can sign a CANCEL. Without the preimage, CANCEL is the only possible resolution on the first two hops.

### Race Rule

If a valid CANCEL signature exists, CANCEL takes precedence over COMMIT. This is enforced via a **dispute mechanism**: if someone broadcasts a COMMIT (using the preimage), there is a challenge period during which the counterparty can present a signed CANCEL to override it. This is deterministic on-chain resolution, not a mempool race.

### Timeout

A timeout exists **only on the final hop** (C→D). There are no chained or decrementing timeouts. Carol and Dave agree on the timeout length. Without mutual trust the timeout is short. With some degree of trust they can extend it, making the protocol more resilient to block congestion attacks. Trust is an option, not a requirement.

Why this matters: with timeouts on intermediate hops, a timeout expiring mid-chain can leave an intermediary stuck — having paid out downstream without getting paid upstream. With a timeout only on the final hop, this cannot happen — the payment simply never starts.

## Incentive Structure

Staggered deposits enforce CANCEL without a timeout. They serve the same role as the timelock in an HTLC, but replace time-locking with deposit-locking.

**Carol** stakes 3N on B→C — as much as Alice and Bob's combined deposits across the path. This makes griefing attacks pointless: Carol cannot lock up other parties' funds without locking up an equal amount of her own. If she cannot complete the payment, the deposit incentivizes her to cancel promptly. If she can complete it, she is already incentivized to commit.

**Bob** stakes N on A→B — equal to Alice's deposit. The same principle applies: Bob cannot lock up Alice's funds without locking up an equal amount of his own. If Carol does not accept the pending payment, or accepts but later cancels, Bob is incentivized to cancel A→B.

**Dave** stakes nothing — C→D uses a timeout, not a deposit lock.

## Routing Core Governance

The protocol requires a full mesh core but is agnostic about how membership is managed. The governance layer is separate from the payment mechanics.

## Credit Clearing via Novation

Routers continuously accumulate bilateral debts from routing payments. 3-party novation clears these debts: if router A owes B and B owes C, the debt is rerouted so that A owes C directly, eliminating B from the chain.

This has the same trust structure as a payment. A payment involves a buyer, two routers, and a seller — but buyer and seller are aligned (they both want the payment to succeed), so the effective structure is three parties that trust each other. Novation between three routers is the same: three parties with direct channels and mutual trust.

Because the structure is the same, novation uses the same 3-hop protocol mechanics — PREPARE with staggered deposits, COMMIT via preimage, CANCEL with dispute. One protocol for both payments and credit clearing.

## Key Properties

- **No chained timeouts:** Only the final hop has a timeout. No timeout cascading, no sensitivity to block congestion on intermediate hops.
- **No path finding:** The full mesh core means all paths are known. Any payment is always sender's router → receiver's router.
- **High transaction throughput:** Throughput scales with the number of routers. Every router pair can process payments in parallel.
- **Routing fees:** Routers earn fees for routing payments. Capital competes for router positions, making the core self-sustaining.