SPAWN: Deterministic Programs
Status: EVM prototype, generic core conceptual. Last checked 2026-11-02. spawn-proto has a working
CREATE2 invoice pattern. The chain-neutral manifest and commitment described here are not built yet.
SPAWN gives a program an identity that anyone can compute from its parameters, before the program exists anywhere. A SPORE can reference that identity, a payer can check it, and a network adapter can activate the program when its conditions are met. Nothing has to be deployed up front, and SPAWN doesn’t assume a blockchain.
Commitment versus destination
These two values are often confused:
| Program commitment | Execution destination | |
|---|---|---|
| What it is | A hash of the program’s rules and parameters | Where assets or calls go on one network |
| Scope | Network independent | Specific to one network and adapter |
| Example | Hash of a canonical manifest | An EVM CREATE2 address or a Cardano script address |
| Payable? | No | Sometimes, depending on the adapter |
One commitment can bind to several destinations. A raw hash is not an address you can pay. Each destination must be derived from, or provably bound to, the commitment by rules that adapter defines.
Counterfactual destinations
On networks that support it, you can compute a destination and share it before anything has been deployed. Funds can arrive there first, and the program activates afterwards.
The mechanism differs by network. EVM uses CREATE2 , which derives an address from a factory, a salt and an init code hash. Cardano derives a script address from the hash of the compiled validator, and validators aren’t deployed at all. Don’t carry assumptions from one to the other. The adapter pages cover the details.
Funds at a predicted address are only recoverable if the program can actually be activated there. If the prediction is wrong, the funds can be lost for good. See the open CreateX issue.
Lifecycle
The prototype’s lifecycle is predicted, triggered, deployed, executed, failed. The architecture page defines the broader target states that also separate funded from settled.
A transfer to a destination moves a program to “triggered” at most. It says nothing about execution. Only evidence from the network can move it to “executed”.
Idempotency
Webhooks repeat, queues redeliver and users reload pages. Activating the same program twice must not repeat its side effects. An adapter has to treat the commitment as the idempotency key and record the outcome durably before reporting success. The EVM mechanism helps here, since CREATE2 can’t deploy twice to one address, but any off-chain side effect still needs its own protection.
Execution evidence
A SPAWN receipt has to let a third party check the outcome. At minimum it references the program commitment, the destination, the network and its identifier, the transaction or service evidence, the amounts moved and the finality observed.
What SPAWN leaves out
SPAWN has no concept of an invoice or a payment fee. Those live in the payment profile above it. An invoice is one pattern built on SPAWN, and escrow or a transaction guard could be others.
Explore invoicing: Programmable Invoicing