Merge branch 'master' into erc-7513

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-5564.md

@@ -85,7 +85,7 @@ function computeStealthKey(
 
 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 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/erc-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.
 
@@ -157,15 +157,15 @@ Thus, a stealth meta-address on Ethereum has the following format:
 st:eth:0x<spendingKey><viewingKey>
 ``` 
 
-Stealth meta-addresses may be managed by the user and/or registered within a publicly available `Registry` contract, as delineated in [ERC-6538](./erc-6538). This provides users with a centralized location for identifying stealth meta-addresses associated with other individuals while simultaneously enabling recipients to express their openness to engage via stealth addresses.
+Stealth meta-addresses may be managed by the user and/or registered within a publicly available `Registry` contract, as delineated in [ERC-6538](./eip-6538). This provides users with a centralized location for identifying stealth meta-addresses associated with other individuals while simultaneously enabling recipients to express their openness to engage via stealth addresses.
 
 *Notably, the address format is used only to differentiate stealth addresses from standard addresses, as the prefix is removed before performing any computations on the stealth meta-address.*
 
 ---
 
 ### Initial Implementation of SECP256k1 with View Tags
 
-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/erc-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:
 
@@ -268,7 +268,7 @@ There are potential denial of service (DoS) attack vectors that are not mitigate
 We consider the incentives to carry out such an attack to be low because **no monetary benefit can be obtained**
 However, to tackle potential spam, parsing providers may adopt their own anti-DoS attack methods. These may include ignoring the spamming users when serving announcements to users or, less harsh, de-prioritizing them when ordering the announcements. The indexed `caller` keyword may help parsing providers to effectively filter known spammers.
 
-Furthermore, parsing providers have a few options to counter spam, such as introducing staking mechanisms or requiring senders to pay a `toll` before including their `Announcement`. Moreover, a Staking mechanism may allow users to stake an unslashable amount of ETH (similarly to [ERC-4337](./erc-4337)), to help mitigate potential spam through *sybil attacks* and enable parsing providers filtering spam more effectively.
+Furthermore, parsing providers have a few options to counter spam, such as introducing staking mechanisms or requiring senders to pay a `toll` before including their `Announcement`. Moreover, a Staking mechanism may allow users to stake an unslashable amount of ETH (similarly to [ERC-4337](./eip-4337)), to help mitigate potential spam through *sybil attacks* and enable parsing providers filtering spam more effectively.
 Introducing a `toll`, paid by sending users, would simply put a cost on each stealth address transaction, making spamming economically unattractive.
 
 ### Recipients' transaction costs

ERCS/erc-6358.md

@@ -16,7 +16,7 @@ This ERC standardizes an interface for contract-layer consensus-agnostic verifia
 
 ### Figure.1 Architecture
 
-![img](../assets/eip-6358/img/o-dlt.png)    
+![img](../assets/erc-6358/img/o-dlt.png)    
 
 With this ERC, we can create a global token protocol, that leverages smart contracts or similar mechanisms on existing blockchains to record the token states synchronously. The synchronization could be made by trustless off-chain synchronizers.
 
@@ -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).

ERCS/erc-6982.md

@@ -4,7 +4,8 @@ title: Efficient Default Lockable Tokens
 description: A gas-efficient approach to lockable ERC-721 tokens
 author: Francesco Sullo (@sullof), Alexe Spataru (@urataps)
 discussions-to: https://ethereum-magicians.org/t/erc721-default-lockable-proposal/13366
-status: Review
+status: Last Call
+last-call-deadline: 2023-11-30
 type: Standards Track
 category: ERC
 created: 2023-05-02
@@ -30,10 +31,10 @@ The interface is defined as follows:
 interface IERC6982 {
   // This event MUST be emitted upon deployment of the contract, establishing 
   // the default lock status for any tokens that will be minted in the future.
-  // If the default lock status changes for any reason, this event 
-  // MUST be re-emitted to update the default status for all tokens.
-  // Note that emitting a new DefaultLocked event does not affect the lock 
-  // status of any tokens for which a Locked event has previously been emitted.
+  // If the default lock status changes for any reason, this event  MUST be 
+  // re-emitted to update the default status for all tokens, including the ones 
+  // already minted.  However, emitting a new DefaultLocked event does not affect 
+  // the lock status of any tokens for which a Locked event has been emitted.
   event DefaultLocked(bool locked);
 
   // This event MUST be emitted whenever the lock status of a specific token 
@@ -69,7 +70,7 @@ The `locked` function gives the current lock status of a particular token, furth
 
 Bear in mind that a token being designated as "locked" doesn't necessarily imply that it is entirely non-transferable. There might be certain conditions under which a token can still be transferred despite its locked status. Primarily, the locked status relates to a token's transferability on marketplaces and external exchanges.
 
-To illustrate, let's consider the Cruna protocol. In this system, an NFT owner has the ability to activate what is termed an 'initiator'. This is essentially a secondary wallet with the unique privilege of initiating key transactions. Upon setting an initiator, the token's status is rendered 'locked'. However, this does not impede the token's transferability if the initiation for the transfer comes from the designated initiator. 
+To illustrate, let's consider the Cruna protocol. In this system, an NFT owner has the ability to activate what is termed an 'protector'. This is essentially a secondary wallet with the unique privilege of initiating key transactions. Upon setting an initiator, the token's status is rendered 'locked'. However, this does not impede the token's transferability if the initiation for the transfer comes from the designated protector. 
 
 ## Backwards Compatibility