Merge branch 'master' into master

.github/workflows/jekyll-label-bot.yml

@@ -14,7 +14,7 @@ jobs:
     runs-on: ubuntu-latest
 
     steps:
-      - uses: Pandapip1/jekyll-label-action@d0fd82c3cd118140a50843906845fca8e59a8b9e
+      - uses: Pandapip1/jekyll-label-action@4b7cce7588a8686f5146a8e12aab7269042057ce
         with:
           token: ${{ secrets.GITHUB_TOKEN }}
           config-path: config/.jekyll-labels.yml

ERCS/eip-1.md

@@ -91,7 +91,7 @@ A PR moving an EIP from Last Call to Final SHOULD contain no changes other than
 
 >*EIP Authors are notified of any algorithmic change to the status of their EIP*
 
-**Withdrawn** - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.
+**Withdrawn** - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at a later date it is considered a new proposal.
 
 **Living** - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.
 

ERCS/erc-1046.md

@@ -58,13 +58,13 @@ interface InteroperabilityMetadata {
 
     /**
      * This MUST be true if this is ERC-721 Token Metadata, otherwise, this MUST be omitted.
-     * Setting this to true indicates to wallets that the address should be treated as a ERC-721 token.
+     * Setting this to true indicates to wallets that the address should be treated as an ERC-721 token.
      **/
     erc721?: boolean | undefined;
 
     /**
      * This MUST be true if this is ERC-1155 Token Metadata, otherwise, this MUST be omitted.
-     * Setting this to true indicates to wallets that the address should be treated as a ERC-1155 token.
+     * Setting this to true indicates to wallets that the address should be treated as an ERC-1155 token.
      **/
     erc1155?: boolean | undefined;
 }

ERCS/erc-1056.md

@@ -222,7 +222,7 @@ Contract Events are a useful feature for storing data from smart contracts exclu
 
 2. Lookup all events for given identity address using web3, but only for the `previousChange` block
 
-3. Do something with event
+3. Do something with the event
 
 4. Find `previousChange` from the event  and repeat
 

ERCS/erc-1062.md

@@ -18,9 +18,9 @@ The following standard details the implementation of how to combine the IPFS cry
 We think that this implementation is not only aim to let more developers and communities to provide more use cases, but also leverage the human-readable features to gain more user adoption accessing decentralized resources. We considered the IPFS ENS resolver mapping standard a cornerstone for building future Web3.0 service.
 
 ## Motivation
-To build fully decentralized web service, it’s necessary to have a decentralized file storage system. Here comes the IPFS, for three following advantages :
+To build a fully decentralized web service, it’s necessary to have a decentralized file storage system. Here comes the IPFS, for three following advantages :
 - Address large amounts of data, and has unique cryptographic hash for every record.
-- Since IPFS is also based on peer to peer network, it can be really helpful to deliver large amounts of data to users, with safer way and lower the millions of cost for the bandwidth.
+- Since IPFS is also based on peer to peer network, it can be really helpful to deliver large amounts of data to users, in a safer way and lower the millions of cost for the bandwidth.
 - IPFS stores files in high efficient way via tracking version history for every file, and removing the duplications across the network.
 
 Those features makes perfect match for integrating into ENS, and these make users can easily access content through ENS, and show up in the normal browser.

ERCS/erc-1066.md

@@ -480,7 +480,7 @@ AwesomeCoin                 DEX                     TraderBot
 
 Status codes are encoded as a `byte`. Hex values break nicely into high and low nibbles: `category` and `reason`. For instance, `0x01` stands for general success (ie: `true`) and `0x00` for general failure (ie: `false`).
 
-As a general approach, all even numbers are blocking conditions (where the receiver does not have control), and odd numbers are nonblocking (the receiver is free to contrinue as they wish). This aligns both a simple bit check with the common encoding of Booleans.
+As a general approach, all even numbers are blocking conditions (where the receiver does not have control), and odd numbers are nonblocking (the receiver is free to continue as they wish). This aligns both a simple bit check with the common encoding of Booleans.
 
 `bytes1` is very lightweight, portable, easily interoperable with `uint8`, cast from `enum`s, and so on.
 

