Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Test lane: fee-charging signet mint on CLN (inr2) + rune-authorized driver

Open
  • Is something wrong?
#415 3 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
infrastructure, payments, testing

Research direction

Start by reading the cloud-lab/QEMU suite and its existing mint-fees profile from #413, then inspect SECURITY.md and the cdk-mintd 0.17.6 CLN configuration referenced here (src/env_vars/cln.rs). First resolve whether inr2 exposes a co-locatable lightning-rpc socket or only clnrest; that decision determines the mint integration. Done means a signet profile tests fee refusal, net-of-fee credit, settled melts, reseller fees, rune-restricted access, and a keyset fee change across rotation.

Written by the indexing model from the issue text.

Description

Test-lane request: fee-charging signet mint backed by our CLN (inr2.cashu.exchange), rune-authorized test driver — the "real world" tier of the fee-mirroring test programme.

Why: real-world mints charge input fees; our signet mint does not. Verified today: testnut.cashu.exchange is a nutshell FakeWallet mint whose keysets all report input_fee_ppk: 0 — every fee behavior #409/#413 hardened (below-fee refusal, net-of-fee credit, keyset resolution) is currently invisible on the fleet that most resembles production. The lab's mint-fees (#413) covers the hermetic tier; what's missing is the signet tier where settlement is real (melt → Lightning invoice → payout lands) and keyset IDs/rotation shapes come from a real operator setup.

Proposed architecture (two components):

  1. mint-signet-fees — cdk-mintd 0.17.6 with the CLN backend (env vars verified against the 0.17.6 source, src/env_vars/cln.rs): CDK_MINTD_LN_BACKEND=cln, CDK_MINTD_CLN_RPC_PATH=<lightning-rpc socket>, CDK_MINTD_CLN_FEE_PERCENT, CDK_MINTD_CLN_RESERVE_FEE_MIN, plus CDK_MINTD_INPUT_FEE_PPK=100 to mirror coinos. cdk's CLN backend speaks the raw UNIX socket, not clnrest — so the wiring depends on what inr2 exposes (see decision below).
  2. Rune-authorized test driver — the test runner gets a CLN rune (restricted: invoice, listpays, listfunds) and drives/asserts the settlement loop directly: melt with fees → invoice created via rune → signet payment → payout observed. Runes also gate the driver's access without handing it the node.

Decision needed (infra, @Amperstrand): does inr2 expose lightning-rpc co-locatable (mount/socket-forward) or only clnrest (HTTPS+rune)?

  • (a) socket available → run mint-signet-fees co-located with (or SSH-forwarded to) the socket; no rune needed for the mint itself; driver uses clnrest+rune.
  • (b) clnrest only → a small socket↔clnrest bridge is required for cdk-mintd, or we contribute/reuse an existing one; alternatively evaluate cdk's grpc-processor/LND backends if the node multiplexes those.

Acceptance criteria:

  • A signet mint at a stable host with input_fee_ppk=100, settling through inr2's CLN.
  • Cloud-lab/QEMU suite extended with a signet profile: below-fee refusal + net-of-fee credit + melt-with-fee settlement (invoice paid on signet, payout received) + reseller chain with asymmetric fees (free upstream / fee downstream).
  • Test driver authenticated by a restricted rune; rune stored per the SECURITY.md secret rules (never committed).
  • Keyset rotation on the signet mint exercised at least once (fee change across rotation) to cover mintKeysetFees' inactive-keyset branch in production shape.

Hermetic predecessor landed meanwhile: #413 (mint-fees in cloud-lab, 4 e2e tests green). A keyset-rotation variant using cdk-mintd's CDK_MINTD_FAKE_WALLET_KEYSET_ROTATIONS (env verified in 0.17.6 source) is being added on top of it.

Refs: #409 (swap-fee handling), #413 (hermetic fee mint), #339 (v0.6.0), #403 (the fund-safety family that started this).

Dominant language
Go
Stars
12
Forks
14
Avg merge
1d 5h
Merged PRs (30d)
220

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from OpenTollGate/tollgate-module-basic-go

All issues in OpenTollGate/tollgate-module-basic-go

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.