En Lightning-node som bare sitter og venter, tjener ingenting. Problemet er at kanaler sjelden forblir balanserte av seg selv: betalinger flyter én vei, og innen få dager har noden din all sin likviditet låst i utgående balanse på én kanal, mens en annen kanal er tom og ikke kan rute noe som helst. Dette kalles kanalubalanse, og det er den vanligste grunnen til at ellers velfungerende routing-noder mister inntekt og forwards. I denne guiden bygger vi et komplett oppsett for likviditetsrebalansering med LND, Lightning Loop og et automatisert rebalanseringsskript, fra grunnen og til produksjon.

Vi tar for oss både sirkulær rebalansering (selvbetalinger som flytter likviditet internt uten å røre kjeden) og Loop Out/Loop In (svap mellom Lightning og on-chain-lommeboken). Du får fungerende kommandoer, et cron-basert automatiseringsskript, konkrete kostnadsberegninger i ppm og sats, og en liste over fallgruver som koster ekte penger hvis du ikke ser dem komme. Målgruppen er deg som allerede kjører en LND-node og vil gjøre den til en pålitelig routing-node i stedet for en som bare ligger der.

Hva er kanalrebalansering, og hvorfor bryr noden din seg

Hver Lightning-kanal har en lokal balanse (det du kan sende ut) og en ekstern balanse (det den andre parten kan sende ut, som igjen er det du kan motta). Lightning Labs beskriver den vanligste metoden for å rette opp en skjevhet slik: man gjør en betaling til seg selv som trekker den lokale balansen fra kanaler med høy balanse og flytter den til kanaler med lav balanse. Det er selve definisjonen av sirkulær rebalansering, og det er fortsatt den teknikken flertallet av routing-operatører bruker i 2026.

Konsekvensen av å ikke rebalansere er konkret: en kanal med 100 % lokal balanse kan sende, men aldri motta. En kanal med 0 % lokal balanse kan motta, men aldri sende videre. Begge tilstander betyr tapte forwards, og tapte forwards betyr tapte rutingsgebyr. Lightning Labs’ egen dokumentasjon for optimal nodekonfigurasjon påpeker at rebalansering ikke er strengt nødvendig for en konkurransedyktig routing-node, men at det kan være nyttig å flytte likviditet inn eller ut av bestemte kanaler når den potensielle inntjeningen på kanalen er høyere enn kostnaden ved å rebalansere. Det er nøkkelordet: kostnaden må alltid vurderes mot forventet inntekt, aldri gjøres automatisk uten tanke.

Det finnes tre hovedverktøy for å løse problemet, og de løser det på forskjellige måter:

  • Sirkulær rebalansering via keysend eller AMP: flytter likviditet mellom egne kanaler uten å røre blokkjeden. Billig, men begrenset av tilgjengelige ruter.
  • Lightning Loop Out: svapper Lightning-saldo til on-chain bitcoin. Fjerner overflødig lokal likviditet og gir deg penger på kjeden tilbake.
  • Lightning Loop In: svapper on-chain bitcoin til Lightning-saldo. Gir deg inngående likviditet når ingen sirkulær rute fungerer.

Bitcoin-pedagogen og nodeoperatøren Jameson Lopp har dokumentert sin egen praksis med å sette opp automatiserte rebalanseringsjobber, og det er nettopp den arbeidsflyten vi bygger videre på i denne guiden: planlagt, målt og loggført rebalansering, ikke tilfeldig klikking i et grensesnitt.

Forutsetninger og versjoner du trenger

Før du starter må noden din allerede kjøre og ha minst to åpne kanaler med noe routing-historie. Denne guiden forutsetter følgende versjoner, som er de nyeste stabile/beta-utgivelsene fra Lightning Labs per oktober 2026, dokumentert i kunngjøringen av LND v0.21 og i utgivelseslisten for Lightning Terminal:

KomponentVersjon brukt i guidenKommentar
LNDv0.21.3-beta (frittstående) / v0.21.4-beta (i Lightning Terminal-bundlen)Lansert juni 2026, med produksjonsklare Taproot-kanaler og onion-meldinger
Lightning Loopv0.35.0-betaPakket med Lightning Terminal v0.17.6
Lightning Poolv0.7.1-betaBrukes for likviditetsmarked, valgfritt i denne guiden
Lightning Terminal (LiT)v0.17.6Bundler LND, Loop, Pool og Faraday
Core Lightning (alternativ)26.06Samme rebalanseringsprinsipp, annen CLI (lightning-cli)
bitcoindsiste stabile versjon anbefalt av node-distribusjonen dinMå være fullsynkronisert

Du trenger også: SSH-tilgang til noden, grunnleggende kjennskap til lncli, minst to-tre kanaler med forskjellig balanseprofil for at øvelsene skal gi mening, og en liten buffer av on-chain bitcoin til mining-gebyr hvis du planlegger å bruke Loop. Merk at Loop-versjonene over er merket beta, ikke endelig stabil, så sjekk alltid GitHub-utgivelsessiden for LND før du oppgraderer en produksjonsnode.

