Ethereum / EVM Adapter
Status: prototype, last checked 2026-11-02. Source: spawn-proto main at f3cd496 and dev at 2043f16. Not production ready.
The EVM adapter derives a payable address with CREATE2, watches it, and deploys a contract there when funds arrive.
How the address is derived
CREATE2Â computes the address from the deploying contract, a salt and the hash of the init code:
address = keccak256(0xff ++ deployer ++ salt ++ keccak256(initCode))[12:]Changing any input changes the address. Init code includes constructor arguments, so the beneficiary and fee settings are part of the address.
Deployment strategies
| Strategy | Status | Notes |
|---|---|---|
Repo Create2Factory | Prototype, live on Sepolia | Uses the salt as given. Factory at 0xBd9680E4dD16Bc3bebE8557F47FFA54184679334 on chain 11155111 |
| CreateXÂ | Blocked | See below |
CreateX is not safe to predict yet
Don’t send funds to an address predicted for CreateX with the current predictor. The address may not match what gets deployed. Tracked as spawn-proto#2, open.
CreateX passes the salt through its own guard before calling CREATE2. The guard’s output depends on the salt’s prefix and flags, and sometimes on the caller and chain. The predictor treats the caller’s salt as final and uses it directly, so the two can diverge.
A strategy may only be called deterministic once these four values are proven equal:
offchain prediction == factory computation == simulated deployment == actual deploymentThe fix also has to record the strategy, factory, input salt, effective salt and init code hash on every new record. Old records that stored only a salt can’t be reinterpreted safely.
What has been proven so far
For the repo factory on Sepolia, the off-chain prediction matches the live factory’s computeAddress. You can check this yourself. A separate local test on dev covers the factory deploying a forwarder. An end-to-end match with an actual deployment on Sepolia is not recorded yet, so the invariant above is only partly met.
Assets
This is the most likely way to lose money with the prototype.
| Contract | ETH | ERC-20 such as USDC |
|---|---|---|
GenericForwarderMinimal | Forwards the balance once, at deployment | Not handled. Tokens sent to it have no way out |
DepositForwarder | Forwards at deployment and on later receipts | Guardian can sweep. It doesn’t forward automatically |
GenericForwarderMinimal has no receive function, so ETH sent after deployment reverts. Stablecoin invoicing needs a contract that doesn’t exist yet in the prototype.
Networks
| Network | Chain ID | Status |
|---|---|---|
| Sepolia | 11155111 | Factory live, no canonical profile recorded |
| Base Sepolia | 84532 | Proposed as the testnet for number accounts, no deployment recorded |
| Base | 8453 | Mapped in code, no deployment recorded |
| Ethereum mainnet | 1 | Mapped in code, no deployment recorded |
A chain ID appearing in code doesn’t mean the network is supported. Each one needs its own deployment evidence, and the same address on two chains doesn’t mean the same state.
Activation and failure
Today a signed webhook reports activity at a watched address, the service marks the program triggered, deploys, and marks the result. Check all of these before relying on it:
| Situation | Current behavior |
|---|---|
| Duplicate webhook | CREATE2 can’t redeploy to the same address. Off-chain effects need their own guard |
| Deployer has no gas | Funds wait at the address until someone retries. No automated policy yet |
| Reorg after deployment | No confirmation policy defined |
| Wrong token or wrong chain | No automatic recovery. See assets above |
| Trigger never fires | Funds stay at the address. Anyone with the parameters can deploy, because the salt and init code are enough |
Standards
CREATE2 itself dates from 2018 and is not unique to Dial. What SPAWN adds is the binding between signed authorization, program commitment and destination, which is not built yet.
Next: EVM invoicing guide.
Explore invoicing: Programmable Invoicing and invoicing on Ethereum