Skip to content

Contract Analysis

DISCLAIMER // NFA // DYOR

This analysis is based on a full disassembly of the deployed bytecode — the contract source code is not verified on Etherscan. The published upstream source was compiled locally and matches the on-chain creation bytecode byte for byte; that match was established by us, not by Etherscan. We are not smart contract security experts. This document should not be considered a comprehensive security audit or financial advice. Always verify critical information independently.

⊙ generated by robots | curated by humans

Analysis Date: 2026-10-30


Metadata

Primary Contract

PROPERTY VALUE
Contract Address 0x4e59b448...B4956C (etherscan)
Network Ethereum Mainnet
Contract Type Standalone, stateless CREATE2 factory. Despite the name, not a Proxy Contract in the delegatecall sense
Deployment Date 2020-08-16 11:28:57 UTC
Deployment Block 10,670,819 (etherscan)
Contract Creator 0x3fab1846...a45362 (etherscan) — a keyless signer; see Keyless Deployment
Creation TX 0xeddf9e61...033d26 (tx)
Compiler Version Yul, solc 0.5.8 with the Yul optimizer (reproduced locally; not declared on-chain)
Runtime Size 69 bytes
Total Functions 1 — a single entry point with no selector dispatch
External Contract Dependencies 0
Upgrade Mechanism ☑ None — not upgradable, no owner, no storage
Verification Status ☒ Not verified on Etherscan. ◇ The published upstream Yul source compiles to the on-chain creation bytecode byte-for-byte
Audit Status ◇ No audit report located
TYPE ADDRESS NOTES
Deployment signer 0x3fab1846...a45362 (etherscan) Recovered from a hand-chosen signature (r = s = 0x2222…22). Nonce 1: its one pre-signed transaction has been spent. Held ~0.025 ETH at block 26,306,072 (etherscan); see Stranded ETH
Signer funder 0xf78cd306...2ad5ef (etherscan) Sent exactly 0.01 ETH (100,000 gas × 100 Gwei) to the signer in 0x2814f03c...ea365b (tx), five blocks before the deployment

Executive Summary

This contract deploys other contracts. A caller sends Calldata made of 32 bytes of salt followed by a contract's init code (the constructor plus the runtime code it returns), and the contract runs CREATE2 with that salt and code, forwarding any ETH sent with the call. The new contract's address depends only on this contract's address, the salt, and the hash of the init code. The caller and its nonce do not enter the calculation.

The contract's own address is fixed by a second mechanism. It was deployed by a pre-signed transaction whose signature was chosen by hand rather than produced by a private key, and which omits the EIP-155 chain id. The same raw transaction is therefore valid on any chain that still accepts unprotected legacy transactions, and on every such chain where the signer's nonce is still 0 it produces this contract at this address. Combined, the two mechanisms let a contract be deployed at the same address on every compatible chain. This is the pattern known as Deterministic Deployment.

The contract has no owner, storage, upgrade path or Function Selector. Every call, whatever its calldata, runs the same 69 bytes. The upstream source is an 18-line Yul file whose runtime is five statements.

Foundry's forge ships with this address as its default create2_deployer, so a new Contract{salt: s}() inside a Forge script is routed here. Its account nonce stood at 56,172 at block 26,306,072 (etherscan), which corresponds to 56,171 contracts created on Ethereum mainnet.

The risks identified sit with the code that callers deploy, not with this contract. Inside a constructor run through it, msg.sender is this contract rather than the person deploying, which leaves an Ownable(msg.sender) contract permanently owned by an address that cannot call anything. Deployments are also permissionless, so a pending deployment can be copied and submitted by anyone, which matters when the constructor reads anything besides its init code, such as tx.origin, msg.value or block values.


Architecture

graph LR
    subgraph Once["Once per chain"]
        F["Anyone funds signer<br/>0x3fab1846...a45362<br/>with 0.01 ETH"]
        T["Pre-signed raw tx<br/>nonce 0, 100 gwei, 100k gas<br/>no chain id"]
    end

    subgraph DDP["Deterministic Deployment Proxy<br/>0x4e59b448...B4956C"]
        R["runtime: 69 bytes<br/>calldatacopy → CREATE2 → return"]
    end

    C["Caller<br/>(EOA or contract)"]
    N["New contract<br/>address = f(proxy, salt, keccak(initCode))"]

    F --> T
    T -->|"CREATE at nonce 0"| DDP
    C -->|"calldata = salt ‖ initCode<br/>value = ETH for constructor"| R
    R -->|"CREATE2(value, initCode, salt)"| N
    R -->|"returns 20-byte address"| C

    style R fill:#e1f0ff
    style T fill:#fff4d6

