Use Cases
The simplest use case is a payment request: an address, an amount and a note. Each use case below adds only the layers it needs, so you can start small. Last checked 2026-11-02.
| Use case | What it does | SPORE | SPAWN | Calvin | Status |
|---|---|---|---|---|---|
| Payment request | Ask for a set amount at an address, by QR code or link | Optional | Optional | Optional | Plain QR works with standard URIs. Signed version is conceptual |
| Invoice | A payment request with an issuer, terms, a due date and a receipt | Yes | Optional | Yes | Conceptual, with EVM and Cardano prototypes |
| Pay-to-activate | A payment starts a service or a bounded operation | Yes | Yes | Yes | Conceptual |
| Agent-to-agent payment | An agent buys a service under a signed budget | Yes | Optional | Yes | Conceptual |
| Recurring payment | Scheduled invoices or a standing authorization | Yes | Optional | Yes | Conceptual |
| Conditional release | A milestone or other evidence releases value | Yes | Yes | Yes | Conceptual |
| Multi-party agreement | Several parties approve one program | Yes | Yes | Optional | Conceptual |
| Cross-network settlement | Payer and recipient use different networks | Yes | Optional | Yes | Conceptual |
What each layer adds
Start with a plain payment request, and add a layer when you hit the problem it solves.
| The problem | What to add |
|---|---|
| The payer can’t tell who really sent the request | Sign it with SPORE |
| You can’t tell which request a payment was for | Give each request its own destination with SPAWN |
| Payment has to trigger something | Add activation with SPAWN |
| The payer holds a different asset or network | Find a route with Calvin |
Pay-to-activate
A customer or agent funds a program’s destination to start a service, buy credits or provision infrastructure. It suits usage-based software, because nothing needs to run until someone pays.
The order of events matters. A transfer arriving is only a signal, so the service has to confirm the payment has settled before it does anything irreversible, and it must not run twice if the payment event repeats. It also needs a stated answer for a payment that arrives too small, too late or in the wrong asset. See security.
Explore invoicing: Programmable Invoicing