Steg 1: Kartlegg kanalenes nåværende balanse

Du kan ikke rebalansere det du ikke har målt. Start med å liste alle kanalene og deres nåværende lokale og eksterne balanse:

lncli listchannels | jq -r '.channels[] | "\(.chan_id)\t\(.remote_pubkey[0:12])\tlocal=\(.local_balance)\tremote=\(.remote_balance)\tcapacity=\(.capacity)"'

Output ser typisk slik ut:

854210948825088	02a1b3c4d5e6	local=4820000	remote=180000	capacity=5000000
881739221811200	03f7e8d9c0b1	local=120000	remote=4880000	capacity=5000000
902156734128128	028899aabbcc	local=2510000	remote=2490000	capacity=5000000

Her ser du umiddelbart problemet: den første kanalen er 96,4 % lokal (kan nesten ikke motta mer), den andre er 2,4 % lokal (kan nesten ikke sende mer), og den tredje er nær perfekt balansert på 50,2 %. Målet med rebalansering er å flytte sats fra kanal én til kanal to, slik at begge nærmer seg en sunnere fordeling, for eksempel 30-70 % i stedet for 96-2 %.

Regn ut balanseprosent for hver kanal med en enkel formel:

lokal_prosent = (local_balance / capacity) * 100

En grei tommelfingerregel er å flagge enhver kanal som ligger under 20 % eller over 80 % lokal balanse som kandidat for rebalansering, forutsatt at kanalen faktisk ruter trafikk regelmessig. En kanal som aldri ruter noe, er ikke verdt å rebalansere uansett balanseprosent.

Steg 2: Forstå den økonomiske formelen før du gjør noe

Rutingsgebyr på Lightning beregnes som en basisavgift pluss en sats i ppm (parts per million) av beløpet:

gebyr_msat = base_fee_msat + (belop_msat * fee_rate_ppm / 1000000)

For en betaling på 1 000 000 sats betyr det: 10 ppm koster rundt 10 sats, 100 ppm koster rundt 100 sats, 500 ppm koster rundt 500 sats, og 1 000 ppm koster rundt 1 000 sats. Dette er ikke universelle nettverkstall, men praksisnivåer som operatører jevnlig rapporterer: lavvolum- og konkurranseutsatte offentlige kanaler ligger ofte i null til 100 ppm-sjiktet, ordinære rutingkanaler i 50 til 500 ppm, og knappe eller bevisst restriktive kanaler kan ligge på flere hundre til over 1 000 ppm.

Når du sirkulærrebalanserer, betaler du gebyret til hvert mellomledd i ruten, men ikke til deg selv på start- og sluttpunktet. Hvis ruten går gjennom fire eksterne hopp som hver tar 100 ppm, blir kostnaden for en rebalansering på 1 000 000 sats omtrent:

4 hopp * 100 ppm * 1000000 sats / 1000000 = 400 sats i rutinggebyr

Regelen du må holde fast på er enkel å skrive, men lett å glemme i praksis: forventet fremtidig rutinginntekt på kanalen du fyller opp, må være høyere enn det du betaler i gebyr for å fylle den. En rebalansering er sjelden en direkte inntektskilde i seg selv, det er et verktøy for å holde en lønnsom kanal i stand til å fortsette å rute. Alex Bosworth, ingeniør hos Lightning Labs, har i et intervju med Bitcoin Magazine beskrevet selve mekanismen presist: “When we talk about circular rebalancing, it’s where you basically send payments out through one channel and then you receive them back in through another channel, so your net liquidity, your net balance stays the same minus fees.”

Steg 3: Sett opp Lightning Terminal med Loop og Pool

Lightning Terminal (LiT) bundler LND, Loop, Pool og Faraday i én prosess, og er den enkleste måten å få Loop-funksjonalitet på en eksisterende node. Last ned og installer siste utgivelse:

# Last ned siste Lightning Terminal-utgivelse (sjekk alltid eksakt filnavn på GitHub Releases)
wget https://github.com/lightninglabs/lightning-terminal/releases/download/v0.17.6/lightning-terminal-linux-amd64-v0.17.6.tar.gz
tar -xzf lightning-terminal-linux-amd64-v0.17.6.tar.gz
sudo install -m 0755 lightning-terminal-linux-amd64-v0.17.6/litd /usr/local/bin/litd

# Start litd mot din eksisterende lnd-instans
litd --lnd-mode=remote \
  --remote.lnd.rpcserver=localhost:10009 \
  --remote.lnd.macaroonpath=/home/bitcoin/.lnd/data/chain/bitcoin/mainnet/admin.macaroon \
  --remote.lnd.tlscertpath=/home/bitcoin/.lnd/tls.cert

Verifiser at Loop-klienten snakker med noden din:

loop --rpcserver=localhost:8443 getinfo

