You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Read fee_claim into NodeConfig and hand it to the LSPS4 client builder, which
forwards it on register_node. The LSP verifies the grant and, if valid, drops
the node off the standard 2% skim.
The claim is node config, not a secret, so it lives in [node] fee_claim. The
MDK_FEE_CLAIM env var is a fallback for deployments that inject config through
the environment. config.toml wins when both are set. Unset everywhere is the
default until the issuer starts minting, which leaves fee_claim None and the
node on the standard policy.
The ldk-node bumps carry the client plumbing for the third
set_liquidity_source_lsps4 argument:
- ldk-node (variant client dep) f13fcead -> 06509b7a, pulling rust-lightning
9b5f40f0 (M1 + M2 + the register_node fee_claim parameter).
- ldk-node-lsp (lsp-0.7.0 dev-dep) e5fcce06 -> 6449e1b8, pulling rust-lightning
bdcdf57d (M1 + M2, no client parameter; this copy is the verifier).
The two pull different rust-lightning revs: existing arrangement, not a
regression. Client and LSP talk over the wire, so duplicate compilation is fine.
The integration test runs a node with a claim bound to its node id and asserts
the full 100k arrives instead of 98k, mirroring test_getbalance_after_payment.
It only passes if the LSP verifies the signature, so it covers the whole loop.
The claim hex is minted offline against the in-tree issuer secret; the
regeneration recipe is in a comment next to it. MDK-998 tracks replacing it
with a reusable mnemonic-bound vector once lightning-liquidity exposes a mint
helper.
0 commit comments