is it possible to create smart contract with deterministic address (like CREATE2 does) from transaction itself (i.e. without proxy/creator smart c)?

Question

I found that

1. From ethereum yellow whitepaper

Transaction contains fields:

• nonce
• gasPrice
• gasLimit
• to
• value
• v, r, s
• init (contains "smart contract creation code" that should return "smart contract runtime code") OR data (arguments to call smart contract, typically "solidity function name hash" and "function arguments")

also

There are a number of intrinsic parameters used when creating an account: ........, the salt for new account’s address (ζ) .....

The salt ζ might be missing (ζ = ∅); ......

If the creation was caused by CREATE2, then ζ = ∅.

2. The "smart contract initialization code" should

• copy code to memory
• using the RETURN(start_offset_of_memory, end_offset) return the "runtime code"

---

It seems like if I provide the "salt" (of course together with "init" and all other fields except of "data") field in transaction issued from EOA it will create smart contract with deterministic address (just like CREATE2 opcode does)

But there is no such field "salt" for transaction, and I see that everyone create smart with deterministic address using "ProxyFactory smart contract" (OpenZeppelin 1 and 2 or here the Deployer smart contract)

It seems like:

• IF EOA creates smart contract from transaction - smart contract will be created using CREATE approach implicitly
• IF smart contract creates smart contract - it can be created using CREATE or CREATE2 opcodes

Question: is it possible / why it's not possible to create smart contract with deterministic address from transaction itself without using ProxyFactory approach?

Answer 1

Tnx to Paul Razvan Berg

This is by design, that's what I wanted to hear

So when people like here https://ethereum.stackexchange.com/a/761/82396 say

For contract created by CREATE2 its address will be:

keccak256( 0xff ++ senderAddress ++ salt ++ keccak256(init_code))[12:]

Note that senderAddress can be either an externally-owned account (EOA) or a contract.

I will know that no, it cannot be EOA, because senterAddress is a address of factory