Skip to Content
Dial v1 live 🎉

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

StrategyStatusNotes
Repo Create2FactoryPrototype, live on SepoliaUses the salt as given. Factory at 0xBd9680E4dD16Bc3bebE8557F47FFA54184679334 on chain 11155111
CreateX BlockedSee 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 deployment

The 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.

ContractETHERC-20 such as USDC
GenericForwarderMinimalForwards the balance once, at deploymentNot handled. Tokens sent to it have no way out
DepositForwarderForwards at deployment and on later receiptsGuardian 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

NetworkChain IDStatus
Sepolia11155111Factory live, no canonical profile recorded
Base Sepolia84532Proposed as the testnet for number accounts, no deployment recorded
Base8453Mapped in code, no deployment recorded
Ethereum mainnet1Mapped 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:

SituationCurrent behavior
Duplicate webhookCREATE2 can’t redeploy to the same address. Off-chain effects need their own guard
Deployer has no gasFunds wait at the address until someone retries. No automated policy yet
Reorg after deploymentNo confirmation policy defined
Wrong token or wrong chainNo automatic recovery. See assets above
Trigger never firesFunds 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

Last updated on