Conditional Recall

Conditional Recall is an experimental frontend flow for short-lived HTLC traffic analysis.

It combines a forwarding-history baseline with a bounded live HTLC window, then reduces that activity into per-channel pressure and draft fee suggestions for manual review.

What it does

During a session, the app:

1. loads recent forwarding history from LND
2. opens the HTLC event stream for a bounded live window
3. aggregates that activity by channel
4. derives friction metrics from attempts, settles, failures, and failed volume
5. emits draft fee suggestions when the current thresholds are met

The final result keeps channel-level aggregates and suggestions only. It does not keep raw HTLC paths, hashes, or per-event routing detail in the final output.

What it needs

• an active browser node session
• an LND REST host
• a routerrpc macaroon in hex
• a lookback window in days
• a live collection window in seconds
• optional Allow self signed TLS

Both inputs matter:

• the browser node session provides channel hints and current fee hints from the node you already connected
• the REST host and macaroon provide forwarding-history access plus the live HTLC event stream

How to use it

1. connect your node in the browser
2. open Conditional Recall
3. enter the REST host and macaroon hex
4. set Lookback days and Live window seconds
5. enable Allow self signed TLS if your local endpoint needs it
6. click Test Config
7. click Start Session
8. review Session Status and Draft Fee Suggestions

Session lifecycle

A successful run moves through these stages:

• starting
• collecting_history
• streaming_live
• analyzing
• completed

The session can also end as:

• failed
• canceled

What the page shows

Session Inputs

The page derives private channel references from the current browser node session and shows how many channel hints and fee hints are available for the run.

Session Status

During the run, the page shows:

• session id
• history events processed
• live events processed
• tracked channels
• start time
• end time or pending state

Draft Fee Suggestions

After the run completes, the page shows:

• a suggestion table with action, current fee, suggested fee, friction, confidence, and reasons
• an aggregate channel table with attempts, settles, failures, success rate, volume pressure, and friction

How suggestions are generated today

The current output is deterministic.

The app derives channel friction from:

• success rate
• failure rate
• failure pressure
• volume pressure

In practical terms:

• repeated forward or link failures push friction up and can trigger a fee increase suggestion
• low activity with low friction and a relatively high current fee can trigger a fee decrease suggestion
• channels with very little observed activity are ignored

This means the current page is a review tool, not an automatic policy engine.

What the result contains

Each suggestion includes:

• raise or lower
• current fee ppm
• suggested fee ppm
• friction score
• confidence
• reason strings
• the observed window start and end

Each aggregate channel row includes:

• attempts
• settles
• forward fails
• link fails
• observed volume
• failed volume
• success and failure rates
• failure pressure
• volume pressure
• friction score

Current scope

• aggregate-only output
• bounded session lifecycle
• manual review workflow
• no automatic fee updates
• no verified-runtime path

Use this page when the normal channel view does not explain why a channel feels noisy, unreliable, or overpriced. It is useful for finding channels that are absorbing repeated failed forwarding load, channels with weak success rates relative to observed activity, and channels that deserve a manual fee review next.