Forventet output bekrefter versjon og at tjenesten er koblet til:

{
    "version":  "0.35.0-beta commit=v0.35.0-beta",
    "serverVersion":  "0.35.0-beta",
    "lndVersion":  "0.21.4-beta"
}

Merk at LND-versjonen Loop rapporterer (v0.21.4-beta) kan avvike litt fra den frittstående LND-utgivelsen på GitHub (v0.21.3-beta), siden Lightning Terminal-bundlen og frittstående LND-repoet noen ganger tagges på litt forskjellige tidspunkt. Dobbeltsjekk alltid hvilken versjon som faktisk kjører med lncli version før du feilsøker noe som ser ut som en versjonskonflikt.

Steg 4: Gjør din første sirkulære rebalansering manuelt

Før du automatiserer noe, bør du forstå hva som skjer under panseret. En sirkulær rebalansering er en keysend-betaling fra din node til din node selv, som tvinges gjennom en rute som går ut én kanal og kommer tilbake en annen. Med LND kan du bruke lncli queryroutes og lncli sendtoroute, men det enkleste er lncli payinvoice kombinert med --outgoing_chan_id og --last_hop-flaggene for å tvinge start- og sluttkanal:

# Lag en keysend-betaling fra deg selv til deg selv
OWN_PUBKEY=$(lncli getinfo | jq -r '.identity_pubkey')

lncli payinvoice \
  --keysend \
  --dest=$OWN_PUBKEY \
  --amt=500000 \
  --outgoing_chan_id=854210948825088 \
  --last_hop_pubkey=028899aabbccddeeff00112233445566778899aabbccddeeff001122334455 \
  --fee_limit=500 \
  --timeout=60s

Her tvinger vi betalingen til å gå ut gjennom den overfylte kanalen (854210948825088) og komme tilbake gjennom den tømte kanalen, med en siste-hopp-pubkey som sikrer at pengene lander der vi vil. Flagget --fee_limit=500 setter et absolutt tak på hva du er villig til å betale i rutinggebyr, noe som er kritisk: uten dette kan LND i verste fall finne en dyr rute og bruke den.

Forventet output ved en lykket rebalansering:

Payment hash: 3a7f9c2e1b8d4f6a0c5e7b9d2f4a6c8e0b1d3f5a7c9e1b3d5f7a9c1e3b5d7f9a
Description:
Amount: 500000 sat
Fee: 215 sat
Finished in: 1.842s
OK (status=SUCCEEDED)

215 sats i gebyr for å flytte 500 000 sats likviditet, altså en effektiv kostnad på 0,043 %. Det er en billig forsikring hvis det åpner opp mottakskapasitet på en kanal som genererer jevn rutingtrafikk.

Steg 5: Bruk Loop Out når sirkulær rebalansering ikke strekker til

Noen ganger finnes det ingen rute med nok kapasitet til å flytte likviditeten internt, typisk når hele nettverket rundt deg er like skjevt som dine egne kanaler. Da må du gå via kjeden. Loop Out tar overflødig Lightning-saldo og svapper den til on-chain bitcoin, noe som frigjør mottakskapasitet på den overfylte kanalen uten å kreve en intern rute:

# Se tilgjengelige vilkår og estimert kostnad før du bekrefter noe
loop quote out --amt=1000000

# Utfør svap fra den spesifikke overfylte kanalen
loop out --channel=854210948825088 --amt=1000000 --conf_target=12

Forventet output fra quote-kommandoen før du bekrefter:

Swap Fee:        1850 sat
Estimated Miner Fee: 420 sat
Total Fee:        2270 sat
Effective rate:    0.227%

Legg merke til at totalkostnaden alltid er summen av tjenestegebyr, rutinggebyr til Loop-tjenesten, og estimert mining-gebyr på kjeden. Beregn alltid den effektive prosentkostnaden, ikke bare satsbeløpet, fordi små svap har en mye høyere effektiv kostnad siden de faste delene av gebyret fordeles på færre sats. En svap på 100 000 sats med samme faste gebyrer vil typisk lande på 2-3 ganger høyere effektiv prosent enn svapet over.

Steg 6: Bruk Loop In for å hente inngående likviditet

Loop In gjør det motsatte: du sender bitcoin på kjeden til Loop-tjenesten, og noden din mottar tilsvarende beløp på Lightning. Dette er nyttig når du har on-chain-saldo liggende ubrukt, men mangler inngående kapasitet på en kanal som ellers presterer bra:

loop quote in --amt=2000000
loop in --amt=2000000 --last_hop=028899aabbccddeeff00112233445566778899aabbccddeeff001122334455

Flagget --last_hop tvinger den innkommende Lightning-betalingen til å lande på den spesifikke kanalen du vil fylle, i stedet for å la Loop-tjenesten velge selv. Vær obs på at Loop In er avhengig av at Loop-tjenesten selv har tilstrekkelig utgående likviditet mot din node. I perioder med høy nettverksbelastning kan dette feile eller bli dyrere enn normalt, så sjekk alltid quote-kommandoen først.

