Gated on ADR 0004's trigger (users, not revenue) — plan of record, not a build order.
When keel monetises, it accepts crypto only, through a self-hosted, non-custodial BTCPay Server — the payment rail coherent with promises already made: no interest-bearing payment rails, no processor that sees the payer's identity, no chargeback asymmetry. It also removes the Stripe/merchant-entity dependency entirely.
Architecture
- BTCPay Server on the operator's own metal — non-custodial: invoices pay out directly to the operator's wallet; the server never holds keys, exactly like everything else keel runs.
- On-chain BTC + Lightning (Lightning carries the small recurring amounts).
- USD-priced, paid at spot: tiers are priced in USD; conversion happens at invoice time; volatility never touches the ledger.
- Prepaid credit, not card-on-file: no auto-charge exists on-chain, so the model is credit that decrements by calendar time — annual prepay emphasized, renewal reminders via Web Push from the portal.
- The invoice ledger is the audit trail — clean, append-only, exportable.
Stated plainly (US-based operator)
Receiving crypto is ordinary income at fair-market value at receipt. Crypto-only removes the processor, not the tax. Bookkeeping stays; the BTCPay ledger makes it easy.
Done when (when the trigger fires)
Gated on ADR 0004's trigger (users, not revenue) — plan of record, not a build order.
When keel monetises, it accepts crypto only, through a self-hosted, non-custodial BTCPay Server — the payment rail coherent with promises already made: no interest-bearing payment rails, no processor that sees the payer's identity, no chargeback asymmetry. It also removes the Stripe/merchant-entity dependency entirely.
Architecture
Stated plainly (US-based operator)
Receiving crypto is ordinary income at fair-market value at receipt. Crypto-only removes the processor, not the tax. Bookkeeping stays; the BTCPay ledger makes it easy.
Done when (when the trigger fires)