SPORE, SPAWN & Calvin Routes
Draft, last checked 2026-11-02. Most of this stack is specified but not built. Read the status table before you plan around any feature.
This stack lets you write down what someone authorized, give the resulting program a stable identity before it runs, and execute it only through paths that authorization allows. Anyone can check the result afterwards without trusting Dial’s website or servers. We call it the Verifiable Execution Stack. Invoicing is the first application, and the protocols are not limited to it.
| Layer | Plain name | What it does | Status |
|---|---|---|---|
| SPORE | Verifiable Instructions | A portable signed object holding instructions, parties, policies and references | Conceptual |
| SPAWN | Deterministic Programs | A program identity, its activation rules, lifecycle and evidence | EVM prototype, generic core conceptual |
| Calvin Routes | Smart Execution Routing | Picks a funding and execution path that stays inside the signed limits | Conceptual |
Four things that are easy to mix up
These are separate values, even when one is derived from another:
- A program commitment is the cryptographic identity of a program’s rules and parameters.
- An execution destination is an address or service reference bound to that commitment on one network.
- A route is a permitted way to fund and execute the program.
- A receipt is evidence of what actually happened.
Paying a predetermined address does not by itself prove that a program ran. A transfer can arrive before activation, in the wrong asset, or on the wrong network. SPAWN and the security page cover how to handle those cases.
Where to start
| You want to | Read |
|---|---|
| See how the layers fit together | Architecture |
| Check what works today | Status & changelog and network adapters |
| Build an invoice flow | Invoicing guide |
| Reproduce something yourself | Verify a predicted EVM address |
| Connect x402, AP2, MCP or ERC standards | Interoperability |
| Review the trust model | Security |
What these docs do not claim
Signatures and executable conditions do not make an agreement legally binding. That depends on jurisdiction and context. The stack does not provide atomic cross-chain settlement, uniform finality, a single address across all networks, or automatic refunds. Where an adapter offers one of these properties, its own page says so.
Explore invoicing: Programmable Invoicing