Steg 7: Installer og konfigurer rebalance-lnd for automatisering

Manuell rebalansering fungerer for læring, men skalerer dårlig når du har et dusin kanaler. Det community-drevne verktøyet rebalance-lnd automatiserer prosessen basert på regler du setter selv. Installer det i et eget Python-virtuelt miljø for å unngå avhengighetskonflikter med andre nodeverktøy:

python3 -m venv ~/rebalance-env
source ~/rebalance-env/bin/activate
git clone https://github.com/C-Otto/rebalance-lnd.git
cd rebalance-lnd
pip install -r requirements.txt

Opprett en konfigurasjonsfil som setter grenser for hvor mye du er villig til å betale og hvilke kanaler som skal prioriteres:

cat > ~/rebalance-env/rebalance-lnd/.env << 'EOF'
LND_DIR=/home/bitcoin/.lnd
LND_NETWORK=mainnet
LND_GRPC_HOST=localhost:10009
REBALANCING_TIME_LIMIT=600
REBALANCING_FEE_LIMIT_SAT=500
REBALANCING_AMOUNT_SAT=500000
EOF

Verktøyet leser gjeldende kanalbalanser, identifiserer kanaler over 80 % lokal balanse som kildekanaler og kanaler under 20 % som målkanaler, og prøver automatisk ruter innenfor gebyrgrensen du har satt. Kjør det manuelt først for å se at konfigurasjonen fungerer før du setter det på cron:

python3 rebalance.py

Steg 8: Automatiser med cron og logg alt

Jameson Lopp har beskrevet sin egen praksis ganske direkte: "I set a cronjob to run a random rebalance every 5 minutes by adding this line to /etc/crontab", skriver han i sin guide til likviditetsstyring. Prinsippet er solid, men i produksjon bør du logge hvert forsøk slik at du kan regne ut faktisk avkastning senere, ikke bare anta at automatiseringen hjelper:

sudo tee /etc/cron.d/lnd-rebalance << 'EOF'
# Kjør rebalansering hvert 15. minutt, logg resultat med tidsstempel
*/15 * * * * bitcoin /home/bitcoin/rebalance-env/bin/python3 /home/bitcoin/rebalance-env/rebalance-lnd/rebalance.py >> /var/log/lnd-rebalance.log 2>&1
EOF
sudo chmod 0644 /etc/cron.d/lnd-rebalance

Følg med på loggen de første dagene for å fange opp mønstre som uendelig mange mislykkede forsøk mot samme kanal, noe som ofte betyr at gebyrgrensen din er satt for lavt for nettverksforholdene akkurat nå:

tail -f /var/log/lnd-rebalance.log | grep -E "SUCCEEDED|FAILED"

Steg 9: Beregn faktisk lønnsomhet per kanal

Automatisering uten måling er bare gjetting med ekstra steg. For å vite om rebalanseringen faktisk er verdt det, må du holde to tall opp mot hverandre per kanal over en gitt periode, for eksempel 30 dager:

Kanal (kort-ID)Rutinginntekt 30 dager (sats)Rebalanseringskostnad 30 dager (sats)Netto (sats)Vurdering
85421094882508818 4006 20012 200Lønnsom, fortsett å rebalansere
8817392218112002 1005 900-3 800Urentabel, vurder å stoppe automatisk rebalansering
9021567341281289 70009 700Naturlig balansert, krever ikke inngripen

Kanal to i tabellen er et klassisk eksempel på hvorfor blind automatisering uten grenser kan gjøre noden din mindre lønnsom, ikke mer. Verktøyet clams.tech beskriver dette som selve kjernen i å forstå nodelønnsomhet: tallet du trenger er ikke bare "rutet jeg noe", men "tjente jeg mer enn jeg betalte for å kunne rute det".

Steg 10: Sett fornuftige gebyrpolicyer som reduserer behovet for rebalansering

Den beste rebalanseringsstrategien er ofte å rebalansere mindre, ved å justere utgående gebyrer dynamisk slik at kanalen naturlig holder seg balansert. Hvis en kanal konsekvent tømmer seg for lokal balanse, hever du heller den utgående satsen på den kanalen for å dempe videre utgående trafikk:

lncli updatechanpolicy \
  --chan_point=abc123...:0 \
  --base_fee_msat=1000 \
  --fee_rate_ppm=350 \
  --time_lock_delta=80

Når lokal balanse er lav, senker du heller den utgående satsen for å oppmuntre til mer trafikk innover, siden du egentlig ønsker flere forwards gjennom den kanalen i den retningen. Kombinert med periodisk rebalansering gir dette en mer stabil kanal enn ren rebalansering alene, og det kommer helt gratis siden det bare er en policyoppdatering, ikke en betaling.

Steg 11: Overvåk HTLC-helse under rebalansering

