Lazy trampoline by ecdsa · Pull Request #10544 · spesmilo/electrum

ecdsa · 2026-03-24T15:37:11Z

This pull request allows a trampoline node to forward payments without having a channel_db, if it has direct channels to other trampoline nodes.

If we (the trampoline forwarder) receive a trampoline onion and we do not have a direct connection to the next trampoline, we will return an unknown_next_peer error, with a list of trampolines we have a channel with in the error data. The client will use that list to create a longer trampoline route.

Note that trampolines are written in the data field of the unknown_next_peer message. (we could use custom TLV fields instead, but that would only works if the route from the client to the trampoline is of length 1, so I think it is better not to).

f321x · 2026-03-31T11:57:34Z

    _allocate_fee_along_route(route, budget=budget, trampoline_fee_level=trampoline_fee_level)

    # check that we can pay amount and fees
    if not is_route_within_budget(


On the maximum trampoline fee level _allocate_fee_along_route will allocate the whole budget on all edges with placeholder fees.
If an additional next_trampoline gets added, the sum of the allocated fees will exceed the budget, so is_route_within_budget will fail.
You could deduct the next_trampoline fee from the budget so that the following _allocate_fee_along_route will only allocate the remaining budget to the remaining edges.

Not sure what you mean. The budget is passed to _allocate_fee_along_route, so I do not think the sum of allocated fees could exceed the budget. Or am I missing something?

Anyway, that would be a pre-existing issue.

oh, I see what you mean: the first edge does not have a placeholder fee, and _allocate_fee_along_route does not deduct that from its budget.

yes, the newly added next_trampoline here:

if next_trampolines and next_trampoline not in invoice_trampolines: next_trampoline = _choose_next_trampoline(next_trampoline, next_trampolines_ids, failed_routes) _extend_trampoline_route(route, end_node=next_trampoline, fee_info=next_trampolines[next_trampoline])

does already allocate fees for itself from fee_info=next_trampolines[next_trampoline].

Then _allocate_fee_along_route following below will split the whole PaymentFeeBudget between the edges with PLACEHOLDER_FEE on MAX_LEVEL trampoline fees.

So after that the actual allocated fees are budget + next_trampolione fee which exceeds the budget in is_route_within_budget.

So _allocate_fee_along_route should probably consider the fees that have already been allocated before and then only allocate the remaining budget to the edges with placeholder to ensure the whole budget is not exceeded(?)

…l_db if there is a direct path

If a trampoline forwarder fails to find a path, it may return a list of trampolines it knows how to reach, so that clients can add these trampolines to their route. The list of trampolines and fees is written in the error data of the 'update_fail_htlc' message.

Consider known feerates for route edges when allocating the feerate along the route by calculating the fees backwards from the destination. Based on spesmilo#10544

f321x · 2026-04-23T10:52:19Z

        if next_trampolines and next_trampoline not in invoice_trampolines:
            next_trampoline = _choose_next_trampoline(next_trampoline, next_trampolines_ids, failed_routes)
            _extend_trampoline_route(route, end_node=next_trampoline, fee_info=next_trampolines[next_trampoline])
+            # compute first_edge_fee (this is overshooting)


Isn't the same required for the legacy trampoline branch above, e.g. if we have
A ---(free)--> B (my_trampoline) --(next trampoline edge fee)--> C (next Trampoline) --(placeholder fee)--> D (invoice_pubkey) ?

Consider known feerates for route edges when allocating the feerate along the route by calculating the fees backwards from the destination. Based on spesmilo#10544