ethereum · jschnelder · Jan 4, 2026
@@ -1,24 +1,24 @@
 ---
 eip: 3014
 title: eth_symbol JSON-RPC method
 author: Peter Grassberger (@PeterTheOne)
 discussions-to: https://github.com/ethereum/EIPs/issues/3012
 status: Stagnant
 type: Standards Track
 category: Interface
 created: 2020-09-30
 ---

 ## Simple Summary
 Add `eth_symbol` method to the JSON-RPC that returns the symbol of the native coin of the network.

 ## Abstract
 The new method `eth_symbol` (`eth_`-namespaced) has no parameters and returns a string of the native coin of the network. For the Ethereum mainnet this will be `ETH`, other networks will have other symbols.

 ## Motivation
 Wallets that deal with multiple networks need some basic information for every blockchain that they connect to. One of those things is the symbol of the native coin of the network. Instead of requiring the user to research and manually add the symbol it could be provided to the wallet via this proposed JSON-RPC endpoint and used automatically. There are lists of networks with symbols like https://github.com/ethereum-lists/chains where a user can manually look up the correct values. But this information could easily come from the network itself.

 ## Specification
 Method: `eth_symbol`.

 Params: none.
@@ -38,11 +38,11 @@
 }
 ```
 
 ## Rationale
-This endpoint is similar to [EIP-695](./eip-695.md) but it provides the symbol instead of `chainId`. It provides functionality that is already there for [ERC-20](./eip-20.md) tokens, but not yet for the native coin of the network. Alternative naming of `eth_nativeCurrencySymbol` was considered, but the context and the fact that it just returns one value makes it clear that that it returns the symbol for the native coin of the network.
+This endpoint is similar to [EIP-695](./eip-695.md) but it provides the symbol instead of `chainId`. It provides functionality that is already there for [ERC-20](./eip-20.md) tokens, but not yet for the native coin of the network. Alternative naming of `eth_nativeCurrencySymbol` was considered, but the context and the fact that it just returns one value makes it clear that it returns the symbol for the native coin of the network.
 
 ## Security Considerations
 It is a read only endpoint. The information is only as trusted as the JSON-RPC node itself, it could supply wrong information and thereby trick the user in believing he/she is dealing with another native coin.

 ## Copyright
 Copyright and related rights waived via [CC0](../LICENSE.md).
@@ -9,7 +9,7 @@
 created: 2021-02-26
 ---

 ## Simple Summary

 Remove gas refunds for SSTORE and SELFDESTRUCT.

@@ -20,7 +20,7 @@
 Gas refunds additionally have multiple harmful consequences:

 * Refunds give rise to [GasToken](https://gastoken.io/). GasToken has benefits in moving gas space from low-fee periods to high-fee periods, but it also has downsides to the network, particularly in exacerbating state size (as state slots are effectively used as a "battery" to save up gas) and inefficiently clogging blockchain gas usage
 * Refunds increase block size variance. The theoretical maximum amount of actual gas consumed in a block is nearly twice the on-paper gas limit (as refunds add gas space for subsequent transactions in a block, though refunds are capped at 50% of a transaction's gas used). This is [not fatal](https://notes.ethereum.org/@vbuterin/eip_1559_spikes), but is still undesirable, especially given that refunds can be used to maintain 2x usage spikes for far longer than EIP 1559 can.

 ## Specification

@@ -36,16 +36,16 @@

 The description above is sufficient to describe the change, but for the sake of clarity we enumerate all places where gas refunds are currently used and which should/could be removed within a node implementation. 

 1. Remove all use of the "refund counter" in SSTORE gas accounting, as defined in [EIP 2200](https://eips.ethereum.org/EIPS/eip-2200). Particularly:

    * If a storage slot is changed and the _current value_ equals the _original value_, but does not equal the _new value_, `SSTORE_RESET_GAS` is deducted (plus `COLD_SLOAD_COST` if [prescribed by EIP 2929 rules](https://eips.ethereum.org/EIPS/eip-2929#sstore-changes)), but no modifications to the refund counter are made.
    * If a storage slot is changed and the _current value_ equals neither the _new value_ nor the _original value_ (regardless of whether or not the latter two are equal), `SLOAD_GAS` is deducted (plus `COLD_SLOAD_COST` if [prescribed by EIP 2929 rules](https://eips.ethereum.org/EIPS/eip-2929#sstore-changes)), but no modifications to the refund counter are made.

 2. Remove the `SELFDESTRUCT` refund.
 
 ## Rationale
 
-A full removal of refunds is the simplest way to solve the issues with refunds; any gains from partial retention of the refund mechanism are not worth the complexity that that would leave remaining in the Ethereum protocol.
+A full removal of refunds is the simplest way to solve the issues with refunds; any gains from partial retention of the refund mechanism are not worth the complexity that would leave remaining in the Ethereum protocol.
 
 ## Backwards Compatibility
 
@@ -60,7 +60,7 @@
 ## Test case changes

 * The "original", "1st", "2nd", "3rd" columns refer to the value of storage slot 0 before the execution and after each SSTORE.
 * The "Berlin (cold)" column gives the post-Berlin (EIP 2929) gas cost assuming the storage slot had not yet been accessed.
 * The "Berlin (hot)" column gives the post-Berlin gas cost assuming the storage slot has already been accessed.
 * The "Berlin (hot) + norefund" column gives the post-Berlin gas cost assuming the storage slot has already been accessed, **and assuming this EIP has been implemented**.

@@ -91,5 +91,5 @@

 TBD

 ## Copyright
 Copyright and related rights waived via [CC0](../LICENSE.md).
@@ -62,7 +62,7 @@
 - `ANNOTATION_PREFIX`s are defined for Subclasses as octal-derived positive integers, limited to the set `2^0,2^1,2^2,2^3,2^4,2^5,2^6,2^7`.

 The `chainContext` value should be of the form `ANNOTATION_COMPOSITE_PREFIX || [{subclass value}...]`, where 
 - `...` means "zero or more of the things to the left," and 
 - `||` denotes the byte/byte-array concatenation operator.

 The `chainContext` value should be encoded as `ANNOTATION_COMPOSITE_PREFIX || rlp[{subclass value}...]`.
@@ -83,7 +83,7 @@
 4. `EXPIRY`

 As above, the `ANNOTATION_COMPOSITE_PREFIX` should be the sum of the designated subclass' `ANNOTATION_PREFIX`s.
 ### Subclasses

 - An `ANNOTATION_PREFIX` value is used to represent each of the available context subclasses.

@@ -261,7 +261,7 @@
 Using the whole hash would result in a "perfectly safe" implementation, and every additional byte reduces the chance of collision exponentially.
 
 The goal of the `ancestorId` is to disambiguate one chain segment from another, and in doing so, enable a transaction to define with adequate precision which chain it needs to be on.
-When a transaction's `ancestorId` references a block, we want to be pretty sure that that reference won't get confused with a different block than the one the author of the transaction had in mind.
+When a transaction's `ancestorId` references a block, we want to be pretty sure that the reference won't get confused with a different block than the one the author of the transaction had in mind.
 
 We assume the trait of collision resistance is uniformly applicable to all possible subsets of the block hash value, so our preference of using the _first_ 4 bytes is arbitrary and functionally equivalent to any other subset of equal length.
 

@@ -160,7 +160,7 @@ subject to the same workflow as other groups.
 ### Alternative: Pain unrelated to process divergences
 
 This is a catch-all for a number of proposals, from allowing discord links in
-discussion-to to allowing more freedom in external links.
+discussion-to, to allowing more freedom in external links.
 
 While the theory that this may reduce the total amount of pain felt by users and
 editors, bringing the pain level down to a more acceptable level, this does not