Title: New_ERC__Programmatically_Derived_Addresses__PDAs_
Category: ERCs

Author: JohnCrunch
Date: 2025-02-08T15:56:32.951Z

A proposal for programmatically derived addresses, which would drastically improve compute efficiency and storage demands on chain. While we are bound by the iron triangle of decentralization, we can “shrink” the entire triangle with structural improvements, such as PDAs.


github.com/ethereum/ERCs








Add ERC: PDAs (Programmatically Derived Addresses)


ethereum:master ← JohnCrunch:erc-pda-proposal



          opened 03:32PM - 08 Feb 25 UTC




            JohnCrunch
          



+106
-0






This is a draft ERC proposing Programmatically Derived Addresses (PDAs).

- ER…C Number: To be assigned by an editor.
- Discussion Link: TODO create conversation in ethereum magicians with this ERC

### Summary
This ERC introduces a mechanism for generating deterministic, contract-derived addresses without private keys. PDAs enable permissionless, stateless interactions with smart contracts while ensuring security and uniqueness.

Requesting review from ERC editors. Thanks!

Author: shemnon
Date: 2025-02-08T16:21:32.737Z

How do you intend to get contracts at those addresses?  A fully worked out process is needed otherwise this won’t work as intended.

Author: JohnCrunch
Date: 2025-02-08T19:50:50.132Z

My perspective is using CREATE2, which allows deterministic deployment for contracts.

Process:


Derive PDA
A contract deployer (e.g., a factory contract) uses CREATE2 to deploy a contract at that PDA address
Any user can verify the address by recomputing the PDA and checking that a contract exists at that location.

(Contracts must be deployed before any interactions).

Author: shemnon
Date: 2025-02-08T20:35:10.903Z

I think what you are missing is that CREATE2 doesn’t really get to pick it’s address.  CREATE2 address derivation is
keccak256( 0xff ++ address ++ salt ++ keccak256(init_code))[12:] per EIP-1014. Your solidity code is not compatible with what the EVM requires.  You may be able to write a contract that will allow arbitrary code with a fixed init_code and then tweak salt, but that’s not even contemplated upon in this ERC.

Author: marioevz
Date: 2025-02-08T21:05:38.702Z

I think this requires at least a couple of new opcodes to be feasible.
I’m thinking of an opcode that allows to make a call from an address that is derived from the current contract’s address plus a salt, and we can call this address a “contract owned address”, something like:
OWNEDCALL(address, salt, value)

address is the recipient of the call.
salt is a value that is combined with the address of the contract in the caller context to generate a new address that would become msg.sender on the recipient end.
value is Eth taken from the calculated address’s balance and included with the message.

We could also have OWNEDSETCODE that would do something very similar to set code transactions from 7702, but for the addresses owned by the contract.

Author: JohnCrunch
Date: 2025-02-08T21:08:14.060Z

thank you, yes! I was thinking something like:
function computeCreate2Address(address deployer, bytes32 salt, bytes memory initCode) public pure returns (address) {
    return address(uint160(uint256(keccak256(abi.encodePacked(
        bytes1(0xff),
        deployer,
        salt,
        keccak256(initCode)
    )))));
}

but @marioevz wrote a much better comment

Author: shemnon
Date: 2025-02-08T22:03:31.409Z

New opcodes for this will be a hard sell, and it would also need to be an EIP instead of an ERC.
That being said, I think a 90% solution may be on the way.  The derivation scheme for EOF’s propsoed TXCREATE (EIP-7873, still a PR) is simply
keccak256(0xff || sender || salt)[12:]

which would allow contracts using a modified PDA to deploy arbitrary contracts to PDAs from it’s address derivation.
The modification would be to have the ERC specify what goes into the salt of the TXCREATE opcode and then let that address derivation occur.  So if one PDA had three seeds and a keccak derivation the effective address derivation would be
keccak256(0xff || sender || keccak256(seed1 || seed2 || seed3))[12:]

And as long as the factory/source contract is wired for it they can have contracts deployed at those addresses per the contract’s own rules.

Author: JohnCrunch
Date: 2025-02-10T01:52:08.961Z

This looks great. Will follow, appreciated

Author: suiiii
Date: 2025-02-14T20:09:36.686Z

Can’t you achieve the same result using create3? For example pcaversaccio/createx on github is deployed on a lot of chains