feat(lnurl): tap-to-receive (top-up) endpoint
Some checks failed
lint.yml / feat(lnurl): tap-to-receive (top-up) endpoint (push) Failing after 0s
Some checks failed
lint.yml / feat(lnurl): tap-to-receive (top-up) endpoint (push) Failing after 0s
Add a deposit counterpart to /scan so a Bolt Card can be tapped to
RECEIVE sats, not only spend. The card only emits its lnurlw (a spend
voucher), so the tap is used as an authenticated identity: the same SUN
p/c that /scan verifies proves possession, and we return an lnurl-PAY
(LUD-06) response for the card's own wallet.
- GET /api/v1/pay/{external_id}?p=&c= — SUN-verified, returns a
payRequest; the single-use hit is the callback bearer (like k1 for
withdraw). No daily-limit check (that gates spending); per-deposit max
is tx_limit.
- GET /api/v1/pay/cb/{hit_id}?amount= — invoices the card wallet.
- Static pay metadata so the LUD-06 description_hash matches.
- Distinct from the LUD-19 refund lnurlp (keyed by a prior scan's hit);
this is reachable directly by a tap via external_id.
- config.json → 1.1.1-aio.1 (fork of upstream v1.1.1; upstream left its
config.json at 1.1.0, but the released tag is v1.1.1). README documents
the endpoint.
Consumed by aiolabs/bitspire #84 (Bolt Card tap-to-receive on cash-in).
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This commit is contained in:
parent
407506ad9f
commit
6d240eaa7b
3 changed files with 139 additions and 1 deletions
30
README.md
30
README.md
|
|
@ -97,3 +97,33 @@ Then fill up the card parameters in the extension. Card Auth key (K0) can be fil
|
|||
- Scan with compatible Wallet
|
||||
|
||||
This app afaik cannot change the keys. If you cannot change them any other way, leave them empty in the extension dialog and remember you're not secured. Card Auth key (K0) can be omitted anyway. Initical counter can be 0.
|
||||
|
||||
---
|
||||
|
||||
## aiolabs fork — tap-to-receive (top-up)
|
||||
|
||||
This fork adds a **deposit** counterpart to the `/scan` withdraw, so a Bolt
|
||||
Card can be tapped to *receive* sats (e.g. the buy flow on a bitSpire ATM), not
|
||||
only to spend.
|
||||
|
||||
A Bolt Card only ever emits its `lnurlw` (a spend voucher), so the tap is used
|
||||
purely as an **authenticated identity**: the same NTAG424 SUN `p`/`c` that
|
||||
`/scan` verifies proves card possession, and the endpoint returns an
|
||||
**lnurl-pay** (LUD-06) response for the card's *own* wallet instead of a
|
||||
withdraw voucher. No card re-writing — same NDEF, keys, and `external_id`.
|
||||
|
||||
**Endpoint** (sibling of `/scan`):
|
||||
|
||||
```
|
||||
GET /boltcards/api/v1/pay/{external_id}?p=<32-hex>&c=<16-hex>
|
||||
→ LnurlPayResponse { tag:"payRequest", callback, minSendable, maxSendable, metadata }
|
||||
GET /boltcards/api/v1/pay/cb/{hit_id}?amount=<msat>
|
||||
→ LnurlPayActionResponse { pr:<bolt11 on the card wallet> }
|
||||
```
|
||||
|
||||
- SUN verification, counter monotonicity, and the single-use `hit` bearer token
|
||||
mirror `/scan` exactly (`hit_id` bridges the two LUD-06 steps like `k1` does
|
||||
for withdraw). A cloned UID can't misdirect a deposit.
|
||||
- No daily-limit check (that gates *spending*); per-deposit max is `tx_limit`.
|
||||
- Distinct from the existing LUD-19 refund `lnurlp` (which is keyed by a prior
|
||||
scan's `hit`); this is reachable directly by a tap via `external_id`.
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue