Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
* EIP-2930: Updates transaction format to match EIP-2718
2718 has the first byte of every transaction be the transaction type, and the remaining bytes are interpreted however this EIP wants. This is the minimal change required to get it in line with 2718 so I think we should merge this ASAP and then continue discussion on whether we think this is the optimal format or not.
* Update EIPS/eip-2930.md
Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
* Changes same thing in more places.
Co-authored-by: lightclient <14004106+lightclient@users.noreply.github.com>
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Rendered file: https://github.com/rekmarks/EIPs/blob/2016/EIPS/eip-3085.md
This PR adds EIP-3085, which introduces the wallet_addEthereumChain RPC method. It's basically EIP-2015, without requiring the network to be switched.
I think 2015 is a great idea, but wallets may desire an RPC method that only adds a chain, without requiring that the network is changed. For example, allowing dapps to request network changes is bound to cause UX issues, especially as we see dapps moving to different layer 2 chains.
Main points:
- Reprice sha256 and Ripemd160 precompiles after #2046 changes and to better reflect current performance and internal structures of the computations performed
- Reprice Keccak256 native function and reflect internal structures of the computations performed
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
This has been discussed a few times. The main problem is that editors have a challenge finding EIP authors and getting their response, unless there is a clear GitHub username. This is blocking a lot of outstanding change requests.
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
EIPs have a new set of statuses, Accepted is no longer a status but we accidentally mass updated Accepted => Final, when it should have been Accepted => Review.
I'm updating EIP statuses according to #2996. The mappings are as follows:
```
Draft => Draft
Last Call => Last Call
Accepted => Final
Final => Final
Superseded => Final
Abandoned => Withdrawn
Rejected => Withdrawn
Active => Living
```
Providing wallet with a `blockExporerUrl` could be valuable given that applications can permissionessly interface with each other given that standards are followed and become interoperable.
Hence I've explored existing block explorers and identified existing patterns where these endpoints are in consensus and could be specified under a standard which this EIP describes
### L1 Blockchain Explorers
#### Blocks
Blockscout (chainId=100) -> https://blockscout.com/poa/xdai/blocks/<BLOCK_HASH_OR_HEIGHT>
Etherscan (chainId=1) -> https://etherscan.io/block/<BLOCK_HASH_OR_HEIGHT>
Etherchain (chainId=1) -> https://etherchain.org/block/<BLOCK_HASH_OR_HEIGHT>
Ethplorer (chainId=1) -> unsupported
Etherscan and Etherchain are in consensus for blocks endpoint but Blockscout uses `/blocks` endpoint instead and Ethplorer doesn't have a page for blocks so returns 404 not found.
#### Transactions
Blockscout (chainId=100) -> https://blockscout.com/poa/xdai/tx/<TX_HASH>
Etherscan (chainId=1) -> https://etherscan.io/tx/<TX_HASH>
Etherchain (chainId=1) -> https://etherchain.org/tx/<TX_HASH>
Ethplorer (chainId=1) -> https://ethplorer.io/tx/<TX_HASH>
All block explorers are in consensus for transactions endpoint.
#### Accounts
Blockscout (chainId=100) -> https://blockscout.com/poa/xdai/address/<ACCOUNT_ADDRESS>
Etherscan (chainId=1) -> https://etherscan.io/address/<ACCOUNT_ADDRESS>
Etherchain (chainId=1) -> https://etherchain.org/account/<ACCOUNT_ADDRESS>
Ethplorer (chainId=1) -> https://ethplorer.io/address/<ACCOUNT_ADDRESS>
All block explorers are in consensus for accounts endpoint except Etherchain which uses `/account` endpoint instead
#### ERC-20 Tokens
Blockscout (chainId=100) -> https://blockscout.com/poa/xdai/tokens/<TOKEN_ADDRESS>
Etherscan (chainId=1) -> https://etherscan.io/token/<TOKEN_ADDRESS>
Etherchain (chainId=1) -> https://etherchain.org/token/<TOKEN_ADDRESS>
Ethplorer (chainId=1) -> https://ethplorer.io/address/<TOKEN_ADDRESS>
Etherscan and Etherchain are in consensus but Blockscout uses `/tokens` endpoint instead and Ethplorer doesn't have a page for tokens so redirects to accounts page (`/address`).
### L2 Explorers
#### Blocks
Matic -> https://explorer.matic.network/blocks/<BLOCK_HEIGHT_OR_HASH>
zkScan -> https://zkscan.io/blocks/<BLOCK_NUMBER>
Fuel -> https://rinkeby.fuel.sh/block/<BLOCK_NUMBER>
#### Transactions
Matic -> https://explorer.matic.network/tx/<TX_HASH>
zkScan -> https://zkscan.io/transactions/<TX_HASH>
Fuel -> https://rinkeby.fuel.sh/tx/<TX_HASH>
#### Accounts
Matic -> https://explorer.matic.network/address/<ACCOUNT_ADDRESS>
zkScan -> https://zkscan.io/accounts/<ACCOUNT_ADDRESS>
Fuel -> https://rinkeby.fuel.sh/address/<ACCOUNT_ADDRESS>
#### ERC-20 Tokens
Matic -> https://explorer.matic.network/tokens/<TOKEN_ADDRESS>
zkScan -> unsupported (`/tokens` displays a list of tokens pointing to L1 explorer)
Fuel -> unsupported
## EIP-3091
### Blocks
<BLOCK_EXPORER_URL>/block/<BLOCK_HASH_OR_HEIGHT>
### Transactions
<BLOCK_EXPORER_URL>/tx/<TX_HASH>
### Accounts
<BLOCK_EXPORER_URL>/address/<ACCOUNT_ADDRESS>
### ERC-20 Tokens
<BLOCK_EXPORER_URL>/token/<TOKEN_ADDRESS>
The proposed Status to changes to EIP-1 inline with clarifiying the EIP repo as soley a standardization body.
Decisions made during the 17th EIPIP meeting. ethereum-cat-herders/EIPIP#33
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
This adds my draft EIP for multiple contenthash records for ENS. Contract implementation is available in ensdomains/resolvers#30, and discussion should be in #2393.
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
A JSON interchange format for Serenity (eth2) that contains the necessary slashing protection information required to safely migrate keys between clients.
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
Hi, I'm a bot! This change was automatically merged because:
- It only modifies existing Draft or Last Call EIP(s)
- The PR was approved or written by at least one author of each modified EIP
- The build is passing
