Skip to content

Add ERC: PDAs (Programmatically Derived Addresses) #890

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 4 commits into
base: master
Choose a base branch
from
Open
Changes from 3 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
106 changes: 106 additions & 0 deletions ERCS/erc-7879.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,106 @@
---
EIP: 7879
Title: Program-Derived Addresses (PDAs)
Author: John Crunch, @JohnCrunch
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
Author: John Crunch, @JohnCrunch
author: John Crunch (@JohnCrunch)

Discussions-to: TBD
Status: Draft
Type: Standards Track
Category: ERC
Created: 2025-2-08
---

## Abstract
This Ethereum Improvement Proposal (EIP) introduces Program-Derived Addresses (PDAs) as a mechanism to generate deterministic, contract-derived addresses without private keys. Inspired by Solana’s PDA architecture, this standard enables smart contracts to create verifiable and immutable addresses using predefined seeds and cryptographic operations. PDAs provide stateless, permissionless interactions with smart contracts while ensuring security and uniqueness.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
This Ethereum Improvement Proposal (EIP) introduces Program-Derived Addresses (PDAs) as a mechanism to generate deterministic, contract-derived addresses without private keys. Inspired by Solana’s PDA architecture, this standard enables smart contracts to create verifiable and immutable addresses using predefined seeds and cryptographic operations. PDAs provide stateless, permissionless interactions with smart contracts while ensuring security and uniqueness.
Program-Derived Addresses (PDAs) are deterministic, contract-derived addresses without private keys. Inspired by Solana’s PDA architecture, this standard enables smart contracts to create verifiable and immutable addresses using predefined seeds and cryptographic operations. PDAs provide stateless, permissionless interactions with smart contracts while ensuring security and uniqueness.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your abstract is decent, but it's missing a high-level (but still technical) overview of how the proposal accomplishes its goals. You should sketch out what the derivation mechanism is, at least briefly.


## Motivation
Ethereum’s current address system requires explicit deployment of contracts to generate new addresses or the use of externally owned accounts (EOAs) with private keys. This introduces inefficiencies in contract-based account generation. However, Ethereum already supports deterministic contract deployment using CREATE2. PDAs provide:
- **Deterministic Contract Addresses**: Smart contracts can generate specific, predictable addresses for interactions without requiring deployment.
- **Improved UX & Statelessness**: Eliminates the need for EOAs for specific interactions, reducing gas costs and simplifying account recovery.
- **Enhanced Security**: No private key exists for PDAs, mitigating risks of key exposure and hacks.
- **Trustless Multi-Contract State Management**: Contracts can interact with off-chain and on-chain data using derived addresses without requiring intermediary registries.
sdf
## Specification
A **Program-Derived Address (PDA)** is an Ethereum address deterministically generated by a contract using a combination of:

- A **base contract address**
- A **set of seed values**
- A **cryptographic derivation function** (Keccak256, SHA256, or other secure hashing algorithms)

The PDA is computed as follows:
```solidity
function derivePDA(address baseContract, bytes32[] memory seeds) public pure returns (address) {
bytes32 hash = keccak256(abi.encodePacked(baseContract, seeds));
return address(uint160(uint256(hash)));
}
Comment on lines +30 to +34

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have some concerns/questions about this since there is no Discussions link to EthMagicians.
This function derives an Ethereum address by truncating a 32-byte Keccak-256 hash to 20 bytes?. If so, this is not the standard method for deriving Ethereum addresses. Usually , an Ethereum address is obtained by taking the last 20 bytes of the Keccak-256 hash of the public key.
Solidity's abi.encodePacked performs tight packing, this makes variable-length arrays like seeds might not be properly hashed as intended.
No Error Handling or validation for invalid inputs.

```

## Rationale

### Key Properties
- **No Private Key Association**: The PDA does not have a corresponding private key, making it non-custodial and non-signable.
- **Verifiable On-Chain**: Any contract can recompute a PDA and validate its authenticity.
- **Prevents Collisions**: By incorporating the contract’s address, PDAs remain unique to the originating smart contract.

### Use Cases
#### 1. Stateless Account Abstraction
PDAs allow contracts to operate permissionlessly on derived accounts, facilitating multi-user, multi-session access without requiring new wallet generation.

#### 2. Gasless Meta-Transactions
Users can interact with PDAs without directly owning them, enabling sponsored transactions where a relayer signs and pays gas on their behalf.

#### 3. Trustless Escrow & Sub-Accounts
Protocols can create predictable, verifiable addresses for escrow, lending, and financial primitives without requiring independent contract deployments.

#### 4. Off-Chain State Commitments
PDAs provide a deterministic address for off-chain data commitments, ensuring verifiability while reducing on-chain storage costs.

#### 5. Efficient Multi-Party Control Without Gas Costs
Ethereum’s multisig wallets require explicit transactions to modify ownership structures, incurring gas fees. PDAs enable multi-party control without the need for continuous storage updates, as authority can be derived programmatically.

#### 6. On-Chain Order Books and Marketplaces
Ethereum’s on-chain order books require storage mappings, making them expensive in gas costs. PDAs allow orders to be stored in derived addresses without bloating contract storage, similar to Solana’s Serum order book model.

#### 7. Dynamic On-Chain Games
PDAs can facilitate player state storage in decentralized games, reducing reliance on smart contract storage while maintaining programmatic access to game states.

#### 8. Precomputed Addresses for DeFi and Oracles
Lending protocols, AMMs, and on-chain oracles can generate deterministic PDAs for vaults, price feeds, and liquidity pools without requiring separate contract deployments, improving gas efficiency.
Comment on lines +39 to +67
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Use cases belong in Motivation. The Rationale section is for explaining choices made within the document itself.


## Backwards Compatibility
PDAs introduce a new derivation method but do not modify existing Ethereum accounts or contract mechanisms. They are opt-in and compatible with existing account models.

## Security Considerations
- **Collision Resistance**: Proper seed selection and hashing prevent unintended address overlaps.
- **Replay Attacks**: Since PDAs are stateless, contracts must implement nonce-based or time-locked execution policies.
- **Access Control**: Contracts should restrict interactions with PDAs to prevent unauthorized execution.

## Implementation Example
A sample implementation of a smart contract utilizing PDAs:
```solidity
contract PDARegistry {
mapping(address => bool) public validPDAs;

function registerPDA(bytes32[] memory seeds, uint256 bumpSeed) external {
address pda = derivePDA(msg.sender, seeds, bumpSeed);
require(validPDAs[pda] == false, "PDA already registered");
require(isPDA(pda, msg.sender, seeds, bumpSeed), "Invalid PDA");
validPDAs[pda] = true;
}

function derivePDA(address baseContract, bytes32[] memory seeds, uint256 bumpSeed) public pure returns (address) {
bytes32 hash = keccak256(abi.encodePacked(baseContract, seeds, bumpSeed));
return address(uint160(uint256(hash)));
}

function isPDA(address potentialPDA, address baseContract, bytes32[] memory seeds, uint256 bumpSeed) public pure returns (bool) {
return potentialPDA == derivePDA(baseContract, seeds, bumpSeed);
}
}
```

## Conclusion
Program-Derived Addresses (PDAs) introduce a deterministic, secure method for smart contracts to generate and interact with addresses without deploying new contracts or requiring EOAs. By integrating PDAs into Ethereum, we enable more flexible and efficient contract interactions while preserving security and decentralization.

## References
- Solana’s PDA Documentation: https://docs.solana.com/developing/programming-model/derived-addresses