ERCS/erc-1077.md

@@ -19,7 +19,7 @@ Allows users to offer [EIP-20] token for paying the gas used in a call.
 
 ## Abstract
 
-A main barrier for adoption of DApps is the requirement of multiple tokens for executing in chain actions. Allowing users to sign messages to show intent of execution, but allowing a third party relayer to execute them can circumvent this problem, while ETH will always be required for ethereum transactions, it's possible for smart contract to take [EIP-191] signatures and forward a payment incentive to an untrusted party with ETH for executing the transaction. 
+A main barrier for the adoption of DApps is the requirement of multiple tokens for executing in chain actions. Allowing users to sign messages to show intent of execution, but allowing a third party relayer to execute them can circumvent this problem, while ETH will always be required for ethereum transactions, it's possible for smart contract to take [EIP-191] signatures and forward a payment incentive to an untrusted party with ETH for executing the transaction. 
 
 ## Motivation
 
@@ -83,7 +83,7 @@ In order to be compliant, the transaction **MUST** request to sign a "messageHas
 
 The fields **MUST** be constructed as this method:
 
-The first and second fields are to make it [EIP-191] compliant. Starting a transaction with `byte(0x19)` ensure the signed data from being a [valid ethereum transaction](https://github.com/ethereum/wiki/wiki/RLP). The second argument is a version control byte. The third being the validator address (the account contract address) according to version 0 of [EIP-191]. The remaining arguments being the application specific data for the gas relay: chainID as per [EIP-1344], execution nonce, execution data, agreed gas Price, gas limit of gas relayed call, gas token to pay back and gas relayer authorized to receive reward.
+The first and second fields are to make it [EIP-191] compliant. Starting a transaction with `byte(0x19)` ensure the signed data from being a [valid ethereum transaction](https://github.com/ethereum/wiki/wiki/RLP). The second argument is a version control byte. The third being the validator address (the account contract address) according to version 0 of [EIP-191]. The remaining arguments being the application specific data for the gas relay: chainID as per [EIP-1344], execution nonce, execution data, agreed gas Price, gas limit of gas relayed call, gas token to pay back and gas relayer authorized to receive the reward.
 
 The [EIP-191] message must be constructed as following:
 ```solidity

ERCS/erc-1078.md

@@ -12,12 +12,12 @@ requires: 191, 681, 725, 1077
 
 ## Abstract
 
-This presents a method to replace the usual signup/login design pattern with a minimal ethereum native scheme, that doesn’t require passwords, backing up private keys nor typing seed phrases. From the user point of view it will be very similar to patterns they’re already used to with second factor authentication (without relying in a central server), but for dapp developers it requires a new way to think about ethereum transactions.
+This presents a method to replace the usual signup/login design pattern with a minimal ethereum native scheme, that doesn’t require passwords, backing up private keys nor typing seed phrases. From the user's point of view it will be very similar to patterns they’re already used to with second factor authentication (without relying in a central server), but for dapp developers it requires a new way to think about ethereum transactions.
 
 
 ## Simple Summary
 
-The unique identifier of the user is a contract which implements both Identity and the Executable Signed Messages ERCs. The user should not need provide this address directly, only a ens name pointing to it. These types of contracts are indirectly controlled by private keys that can sign messages indicating intents, which are then deployed to the contract by a third party (or a decentralized network of deployers).  
+The unique identifier of the user is a contract that implements both Identity and the Executable Signed Messages ERCs. The user should not need provide this address directly, only a ens name pointing to it. These types of contracts are indirectly controlled by private keys that can sign messages indicating intents, which are then deployed to the contract by a third party (or a decentralized network of deployers).  
 
 In this context, therefore, a device "logging into" an app using an identity, means that the device will generate a private key locally and then request an authorization to add that key as one of the signers of that identity, with a given set of permissions. Since that private key is only used for signing messages, it is not required to hold ether, tokens or assets, and if lost, it can be simply be replaced by a new one – the user's funds are kept on the identity contract.
 
@@ -43,7 +43,7 @@ If the user doesn’t have an identity, the app should provide the option to cre
 
 All those steps can be designed to be set up in a single ethereum transaction. Since this step is not free, the app reserves the right to charge for registering users, or require the user to be verified in a sybil resistant manner of the app’s choosing (captcha, device ID registration, proof of work, etc)
 
-The user shouldn’t be forced to wait for transaction confirmation times. Instead, have an indicator somewhere on the app the shows the progress and then allow the user to interact with your app normally. It’s unlikely that they’ll need the identity in the first few minutes and if something goes wrong (username gets registered at the same time), you can then ask the user for an action.
+The user shouldn’t be forced to wait for transaction confirmation times. Instead, have an indicator somewhere on the app that shows the progress and then allow the user to interact with your app normally. It’s unlikely that they’ll need the identity in the first few minutes and if something goes wrong (username gets registered at the same time), you can then ask the user for an action.
 
 **Implementation note:** in order to save gas, some of these steps can be done in advance. The app can automatically deploy a small number of contracts when the gas price is low, and set up all their main variables to be 0xFFFFFF...FFFFF. These should be considered ‘vacant’ and when the user registers one, they will get a gas discount for freeing up space on the chain. This has the added benefit of allowing the user a choice in contract address/icon.
 

ERCS/erc-1129.md

@@ -49,9 +49,9 @@ struct Announcement{
 
 
 ### Methods
-#### the number of ammouncements
+#### the number of announcements
 
-Returns the number of announcement currently active.
+Returns the number of announcements currently active.
 
 OPTIONAL - this method can be used to provide quicker information for the UI, but could also be retrieved from `numberOfMessages` variable.
 

ERCS/erc-3770.md

@@ -4,7 +4,7 @@ title: Chain-specific addresses
 description: Prepending chain-specific addresses with a human-readable chain identifier
 author: Lukas Schor (@lukasschor), Richard Meissner (@rmeissner), Pedro Gomes (@pedrouid), ligi <[email protected]>
 discussions-to: https://ethereum-magicians.org/t/chain-specific-addresses/6449
-status: Stagnant
+status: Draft
 type: Standards Track
 category: ERC
 created: 2021-08-26
@@ -58,7 +58,7 @@ Ethereum addresses without the chain specifier will continue to require addition
 
 ## Security Considerations
 
-The Ethereum List curators must consider how similar looking chain short names can be used to confuse users.
+Similar looking chain short names can be used to confuse users.
 
 ## Copyright
 

ERCS/erc-5173.md

@@ -13,21 +13,21 @@ requires: 165, 721
 
 ## Abstract
 
-This EIP introduces the NFT Future Rewards (nFR) extension for [EIP-721](./eip-721.md) tokens (NFTs). nFR allows owners to benefit from future price appreciation even after selling their tokens. This establishes a Provenance Value Amplification (PVA) framework where creators, buyers, and sellers collaborate to collectively increase value. This innovative approach disrupts the current zero-sum trading paradigm by creating a fairer and more rewarding system for all participants.
+This ERC introduces the NFT Future Rewards (nFR) extension for [ERC-721](./eip-721.md) tokens (NFTs). nFR allows owners to benefit from future price appreciation even after selling their tokens, without the need for market prediction. This establishes a Provenance Value Amplification (PVA) framework where creators, buyers, and sellers collaborate to collectively increase value. This innovative approach disrupts the current zero-sum trading paradigm by creating a fairer and more rewarding system for all participants.
 
-[ERC-5173](./eip-5173.md) fosters a sustainable and collaborative trading environment by aligning the interests of service providers and users. Compliant token owners enjoy price increases during holding and continue receiving nFRs after selling. By eliminating competition and promoting shared prosperity, nFR fosters strong bonds within the NFT ecosystem. The framework ensures equitable profit distribution across all historical owners, including the original minter.
+[ERC-5173](./eip-5173.md) fosters a sustainable and collaborative trading environment by aligning the interests of service providers and users. Compliant token owners enjoy price increases during holding and continue receiving nFRs after selling. By eliminating competition and promoting shared prosperity, nFR fosters strong bonds within the NFT and crypto token ecosystems. The framework ensures equitable profit distribution across all historical owners, including the original minter.
 
 ## Motivation
 
 The current trading landscape is often marred by unfair practices like spoofing, insider trading, and wash trading. These activities disadvantage average traders caught in cycles of fear and greed. However, the rise of NFTs and their inherent transaction tracking capability presents an opportunity to disrupt this unequal value distribution.
 
-ERC-5173 introduces a standardized profit-sharing model across the entire ownership history of an NFT, benefiting all market participants. It creates a Flow of provenance where buyers and owners are rewarded for their contributions to price discovery. This model fosters aligned interests and establishes a mutually beneficial economic structure for both buyers and sellers.
+ERC-5173 introduces a standardized profit-sharing model across the entire ownership history of an NFT, benefiting all market participants. It creates a "Flow of Provenance" where buyers and owners are rewarded for their contributions to price discovery. This model fosters aligned interests and establishes a mutually beneficial economic structure for both buyers and sellers.
 
-NFTs can accurately reflect the contributions of their owners to their value. By recording every price change of each ERC-5173 token, we can establish a Future Rewards program that fairly compensates owners. This program aims to level the playing field and provide average traders with a better chance at success.
+NFTs can accurately reflect the contributions of their owners to their value. By recording every price change of each ERC-5173 token, we can establish a Future Rewards program that fairly compensates owners. This program aims to level the playing field and provide average traders with a better chance at success, without the need for complex market predictions.
 
-In addition to promoting this novel gift economic model, the nFR framework discourages illicit activities that circumvent artist and marketplace rules. This fosters a transparent and trustworthy trading ecosystem.
+In addition to promoting this novel "gift economy" model, the nFR framework discourages illicit activities that circumvent artist and marketplace rules. This fosters a transparent and trustworthy trading ecosystem.
 
-Applied to the exchange of wrapped [EIP-20](./eip-20.md) tokens, this value-amplification construct has the potential to transform the asset transaction sector by integrating identities within the time and sales (T&S) data. This inclusive attribute affords a holistic perspective of each trade, infusing an additional layer of depth into the trading experience.
+Applied to the exchange of wrapped [ERC-20](./eip-20.md) tokens, this value-amplification construct has the potential to transform the asset transaction sector by integrating identities within the time and sales (T&S) data. This inclusive attribute affords a holistic perspective of each trade, infusing an additional layer of depth into the trading experience.
 
 ## Specification
 

ERCS/erc-5625.md

@@ -4,7 +4,7 @@ title: NFT Metadata JSON Schema dStorage Extension
 description: Add a dStorage property to non-fungible tokens (NFTs) metadata JSON schema to provide decentralized storage information of NFT assets
 author: Gavin Fu (@gavfu)
 discussions-to: https://ethereum-magicians.org/t/eip-5625-nft-metadata-json-schema-dstorage-extension/10754
-status: Stagnant
+status: Review
 type: Standards Track
 category: ERC
 created: 2022-09-08

ERCS/erc-5630.md

@@ -4,7 +4,7 @@ title: New approach for encryption / decryption
 description: defines a specification for encryption and decryption using Ethereum wallets.
 author: Firn Protocol (@firnprotocol), Fried L. Trout, Weiji Guo (@weijiguo)
 discussions-to: https://ethereum-magicians.org/t/eip-5630-encryption-and-decryption/10761
-status: Stagnant
+status: Draft
 type: Standards Track
 category: ERC
 created: 2022-09-07