# Fiber CCH Summary and Future Plan ## Metadata **Status**:: #x **Zettel**:: #zettel/fleeting **Created**:: [[2026-03-26]] ## Overview CCH (Cross-Chain Hub) is the cross-chain payment bridge in Fiber Network. It enables atomic swaps between CKB (via Fiber payment channels) and Bitcoin (via Lightning Network) using Hash Time-Locked Contracts (HTLCs). A hub operator runs both a Fiber Network Node and a Lightning node (LND), and facilitates cross-chain payments by locking funds on both sides with the same payment hash. The CCH module lives in `crates/fiber-lib/src/cch/` with supporting types in `fiber-types` and `fiber-json-types`. ## What Has Been Done - Swap between Bitcoin and a configured wrapped UDT script in CKB assumed to have the fixed 1:1 exchange rate with BTC. - Adopt invoices and multi-hop payments in both Fiber and Lightning. - CCH can be run as a separate service. ## Future Plan ### Multi-Asset Swaps #### Current Limitation Today, CCH only handles swaps between BTC (Lightning) and wrapped BTC (Fiber UDT), at a hard-coded 1:1 ratio. There is no negotiation — the hub config's `wrapped_btc_type_script` is the only supported asset, and the ratio is always 1:1 in satoshis. #### Design: Swap Acceptor RPC We can allow clients to specify the Fiber asset to use and the swap ratio when submitting the proposal via `send_btc` and `receive_btc`. However, that exposes risk to hub operators if they still auto accept all proposals. The swap acceptor is a **bidirectional streaming** endpoint, modeled after LND's `ChannelAcceptor`. A single persistent WebSocket connection carries proposals from the hub to the operator's acceptor client, and responses flow back. The operator's acceptor client can use price feed to determine whether to accept the proposal or any other strategy. ##### Wire Protocol (JSON-RPC Subscription) Since the Fiber RPC uses jsonrpsee over WebSocket, bidirectional streaming is implemented as a **subscription with client-initiated method calls** on the same connection: 1. The operator connects via WebSocket and calls `subscribe_swap_proposals` to open the subscription stream. The server begins pushing `SwapProposal` notifications. 2. For each proposal, the operator's client calls `respond_swap_proposal` with an accept/reject response (a normal JSON-RPC method call, not a subscription message). 3. Proposals that are not responded to within a configurable timeout are automatically rejected. ```mermaid sequenceDiagram participant OC as Operator Client participant CCH as CCH Node OC->>CCH: subscribe_swap_proposals Note right of CCH: user calls send_btc or receive_btc CCH-->>OC: SwapProposal (notification) OC->>CCH: respond_swap_proposal<br/>accept: true, ckb_amount, fee, ... Note right of CCH: another swap request arrives CCH-->>OC: SwapProposal (notification) OC->>CCH: respond_swap_proposal<br/>accept: false, reject_reason: "bad rate" ``` ### Swap Negotiation via P2P Now swap proposals are submit via RPC endpoints provided by CCH operators. This exposes a limitation that if you want to use the swap service, you must know the RPC endpoints of a CCH operator. It is also hard for operators to obtain new users. Swap negotiation via P2P can solve this. Operators broadcast advertisements about supported assets and the corresponding swap rate and fee rate. Clients can discover operators by monitoring these advertisements. It's also possible to build a hybrid payment path when swap advertisements are available and bound to Fiber nodes. For example, if Charlie wants to receive 1,000 CKB, Alice can send 50 xUDT to Bob, who then provides the swap service and sends 1,000 CKB to Charlie. ### Further: Protocol Improvements **PTLC migration path**: As noted in the cross-chain HTLC spec's "Future Works" section, Point Time-Locked Contracts offer improved privacy (payment hash unlinkability across hops), reduced on-chain footprint (adaptor signatures), and better security (wormhole attack resistance). Design the CCH interface to be hash-algorithm-agnostic so the PTLC transition requires minimal changes.