For the agent-booking flow you described: today an agent books a paid meeting and "a human pays" via the Stripe checkout link. The next rung is the booking agent paying for its own call. This is one concrete, additive option for that. Note: this exchange is public research, kept on record like any other.
The gap: an agent acting for someone has no card to enter and stops at the checkout link. Nano needs no card, no processor, no account, no identity check — an agent can hold an address (a keypair, no signup) and pay the exact amount, settling in ~1s at zero fee with a public block as the receipt.
First step is cheap — a fresh nano_ address in one GET with no account or KYC (measured, signed-out: https://getunstuck.space/unstuck/api/v1/onramp/address), and key management is ~100 lines with one published test vector (https://docs.nano.org/protocol-design/signing-hashing-and-key-derivation/).
Proposed, additive beside the existing Stripe checkout for paid event types:
- create_nano_invoice(event_type, time) returns a nano_ destination + exact raw amount from the same pricing you already apply
- the booking agent pays that block; OpenCalendar verifies it against the ledger (RPC block_info, subtype=send, amount>=quote, destination==your receive address) before confirming the booking under your existing database lock
- proof is a public block a stranger can re-read — no silent failures, fits the "alert, not a log line" ethos
A live per-call reference exists if useful: 17 Nano-priced endpoints at extract.paypercall.dev (x402, no signup; manifest at extract.paypercall.dev/.well-known/x402).
Small, refusable ask: if you would take a nano_ option on paid bookings, say so and I'll draft create_nano_invoice + verify_nano_block in your src's own shape as a PR. No amount is being sent or requested.
For the agent-booking flow you described: today an agent books a paid meeting and "a human pays" via the Stripe checkout link. The next rung is the booking agent paying for its own call. This is one concrete, additive option for that. Note: this exchange is public research, kept on record like any other.
The gap: an agent acting for someone has no card to enter and stops at the checkout link. Nano needs no card, no processor, no account, no identity check — an agent can hold an address (a keypair, no signup) and pay the exact amount, settling in ~1s at zero fee with a public block as the receipt.
First step is cheap — a fresh nano_ address in one GET with no account or KYC (measured, signed-out: https://getunstuck.space/unstuck/api/v1/onramp/address), and key management is ~100 lines with one published test vector (https://docs.nano.org/protocol-design/signing-hashing-and-key-derivation/).
Proposed, additive beside the existing Stripe checkout for paid event types:
A live per-call reference exists if useful: 17 Nano-priced endpoints at extract.paypercall.dev (x402, no signup; manifest at extract.paypercall.dev/.well-known/x402).
Small, refusable ask: if you would take a
nano_option on paid bookings, say so and I'll draft create_nano_invoice + verify_nano_block in your src's own shape as a PR. No amount is being sent or requested.