Title: EIP_7900__Introduce_SDELEGATECALL_opcode_for_enhan
Category: EIPs

Author: NolanWang
Date: 2025-03-03T13:07:05.885Z

This draft EIP introduces a new EVM opcode SDELEGATECALL (secure delegatecall) that enhances security when executing external contract code. It functions similarly to the existing DELEGATECALL opcode but additionally returns the deployer’s address of the target contract, allowing the caller to verify the authenticity of the contract being called.

github.com/ethereum/EIPs








Draft EIP: Introduce SDELEGATECALL opcode for enhanced delegatecall security


ethereum:master ← maldiohead:master



          opened 11:39AM - 03 Mar 25 UTC




            maldiohead
          



+88
-0






This EIP introduces a new EVM opcode `SDELEGATECALL` (secure delegatecall) that …enhances security when executing external contract code. It functions similarly to the existing `DELEGATECALL` opcode but additionally returns the deployer's address of the target contract, allowing the caller to verify the authenticity of the contract being called.






Update Log
2025-03-03: First Time Drafted.
External Reviews
None as of 2025-03-03.
Outstanding Issues
None as of 2025-03-03.

Author: Arvolear
Date: 2025-03-03T18:55:16.421Z

Generally speaking, there are three existing use cases for a delegatecall:

Proxy/Diamond contracts.
Self multicall/Solidity libraries.
Some weird governance upgrade patterns.

In all these use cases, smart contract addresses are known beforehand. Everything else is probably an anti-pattern that shouldn’t be used. To me, this proposal promotes such anti-patterns without clear benefits. Though please correct me if I am wrong.

Author: NolanWang
Date: 2025-03-04T03:32:09.425Z

Let me address why SDELEGATECALL provides value even in scenarios where contract addresses are known:
Security Benefits for Established Patterns


For Proxy/Diamond contracts:

SDELEGATECALL lets contracts verify that implementations were deployed by trusted entities, not just that they exist at expected addresses
Permits proxy contracts to reject execution if implementation deployer isn’t whitelisted
Example: Even if an admin key is compromised and implementation address changed, the proxy can still verify the deployer is authorized



For Libraries/Multicalls:

We can allow deployers to configure their own whitelist to verify if the return value from SDELEGATECALL matches the whitelist
If configuring a whitelist seems troublesome, developers can continue using delegatecall
The two opcodes don’t conflict with each other - it depends on the specific use case



For Governance Upgrades:

Adds an additional verification layer beyond address-based checks
Ensures new implementations come from authorized deployers, preventing governance attacks that replace implementations



Not Promoting Anti-Patterns
Rather than encouraging delegatecall to random contracts, SDELEGATECALL actually makes established patterns more secure. It addresses the specific attack vector demonstrated in the Bybit hack, where the vulnerability wasn’t calling unknown addresses but rather compromised code at known addresses.
The core security insight: knowing an address isn’t enough when the code at that address can be maliciously replaced. SDELEGATECALL provides origin verification as an additional security layer.

Author: shemnon
Date: 2025-03-04T10:15:53.431Z

From an EVM implementation perspective there are two high level problems:
The first and lesser concern is that currently no operation results in a net add of more than one item to the operand stack. Basually all existing operations return zero or one items (modulo DUP/SWAP that may have a strange definitions, but the net is 1).  Adding an operation that adds two items will be a first for the opcodes so the level of scrutiny will be higher.
The second one is more problematic.  Clients do not track who deployed a contract and retroactively adding that info will be very expensive, requiring a re-evaluation of the entire chain. This would impact verkle/stateless work as well as the deployer address would need to be tracked, and that would require a significant spec and implementation revisions.
This would be an relatively large effort for a single opcode. That makes me skeptical we will ever reach consensus to ship this as specified.