Repository navigation
Fiber Dev Log 2026-10-01 #1676
chenyukang
started this conversation in
Dev Log
Fiber Dev Log 2026-10-01
#1676
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Updates
September 17–30, 2026
Fiber v0.10.0-rc1 was released on September 25, bringing the new full-payment-hash settlement format, improvements to payment recovery after force-closes, and support for multiple listening addresses.
Development after the release candidate continued around token-channel funding, while Hosted LSP work added more verification to the client-side signer.
Features
Full-payment-hash settlement lands in v0.10.0-rc1
The settlement-format work covered in the previous Dev Log is now included in Fiber v0.10.0-rc1.
The new format uses the full 32-byte payment hash for on-chain settlement, with support negotiated when a channel is opened and recorded for that channel.
The node also retains support for the legacy settlement format, allowing existing and newer channel formats to be handled separately. Corresponding commitment-lock changes have since been merged into
fiber-scripts.Migration support for existing databases is being developed separately and remains under review.
Improvements & Fixes
More reliable payment recovery after force-close
v0.10.0-rc1 improves payment recovery when a channel moves to on-chain settlement before an off-chain payment update has fully completed.
Fiber can now continue propagating a recovered payment result upstream after on-chain settlement, helping interrupted payments reach a consistent final state rather than stopping partway through the recovery process.
More flexible node operation
v0.10.0-rc1 adds support for multiple listening addresses, making it easier to run a node across different network endpoints, such as IPv4 and IPv6.
The release also corrects authorization for the
backupRPC so that it follows the intended node-write permission.Fixes for dual-funded token channels
Several related fixes have been merged for opening channels where both peers contribute UDT tokens.
The changes address how outputs, fees, and required script dependencies are handled when combining contributions from both sides. Together, they make funding transaction construction more reliable for dual-funded token channels.
Consistent hash algorithms for Trampoline payments
Fiber checks both sides of a Trampoline-forwarded payment use the same hash algorithm.
If the inner payment instruction specifies a different algorithm from the incoming payment, the forwarding request is rejected before Fiber attempts the next payment. This keeps payment-preimage validation consistent across the Trampoline flow.
Developer Experience
New tutorial for application-verified payments
A new interactive tutorial demonstrates how Hold Invoices can connect payment settlement to a result verified by an application.
In the example, a customer places a Testnet CKB payment on hold while the application checks a sample route-allocation result. The payment is released if the result passes verification or cancelled if it fails. The tutorial includes browser-node setup, channel and liquidity preparation, example verification flows, and a downloadable Next.js project.
The example is intentionally simplified: the solver results are predefined samples, and the browser controls the settlement key.
A follow-up documentation update is also improving Testnet funding and faucet guidance for the tutorial.
In Pipeline
Database migration for v0.10
Work is underway to support existing Fiber databases with the new commitment-contract features introduced in v0.10.
The proposed migration adds the new settlement-format information to existing channel and watchtower records while keeping existing channels on their legacy settlement format.
The migration is still under review and has not been released, so the upgrade restriction for v0.10.0-rc1 remains unchanged.
Hosted LSP adds more client-side verification
Hosted LSP development continued this cycle, with more verification being moved to the client-side signer.
Recent work focuses on giving the client-side signer more information to verify what the Hosted LSP asks it to sign. During channel opening, the SDK records the client’s intended funding parameters and verifies the returned channel information before establishing its initial local state. Later signing flows add checks around channel-state transitions, revocations, closing transactions, and other spending requests.
The aim is to give the client more ability to verify requests from the host rather than simply signing them as received.
The Hosted LSP implementation remains a work in progress and is not part of the current release.
All reactions