Merge branch 'ethereum:master' into master

Author: uni-guillaume

.github/workflows/ci.yml

@@ -17,7 +17,7 @@ jobs:
   save-pr:
     name: Save PR Number
     runs-on: ubuntu-latest
-    
+
     steps:
       - name: Save PR number
         env:
@@ -38,7 +38,7 @@ jobs:
 
   htmlproofer:
     name: HTMLProofer
-    runs-on: ubuntu-20.04
+    runs-on: ubuntu-24.04
 
     steps:
       - name: Checkout EIPs
@@ -65,7 +65,7 @@ jobs:
           cd $GITHUB_WORKSPACE
           rm -rf ERCs
       - name: Setup Ruby
-        uses: ruby/setup-ruby@f26937343756480a8cb3ae1f623b9c8d89ed6984 # v1.196.0
+        uses: ruby/setup-ruby@fb404b9557c186e349162b0d8efb06e2bc36edea # v1.232.0
         with:
           ruby-version: '3.1' # Not needed with a .ruby-version file
           bundler-cache: true # runs 'bundle install' and caches installed gems automatically
@@ -74,7 +74,7 @@ jobs:
         run: bundle exec jekyll build
         env:
           JEKYLL_ENV: production
-          
+
       - name: Build Website
         run: |
           bundle exec jekyll doctor
@@ -88,11 +88,11 @@ jobs:
   link-check:
     name: Link Check
     runs-on: ubuntu-latest
-    
+
     steps:
       - name: Checkout EIP Repository
         uses: actions/checkout@47fbe2df0ad0e27efb67a70beac3555f192b062f
-        
+
       - name: Link Checker
         uses: gaurav-nelson/github-action-markdown-link-check@d53a906aa6b22b8979d33bc86170567e619495ec
         with:

.github/workflows/jekyll.yml

@@ -32,7 +32,7 @@ jobs:
     runs-on: ubuntu-latest
     steps:
       - name: Checkout
-        uses: actions/checkout@v3
+        uses: actions/checkout@v4
       - name: Setup Ruby
         uses: ruby/setup-ruby@f26937343756480a8cb3ae1f623b9c8d89ed6984 # v1.196.0
         with:
@@ -41,7 +41,7 @@ jobs:
           cache-version: 0 # Increment this number if you need to re-download cached gems
       - name: Setup Pages
         id: pages
-        uses: actions/configure-pages@v3
+        uses: actions/configure-pages@v5
       - name: Build with Jekyll
         # Outputs to the './_site' directory by default
         run: bundle exec jekyll build --baseurl "${{ steps.pages.outputs.base_path }}"

ERCS/erc-1123.md

@@ -1200,7 +1200,7 @@ To reference a contract type from a dependency, use the format
 -   The `<package-name>` value **must** be present in the keys of the
     `build_dependencies` of this Package.
 
--   The `<contract-alias>` value **must** be be a valid [Contract
+-   The `<contract-alias>` value **must** be a valid [Contract
     Alias](#term-contract-alias).
 
 -   The resolved package for `<package-name>` must contain the
@@ -1697,7 +1697,7 @@ Example:
         ...
     }
 
-A deployed instance of the `Wallet` contract would be of of type
+A deployed instance of the `Wallet` contract would be of type
 `Wallet`.
 
 

ERCS/erc-1581.md

@@ -10,7 +10,7 @@ category: ERC
 created: 2018-11-13
 ---
 ## Abstract
-BIP32 defines a way to generate hierarchical trees of keys which can be derived from a common master key. BIP32 and [BIP44](https://https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) defines the usage of these keys as wallets. In this EIP we describe the usage of such keys outside the scope of the blockchain defining a logical tree for key usage which can coexist (and thus share the same master) with existing BIP44 compatible wallets.
+BIP32 defines a way to generate hierarchical trees of keys which can be derived from a common master key. BIP32 and [BIP44](https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki) defines the usage of these keys as wallets. In this EIP we describe the usage of such keys outside the scope of the blockchain defining a logical tree for key usage which can coexist (and thus share the same master) with existing BIP44 compatible wallets.
 
 ## Motivation
 Applications interacting with the blockchain often make use of additional, non-blockchain technologies to perform the task they are designed for. For privacy and security sensitive mechanisms, sets of keys are needed. Reusing keys used for wallets can prove to be insecure, while keeping completely independent keys make backup and migration of the full set of credentials more complex. Defining a separate (from BIP44 compliant wallets) derivation branch allows combining the security of independent keys with the convenience of having a single piece of information which needs to be backup or migrated.

ERCS/erc-223.md

@@ -142,7 +142,7 @@ This standard sticks to the push transaction model where the transfer of assets
 
 This standard introduces the ability to correct user errors by allowing to handle ANY transactions on the recipients side and reject incorrect or improper transfers. This tokens utilize ONE transferring method for both types of interactions with contracts and externally owned addresses which can simplify the user experience and allow to avoid possible user mistakes.
 
-One downside of the commonly used [ERC-20](./eip-20.md) standard that ERC-223 is intended to solve is that [ERC-20](./eip-20.md) implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of [ERC-20](./eip-20.md) standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. [ERC-20](./eip-20.md) standard places the burden of determining the transferring method on the user and if the incorrect method is chosen the user can lose the transferred tokens. ERC-223 automatically determines the transferring method, preventing the user from losing tokens due to chosing wrong method.
+One downside of the commonly used [ERC-20](./eip-20.md) standard that ERC-223 is intended to solve is that [ERC-20](./eip-20.md) implements two methods of token transferring: (1) `transfer` function and (2) `approve + transferFrom` pattern. Transfer function of [ERC-20](./eip-20.md) standard does not notify the receiver and therefore if any tokens are sent to a contract with the `transfer` function then the receiver will not recognize this transfer and the tokens can become stuck in the receivers address without any possibility of recovering them. [ERC-20](./eip-20.md) standard places the burden of determining the transferring method on the user and if the incorrect method is chosen the user can lose the transferred tokens. ERC-223 automatically determines the transferring method, preventing the user from losing tokens due to choosing wrong method.
 
 ERC-223 is intended to simplify the interaction with contracts that are intended to work with tokens. ERC-223 utilizes a "deposit" pattern, similar to that of plain Ether. An ERC-223 deposit to a contract is a simple call of the `transfer` function. This is one transaction as opposed to two step process of `approve + transferFrom` depositing.
 

ERCS/erc-3009.md

@@ -521,7 +521,7 @@ library EIP712 {
 }
 ```
 
-A fully working implementation of EIP-3009 can be found in [this repository](https://github.com/CoinbaseStablecoin/eip-3009/blob/master/contracts/lib/EIP3009.sol). The repository also includes [an implementation of EIP-2612](https://github.com/CoinbaseStablecoin/eip-3009/blob/master/contracts/lib/EI32612.sol) that uses the EIP-712 library code presented above.
+A fully working implementation of EIP-3009 can be found in [this repository](../assets/eip-3009/EIP3009.sol). The repository also includes [an implementation of EIP-2612](../assets/eip-3009/EIP2612.sol) that uses the EIP-712 library code presented above.
 
 ## Security Considerations
 

ERCS/erc-4337.md

@@ -432,15 +432,19 @@ as it depends on non-permanent network properties such as operation and data gas
 However, the requirement is for the estimated value to be sufficient to cover the following costs:
 
 * Base bundle transaction cost. On Ethereum, `21000` gas divided by the number of `UserOperations`.
-* The calldata gas cost related to the `UserOperation`.
+* The calldata gas cost related to the `UserOperation` as defined in [EIP-2028](./eip-2028.md).
 * Static `EntryPoint` contract code execution.
 * Static memory cost when loading the fixed size fields of the `UserOperation` into EVM memory
 * Memory cost (including expansion cost) due to context returned by paymaster `validatePaymasterUserOp` function, if relevant.
   * External call to the `innerHandleOp()` function which is a major part of the `EntryPoint` implementation.
   Note that this value is not static and depends on the `UserOperation`'s position in the bundle.
-* EIP-7702 authorization cost, if any.
+* [EIP-7702] authorization cost, if any.
+* [EIP-7623](./eip-7623.md) calldata floor price increase is estimated as follows:
+  * Apply the new formula for `tx.gasUsed`, replacing the `execution_gas_used` value with an estimate for value made for this UserOperation.
+  * The estimate is calculated as a sum of all verification gas used during simulation (account creation, validation and paymaster validation) and 10% of the sum of execution and `postOp` gas limit.
 
 The bundler MUST require a slack in `PreVerificationGas` value, to accommodate memory expansion costs in the future bundle, and the expected position of the `UserOperation` in it.
+
 ### Alternative Mempools
 
 The simulation rules above are strict and prevent the ability of paymasters to grief the system.
@@ -487,8 +491,6 @@ for the `handleOps` validation in its entirety as for individual `UserOperations
 Otherwise, attackers may be able to use the banned opcodes to detect running on-chain and trigger a `FailedOp` revert.
 
 When a bundler includes a bundle in a block it must ensure that earlier transactions in the block don't make any `UserOperation` fail.
-It SHOULD either use an "access lists" parameter as defined in [EIP-2930](./eip-2930) to prevent conflicts,
-or place the bundle as the first transaction in the block.
 
 
 ### Error codes.
@@ -601,7 +603,7 @@ All `paymaster` contracts MUST check that all calls to the `validatePaymasterUse
 
 ### Aggregator contracts
 
-All `paymaster` contracts MUST check that all calls to the `validateSignatures()` function originates from the `EntryPoint`.
+All `aggregator` contracts MUST check that all calls to the `validateSignatures()` function originates from the `EntryPoint`.
 
 ### EIP-7702 delegated Smart Contract Accounts
 

ERCS/erc-4361.md

@@ -4,7 +4,8 @@ title: Sign-In with Ethereum
 description: Off-chain authentication for Ethereum accounts to establish sessions.
 author: Wayne Chang (@wyc), Gregory Rocco (@obstropolos), Brantly Millegan (@brantlymillegan), Nick Johnson (@Arachnid), Oliver Terbu (@awoie)
 discussions-to: https://ethereum-magicians.org/t/eip-4361-sign-in-with-ethereum/7263
-status: Review
+status: Last Call
+last-call-deadline: 2025-07-29
 type: Standards Track
 category: ERC
 created: 2021-10-11
@@ -38,7 +39,7 @@ Sign-In with Ethereum (SIWE) works as follows:
 
 #### ABNF Message Format
 
-A SIWE Message MUST conform with the following Augmented Backus–Naur Form (ABNF, RFC 5234) expression (note that `%s` denotes case sensitivity for a string term, as per RFC 7405).
+A SIWE Message MUST conform with the following Augmented Backus–Naur Form (ABNF, [RFC 5234](https://www.rfc-editor.org/rfc/rfc5234)) expression (note that `%s` denotes case sensitivity for a string term, as per [RFC 7405](https://www.rfc-editor.org/rfc/rfc7405)).
 
 ```abnf
 sign-in-with-ethereum =
@@ -116,9 +117,9 @@ This specification defines the following SIWE Message fields that can be parsed
 - `version` REQUIRED. The current version of the SIWE Message, which MUST be `1` for this specification.
 - `chain-id` REQUIRED. The [EIP-155](./eip-155.md) Chain ID to which the session is bound, and the network where Contract Accounts MUST be resolved.
 - `nonce` REQUIRED. A random string typically chosen by the relying party and used to prevent replay attacks, at least 8 alphanumeric characters.
-- `issued-at` REQUIRED. The time when the message was generated, typically the current time. Its value MUST be an ISO 8601 datetime string.
-- `expiration-time` OPTIONAL. The time when the signed authentication message is no longer valid. Its value MUST be an ISO 8601 datetime string.
-- `not-before` OPTIONAL. The time when the signed authentication message will become valid. Its value MUST be an ISO 8601 datetime string.
+- `issued-at` REQUIRED. The time when the message was generated, typically the current time. Its value MUST be an [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339) datetime string.
+- `expiration-time` OPTIONAL. The time when the signed authentication message is no longer valid. Its value MUST be an [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339) datetime string.
+- `not-before` OPTIONAL. The time when the signed authentication message will become valid. Its value MUST be an [RFC 3339](https://www.rfc-editor.org/rfc/rfc3339) datetime string.
 - `request-id` OPTIONAL. A system-specific identifier that MAY be used to uniquely refer to the sign-in request.
 - `resources` OPTIONAL. A list of information or references to information the user wishes to have resolved as part of authentication by the relying party. Every resource MUST be an RFC 3986 URI separated by `"\n- "` where `\n` is the byte `0x0a`.
 

ERCS/erc-5516.md

@@ -36,7 +36,7 @@ The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL
 
 **Smart contracts implementing this EIP MUST implement all of the functions in the `EIP-5516` interface.**
 
-**Smart contracts implementing this EIP MUST implement the [EIP-165](./eip-165.md) `supportsInterface` function and and MUST return the constant value `true` if `0x8314f22b` is passed through the `interfaceID` argument. They also MUST implement the [EIP-1155](./eip-1155.md) Interface and MUST return the constant value `true` if `0xd9b67a26` is passed through the `interfaceID` argument. Furthermore, they MUST implement the [EIP-1155](./eip-1155.md) Metadata interface, and MUST return the constant value `true` if `0x0e89341c` is passed through the `interfaceID` argument.**
+**Smart contracts implementing this EIP MUST implement the [EIP-165](./eip-165.md) `supportsInterface` function and MUST return the constant value `true` if `0x8314f22b` is passed through the `interfaceID` argument. They also MUST implement the [EIP-1155](./eip-1155.md) Interface and MUST return the constant value `true` if `0xd9b67a26` is passed through the `interfaceID` argument. Furthermore, they MUST implement the [EIP-1155](./eip-1155.md) Metadata interface, and MUST return the constant value `true` if `0x0e89341c` is passed through the `interfaceID` argument.**
 
 _See [EIP-1155](./eip-1155.md#specification)_
 

ERCS/erc-5559.md

@@ -1,6 +1,6 @@
 ---
 eip: 5559
-title: "Cross Chain Write Deferral Protocol"
+title: Cross Chain Write Deferral Protocol
 description: The cross chain write deferral protocol provides a mechanism to defer the storage & resolution of mutations to off-chain handlers
 author: Paul Gauvreau (@0xpaulio), Nick Johnson (@arachnid)
 discussions-to: https://ethereum-magicians.org/t/eip-cross-chain-write-deferral-protocol/10576