From 0b3e9cbfe35d277c74cfda3a3cebc02843f5d3c2 Mon Sep 17 00:00:00 2001
From: maldiohead <maldiohead@outlook.com>
Date: Mon, 3 Mar 2025 19:23:53 +0800
Subject: [PATCH 01/11] Add EIP: Introduce SDELEGATECALL opcode for enhanced
 delegatecall security

Signed-off-by: maldiohead <maldiohead@outlook.com>
---
 eip-secure-delegatecall.md |  88 +++++++++++++++++++++++++++
 eip-template.md            | 120 -------------------------------------
 2 files changed, 88 insertions(+), 120 deletions(-)
 create mode 100644 eip-secure-delegatecall.md
 delete mode 100644 eip-template.md

diff --git a/eip-secure-delegatecall.md b/eip-secure-delegatecall.md
new file mode 100644
index 00000000000000..7d5ad24aaad817
--- /dev/null
+++ b/eip-secure-delegatecall.md
@@ -0,0 +1,88 @@
+---
+title: Secure Delegatecall Opcode
+description: A secure version of delegatecall that returns the target contract's deployer address
+author: nolan wang (@maldiohead)
+discussions-to: [URL for discussion forum thread]
+status: Draft
+type: Standards Track
+category: Core
+created: 2025-03-03
+---
+
+## Abstract
+
+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.
+
+## Motivation
+
+The standard `DELEGATECALL` opcode executes untrusted external code in the context of the calling contract, which has led to numerous security incidents and significant funds loss. For example, the [Bybit hack incident](https://x.com/benbybit/status/1892963530422505586) resulted in approximately $14 billion in lost funds when attackers replaced wallet contract code with backdoored versions.
+
+By providing a way to verify the deployer of the target contract, `SDELEGATECALL` allows developers to implement additional security checks before execution continues, mitigating risks associated with malicious contract replacements or backdoors.
+
+## Specification
+
+
+
+A new EVM opcode `SDELEGATECALL` is introduced with the following properties:
+
+1. The opcode takes the same inputs as the existing `DELEGATECALL` opcode:
+   - `gas`: Gas to allocate for the call
+   - `contractaddress`: Address of the contract to call
+   - `argsOffset`, `argsSize`: Memory offset and size for call arguments
+   - `retOffset`, `retSize`: Memory offset and size for return data
+
+2. The opcode produces the following outputs:
+   - `success`: Boolean indicating if the call was successful (1) or failed (0)
+   - `deployer`: Address of the account that deployed the target contract
+   - `data`: Return data from the called contract (same as `DELEGATECALL`)
+
+3. The opcode SHALL execute the target contract code with the same context rules as `DELEGATECALL`.
+
+4. The opcode SHALL return the deployer's address as determined the contract create transcation.
+
+5. When the call completes, the stack items are arranged as follows (from top to bottom):
+   - `success` (1 for success, 0 for failure)
+   - `deployer` (the address of the contract deployer)
+   - The standard return data is placed in memory at the specified `retOffset`
+
+6. If the contract was created by another contract, the deployer address SHALL be the address of the creating contract, not the transaction sender.
+
+
+## Rationale
+
+By returning the deployer's address, `SDELEGATECALL` allows contracts to make informed decisions about execution based on the origin of the target contract. This provides a crucial security check when executing external code, as contracts can verify if the deployer is an expected/trusted address before continuing execution.
+
+The opcode enhances security while preserving the essential functionality of `DELEGATECALL`, making it straightforward for developers to adopt.
+
+## Backwards Compatibility
+
+No backward compatibility issues found. This EIP introduces a new opcode without modifying the behavior of existing opcodes.
+
+## Test Cases
+
+TBD
+
+## Reference Implementation
+
+TBD
+
+## Security Considerations
+
+While `SDELEGATECALL` provides an additional security layer compared to regular `DELEGATECALL`, several considerations remain:
+
+1. The deployer address alone may not be sufficient to establish trust, as legitimate deployers could also deploy malicious contracts.
+
+2. Contracts using this opcode should implement proper authorization checks on the returned deployer address.
+
+3. In the case of proxy contracts or contract factories, the deployer might be another contract rather than an EOA, requiring more complex verification.
+
+4. This solution doesn't prevent all types of delegatecall attacks, only those involving unauthorized contract replacements.
+
+5. Developers should consider implementing additional security measures such as:
+   - Allowlists of trusted deployers
+   - Contract signature verification
+   - Code hash verification
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).
\ No newline at end of file
diff --git a/eip-template.md b/eip-template.md
deleted file mode 100644
index ffdde950ce130a..00000000000000
--- a/eip-template.md
+++ /dev/null
@@ -1,120 +0,0 @@
----
-title: <The EIP title is a few words, not a complete sentence>
-description: <Description is one full (short) sentence>
-author: <a comma separated list of the author's or authors' name + GitHub username (in parenthesis), or name and email (in angle brackets).  Example, FirstName LastName (@GitHubUsername), FirstName LastName <foo@bar.com>, FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)>
-discussions-to: <URL>
-status: Draft
-type: <Standards Track, Meta, or Informational>
-category: <Core, Networking, Interface, or ERC> # Only required for Standards Track. Otherwise, remove this field.
-created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
-requires: <EIP number(s)> # Only required when you reference an EIP in the `Specification` section. Otherwise, remove this field.
----
-
-<!--
-  READ EIP-1 (https://eips.ethereum.org/EIPS/eip-1) BEFORE USING THIS TEMPLATE!
-
-  This is the suggested template for new EIPs. After you have filled in the requisite fields, please delete these comments.
-
-  Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`.
-
-  The title should be 44 characters or less. It should not repeat the EIP number in title, irrespective of the category.
-
-  TODO: Remove this comment before submitting
--->
-
-## Abstract
-
-<!--
-  The Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.
-
-  TODO: Remove this comment before submitting
--->
-
-## Motivation
-
-<!--
-  This section is optional.
-
-  The motivation section should include a description of any nontrivial problems the EIP solves. It should not describe how the EIP solves those problems, unless it is not immediately obvious. It should not describe why the EIP should be made into a standard, unless it is not immediately obvious.
-
-  With a few exceptions, external links are not allowed. If you feel that a particular resource would demonstrate a compelling case for your EIP, then save it as a printer-friendly PDF, put it in the assets folder, and link to that copy.
-
-  TODO: Remove this comment before submitting
--->
-
-## Specification
-
-<!--
-  The Specification section should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (besu, erigon, ethereumjs, go-ethereum, nethermind, or others).
-
-  It is recommended to follow RFC 2119 and RFC 8170. Do not remove the key word definitions if RFC 2119 and RFC 8170 are followed.
-
-  TODO: Remove this comment before submitting
--->
-
-The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
-
-## Rationale
-
-<!--
-  The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
-
-  The current placeholder is acceptable for a draft.
-
-  TODO: Remove this comment before submitting
--->
-
-TBD
-
-## Backwards Compatibility
-
-<!--
-
-  This section is optional.
-
-  All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
-
-  The current placeholder is acceptable for a draft.
-
-  TODO: Remove this comment before submitting
--->
-
-No backward compatibility issues found.
-
-## Test Cases
-
-<!--
-  This section is optional for non-Core EIPs.
-
-  The Test Cases section should include expected input/output pairs, but may include a succinct set of executable tests. It should not include project build files. No new requirements may be introduced here (meaning an implementation following only the Specification section should pass all tests here.)
-  If the test suite is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. External links will not be allowed
-
-  TODO: Remove this comment before submitting
--->
-
-## Reference Implementation
-
-<!--
-  This section is optional.
-
-  The Reference Implementation section should include a minimal implementation that assists in understanding or implementing this specification. It should not include project build files. The reference implementation is not a replacement for the Specification section, and the proposal should still be understandable without it.
-  If the reference implementation is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. External links will not be allowed.
-
-  TODO: Remove this comment before submitting
--->
-
-## Security Considerations
-
-<!--
-  All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. For example, include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
-
-  The current placeholder is acceptable for a draft.
-
-  TODO: Remove this comment before submitting
--->
-
-Needs discussion.
-
-## Copyright
-
-Copyright and related rights waived via [CC0](../LICENSE.md).

From 8f3b61e776ffc0d90279a42f1ae0a74f0db0813e Mon Sep 17 00:00:00 2001
From: maldiohead <maldiohead@outlook.com>
Date: Mon, 3 Mar 2025 19:37:33 +0800
Subject: [PATCH 02/11] recover the eip-template.md

Signed-off-by: maldiohead <maldiohead@outlook.com>
---
 eip-template.md | 120 ++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 120 insertions(+)
 create mode 100644 eip-template.md

diff --git a/eip-template.md b/eip-template.md
new file mode 100644
index 00000000000000..6540ae83360502
--- /dev/null
+++ b/eip-template.md
@@ -0,0 +1,120 @@
+---
+title: delegatecall enchance
+description: <Description is one full (short) sentence>
+author: <a comma separated list of the author's or authors' name + GitHub username (in parenthesis), or name and email (in angle brackets).  Example, FirstName LastName (@GitHubUsername), FirstName LastName <foo@bar.com>, FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)>
+discussions-to: <URL>
+status: Draft
+type: <Standards Track, Meta, or Informational>
+category: <Core, Networking, Interface, or ERC> # Only required for Standards Track. Otherwise, remove this field.
+created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
+requires: <EIP number(s)> # Only required when you reference an EIP in the `Specification` section. Otherwise, remove this field.
+---
+
+<!--
+  READ EIP-1 (https://eips.ethereum.org/EIPS/eip-1) BEFORE USING THIS TEMPLATE!
+
+  This is the suggested template for new EIPs. After you have filled in the requisite fields, please delete these comments.
+
+  Note that an EIP number will be assigned by an editor. When opening a pull request to submit your EIP, please use an abbreviated title in the filename, `eip-draft_title_abbrev.md`.
+
+  The title should be 44 characters or less. It should not repeat the EIP number in title, irrespective of the category.
+
+  TODO: Remove this comment before submitting
+-->
+
+## Abstract
+
+<!--
+  The Abstract is a multi-sentence (short paragraph) technical summary. This should be a very terse and human-readable version of the specification section. Someone should be able to read only the abstract to get the gist of what this specification does.
+
+  TODO: Remove this comment before submitting
+-->
+
+## Motivation
+
+<!--
+  This section is optional.
+
+  The motivation section should include a description of any nontrivial problems the EIP solves. It should not describe how the EIP solves those problems, unless it is not immediately obvious. It should not describe why the EIP should be made into a standard, unless it is not immediately obvious.
+
+  With a few exceptions, external links are not allowed. If you feel that a particular resource would demonstrate a compelling case for your EIP, then save it as a printer-friendly PDF, put it in the assets folder, and link to that copy.
+
+  TODO: Remove this comment before submitting
+-->
+
+## Specification
+
+<!--
+  The Specification section should describe the syntax and semantics of any new feature. The specification should be detailed enough to allow competing, interoperable implementations for any of the current Ethereum platforms (besu, erigon, ethereumjs, go-ethereum, nethermind, or others).
+
+  It is recommended to follow RFC 2119 and RFC 8170. Do not remove the key word definitions if RFC 2119 and RFC 8170 are followed.
+
+  TODO: Remove this comment before submitting
+-->
+
+The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.
+
+## Rationale
+
+<!--
+  The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages.
+
+  The current placeholder is acceptable for a draft.
+
+  TODO: Remove this comment before submitting
+-->
+
+TBD
+
+## Backwards Compatibility
+
+<!--
+
+  This section is optional.
+
+  All EIPs that introduce backwards incompatibilities must include a section describing these incompatibilities and their severity. The EIP must explain how the author proposes to deal with these incompatibilities. EIP submissions without a sufficient backwards compatibility treatise may be rejected outright.
+
+  The current placeholder is acceptable for a draft.
+
+  TODO: Remove this comment before submitting
+-->
+
+No backward compatibility issues found.
+
+## Test Cases
+
+<!--
+  This section is optional for non-Core EIPs.
+
+  The Test Cases section should include expected input/output pairs, but may include a succinct set of executable tests. It should not include project build files. No new requirements may be introduced here (meaning an implementation following only the Specification section should pass all tests here.)
+  If the test suite is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. External links will not be allowed
+
+  TODO: Remove this comment before submitting
+-->
+
+## Reference Implementation
+
+<!--
+  This section is optional.
+
+  The Reference Implementation section should include a minimal implementation that assists in understanding or implementing this specification. It should not include project build files. The reference implementation is not a replacement for the Specification section, and the proposal should still be understandable without it.
+  If the reference implementation is too large to reasonably be included inline, then consider adding it as one or more files in `../assets/eip-####/`. External links will not be allowed.
+
+  TODO: Remove this comment before submitting
+-->
+
+## Security Considerations
+
+<!--
+  All EIPs must contain a section that discusses the security implications/considerations relevant to the proposed change. Include information that might be important for security discussions, surfaces risks and can be used throughout the life cycle of the proposal. For example, include security-relevant design decisions, concerns, important discussions, implementation-specific guidance and pitfalls, an outline of threats and risks and how they are being addressed. EIP submissions missing the "Security Considerations" section will be rejected. An EIP cannot proceed to status "Final" without a Security Considerations discussion deemed sufficient by the reviewers.
+
+  The current placeholder is acceptable for a draft.
+
+  TODO: Remove this comment before submitting
+-->
+
+Needs discussion.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](../LICENSE.md).

From ae33f6b91fb2df1fdc80cad361335ca9462e165b Mon Sep 17 00:00:00 2001
From: maldiohead <maldiohead@outlook.com>
Date: Mon, 3 Mar 2025 19:42:12 +0800
Subject: [PATCH 03/11] recover the eip-template.md

Signed-off-by: maldiohead <maldiohead@outlook.com>
---
 eip-template.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eip-template.md b/eip-template.md
index 6540ae83360502..ffdde950ce130a 100644
--- a/eip-template.md
+++ b/eip-template.md
@@ -1,5 +1,5 @@
 ---
-title: delegatecall enchance
+title: <The EIP title is a few words, not a complete sentence>
 description: <Description is one full (short) sentence>
 author: <a comma separated list of the author's or authors' name + GitHub username (in parenthesis), or name and email (in angle brackets).  Example, FirstName LastName (@GitHubUsername), FirstName LastName <foo@bar.com>, FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)>
 discussions-to: <URL>

From 92480766fe8899a106ce9c1c59603e9e9f37054d Mon Sep 17 00:00:00 2001
From: maldiohead <maldiohead@outlook.com>
Date: Mon, 3 Mar 2025 19:45:08 +0800
Subject: [PATCH 04/11] fix the format

Signed-off-by: maldiohead <maldiohead@outlook.com>
---
 eip-secure-delegatecall.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eip-secure-delegatecall.md b/eip-secure-delegatecall.md