En rebalansering er aldri ferdig før HTLC-en er avregnet. Mens en betaling er underveis, er likviditeten på begge kanaler i ruten reservert, men ikke nødvendigvis flyttet. Hvis en motpart i ruten har nedetid, er treg eller har en ustabil implementasjon, kan betalingen hefte lenger enn forventet:

lncli listchannels | jq '.channels[] | select(.pending_htlcs | length > 0) | {chan_id, pending_htlcs}'

Hvis du ser HTLC-er som har stått uløst i mer enn noen minutter, bør du undersøke CLTV-forfallstid og motpartens status før du antar at rebalanseringen bare "tar litt tid". En kanal tvunget til å stenges med hengende HTLC-er er langt dyrere enn selve rebalanseringskostnaden, fordi en force-close krever on-chain-oppgjør og låser midlene i flere dager til flere uker avhengig av tidslås.

Steg 12: Bygg et komplett overvåkingsdashbord med enkle skript

For å binde alt sammen i et fungerende prosjekt, lag et sammendragsskript som kjører daglig og gir deg et raskt helsesjekk-bilde av alle kanaler, siste rebalanseringer og netto lønnsomhet:

#!/bin/bash
# daily-rebalance-report.sh
echo "=== Kanalstatus $(date) ==="
lncli listchannels | jq -r '.channels[] |
  "\(.chan_id): local=\(.local_balance) remote=\(.remote_balance) aktiv=\(.active)"'

echo ""
echo "=== Rebalanseringsforsøk siste 24t ==="
grep "$(date -d '1 day ago' +%Y-%m-%d)" /var/log/lnd-rebalance.log | \
  grep -cE "SUCCEEDED" | xargs echo "Suksessfulle:"
grep "$(date -d '1 day ago' +%Y-%m-%d)" /var/log/lnd-rebalance.log | \
  grep -cE "FAILED" | xargs echo "Mislykkede:"

echo ""
echo "=== Forwarding-historie siste 24t ==="
lncli fwdinghistory --start_time=$(date -d '1 day ago' +%s) | \
  jq '[.forwarding_events[].fee_msat | tonumber] | add / 1000'

Sett dette skriptet på en egen cronjob som kjører klokken 07:00 hver morgen og sender output til e-post eller en loggfil du leser over kaffen. Det komplette prosjektet du nå har bygget består av: LND-noden selv, Lightning Terminal med Loop for kjede-svap, rebalance-lnd for automatisert sirkulær rebalansering, en cronjob for planlagt kjøring, og et rapportskript for daglig overvåking. Dette er nøyaktig oppsettet erfarne routing-operatører kjører i produksjon.

Fem vanlige fallgruver ved rebalansering

  • Ingen gebyrgrense satt. Uten --fee_limit kan LND i prinsippet finne en dyr rute og fullføre den uten å spørre. Sett alltid en eksplisitt grense før hver betaling.
  • Rebalansering av kanaler som aldri ruter noe. Å flytte likviditet til en kanal uten etterspørsel er bortkastede sats. Sjekk forwarding-historien per kanal først.
  • For aggressiv automatisering. Å kjøre rebalanseringsskript hvert minutt uten grenser på daglig forbruk kan tømme en nodes driftskapital raskere enn rutinginntektene dekker.
  • Ignorerer effektiv kostnadsprosent på små beløp. Faste gebyrkomponenter gjør små Loop-svap uforholdsmessig dyre. Regn alltid ut prosent, ikke bare absolutt satsbeløp.
  • Stirrer blindt på balanseprosent uten kontekst. En kanal på 90 % lokal balanse som aldri ruter innover, er ikke nødvendigvis et problem som krever handling. Match alltid balansetall med faktisk trafikkmønster før du griper inn.

Åtte feilsøkingsproblemer og løsninger

  • Feil: "unable to find a path to destination". Ruten eksisterer ikke med nåværende likviditet og gebyrgrense. Prøv et lavere beløp eller hev gebyrgrensen marginalt.
  • Feil: "insufficient local balance". Kildekanalen har mindre lokal likviditet enn forsøkt beløp etter at ventende HTLC-er er regnet med. Vent til pågående betalinger er avregnet, eller reduser beløpet.
  • Loop-svap sitter fast i "pending" lenge. Sjekk loop monitor og bekreftelsesstatus på kjeden. Ved lav gebyrsats under høy nettverksbelastning kan bekreftelse ta betydelig lenger enn conf_target antydet.
  • rebalance-lnd krasjer med gRPC-feil. Macaroon- eller TLS-sertifikatsti i konfigurasjonen stemmer ikke med LND sin faktiske filstruktur. Dobbeltsjekk absolutte stier i .env.
  • Gjentatte feil mot samme nabo-node. Motparten kan ha satt en lav maks-HTLC-grense i sin kanalpolicy. Sjekk lncli getchaninfo for den aktuelle kanalen.
  • Cronjobben kjører ikke. Sjekk at brukeren spesifisert i crontab har tilgang til virtuelt miljø og LND-macaroon. Test manuelt med samme bruker via sudo -u bitcoin python3 rebalance.py.
  • Loop-kommandoer gir "permission denied" på RPC. litd kjører med en annen macaroon enn den du forventer. Spesifiser riktig macaroon-fil eksplisitt med --macaroonpath.
  • Rebalansering ser ut til å lykkes, men balansen endrer seg ikke. Du rebalanserte sannsynligvis mellom feil kanalpar, eller beløpet var for lite til å gi en målbar endring. Verifiser med listchannels rett før og rett etter forsøket.

