Skip to content

Follow up BTC sender hardening after PR #333 #344

@romanornr

Description

@romanornr

Summary

PR #333 is incident-driven hardening for the Via BTC sender after the Via main testnet GCP / chain incident, but it is not the final architecture for sender recovery behavior.

This issue tracks the follow-up engineering work that still remains after PR #333.

Background

After Celestia / via-da-proxy recovery, the remaining blocker shifted to the Bitcoin/L1 inscription path. PR #333 improved sender resilience substantially:

  • largest-first UTXO selection
  • full-set fallback when truncated selection would falsely fail
  • minimum inscription / change floors
  • disabling unconfirmed change reuse by default
  • config-backed sender policy
  • runtime chain guardrails / observability
  • reveal-budget-aware selection targeting

These changes reduce fragile chained transactions and make the sender safer under degraded conditions, but they do not yet provide the final long-term architecture.

Follow-up work

1. Proper explicit RBF / replacement engine

  • move beyond simple retry / rebroadcast semantics
  • define a first-class replacement policy for stuck inscriptions
  • make replacement behavior explicit in code, metrics, and logs

2. More formal transaction replacement semantics

  • clearly model when a tx is:
    • fresh
    • inflight
    • replacement candidate
    • replaced
    • abandoned
  • avoid ambiguous retry behavior and make pipeline state easier to reason about

3. Deeper long-term UTXO state modeling

  • distinguish trusted confirmed balance vs pending-context balance more formally
  • model reusable vs fragile vs blocked funds explicitly
  • make pending self-chain behavior easier to inspect and control

4. Richer mempool / fee market strategy

  • improve beyond simple bounded fee floors/caps
  • support better fee escalation decisions under congestion
  • make the sender more adaptive without uncontrolled overpay behavior

Why this matters

PR #333 should be read as:

  • production hardening informed by a real incident
    not
  • the last word on BTC sender architecture

This issue exists so we do not lose sight of the remaining design work once the immediate hardening PR is merged.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions