Merge branch 'master' into eip-PLUME

.github/CODEOWNERS

@@ -1 +1 @@
-* @eth-bot
+* @eip-review-bot

.github/workflows/auto-review-bot.yml

@@ -24,7 +24,7 @@ jobs:
 
       - name: Auto Review Bot
         id: auto-review-bot
-        uses: ethereum/eip-review-bot@3e9905fcb72cf81ae9ed732df429c28b17e155b1
+        uses: ethereum/eip-review-bot@dist
         continue-on-error: true
         with:
           token: ${{ secrets.TOKEN }}

.github/workflows/auto-review-trigger.yml

@@ -21,15 +21,19 @@ jobs:
     runs-on: ubuntu-latest
     name: Trigger
     steps:
+      - name: Stop Bot Recursion
+        run: exit 1
+        if: (endsWith(github.event.sender.login, '-bot') || endsWith(github.event.sender.login, '[bot]')) && github.event.sender.login != 'renovate[bot]'
+
       - name: Write PR Number - PR Target
         run: echo $PR_NUMBER > pr-number.txt
-        if: github.event_name == 'pull_request_target' && ((!endsWith(github.event.sender.login, '-bot') && !endsWith(github.event.sender.login, '[bot]')) || github.event.sender.login == 'renovate[bot]')
+        if: github.event_name == 'pull_request_target'
         env:
           PR_NUMBER: ${{ github.event.number }}
 
       - name: Write PR Number - PR Review
         run: echo $PR_NUMBER > pr-number.txt
-        if: github.event_name == 'pull_request_review' && !endsWith(github.event.sender.login, '-bot') && !endsWith(github.event.sender.login, '[bot]')
+        if: github.event_name == 'pull_request_review'
         env:
           PR_NUMBER: ${{ github.event.pull_request.number }}
 

.github/workflows/ci.yml

@@ -41,15 +41,40 @@ jobs:
     runs-on: ubuntu-20.04
 
     steps:
-      - name: Checkout EIP Repository
-        uses: actions/checkout@47fbe2df0ad0e27efb67a70beac3555f192b062f
-
-      - name: Install Ruby
-        uses: ruby/setup-ruby@55283cc23133118229fd3f97f9336ee23a179fcf
+      - name: Checkout EIPs
+        uses: actions/checkout@v4
         with:
-          ruby-version: 3.1.4 # 3.2 fails, see https://github.com/github/pages-gem/issues/879
-          bundler-cache: true
-
+          repository: ethereum/EIPs
+          path: ''
+      - name: Checkout ERCs
+        uses: actions/checkout@v4
+        with:
+          repository: ethereum/ERCs
+          path: ERCs
+      - name: Merge Repos
+        run: |
+          mkdir -p $GITHUB_WORKSPACE/ERCs/ERCS
+          mkdir -p $GITHUB_WORKSPACE/ERCs/EIPS
+          cp -rp $GITHUB_WORKSPACE/ERCs/ERCS/. $GITHUB_WORKSPACE/EIPS
+          cp -rp $GITHUB_WORKSPACE/ERCs/EIPS/. $GITHUB_WORKSPACE/EIPS
+          cp -rp $GITHUB_WORKSPACE/ERCs/assets/. $GITHUB_WORKSPACE/assets
+          cd $GITHUB_WORKSPACE/EIPS
+          find . -name "erc-*.md" -type f -exec sh -c 'echo mv "$1" "$(echo "$1" | sed s/erc/eip/)"' _ {} \; | sh
+          cd $GITHUB_WORKSPACE/assets
+          find . -name "erc-*" -type d -exec sh -c 'echo mv "$1" "$(echo "$1" | sed s/erc/eip/)"' _ {} \; | sh
+          cd $GITHUB_WORKSPACE
+          rm -rf ERCs
+      - name: Setup Ruby
+        uses: ruby/setup-ruby@55283cc23133118229fd3f97f9336ee23a179fcf # v1.146.0
+        with:
+          ruby-version: '3.1' # Not needed with a .ruby-version file
+          bundler-cache: true # runs 'bundle install' and caches installed gems automatically
+          cache-version: 0 # Increment this number if you need to re-download cached gems
+      - name: Build with Jekyll
+        run: bundle exec jekyll build
+        env:
+          JEKYLL_ENV: production
+
       - name: Build Website
         run: |
           bundle exec jekyll doctor
@@ -111,7 +136,7 @@ jobs:
       - name: Checkout EIP Repository
         uses: actions/checkout@47fbe2df0ad0e27efb67a70beac3555f192b062f
 
-      - uses: ethereum/eipw-action@6858f56d1d9e5cbe49a0afd85150669f6983ed20
+      - uses: ethereum/eipw-action@6785fa283773db4819cb0abf17a185a1d9b6eb9f
         id: eipw
         with:
           token: ${{ secrets.GITHUB_TOKEN }}

.github/workflows/post-ci.yml

@@ -35,7 +35,7 @@ jobs:
           recreate: true
           message: |
             The commit ${{ steps.save-pr-data.outputs.pr_sha }} (as a parent of ${{ steps.save-pr-data.outputs.merge_sha }}) contains errors.
-            Please inspect the [Run Summary](https://github.com/ethereum/EIPs/pull/${{ steps.save-pr-data.outputs.pr_number }}/files) for details.
+            Please inspect the [Run Summary](https://github.com/ethereum/ercs/${{ steps.save-pr-data.outputs.pr_number }}/files) for details.
 
       - name: Add Waiting Label
         uses: actions-ecosystem/action-add-labels@288072f1a3b596f4350fe135bcfe381a23abadef

.github/workflows/stale.yml

@@ -10,7 +10,7 @@ permissions:
 
 jobs:
   stale:
-    if: github.repository == 'ethereum/eips'
+    if: github.repository == 'ethereum/ercs'
     runs-on: ubuntu-latest
     name: Mark Stale Issues
     steps:

ERCS/erc-1363.md

@@ -6,7 +6,7 @@ discussions-to: https://github.com/ethereum/eips/issues/1363
 status: Final
 type: Standards Track
 category: ERC
-created: 2020-01-31
+created: 2018-08-30
 requires: 20, 165
 ---
 

ERCS/erc-223.md

@@ -70,16 +70,6 @@ Returns the number of decimals of the token. The functionality of this method is
 
 OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present. 
 
-##### `standard`
-
-```solidity
-function standard() view returns (string memory)  
-```
-
-Returns the identifier of the standard. If the token is [ERC-223](./eip-20.md) then it must return `"223"`.
-
-OPTIONAL - This method can be used to improve usability, but interfaces and other contracts MUST NOT expect these values to be present.
-
 ##### `balanceOf`
 
 ```solidity

ERCS/erc-2612.md

@@ -50,7 +50,7 @@ The semantics of which are as follows:
 
 For all addresses `owner`, `spender`, uint256s `value`, `deadline` and `nonce`, uint8 `v`, bytes32 `r` and `s`,
 a call to `permit(owner, spender, value, deadline, v, r, s)` will set
-`approval[owner][spender]` to `value`,
+`allowance[owner][spender]` to `value`,
 increment `nonces[owner]` by 1,
 and emit a corresponding `Approval` event,
 if and only if the following conditions are met:

ERCS/erc-3643.md

@@ -4,7 +4,8 @@ title: T-REX - Token for Regulated EXchanges
 description: An institutional grade security token contract that provides interfaces for the management and compliant transfer of security tokens.
 author: Joachim Lebrun (@Joachim-Lebrun), Tony Malghem (@TonyMalghem), Kevin Thizy (@Nakasar), Luc Falempin (@lfalempin), Adam Boudjemaa (@Aboudjem)
 discussions-to: https://ethereum-magicians.org/t/eip-3643-proposition-of-the-t-rex-token-standard-for-securities/6844
-status: Review
+status: Last Call
+last-call-deadline: 2023-11-28
 type: Standards Track
 category: ERC
 created: 2021-07-09
@@ -391,6 +392,12 @@ The T-REX standard provides a comprehensive framework for managing the lifecycle
 
 The T-REX standard supports the implementation of additional compliance rules through modular compliance. These modules can be used to enforce a wide range of rules and restrictions, such as caps on the number of investors or the percentage of tokens held by a single investor, restrictions on transfers between certain types of investors, and more. This flexibility allows issuers to tailor the compliance rules of their tokens to their specific needs and regulatory environment.
 
+### Inclusion of Agent-Related Functions
+
+The inclusion of Agent-scoped functions within the standard interfaces is deliberate. The intent is to accommodate secure and adaptable token management practices that surpass the capabilities of EOA management. We envision scenarios where the agent role is fulfilled by automated systems or smart contracts, capable of programmatically executing operational functions like minting, burning, and freezing in response to specified criteria or regulatory triggers. For example, a smart contract might automatically burn tokens to align with redemption requests in an open-ended fund, or freeze tokens associated with wallets engaged in fraudulent activities.
+
+Consequently, these functions are standardized to provide a uniform interface for various automated systems interacting with different ERC-3643 tokens, allowing for standardized tooling and interfaces that work across the entire ecosystem. This approach ensures that ERC-3643 remains flexible, future-proof, and capable of supporting a wide array of operational models.
+
 ## Backwards Compatibility
 
 T-REX tokens should be backwards compatible with ERC-20 and ERC-173

ERCS/erc-5050.md

@@ -7,7 +7,7 @@ discussions-to: https://ethereum-magicians.org/t/eip-5050-nft-interaction-standa
 status: Stagnant
 type: Standards Track
 category: ERC
-created: 2021-4-18
+created: 2021-04-18
 requires: 165, 173, 721, 1155, 1820, 4906
 ---
 
@@ -348,4 +348,4 @@ As discussed in [Validation](#validation), this is viable because the initiating
 
 ## Copyright
 
-Copyright and related rights waived via [CC0](../LICENSE.md).
+Copyright and related rights waived via [CC0](../LICENSE.md).

ERCS/erc-5564.md

@@ -12,7 +12,7 @@ created: 2022-08-13
 
 ## Abstract
 
-This specification establishes a standardized method for interacting with stealth addresses, which allow senders of transactions or transfers to non-interactively generate private accounts exclusively accessible by their recipients. Moreover, this specification enables developers to create stealth address protocols based on the foundational implementation outlined in this EIP, utilizing a singleton contract to emit the necessary information for recipients. In addition to the base implementation, this ERC also outlines the first implementation of a cryptographic scheme, specifically the SECP256k1 curve.
+This specification establishes a standardized method for interacting with stealth addresses, which allow senders of transactions or transfers to non-interactively generate private accounts exclusively accessible by their recipients. Moreover, this specification enables developers to create stealth address protocols based on the foundational implementation outlined in this ERC, utilizing a singleton contract to emit the necessary information for recipients. In addition to the base implementation, this ERC also outlines the first implementation of a cryptographic scheme, specifically the SECP256k1 curve.
 
 
 ## Motivation
@@ -72,20 +72,22 @@ A recipient MUST be able to compute the private key for a stealth address by cal
 /// @notice Computes the stealth private key for a stealth address.
 /// @param stealthAddress The expected stealth address.
 /// @param ephemeralPubKey The ephemeral public key used to generate the stealth address.
+/// @param viewingKey The recipient's viewing private key.
 /// @param spendingKey The recipient's spending private key.
 /// @return stealthKey The stealth private key corresponding to the stealth address.
 /// @dev The stealth address input is not strictly necessary, but it is included so the method
 /// can validate that the stealth private key was generated correctly.
 function computeStealthKey(
   address stealthAddress,
   bytes memory ephemeralPubKey,
+  bytes memory viewingKey,
   bytes memory spendingKey
 ) external view returns (bytes memory);
 ```
 
 The implementation of these methods is scheme-specific. The specification of a new stealth address scheme MUST specify the implementation for each of these methods. Additionally, although these function interfaces are specified in Solidity, they do not necessarily ever need to be implemented in Solidity, but any library or SDK conforming to this specification MUST implement these methods with compatible function interfaces.
 
-A 256 bit integer (`schemeId`) is used to identify stealth address schemes. A mapping from the schemeId to its specification MUST be declared in the EIP that proposes to standardize a new stealth address scheme. It is RECOMMENDED  that `schemeId`s are chosen to be monotonically incrementing integers for simplicity, but arbitrary or meaningful `schemeId`s  may be chosen. Furthermore, the schemeId MUST be added to [this overview](../assets/eip-5564/scheme_ids.md). These extensions MUST specify:
+A 256 bit integer (`schemeId`) is used to identify stealth address schemes. A mapping from the schemeId to its specification MUST be declared in the ERC that proposes to standardize a new stealth address scheme. It is RECOMMENDED  that `schemeId`s are chosen to be monotonically incrementing integers for simplicity, but arbitrary or meaningful `schemeId`s  may be chosen. Furthermore, the schemeId MUST be added to [this overview](../assets/eip-5564/scheme_ids.md). These extensions MUST specify:
 
 - The integer identifier for the scheme.
 
@@ -150,7 +152,7 @@ contract IERC5564Announcer {
 
 ### Stealth meta-address format
 
-The new address format for the stealth meta-address is based on [ERC-3770](./eip-3770.md) and extends it by adding a `st:` (*stealth*) prefix.
+The new address format for the stealth meta-address extends the chain specific address format by adding a `st:` (*stealth*) prefix.
 Thus, a stealth meta-address on Ethereum has the following format:
 
 ```
@@ -165,7 +167,7 @@ Stealth meta-addresses may be managed by the user and/or registered within a pub
 
 ### Initial Implementation of SECP256k1 with View Tags
 
-This EIP provides a foundation that is not tied to any specific cryptographic system through the `IERC5564Announcer` contract. In addition, it introduces the first implementation of a [stealth address scheme](../assets/eip-5564/scheme_ids.md) that utilizes the SECP256k1 elliptic curve and view tags. The SECP256k1 elliptic curve is defined with the equation $y^2 = x^3 + 7 \pmod{p}$, where $p = 2^{256} - 2^{32} - 977$.
+This ERC provides a foundation that is not tied to any specific cryptographic system through the `IERC5564Announcer` contract. In addition, it introduces the first implementation of a [stealth address scheme](../assets/eip-5564/scheme_ids.md) that utilizes the SECP256k1 elliptic curve and view tags. The SECP256k1 elliptic curve is defined with the equation $y^2 = x^3 + 7 \pmod{p}$, where $p = 2^{256} - 2^{32} - 977$.
 
 The following reference is divided into three sections:
 
@@ -244,7 +246,7 @@ The view tags approach is introduced to reduce the parsing time by around 6x. Us
 
 ## Rationale
 
-This EIP emerged from the need for privacy-preserving ways to transfer ownership without disclosing any information about the recipients' identities. Token ownership can expose sensitive personal information. While individuals may wish to donate to a specific organization or country, they might prefer not to disclose a link between themselves and the recipient simultaneously. Standardizing stealth address generation represents a significant step towards unlinkable interactions, since such privacy-enhancing solutions require standards to achieve widespread adoption. Consequently, it is crucial to focus on developing generalizable approaches for implementing related solutions.
+This ERC emerged from the need for privacy-preserving ways to transfer ownership without disclosing any information about the recipients' identities. Token ownership can expose sensitive personal information. While individuals may wish to donate to a specific organization or country, they might prefer not to disclose a link between themselves and the recipient simultaneously. Standardizing stealth address generation represents a significant step towards unlinkable interactions, since such privacy-enhancing solutions require standards to achieve widespread adoption. Consequently, it is crucial to focus on developing generalizable approaches for implementing related solutions.
 
 The stealth address specification standardizes a protocol for generating and locating stealth addresses, facilitating the transfer of assets without requiring prior interaction with the recipient. This enables recipients to verify the receipt of a transfer without the need to interact with the blockchain and query account balances. Importantly, stealth addresses enable token transfer recipients to verify receipt while maintaining their privacy, as only the recipient can recognize themselves as the recipient of the transfer.
 
@@ -254,7 +256,7 @@ The recipient's address and the `viewTag` MUST be included in the announcement e
 
 ## Backwards Compatibility
 
-This EIP is fully backward compatible.
+This ERC is fully backward compatible.
 
 ## Reference Implementation
 
@@ -280,4 +282,3 @@ Thus, the sender may attach a small amount of ETH to each stealth address transa
 ## Copyright
 
 Copyright and related rights waived via [CC0](../LICENSE.md).
-

ERCS/erc-6358.md

@@ -120,7 +120,7 @@ struct ERC6358TransactionData {
         - The related raw data for `signature` in `o-transaction` is RECOMMENDED to be the concatenation of the raw bytes of `op`, `exData`, and `tokenId`. 
 
 - The member `signature` MUST be defined as `bytes`. It is RECOMMENDED to be created as follows.  
-    - Concat the sectors in `ERC6358TransactionData` as below (take Fungible token for example) and calculate the hash with `keccak256`: 
+    - It is OPTIONAL that concating the sectors in `ERC6358TransactionData` as below (take Fungible token for example) and calculate the hash with `keccak256`: 
 
         ```solidity
         /**
@@ -144,6 +144,7 @@ struct ERC6358TransactionData {
         }
         ```
 
+    - It is OPTIONAL that encapsulating the sectors in `ERC6358TransactionData` according to `EIP-712`.
     - Sign the hash value.
 
 ### Smart Contract Interface
@@ -257,7 +258,7 @@ struct ERC6358TransactionData {
 
 ### Architecture
 
-As shown in [Figure.1](#architecture), smart contracts deployed on multi-chains execute `o-transactions` of ERC-6358 tokens synchronously through the trustless off-chain synchronizers.   
+As shown in [Figure.1](#figure1-architecture), smart contracts deployed on multi-chains execute `o-transactions` of ERC-6358 tokens synchronously through the trustless off-chain synchronizers.   
 
 - The ERC-6358 smart contracts are referred to as **Abstract Nodes**. The states recorded by the Abstract Nodes that are deployed on different blockchains respectively could be considered as copies of the global state, and they are ultimately consistent.  
 - **Synchronizer** is an off-chain execution program responsible for carrying published  `o-transactions` from the ERC-6358 smart contracts on one blockchain to the others. The synchronizers work trustless as they just deliver `o-transactions` with others' signatures, and details could be found in the [workflow](#workflow).