System Overview

A call does four things, in this order:

  • Copy everything after the first 32 bytes of calldata into memory. That is the init code.
  • Run CREATE2(msg.value, initCode, salt), where the salt is the first 32 bytes of calldata.
  • If CREATE2 returned zero, revert with no data. That happens when the constructor reverted or the target address already holds a contract.
  • Otherwise return the new address as 20 raw bytes, not as a 32-byte Application Binary Interface (ABI) word.

What it does not do:

  • It keeps no record of what it deployed. The only trace is its account nonce and the new contract's creation trace.
  • It does not check who calls it. Any address can deploy any code at any salt.
  • It does not pass through the constructor's revert reason. Every failure looks the same from outside.

Keyless Deployment

The deployment transaction was built by fixing the signature first and recovering an address from it, the reverse of normal signing. The upstream build script sets v = 27, r = s = 0x2222…22, and recovers 0x3fab1846...a45362 (etherscan) as the signer. The raw transaction on chain matches the one published in the upstream README byte for byte:

0xf8a58085174876e800830186a08080b853604580600e6000...6014600cf3
  1ba0 2222…2222 a0 2222…2222

Because the signature was fixed rather than produced by a key:

  • No private key for the signer is known to exist, and recovering one from a hand-chosen signature is computationally infeasible. Without it, the only transaction the signer can ever send is this one, at nonce 0.
  • The transaction has no chain id, so it replays on any chain where the signer still has nonce 0 and someone has funded it with 0.01 ETH. The resulting CREATE address, keccak256(rlp(signer, 0)), is the same everywhere.
  • Short of that key being recovered, nothing else can be deployed from the signer, so the keyless route can only place this bytecode. Code placed at genesis depends on the chain's configuration instead; see below.

This is the Keyless Deployment technique.

Cross-Chain Deployments

The address was checked on eight chains on 2026-10-30 through each chain's public Remote Procedure Call (RPC) endpoint. On all eight it holds the same 69-byte runtime. Five received it through the same keyless transaction, identifiable by the same hash on every chain because the signed bytes are identical, and each receipt shows status 1 and 68,131 gas used. On Arbitrum One the code was already present at the Nitro genesis block; the keyless transaction was included there later and reverted. On MegaETH and Robinhood Chain the signer's nonce is still 0, so the code arrived some other way.

CHAIN CHAIN ID CODE MATCHES HOW IT ARRIVED PROXY NONCE (LIVE READ) SIGNER NONCE
Ethereum 1 ☑ 0x4e59b448...B4956C (etherscan) Keyless tx 0xeddf9e61...033d26 (tx), block 10,670,819 (etherscan), 2020-08-16 56,176 1
OP Mainnet 10 ☑ 0x4e59b448...B4956C (optimistic etherscan) Keyless tx 0xeddf9e61...033d26 (tx), block 1,381,134 (optimistic etherscan), 2021-12-20 13,451 1
Sepolia 11155111 ☑ 0x4e59b448...B4956C (sepolia etherscan) Keyless tx 0xeddf9e61...033d26 (tx), block 1,986,524 (sepolia etherscan), 2022-09-29 346,103 1
Base 8453 ☑ 0x4e59b448...B4956C (basescan) Keyless tx 0xeddf9e61...033d26 (tx), block 5,144 (basescan), 2023-06-15 70,372 1
Base Sepolia 84532 ☑ 0x4e59b448...B4956C (basescan) Keyless tx 0xeddf9e61...033d26 (tx), block 1,128,866 (basescan), 2023-10-23 62,818 1
Arbitrum One 42161 ☑ 0x4e59b448...B4956C (arbiscan) Present by Nitro genesis, block 22,207,817 (arbiscan), 2022-08-31. Keyless tx 0xeddf9e61...033d26 (tx) at block 202,430,856 (arbiscan), 2024-04-18, reverted: status 0, all 100,000 gas used 32,642 1
MegaETH 4326 ☑ 0x4e59b448...B4956C (blockscout) Present at genesis (block 0, 2025-11-10); no creation transaction 1,479 0
Robinhood Chain 4663 ☑ 0x4e59b448...B4956C (blockscout) Not via the keyless tx; origin not determinable from the public RPC (no historical state) 28,047 0

