A payment channel whose funds live in an ordinary Bitcoin 2‑of‑2, while its state is recorded on a Bitcoin Cash covenant instead of inside a private Lightning node.
No node. No watchtower. No “stay online to defend or lose your funds.” Two light, self‑custodial wallets — one key each — and a public chain that remembers the balance. This is T6.
The idea
Lightning keeps channel state inside a private node you must run and defend: lose that state, or go offline while a counterparty broadcasts a stale one, and you can lose funds. T6 keeps the same trust model — a Bitcoin 2‑of‑2 holding the value — but moves the state record onto the Bitcoin Cash chain, where it is public, permanent, and unloseable. The channel becomes two coupled halves, one secp256k1 key per party working on both chains.
Architecture
Versus Lightning
| Lightning | T6 | |
|---|---|---|
| Channel state lives in… | a private node’s database | the public BCH board |
| A persistent node / daemon | required | not run — two light wallets |
| A watchtower to catch a cheat | required (or you self‑watch) | the chain is the watchtower |
| Stay online to defend | yes — or risk a stale broadcast | no — the board can’t be overwritten |
| Private state you can lose | yes (commitments + secrets) | no — restore from seed + read the board |
| Who holds your key | you | you — never the peer, never the relay |
A payment
Computes the next state (new balances), signs that message with only its own key.
The proposal rides the relay to the peer, who checks it and signs with only its own key — a 64‑byte reply.
The payer broadcasts the update to the BCH board, paying only its own fee. Both sides now read the new state.
Proven on real coins
Two independent wallet processes — each holding only its own keys, coordinating through the keyless relay — opened a real channel, paid both directions, and cooperatively closed it. Every step is a live transaction on BCH chipnet (the board) and BTC signet (the funds).
Where it stands