On the Routstr platform, users log in with their Nostr nsec, create a wallet (NIP-60), and fund it with Lightning — no Cashu token needed upfront. But the API currently requires a Cashu token to bootstrap (/v1/balance/create?initial_balance_token=cashuA...). This creates a gap for third-party apps that want to offer the same smooth onboarding.
Request
Expose nsec/npub-based wallet creation via the API, so apps can replicate the platform's onboarding flow:
- Authenticate with Nostr — e.g.
POST /v1/auth/nostr with a signed NIP-98 event (kind 27235), or accept nsec/npub as a wallet creation parameter
- Return an API key tied to that npub identity
- Fund via Lightning —
/v1/balance/lightning/invoice already works once a key exists
Current workaround
Users must:
- Go to cashu.me → pay a Lightning invoice → get a Cashu token
- Paste the token into the app — we auto-convert it to a session key via
/v1/balance/create
- Show a key reveal screen (the token is spent, session key is the only way to access the balance)
- Then they can top up with Lightning directly via
/v1/balance/lightning/invoice + QR codes
This works but adds friction — users need to understand Cashu before they can use Routstr. On the platform itself, none of this is needed because nsec login handles it.
Use case
getbased integrates Routstr as an AI provider with in-app balance display (sats), Lightning QR topup, and Cashu token deposit. We'd like to offer the same zero-friction onboarding the Routstr platform has: enter nsec → create wallet → fund with Lightning → start using AI. Right now we have to explain Cashu tokens to users first.
On the Routstr platform, users log in with their Nostr nsec, create a wallet (NIP-60), and fund it with Lightning — no Cashu token needed upfront. But the API currently requires a Cashu token to bootstrap (
/v1/balance/create?initial_balance_token=cashuA...). This creates a gap for third-party apps that want to offer the same smooth onboarding.Request
Expose nsec/npub-based wallet creation via the API, so apps can replicate the platform's onboarding flow:
POST /v1/auth/nostrwith a signed NIP-98 event (kind 27235), or accept nsec/npub as a wallet creation parameter/v1/balance/lightning/invoicealready works once a key existsCurrent workaround
Users must:
/v1/balance/create/v1/balance/lightning/invoice+ QR codesThis works but adds friction — users need to understand Cashu before they can use Routstr. On the platform itself, none of this is needed because nsec login handles it.
Use case
getbased integrates Routstr as an AI provider with in-app balance display (sats), Lightning QR topup, and Cashu token deposit. We'd like to offer the same zero-friction onboarding the Routstr platform has: enter nsec → create wallet → fund with Lightning → start using AI. Right now we have to explain Cashu tokens to users first.