index 7d5ad24aaad817..e37fe6754bae08 100644
--- a/eip-secure-delegatecall.md
+++ b/eip-secure-delegatecall.md
@@ -85,4 +85,4 @@ While `SDELEGATECALL` provides an additional security layer compared to regular
 
 ## Copyright
 
-Copyright and related rights waived via [CC0](../LICENSE.md).
\ No newline at end of file
+Copyright and related rights waived via [CC0](../LICENSE.md).

From 11caf54b1e277cbba5f1306c04ef0ff8050bd8dd Mon Sep 17 00:00:00 2001
From: maldiohead <maldiohead@outlook.com>
Date: Mon, 3 Mar 2025 21:12:11 +0800
Subject: [PATCH 05/11] add discussion link

Signed-off-by: maldiohead <maldiohead@outlook.com>
---
 eip-secure-delegatecall.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eip-secure-delegatecall.md b/eip-secure-delegatecall.md
index e37fe6754bae08..abaeed36f32aff 100644
--- a/eip-secure-delegatecall.md
+++ b/eip-secure-delegatecall.md
@@ -1,8 +1,8 @@
 ---
 title: Secure Delegatecall Opcode
 description: A secure version of delegatecall that returns the target contract's deployer address
-author: nolan wang (@maldiohead)
-discussions-to: [URL for discussion forum thread]
+author: nolan wang (https://x.com/ma1fan)
+discussions-to:https://ethereum-magicians.org/t/introduce-sdelegatecall-opcode-for-enhanced-delegatecall-security/23045/1 
 status: Draft
 type: Standards Track
 category: Core

From 7c41e5601627a0b3f81d8401dda8410e6e9340c4 Mon Sep 17 00:00:00 2001
From: maldiohead <maldiohead@outlook.com>
Date: Mon, 3 Mar 2025 21:16:57 +0800
Subject: [PATCH 06/11] fix the link

Signed-off-by: maldiohead <maldiohead@outlook.com>
---
 eip-secure-delegatecall.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eip-secure-delegatecall.md b/eip-secure-delegatecall.md
index abaeed36f32aff..199ffdd5e9b383 100644
--- a/eip-secure-delegatecall.md
+++ b/eip-secure-delegatecall.md
@@ -2,7 +2,7 @@
 title: Secure Delegatecall Opcode
 description: A secure version of delegatecall that returns the target contract's deployer address
 author: nolan wang (https://x.com/ma1fan)
-discussions-to:https://ethereum-magicians.org/t/introduce-sdelegatecall-opcode-for-enhanced-delegatecall-security/23045/1 
+discussions-to: https://ethereum-magicians.org/t/introduce-sdelegatecall-opcode-for-enhanced-delegatecall-security/23045/
 status: Draft
 type: Standards Track
 category: Core

From 8536ace245ef55c03c72b8e1d5d102c8a73e9497 Mon Sep 17 00:00:00 2001
From: maldiohead <maldiohead@outlook.com>
Date: Mon, 3 Mar 2025 21:19:57 +0800
Subject: [PATCH 07/11] fix the Specification point 4

Signed-off-by: maldiohead <maldiohead@outlook.com>
---
 eip-secure-delegatecall.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/eip-secure-delegatecall.md b/eip-secure-delegatecall.md
index 199ffdd5e9b383..bfd5d1f29609fa 100644
--- a/eip-secure-delegatecall.md
+++ b/eip-secure-delegatecall.md
@@ -38,7 +38,7 @@ A new EVM opcode `SDELEGATECALL` is introduced with the following properties:
 
 3. The opcode SHALL execute the target contract code with the same context rules as `DELEGATECALL`.
 
-4. The opcode SHALL return the deployer's address as determined the contract create transcation.
+4. The opcode SHALL return the deployer's address as determined by the contract creation transaction
 
 5. When the call completes, the stack items are arranged as follows (from top to bottom):
    - `success` (1 for success, 0 for failure)

From 71a74c1c9e2aa2ed6364d0a0011f39e4f98385c7 Mon Sep 17 00:00:00 2001
From: Sam Wilson <57262657+SamWilsn@users.noreply.github.com>
Date: Mon, 3 Mar 2025 09:44:16 -0500
Subject: [PATCH 08/11] Update and rename eip-secure-delegatecall.md to
 eip-7900.md

---
 eip-secure-delegatecall.md => eip-7900.md | 1 +
 1 file changed, 1 insertion(+)
 rename eip-secure-delegatecall.md => eip-7900.md (99%)

diff --git a/eip-secure-delegatecall.md b/eip-7900.md
similarity index 99%
rename from eip-secure-delegatecall.md
rename to eip-7900.md
index bfd5d1f29609fa..27a23bf13df09d 100644
--- a/eip-secure-delegatecall.md
+++ b/eip-7900.md
@@ -1,4 +1,5 @@
 ---
+eip: 7900
 title: Secure Delegatecall Opcode
 description: A secure version of delegatecall that returns the target contract's deployer address
 author: nolan wang (https://x.com/ma1fan)

From 1ffc501d70221125b73644f8bc15a23f85dfb0bd Mon Sep 17 00:00:00 2001
From: maldiohead <maldiohead@outlook.com>
Date: Tue, 4 Mar 2025 10:35:37 +0800
Subject: [PATCH 09/11] update the Rationale

Signed-off-by: maldiohead <maldiohead@outlook.com>
---
 1.sol                      | 17 +++++++++++++++++
 eip-secure-delegatecall.md | 21 ++++++++++++++++++---
 2 files changed, 35 insertions(+), 3 deletions(-)
 create mode 100644 1.sol

diff --git a/1.sol b/1.sol
new file mode 100644
index 00000000000000..a39ab285ba61b7
--- /dev/null
+++ b/1.sol
@@ -0,0 +1,17 @@
+^pragma solidity ^0.4.24;
+contract Delegate {
+    address public owner;
+mapping(address => bool) public whiteListed;
+
+    constructor() public {
+        owner = msg.sender;
+    }
+    function pwn() public {
+        owner = msg.sender;
+        (success,deployer,byte memory data)=sdelegatecall(gas,addr,argsOffset, argsSize,retOffset, retSize)
+ if whiteListed[deployer]! =true{
+        
+        revert();
+    }
+}
+
diff --git a/eip-secure-delegatecall.md b/eip-secure-delegatecall.md
index bfd5d1f29609fa..61c3bcc3ee6fae 100644
--- a/eip-secure-delegatecall.md
+++ b/eip-secure-delegatecall.md
@@ -50,9 +50,24 @@ A new EVM opcode `SDELEGATECALL` is introduced with the following properties:
 
 ## Rationale
 
-By returning the deployer's address, `SDELEGATECALL` allows contracts to make informed decisions about execution based on the origin of the target contract. This provides a crucial security check when executing external code, as contracts can verify if the deployer is an expected/trusted address before continuing execution.
-
-The opcode enhances security while preserving the essential functionality of `DELEGATECALL`, making it straightforward for developers to adopt.
+The SDELEGATECALL opcode represents a significant security enhancement over DELEGATECALL by exposing the deployer's address of the target contract. This design enables smart contracts to implement origin-based trust verification, allowing developers to make security decisions based on the provenance of external code rather than just its current address. With this information, contracts can maintain whitelists of trusted deployers and reject execution from unauthorized sources, effectively preventing many contract replacement attacks.
+
+This security improvement is achieved without sacrificing the core functionality that makes DELEGATECALL valuable for proxy patterns and other use cases. The opcode maintains backward compatibility with existing patterns while providing additional security guarantees.
+
+Below is a simple demonstrating the practical application:
+
+```solidity
+contract SecureProxy {
+   mapping(address => bool) public whiteListed;
+   ...
+   fallback()external payable  {
+   (success,deployer,byte memory data)=sdelegatecall(gas,addr,argsOffset, argsSize,retOffset, retSize);
+   if whiteListed[deployer]! =true{
+        revert();
+    }
+   ...
+}
+```
 
 ## Backwards Compatibility
 

From 8f8ae496107953424734527b07e05112eabbfb1c Mon Sep 17 00:00:00 2001
From: maldiohead <maldiohead@outlook.com>
Date: Tue, 4 Mar 2025 10:37:10 +0800
Subject: [PATCH 10/11] fix the Rationale

Signed-off-by: maldiohead <maldiohead@outlook.com>
---
 1.sol | 17 -----------------
 1 file changed, 17 deletions(-)
 delete mode 100644 1.sol

diff --git a/1.sol b/1.sol
deleted file mode 100644
index a39ab285ba61b7..00000000000000
--- a/1.sol
+++ /dev/null
@@ -1,17 +0,0 @@
-^pragma solidity ^0.4.24;
-contract Delegate {
-    address public owner;
-mapping(address => bool) public whiteListed;
-
-    constructor() public {
-        owner = msg.sender;
-    }
-    function pwn() public {
-        owner = msg.sender;
-        (success,deployer,byte memory data)=sdelegatecall(gas,addr,argsOffset, argsSize,retOffset, retSize)
- if whiteListed[deployer]! =true{
-        
-        revert();
-    }
-}
-

From 135ff8af9793dede08cbf39090e4ad3c31ef2f72 Mon Sep 17 00:00:00 2001
From: maldiohead <maldiohead@outlook.com>
Date: Tue, 4 Mar 2025 11:47:14 +0800
Subject: [PATCH 11/11] fix the description

Signed-off-by: maldiohead <maldiohead@outlook.com>
---
 eip-7900.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/eip-7900.md b/eip-7900.md
index fcd452da817cad..1457f8ccd36fc0 100644
--- a/eip-7900.md
+++ b/eip-7900.md
@@ -28,7 +28,7 @@ A new EVM opcode `SDELEGATECALL` is introduced with the following properties:
 
 1. The opcode takes the same inputs as the existing `DELEGATECALL` opcode:
    - `gas`: Gas to allocate for the call
-   - `contractaddress`: Address of the contract to call
+   - `targetcontract`: Address of the contract to call
    - `argsOffset`, `argsSize`: Memory offset and size for call arguments
    - `retOffset`, `retSize`: Memory offset and size for return data
 
@@ -43,7 +43,7 @@ A new EVM opcode `SDELEGATECALL` is introduced with the following properties:
 
 5. When the call completes, the stack items are arranged as follows (from top to bottom):
    - `success` (1 for success, 0 for failure)
-   - `deployer` (the address of the contract deployer)
+   - `deployer` (the address of the `targetcontract` deployer)
    - The standard return data is placed in memory at the specified `retOffset`
 
 6. If the contract was created by another contract, the deployer address SHALL be the address of the creating contract, not the transaction sender.