Avanserte tips for erfarne nodeoperatører

Når grunnoppsettet fungerer stabilt, er det tre forbedringer som gir mest igjen for innsatsen. Først: bruk AMP-betalinger (Atomic Multi-Path Payments) for større rebalanseringer der ingen enkelt rute har nok kapasitet. AMP splitter betalingen i flere kryptografisk lenkede deler som kan ta forskjellige ruter samtidig, men vær forberedt på mer kompleks feilsøking siden en delvis feilet AMP-betaling krever at du forstår hvilke deler som faktisk gikk gjennom.

For det andre: kombiner rebalansering med dynamisk gebyrstyring ved å la et skript lese forwarding-historie hver time og justere fee_rate_ppm automatisk basert på balanseretning, i stedet for å rebalansere og la gebyrene stå statiske. Dette reduserer samlet rebalanseringsvolum over tid fordi kanalene i større grad balanserer seg selv gjennom prisinsentiver.

For det tredje: sett en daglig budsjettgrense i rebalanseringsskriptet, for eksempel maks 10 000 sats i rutinggebyr per døgn uansett hvor mange forsøk som gjøres. Dette er den enkleste måten å unngå at en feilkonfigurert automatisering blør noden tom over en helg du ikke sjekker loggene. LightningNetwork+ har pekt på nettopp dette som kjernen i god rebalanseringspraksis: "Rebalancing is how you turn stranded liquidity into usable inventory, so you can accept and forward more reliably and earn fees more consistently." Det handler altså ikke om å maksimere antall transaksjoner for sin egen skyld.

Sirkulær rebalansering versus Loop: når bruker du hva

SituasjonAnbefalt metodeTypisk kostnad
Nok intern likviditet finnes i andre kanalerSirkulær rebalansering (keysend/AMP)0,02–0,1 % av beløpet
Hele lokalt nettverk er skjevt i samme retningLoop Out0,15–0,3 % av beløpet, høyere på små svap
Mangler inngående kapasitet og har on-chain-saldo ledigLoop In0,15–0,3 % av beløpet, avhenger av miljøgebyr
Kronisk ubalanse på samme kanal uke etter ukeJuster gebyrpolicy i stedet for å rebalansere0 sats, bare tapt potensiell trafikk

Hvordan rebalansering påvirker nodens samlede rutingøkonomi

Det er lett å tenke på rebalansering som en isolert handling, men den riktige måten å vurdere det på er som en investering i fremtidig kapasitet. Hver sats du bruker på å flytte likviditet til en kanal, er sats du i prinsippet gir opp muligheten til å bruke et annet sted, enten som driftskapital eller som likviditet du heller kunne latt stå i en annen kanal. Lightning Labs beskriver dette presist i sin dokumentasjon for optimal nodekonfigurasjon: rebalansering er ikke strengt nødvendig, men det er nyttig akkurat der den forventede inntjeningen på kanalen overstiger kostnaden ved å flytte likviditeten dit.

Dette betyr i praksis at du bør føre et enkelt regnskap, ikke bare kjøre skript og glemme det. En node med ti kanaler og automatisert rebalansering uten grenser kan fort ende opp med å betale mer i rutinggebyr til naboer enn den selv tjener i rutinggebyr fra kunder, spesielt i perioder med lav nettverksaktivitet der rutene blir dyrere og mindre forutsigbare. Den daglige rapporten fra steg 12 er ikke valgfri pynt, den er det som forteller deg om automatiseringen din faktisk er lønnsom eller bare holder deg opptatt.

Et annet poeng som ofte overses, er at god gebyrpolitikk reduserer behovet for rebalansering mer effektivt enn enda mer aggressiv automatisering gjør. Hvis en kanal konsekvent tømmes i én retning, er en justering av den utgående satsen på den kanalen ofte billigere over tid enn å betale for å fylle den opp igjen hver dag. Tenk på rebalansering som en nødbrems for akutte ubalanser, ikke som den primære mekanismen for å holde kanaler sunne over tid.

Sikkerhetsvurderinger ved automatisert rebalansering

