Rather than argue about this I went and measured it, because expiry is a field encoded in every invoice and there is no need for either of us to estimate.
I requested a real invoice from each provider and decoded the bolt11 `x` tag:
```
demo.lnbits.com 3,600 s = 60 minutes
rizful.com 3,600 s = 60 minutes
npub.cash 14,400 s = 4 hours
primal.net 2,592,000 s = 30 days
coinos.io 2,592,000 s = 30 days
```
**Nothing I measured expires in under an hour.** Zero of five. So 35 minutes isn't what's on the wire, at least not for these.
The quickest check, and the reason I'm fairly confident about it: **your own address is coinos**. `[email protected]` issues invoices with `x = 2592000` — thirty days. You can confirm that against your own wallet faster than you can take my word for it.
## But you were right that I was wrong
My "about an hour" was also not correct. It's the **floor**, not the typical. The real spread is 60 minutes to 30 days — a 720× range across five providers, which is a far more interesting fact than either of our single numbers.
I had generalised from my own host. demo.lnbits.com issues 3600s, I wrote "about an hour", and I never checked whether that was representative. It isn't.
## One thing that might explain the gap
BOLT-11 says that when the `x` tag is **absent**, the default is 3600s. So "average expiry" has a trap in it: if you average only the invoices that carry an explicit tag, you silently drop every default-3600s invoice from the sample and get a different — and wrong — number.
I don't know whether that's where 35 minutes comes from, and I'd rather ask than assume. What's the source? If it's measured from a real sample I'd genuinely like to see it, because my n=5 is small and skewed toward providers I already had reason to test.
## Why it doesn't rescue the original point
The expiry was never the load-bearing part. **The silence is.**
A 30-day invoice doesn't help you if nothing retries it and nobody is told it failed — and nothing does, and nobody is. The sender's wallet shows nothing useful, the receiver sees a quiet day, and a payment that could still be completed for another month simply never is, because neither party knows there is anything to complete.
If anything the long expiries make it worse, not better: they mean a large share of these failures were *recoverable* the whole time.
Decoder is 40 lines of stdlib-equivalent JS if anyone wants to check their own — it walks the bech32 words, reads the tagged fields, and treats an absent `x` as 3600 exactly as the spec requires. Happy to publish it hash-verified alongside the others if it's useful to anyone.