Proxy nonces were read at each chain's latest block during the check, with heights recorded in Artifacts, and will have moved since; each minus one is the number of contracts created on that chain. On Ethereum that read was at block 26,306,479 (etherscan), which is why it shows 56,176 against the 56,172 pinned at block 26,306,072 elsewhere in this analysis. Where the code was present before the keyless transaction, the guarantee that the address holds this code comes from the chain's genesis configuration rather than from the keyless signer. The bytecode is identical either way. On those chains the keyless transaction can still be submitted once the signer is funded, and it fails: Arbitrum One shows this on chain, and a local test that placed the code first and then published the transaction reproduced it, with status 0, all 100,000 gas used, and the signer's nonce moved to 1 without changing the contract.

Design Patterns Used

  • CREATE2 factory: the contract wraps one opcode. Address determinism comes from CREATE2, and the factory's job is only to provide a fixed sender input to the address formula.
  • Keyless deployment: a pre-signed, chain-agnostic transaction pins the factory's address across chains without trusting a deployer key.
  • No ABI: the calldata is a raw byte layout rather than an ABI-encoded call. See Return Value Is Not ABI-Encoded for the return side.

Access Control

Roles & Permissions

ROLE ASSIGNED BY REVOKABLE CALL COUNT
Anyone — N/A Unlimited

There is no privileged role. The bytecode reads neither the caller nor storage (see Functions), so it cannot distinguish one caller from another and has nowhere to store a permission.

Permission Matrix

FUNCTION ANYONE
fallback (deploy) ☑

Time Locks & Delays

ACTION TIME LOCK CAN CANCEL PURPOSE
Deploy a contract None N/A ◇ Immediate. There is nothing to delay — the contract has no admin actions

Economic Model

The contract charges no fee and holds no funds. Any ETH attached to a call is passed in full to CREATE2 as the new contract's starting balance. If the deployment fails, the whole call reverts and the ETH returns with it. A local fork test confirmed both cases: 1 wei sent with a deployment arrived in the child contract, and a mined call carrying 1 wei with failing init code ended with status 0 and the proxy's balance still at zero.

The balance was zero at block 26,306,072 (etherscan). The only ways ETH could be stranded here are routes that bypass code execution, such as a SELFDESTRUCT beneficiary payment or a block reward. Nothing in the code could send it on.

ETH stranded at the deployment signer is a separate matter. The signer was funded with exactly the 0.01 ETH the deployment could cost, and the deployment used 68,131 of the 100,000 gas limit. The unused gas, plus later transfers from other addresses, leaves ~0.025 ETH at an address for which no key is known; see Potential Risks.


Summary of Observations

The Deterministic Deployment Proxy is a single-purpose CREATE2 factory, deployed with a keyless pre-signed transaction so that it can occupy the same address on every chain that accepts the transaction. Its 69-byte runtime performs one CREATE2 and nothing else. The upstream Yul source compiles to the on-chain creation bytecode exactly, and the runtime behaviour was confirmed against a local mainnet fork.

Nothing in the bytecode is administrable. Through the keyless transaction, nothing else can be deployed at its address unless the signer's key is recovered. Contracts deployed through it get an address that depends only on their own code and salt, and a Front-Running copy of a deployment produces the same contract at the same address unless the constructor reads anything besides its init code.

Callers need to account for:

  • Constructors see this contract as msg.sender. Anything that records the deployer through msg.sender records an address that can never act.
  • tx.origin is whoever submitted the transaction, which on a public Mempool may not be the intended deployer.
  • Failures are silent: an empty revert for a reverting constructor or an occupied address, and an out-of-gas for calldata under 32 bytes.
  • Availability on a given chain depends on that chain accepting a pre-EIP-155 transaction at 100 gwei within 100,000 gas.

Of these, only the msg.sender behaviour was found to cause lasting loss — a permanently unusable owner role — and that loss falls on the deployed contract.

This analysis was performed for educational purposes and should not be considered an official security audit or financial advice.


References

RESOURCE NOTES
Arachnid/deterministic-deployment-proxy Upstream Yul source, build script, and published deployment transaction. Commit be3c5974 cloned for local reads and compilation
EIP-1014: Skinny CREATE2 Specification of the CREATE2 opcode and its address formula
EIP-155: Simple replay attack protection The chain id rule the deployment transaction deliberately omits
EIP-161: State trie clearing Contract accounts start at nonce 1, which is why nonce − 1 equals contracts created
Foundry — forge configuration Source of the create2_deployer default, also checked against forge config locally
Mastering Ethereum, 2nd Edition Background on transaction signing and contract creation
Etherscan — contract page Creation data, verification status, transaction lists
SafeSummoner analysis A second public CREATE2 deployer on this site, built into a larger contract

Change Log

DATE AUTHOR NOTES
2026-10-30 Artificial. Generated by robots. Gas: 735 tok
2026-10-30 Denizen. Reviewed, edited, and curated by humans.