Web app deployed
Lightning Invoice Decoder
Make Lightning invoice details inspectable through a web interface, terminal client, and HTTP API.
Software engineer
System flow
- 01Enter a BOLT11 invoice
- 02Decode with Rust
- 03Validate signature & expiry
- 04Present the details
Context & role
The Lightning Invoice Decoder connects protocol-oriented Rust work to an accessible full-stack application. A shared decoding library powers its web, terminal, and HTTP interfaces.
Problem & scope
An encoded Lightning invoice contains payment metadata that is difficult to inspect directly. The tool extracts that metadata and reports signature validity and expiration.
Its scope is invoice inspection. It does not pay invoices, manage channels, discover routes, or report settlement state.
Implementation & architecture
A reusable Rust library wraps invoice parsing and validation using lightning-invoice. An Axum API, a Ratatui terminal client, and a Next.js web client share that decoder boundary.
The terminal client supports local decoding or HTTP access to the API. The application is stateless and requires no database or Lightning node.
Interface & operational decisions
The API publishes an OpenAPI specification and stable error responses. The decoder reports amounts, network, payee keys, timestamps, payment hashes, fallback addresses, and private route hints.
Input length is bounded, decode responses are not cached, and application tracing excludes invoice URLs. The current GET endpoint still requires care with upstream request logs; a POST endpoint is a possible privacy improvement.
Result & next steps
The project provides web, API, and terminal access to one decoder library. Source code, architecture documentation, deployment configuration, and a recorded demo are available in the repository.
Further work can strengthen privacy at the HTTP boundary and expand documented validation evidence. Invoice decoding remains distinct from payment execution.