Automatiseringsskript som rebalance-lnd krever gRPC-tilgang til noden din med en macaroon som i praksis kan sende betalinger på dine vegne. Dette er en reell angrepsflate, og den bør behandles med samme forsiktighet som selve LND-noden. Opprett en dedikert macaroon med begrensede rettigheter i stedet for å bruke admin-macaroonen direkte der det er mulig, og sørg for at konfigurasjonsfilen med gebyrgrenser og stier til nøkkelmateriale ikke er lesbar for andre brukere på systemet:

chmod 600 ~/rebalance-env/rebalance-lnd/.env
chown bitcoin:bitcoin ~/rebalance-env/rebalance-lnd/.env

Vurder også å kjøre rebalanseringsprosessen i en egen systembruker-kontekst uten root-tilgang, slik at en feil i skriptet aldri kan påvirke resten av serveren. Siden LND v0.21 har fått produksjonsklare Taproot-kanaler og utvidet onion-meldingsstøtte, er det verdt å holde seg oppdatert på sikkerhetsrettelser gjennom Lightning Labs' offisielle utgivelseskanaler i stedet for å la en node stå ukeoppdatert i produksjon.

Alternativet med Core Lightning: samme prinsipp, annet verktøy

Ikke alle kjører LND. Core Lightning (CLN), utviklet av Blockstream, nådde versjon 26.06 i løpet av 2026 og fikk da med seg kvanteresistent kanalfunksjonalitet i tillegg til de vanlige stabilitetsforbedringene. Den underliggende teknikken for rebalansering er identisk med LND: en selvbetaling rutes ut gjennom én kanal og tilbake gjennom en annen. Forskjellen ligger i verktøyene og kommandolinjen.

Først sjekker du kanalbalansene med lightning-cli i stedet for lncli:

lightning-cli listpeerchannels | jq -r '.channels[] | "\(.short_channel_id)\tto_us=\(.to_us_msat)\ttotal=\(.total_msat)"'

For selve rebalanseringen finnes det ingen innebygd kommando i kjernen av CLN, så de fleste operatører bruker community-pluginet rebalance, som installeres via lightningd-pluginmappen og eksponerer egne RPC-kommandoer:

# Installer rebalance-pluginet (community-vedlikeholdt)
git clone https://github.com/lightningd/plugins.git ~/cln-plugins
lightning-cli plugin start ~/cln-plugins/rebalance/rebalance.py

# Kjør en rebalansering fra én kanal til en annen
lightning-cli rebalance

Pluginet finner selv en rute som går ut gjennom from_scid og kommer tilbake gjennom to_scid, på samme måte som den manuelle keysend-kommandoen vi brukte med LND i steg 4. Logging og gebyrgrenser må settes opp separat, siden CLN-pluginet ikke har samme innebygde cron-integrasjon som Lightning Terminal. De samme prinsippene for gebyrgrenser, HTLC-overvåking og måling av lønnsomhet per kanal gjelder uansett hvilken nodeimplementasjon du kjører.

Lightning Network i Norden: hvorfor likviditetsstyring er relevant nå

Rebalansering er ikke bare en teknisk øvelse for globale routing-noder langt fra Norge. Kryptoadopsjonen i Norden har vokst merkbart: en kartlegging fra Nordic Blockchain Association i 2026 anslo at 2,5 millioner voksne i Norden nå eier krypto, en økning på 326 000 nye eiere fra året før, noe som bringer adopsjonsraten til 11,1 prosent, opp fra 9,6 prosent. Samme kartlegging fant at unge voksne under 40 år i Sverige, Danmark og Norge i større grad eier krypto enn aksjer, med 1,53 millioner eiere av digitale aktiva mot 938 000 aksjeeiere i samme aldersgruppe.

Det betyr at flere nordiske brukere og små virksomheter har en praktisk interesse i at Lightning-betalinger faktisk går gjennom, uansett om de selv kjører en node eller bare er avhengige av at butikkens betalingsleverandør gjør det. En butikk eller et nettsted som tar imot Lightning-betalinger via en node med dårlig balansert likviditet, vil oppleve mislykkede betalinger nettopp i de periodene med høyest trafikk, det motsatte av hva man ønsker. Driftssikker likviditetsstyring er derfor ikke bare et spørsmål om inntekt for routing-operatøren selv, men om hvor pålitelig Lightning fungerer som betalingslag for alle som er avhengige av at nettverket leverer.

Her ligger også grunnen til at dokumentert, målt drift slår tilfeldig drift. En node som logger hver rebalansering, hver kostnad og hver inntekt, kan faktisk svare på om driften er sunn. En node som bare kjører et skript uten måling, vet ikke om den taper eller tjener penger på egen automatisering, og det er en dårlig posisjon å stå i når stadig flere nordiske brukere faktisk forventer at Lightning-betalingen deres går gjennom første gang.

Hva nettverksstatistikk faktisk kan fortelle deg om egen rebalanseringsstrategi

Det er fristende å lene seg på globale tall for total kapasitet, antall kanaler og antall noder i Lightning Network for å vurdere egen strategi, men vær forsiktig med å gjøre det ukritisk. Offentlige utforskere som Amboss, 1ML, mempool.space og lnrouter.app teller ofte forskjellige tall, fordi de har forskjellig syn på nettverkets gossip-data, utelater private kanaler i varierende grad, og oppdaterer med forskjellige intervaller. Et tall for "total kapasitet" fra en kilde kan derfor ikke uten videre sammenlignes med et tall fra en annen kilde samme dag.

For din egen rebalanseringsstrategi er det derfor viktigere å stole på dine egne målte tall enn på nettverksbrede snapshots: din egen forwarding-historie, dine egne rebalanseringskostnader og din egen kanalbalanse over tid. De fire kommandoene i steg 1, 9 og 12 gir deg nøyaktig det datagrunnlaget, uavhengig av hvilket tall en ekstern utforsker rapporterer samme dag. Hvis du likevel siterer et nettverkstall offentlig, bør du alltid oppgi eksakt måletidspunkt og hvilken utforsker tallet kommer fra, siden begge faktorer påvirker tallet markant.

Bruk Faraday til regnskap i stedet for manuelle utregninger

Tabellen i steg 9 kan regnes ut manuelt for noen få kanaler, men blir fort uoversiktlig med et dusin eller flere. Faraday, som følger med i Lightning Terminal-bundlen (versjon 0.2.19-alpha i LiT v0.17.6), er bygget nettopp for dette: det kobler seg til noden din og regner ut rapporter om inntekt, kostnad og netto per kanal over valgfrie perioder, uten at du må skrive egne jq-filtre for hver rapport.

# Faraday-rapport for siste 30 dager, gruppert per kanal
frcli report --start_time=$(date -d '30 days ago' +%s) --disable_fiat

Flagget --disable_fiat er verdt å kjenne til hvis du ikke vil at verktøyet skal hente valutakurser fra en ekstern tjeneste for å regne om sats til lokal valuta. For en norsk nodeoperatør som bare vil se tallene i sats, er det enklere og raskere å slå av denne funksjonen enn å vente på eksterne API-kall hver gang rapporten kjøres. Siden Faraday fortsatt er merket alfa-versjon, bør du teste rapportene opp mot egne manuelle beregninger den første uken før du stoler fullt på tallene i en driftsbeslutning.

Ofte stilte spørsmål om Lightning-kanalrebalansering

Er rebalansering nødvendig for alle Lightning-noder?
Nei. Lightning Labs' egen dokumentasjon er tydelig på at det ikke er strengt nødvendig for en konkurransedyktig routing-node, men det kan være lønnsomt på kanaler der potensiell inntjening overstiger rebalanseringskostnaden.

Hva er forskjellen mellom sirkulær rebalansering og Loop Out?
Sirkulær rebalansering flytter likviditet internt mellom dine egne kanaler uten å røre blokkjeden. Loop Out svapper Lightning-saldo til on-chain bitcoin og involverer en ekstern tjeneste og en kjede-transaksjon.

Hvor ofte bør jeg kjøre automatisert rebalansering?
Det finnes ikke et universelt svar, men start konservativt, for eksempel hvert 15. til 30. minutt med strenge gebyrgrenser, og juster frekvensen basert på hva den daglige lønnsomhetsrapporten din faktisk viser.

Kan rebalansering gjøre noden min mindre lønnsom?
Ja, hvis rebalanseringskostnaden overstiger den ekstra rutinginntekten kanalen genererer etterpå. Dette er grunnen til at måling per kanal, som beskrevet i steg 9, er avgjørende.

Hva skjer hvis en rebalanseringsbetaling setter seg fast?
Likviditeten på involverte kanaler forblir reservert til HTLC-en enten avregnes eller når sin tidsgrense. I verste fall kan en vedvarende fastlåst HTLC tvinge en kanal til en force-close, som er langt dyrere enn selve rebalanseringskostnaden.

Trenger jeg Lightning Pool for å rebalansere kanaler?
Nei. Pool er et likviditetsmarked for å kjøpe og selge kanalkapasitet og er et valgfritt verktøy. Rebalansering i denne guiden gjøres med sirkulære betalinger og Loop, uten at Pool er nødvendig.

Er LND v0.21 bakoverkompatibel med eldre rebalanseringsskript?
Oppgraderingen fra v0.21 fokuserer på Taproot-kanaler, onion-meldinger og migrering til SQL-backend, og endrer ikke de grunnleggende gRPC-kallene som verktøy som rebalance-lnd bruker. Test likevel alltid i et ikke-produksjonsmiljø før du oppgraderer en aktiv routing-node.

Hvordan vet jeg om en kanal er verdt å rebalansere i det hele tatt?
Se på forwarding-historien for kanalen de siste 30 dagene. Hvis kanalen jevnlig ruter betalinger og bare mangler likviditet i én retning, er den en god kandidat. Hvis kanalen aldri ruter noe uansett balanse, løser rebalansering ikke det underliggende problemet.