Ethereum Improvement Proposals - Withdrawn

Ed25519 transaction support

2025-06-25T00:00:00+00:00

Abstract</h2>
This EIP adds a new EIP-7932</a> algorithm of type `0x0</code> for supporting Ed25519 signatures.</p>`

Motivation</h2>

Ed25519 is one of the most widely used forms of Elliptic Curve Cryptography and is one of the defaults for SSH keys,
this makes it a good contender to be able to sign transactions with. It also provides an algorithm to write test
cases against during the implementation phase of EIP-7932</a>.</p>
Specification</h2>
This EIP defines a new EIP-7932</a> algorithmic type with the following parameters:</p>
Constant</th> Value</th></tr></thead>

ALG_TYPE</code></td> Bytes1(0x0)</code></td></tr>
GAS_PENALTY</code></td> 1000</code></td></tr>
MAX_SIZE</code></td> 96</code></td></tr>
</tbody></table>
def</span> verify</span>(</span>signature_info</span>:</span> bytes</span>,</span> payload_hash</span>:</span> Hash32</span>)</span> -></span> ExecutionAddress</span>:</span></span>
  assert</span>(</span>len</span>(</span>signature_info</span>)</span> ==</span> 96</span>)</span></span>
</span>
  signature</span> =</span> signature_info</span>[</span>:</span>64</span>]</span></span>
  public_key</span> =</span> signature_info</span>[</span>64</span>:</span>]</span></span>
  </span></span>
  #</span> This is the `Verify` function described in [RFC 8032 Section 5.1.7](https://datatracker.ietf.org/doc/html/rfc8032#section-5.1.7),</span></span>
  #</span> This MUST be processed as raw `Ed25519` and not `Ed25519ctx` or `Ed25519ph`</span></span>
  assert</span>(</span>ed25519_verify</span>(</span>signature</span>,</span> public_key</span>,</span> payload_hash</span>)</span>)</span></span>
</span>
  return</span> keccak256</span>(</span>public_key</span>)</span>[</span>-</span>20</span>:</span>]</span></span></code></pre>Rationale</h2>
Additional 1000 gas penalty</h3>
The gas penalty discourages people from attempting to migrate off current secp256k1 accounts, and also covers the additional overhead (in regards to hashing) that the ed25519 curve applies.</p>
Why Ed25519?</h3>
Ed25519 has significant tooling backing it, this makes it a good candidate for using as a "dummy" algorithm.
This allows it to be an algorithm for client teams to easily test EIP-7932</a>.</p>
It may also be useful for signing in Hardware security modules in server environments designed for serving
as ERC-4337</a> bundlers. It may also improve interoperability with other components such as TPM chips.</p>
Appending the public key to the signature</h3>
Currently, without changing the algorithm itself, it is impossible to efficiently recover the public key
from a signature and message.</p>
Backwards Compatibility</h2>
No backward compatibility issues found.</p>
Security Considerations</h2>
Needs discussion.</p>

Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Dynamic target blob count
2024-10-15T00:00:00+00:00
Abstract</h2>
This EIP proposes to make the target blob count adjust dynamically up to a safe maximum target. This adjustment will target a constant price in ETH for blobs, aiming for consistent costs of L2 transactions.</p>
Motivation</h2>
Ethereum currently uses a target of 50% capacity for blob count, with EIP-1559</a> smoothing out short-term spikes and pushing average throughput towards the target. A dynamic target is orthogonal to EIP-1559, tweaking the target itself over a longer timescale to aim for some desired blob cost.</p>
With static targeting the target may be higher than the actual demand, causing the protocol to undercharge for blobspace. This decreases the amount of fees burned, negatively affecting the price of ETH and total network security.</p>
As an example, consider what would happen if there was a large increase in max blob count due to DAS implementation but the target remained at 50%. It is unlikely that demand would immediately jump to anywhere near the target, and so for months or years the protocol would effectively charge nothing for L2 transactions. With a dynamic target, the target blob count would drop until the cost of blobspace for an L2 transaction approximated some affordable constant value. In this way, some fees are still burned by the protocol, but new L2s are not discouraged from using Ethereum blobspace, knowing that the target will increase in response to an increase in demand and blob fees will remain reasonably consistent.</p>
While the max blob count and max target are hard constraints based on resource utilisation limits, setting the target itself is far more subjective. A dynamic target can optimise for constant and affordable L2 transaction costs without requiring regular intervention by core developers to make tweaks based on changes in demand.</p>
Specification</h2>
Parameters</h3>
Parameter</th> Value</th></tr></thead>

FORK_TIMESTAMP</code></td> TBD</td></tr>
TARGET_BLOB_COUNT_CHANGE_RATE</code></td> 1</code></td></tr>
MIN_TARGET_BLOB_COUNT</code></td> 1</code></td></tr>
MAX_TARGET_BLOB_COUNT</code></td> 3</code></td></tr>
BLOB_COST_CHANGE_MARGIN</code></td> 2^48</code></td></tr>
TARGET_BLOB_COST</code></td> 2^49</code></td></tr>
</tbody></table>
Dynamic targeting</h3>
The target blob count changes each epoch based on the mean blob cost over the previous epoch. If the average cost exceeds the desired amount beyond some margin then the target is increased; likewise if it is below the desired amount by some margin the target will decrease. The target can increase up to MAX_TARGET_BLOB_COUNT</code>, which is deemed to be a safe average throughput for the network, and down to a minimum of MIN_TARGET_BLOB_COUNT</code>.</p>
Calculating targets:</p>
blob_cost_diff</span> =</span> mean_blob_cost</span> -</span> TARGET_BLOB_COST</span></span>
target_change_direction</span> =</span> -</span>1</span> if</span> blob_cost_diff</span> <</span> -</span>BLOB_COST_CHANGE_MARGIN</span> else</span> (</span>1</span> if</span> blob_cost_diff</span> ></span> BLOB_COST_CHANGE_MARGIN</span> else</span> 0</span>)</span></span>
next_epoch_blob_count</span> =</span> max</span>(</span>min</span>(</span>MAX_TARGET_BLOB_COUNT</span>,</span> previous_epoch_blob_count</span> +</span> (</span>target_change_direction</span> *</span> TARGET_BLOB_COUNT_CHANGE_RATE</span>)</span>)</span>,</span> MIN_TARGET_BLOB_COUNT</span>)</span></span></code></pre>Engine API change</h3>
The Engine API is extended to provide the mean_blob_cost</code> for the current epoch when the CL requests it from the EL. The CL requests this at the end of an epoch to set the target for the next epoch (depends on EIP-7742</a>).</p>
Rationale</h2>
Constant blob cost target</h3>
A constant blob cost target can keep L2 transaction costs affordable for end users. Volatility in the price of ETH would affect affordability, but is unlikely to be significant compared to normal fluctuations in blob gas costs due to spikes in activity. In future the costs could be adjusted in the case of changes in the order of magnitude of ETH price.</p>
An alternative approach would be to track a target blob cost in fiat. However, choosing a specific fiat currency is not credibly neutral, and introducing exchange rate oracles into the protocol could be an attack vector.</p>
Yet another alternative is to have validators vote on the target blob cost, but they may have conflicts of interest (for example if they operate a rollup) so again this is not credibly neutral.</p>
Target block gas</h3>
The same logic could be applied to the target block gas, but generally blockspace is in high demand so arguably gas costs are never too low. The target should be set to the maximum average throughput that the network can safely handle, a dynamic target is not necessary.</p>
Parameter choices</h3>
TARGET_BLOB_COST</code> is chosen so that the system targets affordable L2 transactions. Assuming that the theoretical compressed size of a simple transfer is 23 bytes, this gives a blobspace cost for L2 transactions of:</p>
(23 / 125000) * TARGET_BLOB_COST ≈ 104 gWei</span></span></code></pre>
At today’s prices, $1 would cover blobspace for around 3700 simple transfers on L2. The blob cost target should be chosen with extensive community involvement. Note that this is the cost of blobspace for an L2 transaction; the total cost will be more due to rollup execution costs.</p>
TARGET_BLOB_COUNT_CHANGE_RATE</code> is chosen as a compromise between the system being reactive to changes in demand, and not having large jumps in average throughput. BLOB_COST_CHANGE_MARGIN</code> is set such that target blob count will stay static when blob costs are within a range ±50% of TARGET_BLOB_COST</code>.</p>
MAX_TARGET_BLOB_COUNT</code> is set to 3</code> to match the current static target. This value should be increased in future when it is deemed to be safe to increase average blob throughput.</p>
Backwards Compatibility</h2>
N/A</p>
Test Cases</h2>
N/A</p>
Reference Implementation</h2>
N/A</p>
Security Considerations</h2>

Needs discussion.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Wallet-Linked Services for Smart Accounts
2024-04-15T00:00:00+00:00
Abstract</h2>
This proposal defines a registry for generic services linked to smart accounts, with a special focus on ERC-4337</a> wallets, where services are  contracts extending a wallet's functionality, owned by the wallet itself. It leverages ERC-1167</a> minimal proxies and deterministic addressing to enable permissionless innovation while maintaining backward compatibility with existing ERC-4337</a> wallets. To reach its goal, it takes the concept introduced with ERC-6551</a> and ERC-7656</a> standards that work for NFTs, and applies it to wallets.</p>
Note: This proposal is not needed anymore since the same functionality can be achieved using ERC-7656</a> standard.</strong></p>
Motivation</h2>
ERC-4337</a> (Account Abstraction) introduces programmable smart accounts. Existing proposals to extend wallet functionalities (e.g., ERC-6900</a>) focus on internal modules. This proposal generalizes the concept of service binding, allowing any ERC-4337</a> wallet to attach external services (e.g., recovery, automation, compliance) without requiring changes to the wallet's core logic.</p>
By enabling modular, non-invasive extensions, this standard fosters an open ecosystem of wallet-linked services while ensuring backward compatibility with existing ERC-4337</a> wallets.</p>
Specification</h2>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
Registry Interface</h3>
The interface IERC7897Registry</code> is defined as follows:</p>
interface</span> IERC7897Registry</span> {</span></span>
    /**</span></span>
     * </span>@notice</span> Emitted when a wallet-linked service is successfully deployed.</span></span>
       * </span>@param</span> deployedService</span> The address of the deployed contract</span></span>
       * </span>@param</span> serviceImplementation</span> The address of the implementation contract</span></span>
       * </span>@param</span> salt</span> The salt used for the CREATE2 operation</span></span>
       * </span>@param</span> chainId</span> The chain ID where the contract is deployed</span></span>
       * </span>@param</span> wallet</span> The address of the ERC-4337 wallet</span></span>
       */</span></span>
    event</span> ServiceDeployed</span>(</span></span>
        address</span> deployedService</span>,</span></span>
        address</span> indexed</span> serviceImplementation</span>,</span></span>
        bytes32</span> salt</span>,</span></span>
        uint256</span> chainId</span>,</span></span>
        address</span> indexed</span> wallet</span></span>
    )</span>;</span></span>
    </span></span>
    /**</span></span>
     * </span>@notice</span> Thrown when the CREATE2 operation fails to deploy the contract.</span></span>
       */</span></span>
    error</span> DeployFailed</span>(</span>)</span>;</span></span>
    </span></span>
    /**</span></span>
     * </span>@notice</span> Deploys a wallet-linked service for an ERC-4337 wallet.  </span></span>
       * If the service already exists, returns its address without calling CREATE2.  </span></span>
       * </span>@param</span> serviceImplementation</span> The address of the implementation contract  </span></span>
       * </span>@param</span> salt</span> The salt used for the CREATE2 operation  </span></span>
       * </span>@param</span> wallet</span> The address of the ERC-4337 wallet  </span></span>
       * Emits a {ServiceDeployed} event.  </span></span>
       * </span>@return</span> service</span> The address of the wallet-linked service  </span></span>
       */</span></span>
    function</span> deployService</span>(</span></span>
        address</span> serviceImplementation</span>,</span></span>
        bytes32</span> salt</span>,</span></span>
        address</span> wallet</span></span>
    )</span> external</span> returns</span> (</span>address</span> service</span>)</span>;</span></span>
    </span></span>
    /**</span></span>
     * </span>@notice</span> Computes the expected wallet-linked service address for an ERC-4337 wallet  </span></span>
       * without deploying it.  </span></span>
       * </span>@param</span> serviceImplementation</span> The address of the implementation contract  </span></span>
       * </span>@param</span> salt</span> The salt used for the CREATE2 operation  </span></span>
       * </span>@param</span> chainId</span> The chain ID where the service would be deployed  </span></span>
       * </span>@param</span> wallet</span> The address of the ERC-4337 wallet  </span></span>
       * </span>@return</span> service</span> The computed address of the wallet-linked service  </span></span>
       */</span></span>
    function</span> serviceAddress</span>(</span></span>
        address</span> serviceImplementation</span>,</span></span>
        bytes32</span> salt</span>,</span></span>
        uint256</span> chainId</span>,</span></span>
        address</span> wallet</span></span>
    )</span> external</span> view</span> returns</span> (</span>address</span> service</span>)</span>;</span></span>
}</span></span></code></pre>Deployment Requirements</h3>
The registry MUST deploy each wallet-linked service as an ERC-1167</a> minimal proxy with immutable constant data appended to the bytecode.</p>
The deployed bytecode of each wallet-linked service MUST have the following structure:</p>
ERC-1167 Header                      (10 bytes)</span></span>
<serviceImplementation (address)>    (20 bytes)</span></span>
ERC-1167 Footer                      (15 bytes)</span></span>
<salt (bytes32)>                     (32 bytes)</span></span>
<chainId (uint256)>                  (32 bytes)</span></span>
<wallet (address)>                   (20 bytes)</span></span></code></pre>Recommended Service Interface</h3>
Any contract created using an ERC7897Registry</code> SHOULD implement the IERC7897Service</code> interface:</p>
interface</span> IERC7897Service</span> {</span></span>
  /**</span></span>
  * </span>@notice</span> Returns the wallet linked to the contract</span></span>
  * </span>@return</span> chainId</span> The chainId of the wallet</span></span>
  * </span>@return</span> wallet</span> The address of the [ERC-4337](./04337.md) wallet</span></span>
  */</span></span>
  function</span> wallet</span>(</span>)</span> external</span> view</span> returns</span> (</span>uint256</span> chainId</span>,</span> address</span> wallet</span>)</span>;</span></span>
}</span></span></code></pre>Access Control</h3>
Services SHOULD implement access control to restrict critical operations to the wallet owner. For example:</p>
function</span> owner</span>(</span>)</span> public</span> view</span> returns</span> (</span>address</span>)</span> {</span></span>
  (</span>,</span> address</span> wallet</span>)</span> =</span> IERC7897Service</span>(</span>address</span>(</span>this</span>)</span>)</span>.</span>wallet</span>(</span>)</span>;</span></span>
  return</span> wallet</span>;</span></span>
}</span></span>
</span>
modifier</span> onlyOwner</span>(</span>)</span> {</span></span>
  require</span>(</span>msg.sender</span> ==</span> owner</span>(</span>)</span>,</span> "Unauthorized"</span>)</span>;</span></span>
  _</span>;</span></span>
}</span></span></code></pre>Rationale</h2>
The technical foundation of ERC-7897</a> centers on the extension and generalization of contract types that can be associated with ERC-4337</a> wallets. Key decisions include:</p>


Flexibility: Enables any ERC-4337</a> wallet to attach external services without modifying its core logic.</p>
</li>

Permissionless Innovation: Developers can deploy services for any wallet, fostering an open ecosystem.</p>
</li>

Backward Compatibility: Works with existing ERC-4337</a> wallets, including Safe, Argent, and Biconomy.</p>
</li>

Deterministic Addressing: Uses CREATE2 + salt/chainId/wallet for predictable service deployments.</p>
</li>
</ul>
Reference Implementation</h2>
// This implementation is a variation of the ERC6551Registry contract written by Jayden Windle @jaydenwindle and Vectorized @vectorized</span></span>
 </span></span>
contract ERC7897Registry is IERC7897Registry {</span></span>
  function deployService(</span></span>
    address serviceImplementation,</span></span>
    bytes32 salt,</span></span>
    address wallet</span></span>
  ) external override returns (address) {</span></span>
    // solhint-disable-next-line no-inline-assembly</span></span>
    assembly {</span></span>
    // Memory Layout:</span></span>
    // ----</span></span>
    // 0x00   0xff                           (1 byte)</span></span>
    // 0x01   registry (address)             (20 bytes)</span></span>
    // 0x15   salt (bytes32)                 (32 bytes)</span></span>
    // 0x35   Bytecode Hash (bytes32)        (32 bytes)</span></span>
    // ----</span></span>
    // 0x55   ERC-1167 Constructor + Header  (20 bytes)</span></span>
    // 0x69   implementation (address)       (20 bytes)</span></span>
    // 0x5D   ERC-1167 Footer                (15 bytes)</span></span>
    // 0x8C   salt (uint256)                 (32 bytes)</span></span>
    // 0xAC   chainId (uint256)              (32 bytes)</span></span>
    // 0xCC   wallet (address)               (20 bytes)</span></span>
</span>
    // Copy bytecode + constant data to memory</span></span>
      mstore(0x8c, salt) // salt</span></span>
      mstore(0xac, chainid()) // chainId</span></span>
      mstore(0xcc, wallet) // wallet address (20 bytes)</span></span>
      mstore(0x6c, 0x5af43d82803e903d91602b57fd5bf3) // ERC-1167 footer</span></span>
      mstore(0x5d, serviceImplementation) // implementation</span></span>
      mstore(0x49, 0x3d60ad80600a3d3981f3363d3d373d3d3d363d73) // ERC-1167 constructor + header</span></span>
</span>
    // Copy create2 computation data to memory</span></span>
      mstore8(0x00, 0xff) // 0xFF</span></span>
      mstore(0x35, keccak256(0x55, 0x8b)) // keccak256(bytecode) - 0x8b = 139 bytes</span></span>
      mstore(0x01, shl(96, address())) // registry address</span></span>
      mstore(0x15, salt) // salt</span></span>
</span>
    // Compute service address</span></span>
      let computed := keccak256(0x00, 0x55)</span></span>
</span>
    // If the service has not yet been deployed</span></span>
      if iszero(extcodesize(computed)) {</span></span>
      // Deploy service contract</span></span>
        let deployed := create2(0, 0x55, 0x8b, salt) // 0x8b = 139 bytes</span></span>
</span>
      // Revert if the deployment fails</span></span>
        if iszero(deployed) {</span></span>
          mstore(0x00, 0xd786d393) // `DeployFailed()`</span></span>
          revert(0x1c, 0x04)</span></span>
        }</span></span>
</span>
      // Emit the ServiceDeployed event</span></span>
        mstore(0x00, deployed) // deployedService</span></span>
        mstore(0x20, serviceImplementation) // serviceImplementation</span></span>
        mstore(0x40, salt) // salt</span></span>
        mstore(0x60, chainid()) // chainId</span></span>
        mstore(0x80, wallet) // wallet</span></span>
</span>
        log4(</span></span>
          0x00, // Start of data</span></span>
          0xa0, // Data length (160 bytes: deployed + implementation + salt + chainId + wallet)</span></span>
          0x2f82bd0c129ea2d065cf394fb7760031982c6278372c89e1a059f2478ddf4763, // Event signature hash</span></span>
          deployed, // indexed deployedService</span></span>
          serviceImplementation, // indexed serviceImplementation</span></span>
          salt, // salt</span></span>
          chainid(), // chainId</span></span>
          wallet // indexed wallet</span></span>
        )</span></span>
</span>
      // Return the service address</span></span>
        return(0x00, 0x20)</span></span>
      }</span></span>
</span>
    // Otherwise, return the computed service address</span></span>
      mstore(0x00, computed)</span></span>
      return(0x00, 0x20)</span></span>
    }</span></span>
  }</span></span>
</span>
  function serviceAddress(</span></span>
    address serviceImplementation,</span></span>
    bytes32 salt,</span></span>
    uint256 chainId,</span></span>
    address wallet</span></span>
  ) external view override returns (address) {</span></span>
    // solhint-disable-next-line no-inline-assembly</span></span>
    assembly {</span></span>
    // Copy bytecode + constant data to memory</span></span>
      mstore(0x8c, salt) // salt</span></span>
      mstore(0xac, chainId) // chainId</span></span>
      mstore(0xcc, wallet) // wallet address (20 bytes)</span></span>
      mstore(0x6c, 0x5af43d82803e903d91602b57fd5bf3) // ERC-1167 footer</span></span>
      mstore(0x5d, serviceImplementation) // implementation</span></span>
      mstore(0x49, 0x3d60ad80600a3d3981f3363d3d373d3d3d363d73) // ERC-1167 constructor + header</span></span>
</span>
    // Copy create2 computation data to memory</span></span>
      mstore8(0x00, 0xff) // 0xFF</span></span>
      mstore(0x35, keccak256(0x55, 0x8b)) // keccak256(bytecode) - 0x8b = 139 bytes</span></span>
      mstore(0x01, shl(96, address())) // registry address</span></span>
      mstore(0x15, salt) // salt</span></span>
</span>
    // Compute and return the service address</span></span>
      mstore(0x00, keccak256(0x00, 0x55))</span></span>
      return(0x00, 0x20)</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>Security Considerations</h2>
Ownership and Control</h3>
Wallet-linked services MUST be controlled by the ERC-4337</a> wallet owner to prevent unauthorized access. Implementers SHOULD include safeguards against malicious or unverified implementations.</p>
Upgradeability Risks</h3>
If a service is upgradable, ensure secure upgrade mechanisms to prevent unauthorized changes. For example:</p>


The owner of the service SHOULD be the wallet itself.</p>
</li>

Only the wallet SHOULD be able to upgrade the implementation of the service.</p>
</li>

Implement versioning to ensure backward compatibility between upgrades.</p>
</li>

Use a timelock or multisig for critical upgrades to reduce the risk of malicious changes.</p>
</li>
</ul>
Reentrancy and Cross-Contract Interactions</h3>
Services interacting with external protocols SHOULD follow best practices to prevent reentrancy attacks.</p>
User Education</h3>
Clear user interfaces and warnings SHOULD be provided to reduce phishing and social engineering risks.</p>
Testing</h3>
Implementers SHOULD thoroughly test the registry and services on testnets to ensure correctness and security before deploying to mainnet.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Retroactively Included EIPs
2024-04-04T00:00:00+00:00
Abstract</h2>
This Meta EIP lists Core EIPs introducing changes to Ethereum's consensus which were activated independently of an Ethereum hard fork due to their backward compatible nature. These EIPs generally introduce constraints to underspecified protocol rules  or clarify how certain edge cases should be handled.</p>
Motivation</h2>
To maintain consensus across all nodes, backward incompatible changes to Ethereum must be activated synchronously. Given the coordination required for this, changes are usually bundled together in network upgrades. A Meta EIP is typically used to list the changes included in a network upgrade, as well as its activation time.</p>
However, backward compatible consensus changes do not require a network upgrade to be activated. For example, if a consensus rule is underspecified, an EIP can propose a constraint to bound it. If the constraint was never broken in Ethereum's history and is unlikely to be broken in the future, the EIP can be considered backward compatible. It could then be "retroactively activated", as both nodes which support the change and those which do not would agree on the current network state and history.</p>
This Meta EIP lists all such EIPs which core developers have retroactively included as part of the Ethereum protocol specification.</p>
Specification</h2>
Retroactively Activated EIPs</h3>

EIP-2681</a>: Limit account nonce to 2^64-1</li>
EIP-3607</a>: Reject transactions from senders with deployed code</li>
EIP-4803</a>: Limit transaction gas to a maximum of 2^63-1</li>
EIP-7523</a>: Empty accounts deprecation</li>
EIP-7610</a>: Revert creation in case of non-empty storage</li>
</ul>
Activation</h3>
All EIPs listed above are considered activated as of Ethereum's genesis block. Note that EIP-7523 distinguishes pre- and post-merge behavior on the Ethereum mainnet.</p>
Rationale</h2>
This Meta EIP provides a global view of all changes included in the Ethereum protocol without an explicit network upgrade, as well as links to full specification.</p>
Backwards Compatibility</h2>
No backward compatibility issues found.</p>
Security Considerations</h2>
None.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Access-Key opcode
2024-03-27T00:00:00+00:00
Abstract</h2>
This EIP introduces a new opcode to inspect the access-list keys of the executing address.</p>
Motivation</h2>
This EIP serves as a substitute of top-level-call detection to enable a smart-contract to
enforce static declaration of attributes.</p>
Previously, application-layer contracts, against common advice from account-abstraction proponents, used to rely
on the tx.origin</code> to enforce a top-level call, such that the contract inputs are encoded as transaction input.</p>
While the access-list of transactions directly affects the execution, it only affects the gas-costs.
This EIP enhances the access-list feature to provide the property of statically-defined contract-inputs,
without relying on top-level calls, the tx.origin</code> behavior, or gas introspection.</p>
This enables smart contracts to reliably enforce static declaration of inputs.</p>
This is a step towards fulfilling the purposes as described in the Motivation of EIP-2930</a>:</p>

Introduces the access list format and the logic for handling the format.
This logic can later be repurposed for many other purposes, including block-wide witnesses,
use in ReGenesis, moving toward static state access over time, and more."</p>
</blockquote>
Specification</h2>
Parameters</h3>
Constant</th> Value</th></tr></thead>

ACCESS_KEY_OPCODE_GAS</code></td> 3</code></td></tr>
ACCESS_KEY_OPCODE_BYTE</code></td> 0x4B</code></td></tr>
</tbody></table>
Opcode</h3>
We add an instruction ACCESS_KEY</code> (with opcode ACCESS_KEY_OPCODE_BYTE</code>) which pops index</code> from the top
of the stack as big-endian uint256</code>, and pushes tx.access_list[address][index]</code> back on the stack,
if address</code> is present in the tx.access_list</code> and index < len(tx.access_list[address])</code>,
and otherwise pushes a zeroed bytes32</code> value.</p>
Gas costs</h3>
The opcode has a fixed gas cost of ACCESS_KEY_OPCODE_GAS</code>.</p>
The intrinsic gas costs of the access-list contents of the transaction itself do not change.</p>
Rationale</h2>
Static analysis of transactions</h3>
Static declaration of contract-inputs enables advanced layer-two constructions and block-building techniques:
data is available without EVM introspection, and contracts can reliably tell if the executing transaction
declared critical properties to the block builder and verifying nodes.</p>
Static-declaration of contract inputs is now independent of account-abstraction related changes,
such as transaction bundlers, as well as in-protocol with 3074.</p>

Global read-only values</h3>
Akin to TLOAD</code>, as described in EIP-1153</a>,
the ACCESS_KEY</code> opcode provides contracts with a view that is global
to the message-execution of the transaction in the EVM.</p>
However, with ACCESS_KEY</code> it is guaranteed to be read-only, and cannot change during the execution of a transaction.</p>
Access-list utility</h3>
Access-lists are under-utilized today:
very few users utilize this to warm-up storage interactions for reduced gas costs.
Generally the gas cost savings achieved with EIP-2930 are not applicable in as many use-cases.</p>
With this EIP, the utility of the access-list functionality increases,
without requiring additional resources from the EVM.</p>
Witness data</h3>
This EIP supports the transformation of applications to reduce statefulness,
by supporting read-only application state to be provided to contracts without
requiring the contract caller to support forwarding of data.</p>
The access-list contents may contain witness-data, which the contract can verify and utilize statelessness.</p>
Gas costs</h3>
The gas cost of ACCESS_KEY_OPCODE_GAS</code> gas matches that of similar operations,
specifically the BLOBHASH</code> opcode of EIP-4844</a>:
this opcode also pop an index-like EVM word from the stack,
and pushes a full 32 byte EVM word back on the stack, based on a list of hashes embedded in the transaction.</p>
The BLOBHASH</code> functionality of EIP-4844</a> is not re-usable for the purposes of this EIP however,
as the intention is to have access to just the statically declared hash, and not the cost of a blob.</p>
Naming of ACCESS_KEY</code></h3>
Access-lists currently only support a list of access-keys.
The list is not enforced to be sorted, and thus supports indexed lookups.</p>
This is not a LOAD</code> opcode, as SLOAD</code> or TLOAD</code> are, since the opcode returns a key.</p>
Backwards Compatibility</h2>
No transaction-type changes</h3>
This enhancement of access-lists utility does not affect the access-list encoding,
or the existing transaction types that support access-lists.</p>
Minimal impact on EVM transaction-context</h3>
With EIP-2930, the access-list contents are already readily available in the transaction-context during EVM execution,
and the RPC methods that trigger said execution.</p>
This EIP thus does not require significant changes to the construction of the EVM context,
nor any changes to RPC methods.</p>
Test Cases</h2>
The block fee-recipient, and any other warmed-up attributes not declared statically in the transaction access-list,
must not be considered to be part of the access-list.</p>
Security Considerations</h2>
The access-list attributes are already gas-metered in EIP-2930,
and readily accessible in the EVM to determine storage gas-costs. In terms of denial-of-service risks,
this EIP introduces no new significant data or data-processing costs.</p>
The access-list is read-only, and thus forms a minimal risk to application-developers.</p>
The access is scoped strictly to the contract that would otherwise perform a warm SLOAD</code>,
and thus storage-layout abstractions do not leak between different smart contract applications.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Extension of EIP-778 for "client" ENR Entry
2024-02-25T00:00:00+00:00
Abstract</h2>
The Ethereum network consists of nodes running various client implementations. Each client has its own set of features, optimizations, and unique behaviors. Introducing a standardized way to identify client software and its version in the ENR allows for more effective network analysis, compatibility checks, and troubleshooting. This EIP proposes the addition of a "client" field to the ENR.</p>
Motivation</h2>
Understanding the landscape of client software in the Ethereum network is crucial for developers, nodes, and network health assessment. Currently, there is no standardized method for nodes to announce their software identity and version, which can lead to compatibility issues or difficulty in diagnosing network-wide problems. Adding this to the ENR allows clients to audit network health only using discv5, and additionally track discv5 adoption across different services.</p>
Specification</h2>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 and RFC 8174.</p>
The "client" entry is proposed to be added to the ENR following the specifications in EIP-778</a>. This entry is OPTIONAL and can be omitted by clients that choose not to disclose such information. The key for this entry is "client"</code>.</p>
All elements MUST be encoded as a string using the ASCII standard as described in RFC 20</a>.</p>
The value for this entry MUST be an RLP list:</p>
[ClientName, Version, (BuildVersion)]</span></span></code></pre>

ClientName</code>: A string identifier for the client software. It SHOULD be concise, free of spaces, and representative of the client application.</li>
Version</code>: A string representing the version of the client software in a human-readable format. It is RECOMMENDED to follow semantic versioning.</li>
BuildVersion</code>: An OPTIONAL string representing the build or commit version of the client software. This can be used to identify specific builds or development versions.</li>
</ul>
Rationale</h2>
One key was chosen over using many keys to make efficient use of space. The use of one string, however, does not align with other EIPs of similar purpose and as such the RLP list was decided as the best encoding.</p>
Backwards Compatibility</h2>
This EIP is fully backwards compatible as it extends the ENR specification by adding an optional entry. Existing implementations that do not recognize the "client" entry will ignore it without any adverse effects on ENR processing or network behavior.</p>
Test Cases</h2>
A node running Geth version 1.10.0 on the mainnet might have an ENR client</code> entry like:</p>
["Geth", "1.10.0"]</span></span></code></pre>
A node running an experimental build of Nethermind might include:</p>
["Nethermind", "1.9.53", "7fcb567"]</span></span></code></pre>
and an ENR of</p>
enr:-MO4QBn4OF-y-dqULg4WOIlc8gQAt-arldNFe0_YQ4HNX28jDtg41xjDyKfCXGfZaPN97I-MCfogeK91TyqmWTpb0_AChmNsaWVudNqKTmV0aGVybWluZIYxLjkuNTOHN2ZjYjU2N4JpZIJ2NIJpcIR_AAABg2lwNpAAAAAAAAAAAAAAAAAAAAABiXNlY3AyNTZrMaECn-TTdCwfZP4XgJyq8Lxoj-SgEoIFgDLVBEUqQk4HnAqDdWRwgiMshHVkcDaCIyw</span></span></code></pre>
which can be decoded to yield normal data such as seq</code>, signature</code>, id</code> and secp256k1</code>. Additionally, it would yield the client value of ["0x4e65746865726d696e64","0x312e392e3533","0x37666362353637"]</code> or ["Nethermind", "1.9.53", "7fcb567"]</code></p>
Security Considerations</h2>
Introducing identifiable client information could potentially be used for targeted attacks against specific versions or builds known to have vulnerabilities. It is crucial for clients implementing this EIP to consider the implications of disclosing their identity and version. Users or operators should have the ability to opt-out or anonymize this information if desired.</p>
Additionally, as this information is self proclaimed, this data MUST NOT</strong></em> be used for anything that requires it to be reliable.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


eth/70 - available-blocks-extended protocol
2023-10-21T00:00:00+00:00
Abstract</h2>
The purpose of this EIP is to introduce a method that allows an Ethereum node to communicate the range of blocks it has available. By knowing the block range a node can serve, peers can make more informed decisions when choosing whom to request blocks from or whom to connect to, especially when looking for specific block ranges. This can lead to more efficient network behavior.</p>
This EIP proposes extending the Ethereum wire protocol (eth</code>) handshake, introducing a new version, eth/70</code>, which will contain information regarding the block range a node can serve. Furthermore, it extends the protocol with two new message types to share the updated block ranges when requested.</p>
Motivation</h2>
In a first stage of EIP-4444</a>, some nodes will still need to serve the historical data of the chain and others might be interested in starting to prune it. Currently, nodes need to connect to peers and request specific blocks to determine if a peer has the requested data. This can be inefficient, leading to unnecessary data requests and wasting both bandwidth and time. Consequently, this change empowers nodes that still want to retrieve historical data from the network to do so efficiently.</p>
As a bonus, This change enhances the efficiency of synchronization by allowing a node to determine if a peer, potentially still in the process of syncing, has the necessary blocks available, thereby avoiding unnecessary block requests and potential empty responses.</p>
Specification</h2>


Advertise a new eth</code> protocol capability (version) at eth/70</code>.</p>

The old eth/69</code> protocol should still be kept alive side-by-side, until eth/70</code> is sufficiently adopted by implementors.</li>
</ul>
</li>

Modify the Status (0x00)</code> message for eth/70</code> to add an additional blockRange</code> field right after the forkid</code>:</p>

Current packet for eth/69</code>: [version: P, networkid: P, blockhash: B_32, genesis: B_32, forkid]</code></li>
New packet for eth/70</code>: [version: P, networkid: P, blockhash: B_32, genesis: B_32, forkid blockRange]</code>,
where blockRange</code> is [startBlock: uint64, endBlock: uint64]</code>.</li>
</ul>
</li>

Introduce two new message types:</p>

RequestBlockRange (0x0b)</code> - A message from a node to request the current block range of a peer.</li>
SendBlockRange (0x0c): [startBlock: uint64, endBlock: uint64]</code> - The response to RequestBlockRange</code>, informing the requesting node of the current available block range of the peer.</li>
</ul>
</li>
</ul>
Upon connecting using eth/70</code>, nodes should exchange the Status</code> message. Afterwards, they can use the RequestBlockRange</code> and SendBlockRange</code> messages to keep informed about peer block range changes.</p>
Nodes must retain connections regardless of a peer's available block range, with an exception, if a node's peer slots are full and it lacks connections to peers with the necessary block range, it may disconnect to seek such peers.</p>
Rationale</h2>
Including the available block range in the eth</code> handshake allows for immediate understanding of peer capabilities. This can lead to more efficient networking as nodes can prioritize connections based on the data they need.
The new message types are introduced to allow nodes to request updated available block range from other nodes since the range can change by the node syncing or pruning blocks.
Maintaining connections with peers that don't have the desired range ensures network resilience, while the exception facilitates efficient block sync under full peer capacity.</p>
Backwards Compatibility</h2>
This EIP extends the eth</code> protocol handshake in a backwards incompatible manner and proposes the introduction of a new version, eth/70</code>. However, devp2p</code> allows for multiple versions of the same wire protocol to run concurrently. Hence, nodes that have not been updated can continue using older versions like eth/69</code>, eth/68</code> or eth/67</code>.</p>
This EIP doesn't affect the consensus engine and doesn't necessitate a hard fork.</p>
Test Cases</h2>
Testing will involve ensuring that nodes can correctly communicate and understand the block range information during the handshake. Additionally, it will involve ensuring nodes can correctly request and share updated block range when requested.</p>
Security Considerations</h2>
This change is not a standardization of not storing and serving historical blocks before the implementation of alternative historical blocks storage solutions.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Linter Scope
2023-06-20T00:00:00+00:00
Abstract</h2>
Currently in practice EIP linter tools (EIPW, for example) will block a Pull Request for lint errors even if that lint errors was not introduced in that Pull Request.
This EIP make it explicit that lint errors for untouched lines shall be considered ignorable except for status change.</p>
Specification</h2>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</p>
In an update to an EIP, A Pull Request SHOULD NOT be required to fix linter errors in untouched lines unless it's changing the Status of the EIP.</p>
Rationale</h2>
This policy allows micro contributions for anyone who just want to fix a typo or change a section of a section in a large EIP.</p>
Security Considerations</h2>
None</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


SETCODE instruction
2023-04-20T00:00:00+00:00
Abstract</h2>
Introduce the SETCODE</code> (0xfc</code>) instruction, which replaces the code of the executing account from memory.</p>
Motivation</h2>
Many contracts are upgradeable in order to facilitate improvement or defer decisions without migrating to a new address.
Contracts presently do this in several ways:</p>
The oldest method uses CALL</code>.
The limitation of this method is that internal state must be modifiable by all future implementations.</p>
Second, DELEGATECALL</code> can proxy the implementation.
Some proxies are minimal while others branch to many separate implementation accounts.
This method can also bypass account code size limits.</p>
A third method uses SELFDESTRUCT</code> and CREATE2</code> to replace code in-place.
This method improves upon the prior methods by removing the need to call into external contracts.
One limitation of this method is that any internal state is removed by SELFDESTRUCT</code>.
Another limitation is that SELFDESTRUCT</code> does not remove code until the end of the transaction, sacrificing availability until CREATE2</code> can complete the upgrade.</p>
Given the upcoming deprecation of SELFDESTRUCT</code>, SETCODE</code> introduces a better method for replacing code in-place.</p>
Specification</h2>
When within a read-only execution scope like the recursive kind created by STATICCALL</code>, SETCODE</code> causes an exceptional abort.</p>
When the currently executing code does not equal the code of the executing account, such as can happen inside of DELEGATECALL</code> or CREATE</code>, SETCODE</code> causes an exceptional abort.</p>
Otherwise, SETCODE</code> consumes two words from the stack: offset and length.
These specify a range of memory containing the new code.
Any validations that would be performed on the result of CREATE</code> or CREATE2</code> occur immediately, potentially causing failure with exceptional abort.
The operations EXTCODESIZE</code> and EXTCODECOPY</code> now query the updated code, and message-calls such as DELEGATECALL</code>, CALLCODE</code>, CALL</code>, and STATICCALL</code> now execute the updated code.
Any execution scopes already executing replaced code, including the one that SETCODE</code>, will continue executing the prior code.
Inside such scopes, CODESIZE</code> and CODECOPY</code> continue to query the executing code.</p>
Like SSTORE</code>, this account modification will be reverted if the current scope or any parent scope reverts or aborts.</p>
Unlike SELFDESTRUCT</code>, SETCODE</code> does not clear account balance, nonce, or storage.</p>
Gas</h3>
The gas cost of this operation is the sum of Gselfdestruct</code> and the product of Gcodedeposit</code> and the number of bytes in the new code.</p>
Rationale</h2>
The behavior of CODECOPY</code>, CODESIZE</code>, EXTCODESIZE</code>, and EXTCODECOPY</code> match the behavior of DELEGATECALL</code> and CREATE</code>, where it is also possible for executing code to differ from the code of the executing account.</p>
The gas cost of SETCODE</code> is comparable to CREATE</code> but excludes Gcreate</code> because no execution context is created, nor any new account.
Other account modification costs are accounted for outside of execution gas.</p>
Unlike SELFDESTRUCT</code>, execution proceeds normally after SETCODE</code> in order to allow validation and return data.
Post-update validation can undo a SETCODE</code> operation with REVERT</code>, or with a recursive SETCODE</code>, but REVERT</code> uses less gas.</p>
Preventing SETCODE</code> within most DELEGATECALL</code> allows static analysis to easily identify mutable code.
Account code not containing the SETCODE</code> operation can be safely assumed to be immutable.
Code observed in a non-reverting context to be immutable will remain immutable, allowing on-chain static analysis for immutability.</p>
Backwards Compatibility</h2>
The only prior operation changing code is SELFDESTRUCT</code>.
As code modification via SELFDESTRUCT</code> is deferred until the end of the transaction, its interactions with SETCODE</code> are well-defined.</p>
Test Cases</h2>
CodeStart</th> CallData</th> CodeResult</th> Gas</th></tr></thead>

365f5f37365ffc00</td> 365f5f37365ffc00</td> 365f5f37365ffc00</td> 6613</td></tr>
365f5f37365ffc00</td> 00</td> 00</td> 5213</td></tr>
365f5f37365ffc00</td> </td> </td> 5013</td></tr>
365f5f37365ffc595ffd</td> 365f5f37365ffc00</td> 365f5f37365ffc595ffd</td> 6617</td></tr>
365f5f37365ffcfe</td> 365f5f37365ffc00</td> 365f5f37365ffcfe</td> all</td></tr>
</tbody></table>
Security Considerations</h2>
Risks related to SETCODE</code> similarly apply to other upgrade patterns.</p>
Most contracts should never be replaced and should not be upgradeable.
Any upgrade mechanism can risk permanent failure.
The possibility of upgrade perpetuates such risk.</p>
Access to upgrade operations should be restricted.
Upgrades should never be performed in a hurry or when tired.
Upgrades should be tested under as similar conditions to production as possible; discrepancies are sources of unexpected results.
When possible, multiple engineers should preview and independently verify pending upgrade procedures.</p>
Block explorers, wallets, and other interfaces should flag upgradeable code.
Client software should warn against approving ERC-20</a> or ERC-721</a> tokens for upgradeable accounts.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Insert Code into EOAs with AUTHUSURP
2022-03-26T00:00:00+00:00
Abstract</h2>
This EIP introduces a new opcode, AUTHUSURP</code>, which deploys code at an EIP-3074</a> authorized address. For externally owned accounts (EOAs), together with EIP-3607</a>, this effectively revokes the original signing key's authority.</p>
Motivation</h2>
EOAs currently hold a significant amount of user-controlled value on Ethereum blockchains, but are limited by the protocol in a variety of critical ways. These accounts do not support rotating keys for security, batching to save gas, or sponsored transactions to reduce the need to hold ether yourself. There are countless other benefits that come from having a contract account or account abstraction, like choosing one's own authentication algorithm, setting spending limits, enabling social recovery, allowing key rotation, arbitrarily and transitively delegating capabilities, and just about anything else we can imagine.</p>
New users have access to these benefits using smart contract wallets, and new contracts can adopt recent standards to enable app-layer account abstraction (like EIP-4337</a>), but these would neglect the vast majority of existing Ethereum users' accounts. These users exist today, and they also need a path to achieving their security goals.</p>
Those added benefits would mostly come along with EIP-3074 itself, but with one significant shortcoming: the original signing key has ultimate authority for the account. While an EOA could delegate its authority to some additional</em> contract, the key itself would linger, continuing to provide an attack vector, and a constantly horrifying question lingering: have I been leaked? In other words, EIP-3074 can only grant authority to additional actors, but never revoke it.</p>
Today's EOAs have no option to rotate their keys. A leaked private key (either through phishing, or accidental access) cannot be revoked. A prudent user concerned about their key security might migrate to a new secret recovery phrase but at best this requires a transaction per asset (making it extremely expensive), and at worst, some powers (like hard-coded owners in a smart contract) might not be transferable at all.</p>
We know that EOAs cannot provide ideal user experience or safety, and there is a desire in the community to change the norm to contract-based accounts, but if that transition is designed without regard for the vast majority of users today—for whom Ethereum has always meant EOAs—we will be continually struggling against the need to support both of these userbases. This EIP provides a path not to enshrine EOAs, but to provide a migration path off of them, once and for all.</p>
This proposal combines well with, but is distinct from, EIP-3074</a>, which provides opcodes that could enable any externally owned account (EOA) to delegate its signing authority to an arbitrary smart contract. It allows an EOA to authorize a contract account to act on its behalf without forgoing its own powers</em>, while this EIP provides a final migration path off the EOA's original signing key.</p>
Specification</h2>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.</p>
Conventions</h3>

top - N</code></strong> - the N</code>th most recently pushed value on the EVM stack, where top - 0</code> is the most recent.</li>
invalid execution</strong> - execution that is invalid and must exit the current execution frame immediately, consuming all remaining gas (in the same way as a stack underflow or invalid jump).</li>
empty account</strong> - account where its balance is 0, its nonce is 0, and it has no code.</li>
</ul>
AUTHUSURP</code> (0xf8</code>)</h3>
A new opcode AUTHUSURP</code> shall be created at 0xf8</code>. It shall take two stack elements and return one stack element.</p>
Input</h4>
Stack</th> Value</th></tr></thead>

top - 0</code></td> offset</code></td></tr>
top - 1</code></td> length</code></td></tr>
</tbody></table>
Output</h4>
Stack</th> Value</th></tr></thead>

top - 0</code></td> address</code></td></tr>
</tbody></table>
Behavior</h4>
AUTHUSURP</code> behaves identically to CREATE</code> (0xf0</code>), except as described below:</p>

If authorized</code> (as defined in EIP-3074) is unset, execution is invalid.</li>
If authorized</code> points to an empty account, then static_gas</code> remains 32,000. Otherwise, static_gas</code> shall be 7,000.</li>
AUTHUSURP</code> does not check the nonce of the authorized</code> account.</li>
The initcode runs at the address authorized</code>.</li>
If the initcode returns no bytes, its execution frame must be reverted, and AUTHUSURP</code> returns zero.</li>
After executing the initcode, but before the returned code is deployed, if the account's code is non-empty, the initcode's execution frame must be reverted, and AUTHUSURP</code> returns zero.</li>
The code is deployed into the account with the address authorized</code>.</li>
</ul>
Rationale</h2>
AUTHUSURP</code> does not check the nonce of the authorized</code> account because it must work with accounts that have previously sent transactions.</p>
When using AUTHUSURP</code>, if the initcode were to deploy a zero-length contract, there would be no way to prevent using AUTHUSURP</code> again later.</p>
The account's code must be checked immediately before deploying to catch the situation where the initcode attempts to AUTHUSURP</code> at the same address. This is unnecessary with other deployment instructions because they increment and check the account's nonce.</p>
Backwards Compatibility</h2>
AUTHUSURP</code> with EIP-3607 revokes the authority of the original ECDSA signature to send transactions from the account. This is completely new behavior, although it is somewhat similar to the CREATE2</code> opcode.</p>
Security Considerations</h2>
Contracts using ECDSA signatures outside of transactions will not be aware that the usurped account is no longer controlled by a private key. This means that, for example, the private key will always</em> have access to the permit</code> function on token contracts. This can—and should—be mitigated by modifying the ecrecover</code> pre-compiled contract.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Safer Control Flow for the EVM
2021-08-30T00:00:00+00:00
Abstract</h2>
We define a safe EVM contract as one that cannot encounter an exceptional halting state.  In general, we cannot prove safety for Turing-complete programs. But we can prove a useful subset.</p>
This EIP specifies validity rules to ensure that:</p>

Valid contracts will not halt with an exception unless they either</p>

throw out of gas</code> or</li>
recursively overflow stack.</li>
</ul>
</blockquote>
This EIP does not introduce any new opcodes.  Rather, it restricts the use of existing and proposed control-flow instructions.  The restrictions must be validated at contract initialization time – not at runtime – by the provided algorithm or its equivalent. This algorithm must take time and space near-linear in the size of the contract, so as not to be a denial of service vulnerability.</p>
This specification is entirely semantic.  It imposes no further syntax on bytecode, as none is required to ensure the specified level of safety.  Ethereum Virtual Machine bytecode is just that -- a sequence of bytes that when executed causes a sequence of changes to the machine state.  The safety we seek here is simply to not, as it were, jam up the gears.</p>
Motivation</h2>
Safety</h3>
For our purposes we define a safe EVM contract as one that cannot encounter an exceptional halting state.  From the standpoint of security it would be best if unsafe contracts were never placed on the blockchain.  Unsafe code can attempt to overflow stack, underflow stack, execute invalid instructions, and jump to invalid locations.</p>
Unsafe contracts are exploits waiting to happen.</p>
Validating contract safety requires traversing the contract code.  So in order to prevent denial of service attacks all jumps, including the existing JUMP</code> and JUMPI</code>, and also the other proposed jumps -- RJUMP</code>, RJUMPI</code>, RJUMPSUB</code> and RETURNSUB</code> -- must be validated at initialization time, and in time and space linear in the size of the code.</p>
Static Jumps and Subroutines</h4>
The relative jumps of EIP-4200</a> and the simple subroutines of EIP-2315</a> provide a complete set of static control flow instructions:</p>

RJUMP</code> offset</em></p>
</blockquote>

Jumps to IP+offset</em>.</li>
</ul>

RJUMPI</code> offset</em></p>
</blockquote>

Jumps if the top of stack is non-zero.</li>
</ul>

RJUMPSUB</code> offset</p>
</blockquote>

Pushes IP+1</em> on the return stack and jumps to IP+offset</em>.</li>
</ul>

RETURNSUB</code></p>
</blockquote>

Jumps to the address popped off the return stack.</li>
</ul>
Note that each jump creates at most two paths of control through the code, such that the complexity of traversing the entire control-flow graph is linear in the size of the code.</p>
Dynamic Jumps</em></h4>
Dynamic jumps, where the destination of a JUMP</code> or JUMPI</code> is not known until runtime, are an obstacle to proving validity in linear time -- any jump can be to any destination in the code, potentially requiring time quadratic in the size of code. For this reason we have two real choices.</p>

Deprecate dynamic jumps. This is easily done:</li>
</ol>

Define JUMP</code> and JUMPI</code> as INVALID</code> for the purposes of EOF Code Validation</p>
</blockquote>

Constrain dynamic jumps. This requires static analysis.</li>
</ol>
Consider the simplest and most common case.</p>
PUSH address</span></span>
JUMP</span></span></code></pre>
This is effectively a static jump.</p>
Another important use of JUMP</code> is to implement the return jump from a subroutine. So consider this example of calling and returning from a minimal subroutine:</p>
TEST_SQUARE:</span></span>
    jumpdest</span></span>
    push RTN_SQUARE </span></span>
    0x02</span></span>
    push SQUARE</span></span>
    jump</span></span>
RTN_SQUARE</span></span>
    jumpdest</span></span>
    swap1</span></span>
    jump</span></span>
</span>
SQUARE:</span></span>
    jumpdest</span></span>
    dup1</span></span>
    mul</span></span>
    swap1</span></span>
    jump</span></span></code></pre>
The return address -RTN_SQUARE</code> - and the destination address - SQUARE</code> - are pushed on the stack as constants and remain unchanged as they move on the stack, such that only those constants are passed to each JUMP</code>. They are effectively static.  We can track the motion of constants on the data stack</code> at validation time, so we do not need unconstrained dynamic jumps to implement subroutines.</em></p>
The above is the simplest analysis that suffices.  A more powerful analysis that takes in more use cases is possible -- slower, but still linear-time.</em></p>
Validation</h4>
We can validate the safety of contracts with a static analysis that takes time and space linear in the size of the code</em>, as shown below.  And since we can, we should.</p>
Performance</h3>
Validating safe control flow at initialization time has potential performance advantages.</p>

Static jumps do not need to be checked at runtime.</li>
Stack underflow does not need to be checked for at runtime.</li>
</ul>
Specification</h2>
Validity</h3>

In theory, theory and practice are the same. In practice, they're not. -- Albert Einstein</p>
</blockquote>
We define a safe</em> EVM contract as one that cannot encounter an exceptional halting state.  We validate safety</em> at initialization time to the extent practical.</p>
Exceptional Halting States</em></h4>
The execution</em> of each instruction is defined in the Yellow Paper as a change to the EVM state that preserves the invariants of EVM state.  At runtime, if the execution of an instruction would violate an invariant the EVM is in an exceptional halting state.  The Yellow Paper defined five such states.</p>

Insufficient gas</li>
More than 1024 stack items</li>
Insufficient stack items</li>
Invalid jump destination</li>
Invalid instruction</li>
</ol>
A program is safe iff no execution can lead to an exceptional halting state.</em></p>
We would like to consider EVM programs valid iff they are safe.</em></p>
In practice</em>, we must be able to validate code</em> in linear time to avoid denial of service attacks. And we must support dynamically-priced instructions, loops, and recursion, which can use arbitrary amounts of gas and stack.</p>
Thus our validation cannot consider concrete computations -- it only performs a limited symbolic execution of the code</em>.  This means we will reject programs if we detect any invalid execution paths, even if those paths are not reachable at runtime.  And we will count as valid programs that may not always produce correct results.</p>
We can detect only non-recursive</em> stack overflows at validation time</em>, so we must check for the first two states at runtime</em>:</p>

out of gas</code> and</li>
stack overflow.</li>
</ul>
The remaining three states we can check at validation time</em>:</p>

stack underflow,</li>
invalid jump, and</li>
invalid instruction.</li>
</ul>
That is to say:</p>

Valid contracts will not halt with an exception unless they either</p>

throw out of gas</code> or</li>
recursively overflow stack.</li>
</ul>
</blockquote>
Constraints on Valid Code</em></h4>

Every instruction is valid.</li>
Every jump is valid:

EveryJUMP</code> and JUMPI</code> is static</em>.</li>
No JUMP</code>, JUMPI</code>, RJUMP</code>, RJUMPI</code>, or RJUMPSUB</code> addresses immediate data.</li>
</ul>
</li>
The stacks are always valid:

The number</em> of items on the data stack</code> is always positive, and at most 1024.</li>
The number</em> of items on the return stack</code> is always positive, and at most 1024.</li>
</ul>
</li>
The data stack is consistently aligned:

The number</em> of items on the data stack</code> between the current stack pointer</code> and the stack pointer</code> on entry to the most recent basic block is the same for each execution</em> of a byte_code</em>.</li>
</ul>
</li>
</ul>
We define a JUMP</code> or JUMPI</code> instruction to be static</em> if its jumpsrc</code> argument was first placed on the stack via a PUSH…</code> and that value has not changed since, though it may have been copied via a DUP…</code> or SWAP…</code>.</p>
The RJUMP</code>, RJUMPI</code> and RJUMPSUB</code>instructions take their destination as an immediate argument, so they are static</em>.</p>
Taken together, these rules allow for code to be validated by traversing the control-flow graph, in time and space linear in the size of the code, following each edge only once.</p>
Note: The definition of 'static' for JUMP</code> and JUMPI</code> is the bare minimum needed to implement subroutines.  Deeper analyses could be proposed that would validate a larger and probably more useful set of jumps, at the cost of more expensive (but still linear) validation.</em></p>
Rationale</h2>
Demanding static</em> destinations for all jumps means that all jump destinations can be validated at initialization time, not runtime.</p>
Bounding the stack pointers catches all data stack</code> and non-recursivereturn stack</code> overflows.</p>
Requiring a consistently aligneddata stack</code> prevents stack underflow. It can also catch such errors as misaligned stacks due to irreducible control flows and calls to subroutines with the wrong number of arguments.</p>
Backwards Compatibility</h2>
These changes affect the semantics of EVM code – the use of JUMP</code>, JUMPI</code>, and the stack are restricted, such that some code</em> that would otherwise run correctly will nonetheless be invalid EVM code</em>.</p>
Reference Implementation</h2>
The following is a pseudo-Go implementation of an algorithm for predicating code validity.  An equivalent algorithm must be run at initialization time.</p>
This algorithm performs a symbolic execution of the program that recursively traverses the code</em>, emulating its control flow and stack use and checking for violations of the rules above.</p>
It runs in time equal to O(vertices + edges)</code> in the program's control-flow graph, where edges represent control flow and the vertices represent basic blocks</em> -- thus the algorithm takes time proportional to the size of the code</em>.</p>
Note: All valid code has a control-flow graph that can be traversed in time and space linear in the length of the code.  That means that some other static analyses and code transformations that might otherwise require quadratic time can also be written to run in near-linear time, including one-pass and streaming compilers.</em></p>
Validation Function</h3>
Note:</strong> This function is a work in progress, and the version below is known to be incorrect.</em></p>
For simplicity's sake we assume that jumpdest analysis</em> has been done and that we have some helper functions.</p>

isValidInstruction(pc)</code> returns true if pc</code> points at a valid instruction</li>
isValidJumpdest(dest)</code> returns true if dest</code> is a valid jumpdest</li>
immediateData(pc)</code> returns the immediate data for the instruction at pc</code>.</li>
advancePC(pc)</code> returns next pc</code>,  skipping any immediate data.</li>
removed_items(pc)</code> returns the number of items removed from the dataStack</code> by the instruction at pc</code>.</li>
added_items(pc)</code> returns the number of items added to the dataStack</code> by the instruction at pc</code>.</li>
</ul>
var bytecode      [codeLen]byte</span></span>
var subMin        [codeLen]int</span></span>
var subMax        [codeLen]int</span></span>
var subDelta      [codeLen]int</span></span>
var visited       [codeLen]bool</span></span>
var dataStack     [1024]int</span></span>
</span>
// validate a path through the control flow of the bytecode at pc</span></span>
// and return the maximum number of stack items used down that path</span></span>
// or else the PC and an error</span></span>
//</span></span>
// by starting at pc:=0 the entire program is recursively evaluated</span></span>
//</span></span>
func validate(pc := 0, sp := 0, rp := 0) int, error {</span></span>
   minStack := 0 </span></span>
   maxStack := 0 </span></span>
   deltaStack := 0 </span></span>
   for pc < codeLen {</span></span>
      if !isValidInstruction(pc) {</span></span>
         return 0,0,0,invalid_instruction</span></span>
      }</span></span>
      </span></span>
      // if we have jumped here before return to break cycle</span></span>
      if visited[pc] {</span></span>
</span>
          // stack is not aligned if deltas not the same</span></span>
          if ??? {</span></span>
            return 0,0,0,invalid_stack</span></span>
          }</span></span>
          return minStack, maxStack, sp</span></span>
      }</span></span>
      visited[pc] = true</span></span>
      switch bytecode[pc] {</span></span>
</span>
      // successful termination</span></span>
      case STOP:</span></span>
         return minStack, maxStack, sp</span></span>
      case RETURN:</span></span>
         return minStack, maxStack, sp</span></span>
</span>
      case SELFDESTRUCT:</span></span>
         return minStack, maxStack, sp</span></span>
      case REVERT:</span></span>
         return minStack, maxStack, sp</span></span>
      case INVALID:</span></span>
         return 0,0,0,invalid_instruction</span></span>
    </span></span>
      case RJUMP:</span></span>
</span>
         // check for valid jump destination</span></span>
         if !isValidJumpdest(jumpdest) {</span></span>
            return 0,0,0,invalid_destination</span></span>
         }</span></span>
         </span></span>
         // reset pc to destination of jump</span></span>
         pc += immediateData(pc)</span></span>
</span>
      case RJUMPI:</span></span>
      </span></span>
         // recurse to validate true side of conditional</span></span>
         jumpdest = pc + immediateData(pc)</span></span>
         if !isValidJumpdest(pc + jumpdest) {</span></span>
            return 0,0,0,invalid_destination</span></span>
         }</span></span>
         minRight, maxLeft, deltaRight, err =</span></span>
            validate(jumpdest, sp, rp)</span></span>
  </span></span>
     err {</span></span>
            return 0,0,0,err</span></span>
         }</span></span>
         </span></span>
         // recurse to validate false side of conditional</span></span>
         pc = advancePC(pc)</span></span>
         minRight, maxRight, deltaRight, err =</span></span>
            validate(pc, sp, rp)</span></span>
         if err {</span></span>
            return 0,0,0,err</span></span>
         }</span></span>
         </span></span>
         // both paths valid, so return max</span></span>
         minStack = min(minStack, min(minLeft, minRight))</span></span>
         maxStack += max(maxLeft, maxRight)</span></span>
         deltaStack += max(deltaLeft, deltaRight)</span></span>
         return minStack, maxStack, deltaStack</span></span>
</span>
      case RJUMPSUB:</span></span>
</span>
         // check for valid jump destination</span></span>
         jumpdest = immediateData(pc)</span></span>
         if !isValidJumpdest(pc + jumpdest) {</span></span>
            return 0,0,0,invalid_destination</span></span>
         }</span></span>
</span>
         pc += jumpdest</span></span>
</span>
         // recurse to validate subroutine call</span></span>
         minSub, maxSub, deltaSub, err = validate(jumpdest, sp, rp)</span></span>
         if err {</span></span>
            return 0,0,0,err</span></span>
         }</span></span>
         subMin[pc] = minSub</span></span>
         subMax[pc] = maxSub</span></span>
         subDelta[pc] = deltaSub</span></span>
         minStack = min(minStack, sp)</span></span>
         maxStack = max(maxStack, sp)</span></span>
         pc = advancePC(pc)</span></span>
</span>
      case RETURNSUB:</span></span>
      </span></span>
         maxStack = max(maxStack, sp)</span></span>
         return minStack, maxStack, sp, nil</span></span>
</span>
      /////////////////////////////////////////////////////</span></span>
      //</span></span>
      // The following are to be included only if we take</span></span>
      //</span></span>
      //    Option 2</span></span>
      //</span></span>
      // and do not deprecate JUMP and JUMPI</span></span>
      //</span></span>
      case JUMP:</span></span>
         // pop jump destination</span></span>
         jumpdest = dataStack[--sp]</span></span>
         if !valid_jumpdest(jumpdest) {</span></span>
            return 0,0,0,invalid_destination</span></span>
         }</span></span>
         pc = jumpdest</span></span>
      case JUMPI:</span></span>
         // pop jump destination and conditional</span></span>
         jumpdest = dataStack[--sp]</span></span>
         jumpif = dataStack[--sp]</span></span>
         if sp < 0 {}</span></span>
            return 0,0,0,stack_underflow</span></span>
         }</span></span>
         if !valid_jumpdest(jumpdest) {</span></span>
            return 0,0,0,invalid_destination</span></span>
         }</span></span>
</span>
         // recurse to validate true side of conditional</span></span>
         if !isValidJumpdest(jumpdest) {</span></span>
            return 0,0,0,invalid_destination</span></span>
         }</span></span>
         maxLeft, err = validate(jumpdest, sp, rp)</span></span>
         if err {</span></span>
            return 0,0,0,err</span></span>
         }</span></span>
         </span></span>
         // recurse to validate false side of conditional</span></span>
         pc = advance_pc(pc)</span></span>
         maxRight, err = validate(pc, sp, rp)</span></span>
         if err {</span></span>
            return 0,0,0,err</span></span>
         }</span></span>
         </span></span>
         // both sides valid, return max</span></span>
         maxStack += max(maxLeft, maxRight)</span></span>
         return minStack, maxStack, sp</span></span>
      case PUSH1 <= bytecode[pc] && bytecode[pc] <= PUSH32 {</span></span>
         sp++</span></span>
         if (sp > 1023) {</span></span>
            return 0,0,0,stack_overflow</span></span>
         }</span></span>
         maxStack = max(maxStack, sp)</span></span>
         dataStack[sp] = immediateData(pc)</span></span>
         pc = advancePC(pc)</span></span>
      case DUP1 <= bytecode[pc] && bytecode[pc] <= DUP32 {</span></span>
         dup = sp - (bytecode[pc] - DUP1)</span></span>
         if dup < 0 {</span></span>
            return 0,0,0,stack_underflow</span></span>
         }</span></span>
         sp++</span></span>
         if (sp > 1023) {</span></span>
            return 0,0,0,stack_overflow</span></span>
         }</span></span>
         maxStack = max(maxStack, sp)</span></span>
         dataStack[sp] = dataStack[dup]</span></span>
         pc = advancePC(pc)</span></span>
      case SWAP1 <= bytecode[pc] && bytecode[pc] <= SWAP32 {</span></span>
         swap = sp - (bytecode[pc] - SWAP1)</span></span>
         if swap < 0 {</span></span>
            return 0,0,0,stack_underflow</span></span>
         }</span></span>
         temp := dataStack[swap]</span></span>
         dataStack[swap] = dataStack[0]</span></span>
         dataStack[0] = temp</span></span>
         pc = advancePC(pc)</span></span>
      //</span></span>
      /////////////////////////////////////////////////////</span></span>
</span>
      default:</span></span>
</span>
         // apply other instructions to stack pointer</span></span>
         sp -= removed_items(pc)</span></span>
         if (sp < 0) {</span></span>
            return 0,0,0,stack_underflow</span></span>
         }</span></span>
         minStack = min(minStack, sp)</span></span>
         sp += added_items(pc)</span></span>
         if (sp > 1023) {</span></span>
            return 0,0,0,stack_overflow</span></span>
         }</span></span>
         maxStack = max(maxStack, sp)</span></span>
         pc = advancePC(pc)</span></span>
      }</span></span>
   }</span></span>
</span>
   // successful termination</span></span>
   return minStack, maxStack, sp</span></span>
}</span></span></code></pre>Security Considerations</h2>
This EIP is intended to ensure an essential level of safety for EVM code deployed on the blockchain.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Predictable Proof-of-Work (POW) Sunsetting
2021-03-13T00:00:00+00:00
Simple Summary</h2>
Sets block reward to 3 and reduces it to 1 linearly over the course of about 1 year.</p>
Abstract</h2>
Sets the block reward to 3 ETH and then incrementally decreases it every block for 2,362,000 blocks (approximately 1 year) until it reaches 1 ETH.</p>
Motivation</h2>
Unnecessarily abrupt changes to the Ethereum ecosystem cause disruption and disharmony resulting in the disenfranchisement of community members while undermining stability and confidence.  While moves from Proof-of-Work to Proof-of-Stake will undoubtedly cause friction between those community members vested in either, all benefit from a measured, predictable transition.</p>
This proposal:</p>

Is issuance neutral over 1 year, and reduces issuance beyond that.</li>
Sets an initial block reward of 3;</li>
Introduces an ongoing, predictable reduction in future mining rewards down to 1, effectively "sunsetting" POW and codifying the move to POS;</li>
Reduces economic incentives for continued development of ASICs;</li>
Allows the impacts of decreasing miner rewards to be measured and monitored rather than relying on conjecture and game theory, so adjustments can be made if necessary.</li>
</ol>
Specification</h2>
Constants</h3>

TRANSITION_START_BLOCK_NUMBER: TBD</code></li>
TRANSITION_DURATION: 2_362_000</code> // (about one year)</li>
TRANSITION_END_BLOCK_NUMBER: FORK_BLOCK_NUMBER + TRANSITION_DURATION</code></li>
STARTING_REWARD: 3_000_000_000_000_000_000</code></li>
ENDING_REWARD: 1_000_000_000_000_000_000</code></li>
REWARD_DELTA: STARTING_REWARD - ENDING_REWARD</code></li>
</ul>
Block Reward</h3>
if</span> block</span>.</span>number</span> >=</span> TRANSITION_END_BLOCK_NUMBER</span>:</span></span>
    block_reward</span> =</span> ENDING_REWARD</span></span>
elif</span> block</span>.</span>number</span> ==</span> TRANSITION_START_BLOCK_NUMBER</span>:</span></span>
    block_reward</span> =</span> STARTING_REWARD</span></span>
elif</span> block</span>.</span>number</span> ></span> TRANSITION_START_BLOCK_NUMBER</span>:</span></span>
    block_reward</span> =</span> STARTING_REWARD</span> -</span> REWARD_DELTA</span> *</span> TRANSITION_DURATION</span> /</span> (</span>block</span>.</span>number</span> -</span> TRANSITION_START_BLOCK_NUMBER</span>)</span></span></code></pre>Rationale</h2>
Picking starting and ending block reward values that are equidistant from the current block reward rate of 2 ensures the impact of this EIP will be issuance neutral over the one year time frame.  Temporarily raising the block reward to 3 blunts the initial impact of a sudden miner revenue decrease and the continual reductions thereafter codify Ethereum's move to POS by increasingly disincentivizing POW.  Importantly, this approach moderates the rate of change so impacts and threats can be measured and monitored.</p>
Backwards Compatibility</h2>
There are no known backward compatibility issues with the introduction of this EIP.</p>
Security Considerations</h2>
There are no known security issues with the introduction of this EIP.</p>
Copyright</h2>
Copyright and related rights waived via CC0.</p>


Hardcoded Block Gas Limit
2021-03-13T00:00:00+00:00
Simple Summary</h2>
Hardcode the block gas limit to 12,500,000</code> gas per block.</p>
Abstract</h2>
Updates the block validation rules such that a block is invalid if the gas_limit</code> header field is not equal to 12,500,000</code>.</p>
Motivation</h2>
Both Ethereum's Proof of Work and Proof of Stake designs assume that block producers are financially rational, but does not assume block producers to be benevolent. There is one exception however, and it is when block producers choose the gas limit of a block where it is assumed that block producers care about the long term health and decentralisation of the chain. Indeed, the block gas limit is one of the only parameters in Ethereum that is not dictated by node consensus, but instead is chosen by block producers. This decision was initially made to allow urgent changes in the block gas limit if necessary. Both drastically increasing or decreasing this parameter could have serious consequences that may not be desired. It is therefore a critical parameter that should require node consensus to avoid any sudden harmful change imposed by a small number of actors on the rest of the network.</p>
Specification</h2>
Refer to gasLimit</code> as gasTarget</code> post EIP-1559.</p>
Added Consensus Constraint</h3>
As of FORK_BLOCK_NUMBER</code>, the header.gasLimit</code> MUST</strong> be equal to BLOCK_GAS_LIMIT</code>, where BLOCK_GAS_LIMIT</code> is a hardcoded constant set to 12,500,000</code>.</p>
Rationale</h2>
Keeping gasLimit in Block Headers</h3>
While it would be possible to remove the gasLimit</code> field from block headers, it would change the data structure to be hashed, which could lead to unintended consequences. It is therefore easier to leave the gasLimit as part of block headers.</p>
Chosen Gas Limit</h3>
The 12,500,000</code> value is being proposed as it's the current block gas limit as of time of writing this EIP. The actual amount could be altered with a subsequent EIP to avoid deviating from the core intent of this EIP.</p>
Backwards Compatibility</h2>
This EIP is backward compatible.</p>
Security Considerations</h2>
Rapid changes to the gas limit will likely be more difficult to execute, which could be problematic if an urgent situation arise that required changing the gas limit.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Limit account nonce to 2^52
2021-03-07T00:00:00+00:00
Abstract</h2>
Limit account nonce to be between 0</code> and 2^52</code>.</p>
Motivation</h2>
Account nonces are currently specified to be arbitrarily long unsigned integers. Dealing with arbitrary length data in the state witnesses is not optimal, therefore this EIP will allow proofs to represent the nonce in a more optimized way.</p>
Additionally it could prove beneficial to transaction formats, where some improvements are potentially sought by at least three other proposals.</p>
Lastly, this facilitates a minor optimisation in clients, because the nonce no longer needs to be kept as a 256-bit number.</p>
Specification</h2>
If block.number >= FORK_BLOCK</code> introduce two new restrictions:</p>

Consider any transaction invalid, where the nonce exceeds 2^52</code>.</li>
The CREATE</code> instruction to abort with an exceptional halt, where the account nonce is 2^52</code>.</li>
</ol>
Rationale</h2>


It is unlikely for any nonce to reach or exceed the proposed limit. If one would want to reach that limit via external transactions, it would cost at least 21000 * (2^64-1) = 387_381_625_547_900_583_915_000</code> gas.</p>
</li>

It must be noted that in the past, in the Morden testnet, each new account had a starting nonce of 2^20</code> in order to differentiate transactions from mainnet transactions.
This mode of replay protection is out of fashion since EIP-155</a> introduced a more elegant way using chain identifiers.</p>
</li>

Most clients already consider the nonce field to be 64-bit, such as go-ethereum.</p>
</li>

All integer values <= 2^52 can be encoded in a 64-bit floating point without any loss of precision, making this value easy to work with in languages that only have floating point number support.</p>
</li>
</ol>
Backwards Compatibility</h2>
While this is a breaking change, no actual effect should be visible:</p>

There is no account in the state currently which would have a nonce exceeding that value. As of November 2020, the account 0xea674fdde714fd979de3edf0f56aa9716b898ec8</code> is responsible for the highest account nonce at approximately 29 million.</li>
</ol>
Security Considerations</h2>
None.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


MEDGASPRICE Opcode
2021-03-05T00:00:00+00:00
Simple Summary</h2>
An opcode for getting the median gas price of the parent block.</p>
Abstract</h2>
Adds MEDGASPRICE (0x46)</code> opcode that returns the median gas price for the parent block.</p>
Motivation</h2>
With the emergence of rollups as core mechanisms in scaling Ethereum there are a number of common transactions that can be front-run. Optimistic rollups rely on the submission of fraud proofs to maintain the integrity of their systems. As a result actors submitting fraud proofs typically receive a financial reward for doing so. This opens a trivial front-running strategy of watching the mempool for fraud proof submissions and copying such transactions with a much higher gas price to reap the reward. Such front-runners do not perform validation independently and de-incentivize others from performing validation. Adding a mechanism enforcing an upper bound on gas prices for a transaction could be an effective defense against such front-running attacks.</p>
Consider a smart contract that wants to implement a first come first serve mechanism. Such a mechanism must defeat the inherently pay-to-win nature of the gas price market. Enforcing a maximum gas price for a transaction relies on the fact that transactions of the same gas price are generally processed in a first in first out way by Ethereum miners. A contract currently has few options for setting a max gas price:</p>

Set a constant value at a reasonable rate given the current gas prices</li>
Allow an individual or group of individuals to adjust a max gas price over time</li>
</ul>
More elaborate schemes could likely be constructed but all would involve storing gas price information on chain increasing the number of transactions and costing Ether.</p>
Given a median gas price opcode a contract can set a maximum gas price as a function of the last blocks gas price. This can easily be implemented using a strategy such as the following:</p>
// Assume that block.medgasprice is bound to MEDGASPRICE (0x46)</span></span>
</span>
function submitFraudProof(bytes calldata proof) public {</span></span>
  require(tx.gasprice <= maxGasPrice());</span></span>
  // process the fraud proof and provide a reward (if valid)</span></span>
}</span></span>
</span>
function maxGasPrice() public view returns (uint) {</span></span>
  return 3 * block.medgasprice;</span></span>
}</span></span></code></pre>
Given the contract implementation above a client would simply call maxGasPrice</code> to determine the gas price to use when submitting a fraud proof. This particular implementation allows up to 3x the median gas price of the last block to be used.</p>
Forwards Compatibility</h3>
EIP-1559</a> plans to change the fee market in a number of ways. Most notably is the creation of a base fee that is burned. In this context an "inclusion fee" still exists as a part of the total fee. Consider the following two cases:</p>
Block sizes are increasing (all available gas is being consumed)</h4>
In this case there will be bidding contention in the inclusion fee to incentivize miners to include transactions. A median gas price operator would still be helpful as an attacker could supply a high inclusion fee to bump honest transactions.</p>
Block sizes are decreasing (excess gas is available)</h4>
In this case an attacker could specify a high inclusion fee to incentivize miners to include their transaction early in the block. Miners are incentivized to do so as including expensive transactions first reduces the risk of a revert (and partial refund) occurring.</p>
Given these two cases this EIP seems relevant in the context of EIP-1559.</p>
Post EIP-1559 MEDGASPRICE (0x46)</code> should return the median effective_gas_price</code> of the previous block.</p>
EIP-3198</a> is required for the above strategies to be implemented. With the inclusion of BASEFEE (0x48)</code> a contract can subtract the base_fee_per_gas</code> from the effective_gas_price</code> to determine the inclusion fee per gas being paid for the transaction and thus implement an upper bound.</p>
Specification</h2>
If block.number >= TBD</code>, add a new opcode MEDGASPRICE (0x46)</code>:</p>
Pushes the median gas price of the parent block onto the stack.</p>
|  Op  	| Input 	| Output 	| Cost 	|
|:----:	|:-----:	|:------:	|:----:	|
| 0x46 	|   0   	|    1   	|   8  	|</p>
Rationale</h2>
Having access to the current gas price economy allows contracts to implement more robust and automated logic surrounding acceptable transaction gas prices.</p>
Naming note</h3>
The name MEDGASPRICE</code> was chosen because the median gas price of the network can only be calculated from the latest complete block. Thus transactions being executed should expect the median gas price to be calculated from the previous block.</p>
Backwards Compatibility</h2>
There are no known backwards incompabitility issues.</p>
Security Considerations</h2>
The strategy described for preventing front-running by setting an upper bound on the gas price of transactions has a few caveats:</p>

It relies on miners being impartial. Reordering transactions with the same gas price is a trivial means of defeating this strategy.</li>
The value returned by MEDGASPRICE (0x46)</code> may fluctuate rapidly between blocks. If a transaction is not included immediately it may either fail (if the gas price drops) or become vulnerable to front-running (if the gas price increases).</li>
</ol>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


AUTH and AUTHCALL opcodes
2020-10-15T00:00:00+00:00
Abstract</h2>
This EIP introduces two EVM instructions AUTH</code> and AUTHCALL</code>. The first sets a context variable authorized</code> based on an ECDSA signature. The second sends a call as the authorized</code> account. This essentially delegates control of the externally owned account (EOA) to a smart contract.</p>
Motivation</h2>
Adding more functionality to EOAs has been a long-standing feature request. The requests have spanned from implementing batching capabilities, allowing for gas sponsoring, expirations, scripting, and beyond. These changes often mean increased complexity and rigidity of the protocol. In some cases, it also means increased attack surfaces.</p>
This EIP takes a different approach. Instead of enshrining these capabilities in the protocol as transaction validity requirements, it allows users to delegate</em> control of their EOA to a contract. This gives developers a flexible framework for developing novel transaction schemes for EOAs. A motivating use case of this EIP is that it allows any EOA to act like a smart contract wallet without</em> deploying a contract.</p>
Although this EIP provides great benefit to individual users, the leading motivation for this EIP is "sponsored transactions". This is where the fee for a transaction is provided by a different account than the one that originates the call.</p>
With the extraordinary growth of tokens on Ethereum, it has become common for EOAs to hold valuable assets without holding any ether at all. Today, these assets must be converted to ether before they can be used to pay gas fees. However, without ether to pay for the conversion, it's impossible to convert them. Sponsored transactions break the circular dependency.</p>
Specification</h2>
Conventions</h3>

top - N</code></strong> - the N</code>th most recently pushed value on the EVM stack, where top - 0</code> is the most recent.</li>
||</code></strong> - byte concatenation operator.</li>
invalid execution</strong> - execution that is invalid and must exit the current execution frame immediately, consuming all remaining gas (in the same way as a stack underflow or invalid jump).</li>
</ul>
Constants</h3>
Constant</th> Value</th></tr></thead>

MAGIC</code></td> 0x04</code></td></tr>
</tbody></table>
MAGIC</code> is used for EIP-3074</a> signatures to prevent signature collisions with other signing formats.</p>
Context Variables</h3>
Variable</th> Type</th> Initial Value</th></tr></thead>

authorized</code></td> address</code></td> unset</td></tr>
</tbody></table>
The context variable authorized</code> shall indicate the active account for AUTHCALL</code> instructions in the current frame of execution. If set, authorized</code> shall only contain an account which has given the contract authorization to act on its behalf. An unset value shall indicate that no such account is set and that there is not yet an active account for AUTHCALL</code> instructions in the current frame of execution.</p>
The variable has the same scope as the program counter -- authorized</code> persists throughout a single frame of execution of the contract, but is not passed through any calls (including DELEGATECALL</code>). If the same contract is being executed in separate execution frames (ex. a CALL</code> to self), both frames shall have independent values for authorized</code>. Initially in each frame of execution, authorized</code> is always unset, even if a previous execution frame for the same contract has a value.</p>
AUTH</code> (0xf6</code>)</h3>
A new opcode AUTH</code> shall be created at 0xf6</code>. It shall take three stack element inputs (the last two describing a memory range), and it shall return one stack element.</p>
Input</h4>
Stack</h5>
Stack</th> Value</th></tr></thead>

top - 0</code></td> authority</code></td></tr>
top - 1</code></td> offset</code></td></tr>
top - 2</code></td> length</code></td></tr>
</tbody></table>
Memory</h5>
The final two stack arguments (offset</code> and length</code>) describe a range of memory. The format of the contents of that range is:</p>

memory[offset    : offset+1 ]</code> - yParity</code></li>
memory[offset+1  : offset+33]</code> - r</code></li>
memory[offset+33 : offset+65]</code> - s</code></li>
memory[offset+65 : offset+97]</code> - commit</code></li>
</ul>
Output</h4>
Stack</h5>
Stack</th> Value</th></tr></thead>

top - 0</code></td> success</code></td></tr>
</tbody></table>
Memory</h5>
Memory is not modified by this instruction.</p>
Behavior</h4>
If length</code> is greater than 97, the extra bytes are ignored for signature verification (they still incur a gas cost as defined later). Bytes outside the range (in the event length</code> is less than 97) are treated as if they had been zeroes.</p>
authority</code> is the address of the account which generated the signature. If EXTCODESIZE</code> of authority</code> is not zero, consider the operation unsuccessful and unset authorized</code>.</p>
The arguments (yParity</code>, r</code>, s</code>) are interpreted as an ECDSA signature on the secp256k1 curve over the message keccak256(MAGIC || chainId || nonce || invokerAddress || commit)</code>, where:</p>

chainId</code> is the current chain's EIP-155</a> unique identifier padded to 32 bytes.</li>
nonce</code> is the signer's current nonce, left-padded to 32 bytes.</li>
invokerAddress</code> is the address of the contract executing AUTH</code> (or the active state address in the context of CALLCODE</code> or DELEGATECALL</code>), left-padded with zeroes to a total of 32 bytes (ex. 0x000000000000000000000000AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA</code>).</li>
commit</code>, one of the arguments passed into AUTH</code>, is a 32-byte value that can be used to commit to specific additional validity conditions in the invoker's pre-processing logic.</li>
</ul>
Signature validity and signer recovery are handled analogously to transaction signatures, including the stricter s</code> range for preventing ECDSA malleability. Note that yParity</code> is expected to be 0</code> or 1</code>.</p>
If the signature is valid and the signer address is equal to authority</code>, the context variable authorized</code> is set to the authority</code>. In particular, this is also true if authority == tx.origin</code>, which used to be handled separately in earlier versions of this EIP (see Security Considerations). If the signature is instead invalid or the signer address does not equal authority</code>, authorized</code> is reset to an unset value.</p>
AUTH</code> returns 1</code> if authorized</code> is set, or 0</code> otherwise.</p>
Gas Cost</h4>
The gas cost for AUTH</code> is equal to the sum of:</p>

fixed fee 3100</code>.</li>
memory expansion gas cost (auth_memory_expansion_fee</code>).</li>
100</code> if authority</code> is warm, 2600</code> if it is cold (per EIP-2929</a>).</li>
</ul>
The fixed fee is equal to the cost for the ecrecover</code> precompile, plus a bit extra to cover a keccak256 hash and some additional logic.</p>
The memory expansion gas cost (auth_memory_expansion_fee</code>) shall be calculated in the same way as RETURN</code>, where memory is expanded if the specified range is outside the current allocation.</p>
AUTHCALL</code> (0xf7</code>)</h3>
A new opcode AUTHCALL</code> shall be created at 0xf7</code>. It shall take seven stack elements and return one stack element. It matches the behavior of the existing CALL</code> (0xF1</code>) instruction, except where noted below.</p>
Input</h4>
Stack</th> Value</th></tr></thead>

top - 0</code></td> gas</code></td></tr>
top - 1</code></td> addr</code></td></tr>
top - 2</code></td> value</code></td></tr>
top - 3</code></td> argsOffset</code></td></tr>
top - 4</code></td> argsLength</code></td></tr>
top - 5</code></td> retOffset</code></td></tr>
top - 6</code></td> retLength</code></td></tr>
</tbody></table>
Output</h4>
Stack</th> Value</th></tr></thead>

top - 0</code></td> success</code></td></tr>
</tbody></table>
Behavior</h4>
AUTHCALL</code> is interpreted the same as CALL</code>, except for (note: this list is also the order of precedence for the logical checks):</p>

If authorized</code> is unset, execution is invalid (as defined above). Otherwise, the caller address for the call is set to authorized</code>.</li>
The gas cost, including how much gas is available for the subcall, is specified in the Gas Cost section.</li>
If the gas</code> operand is equal to 0</code>, the instruction will send all available gas as per EIP-150</a>.</li>
If the gas available for the subcall would be less than gas</code>, execution is invalid.</li>
There is no gas stipend, even for non-zero value</code>.</li>
value</code> is deducted from the balance of authorized</code>. If value</code> is higher than the balance of authorized</code>, execution is invalid.</li>
</ul>
AUTHCALL</code> must increase the call depth by one. AUTHCALL</code> must not increase the call depth by two as it would if it first called into the authorized account and then into the target.</p>
The return data area accessed with RETURNDATASIZE</code> (0x3d</code>) and RETURNDATACOPY</code> (0x3e</code>) must be set in the same way as the CALL</code> instruction.</p>
Importantly, AUTHCALL</code> does not reset authorized</code>, but leaves it unchanged.</p>
Gas Cost</h4>
The gas cost for AUTHCALL</code> shall be the sum</strong> of:</p>

static gas cost (warm_storage_read</code>)</li>
memory expansion gas cost (memory_expansion_fee</code>)</li>
dynamic gas cost (dynamic_gas</code>)</li>
gas available for execution in the subcall (subcall_gas</code>)</li>
</ul>
The memory expansion gas cost (memory_expansion_fee</code>) shall be calculated in the same way as CALL</code>.</p>
The dynamic gas portion (dynamic_gas</code>), and the gas available for execution in the subcall (subcall_gas</code>) shall be calculated as:</p>
dynamic_gas = 0</span></span>
</span>
if addr not in accessed_addresses:</span></span>
    dynamic_gas += 2500         # cold_account_access - warm_storage_read</span></span>
</span>
if value > 0:</span></span>
    dynamic_gas += 6700         # NB: Not 9000, like in `CALL`</span></span>
    if is_empty(addr):</span></span>
        dynamic_gas += 25000</span></span>
</span>
remaining_gas = available_gas - dynamic_gas</span></span>
all_but_one_64th = remaining_gas - (remaining_gas // 64)</span></span>
</span>
if gas == 0:</span></span>
    subcall_gas = all_but_one_64th</span></span>
elif all_but_one_64th < gas:</span></span>
    raise                       # Execution is invalid.</span></span>
else:</span></span>
    subcall_gas = gas</span></span></code></pre>
As with CALL</code>, the full gas cost is charged immediately, independently of actually executing the call.</p>
Rationale</h2>
Signature in Memory</h3>
The signature format (yParity</code>, r</code>, and s</code>) is fixed, so it might seem curious that auth</code> accepts a dynamic memory range. The signature is placed in memory so that auth</code> can be upgraded in the future to work with contract accounts (which might use non-ECDSA signatures) and not just EOAs.</p>
Signing Address auth</code> Argument</h3>
Including authority</code> (the signing address) as an argument to auth</code> allows future upgrades to the instruction to work with contract accounts, and not just EOAs.</p>
If authority</code> were not included and multiple signature schemes allowed, it would not be possible to compute the authorizing account's address from just the signature alone.</p>
Reserving One Sixty-Fourth of Available Gas</h3>
AUTHCALL</code> will not pass more than 63/64th of the available gas for the reasons enumerated in EIP-150</a>.</p>
Throwing for Unset authorized</code> During AUTHCALL</code></h3>
A well-behaved contract should never reach an AUTHCALL</code> without having successfully set authorized</code> beforehand. The safest behavior, therefore, is to exit the current frame of execution immediately. This is especially important in the context of transaction sponsoring / relaying, which is expected to be one of the main use cases for this EIP. In a sponsored transaction, the inability to distinguish between a sponsee-attributable fault (like a failing sub-call) and a sponsor-attributable fault (like a failing AUTH</code>) is especially dangerous and should be prevented because it charges unfair fees to the sponsee.</p>
Another Sponsored Transaction EIP</h3>
There are two general approaches to separating the "fee payer" from the "action originator".</p>
The first is introducing a new transaction type. This requires significant changes to clients to support and is generally less upgradeable than other solutions (e.g. this EIP). This approach is also not immediately compatible with account abstraction (AA). These proposals require a signed</em> transaction from the sponsor's account, which is not possible from an AA contract, because it has no private key to sign with. The main advantage of new transaction types is that the validity requirements are enforced by the protocol, therefore invalid transactions do not pollute block space.</p>
The other main approach is to introduce a new mechanism in the EVM to masquerade as other accounts. This EIP introduces AUTH</code> and AUTHCALL</code> to make calls as EOAs. There are many different permutations of this mechanism. An alternative mechanism would be to add an opcode that can make arbitrary calls based on a similar address creation scheme as CREATE2</code>. Although this mechanism would not benefit users today, it would immediately allow for those accounts to send and receive ether -- making it feel like a more first-class primitive.</p>
Besides better compatibility with AA, introducing a new mechanism into the EVM is a much less intrusive change than a new transaction type. This approach requires no changes in existing wallets, and little change in other tooling.</p>
AUTHCALL</code>'s single deviation from CALL</code> is to set CALLER</code>. It implements the minimal functionality to enable sender abstraction for sponsored transactions. This single mindedness makes AUTHCALL</code> significantly more composable with existing Ethereum features.</p>
More logic can be implemented around the AUTHCALL</code> instruction, giving more control to invokers and sponsors without sacrificing security or user experience for sponsees.</p>
What to Sign?</h3>
As originally written, this proposal specified a precompile with storage to track nonces. Since a precompile with storage is unprecedented, a revision moved replay protection into the invoker contract, necessitating a certain level of user trust in the invoker. Expanding on this idea of trusted invokers, the other signed fields were eventually eliminated, one by one, until only invoker</code> and commit</code> remained. To appease concerns about cross-chain replay attacks and irrevocable signatures, the chainId</code> and nonce</code> fields returned to the signed message.</p>
The invoker</code> binds a particular signed message to a single invoker. If invoker was not part of the message, any invoker could reuse the signature to completely compromise the EOA. This allows users to trust that their message will be validated as they expect, particularly the values committed to in commit</code>.</p>
Understanding commit</code></h3>
Earlier iterations of this EIP included mechanisms for replay protection, and also signed over value, gas, and other arguments to AUTHCALL</code>. After further investigation, we revised this EIP to its current state: explicitly delegate these responsibilities to the invoker contract.</p>
A user will specifically interact with an invoker they trust. Because they trust this contract to execute faithfully, they will "commit" to certain properties of a call they would like to make by computing a hash of the call values. They can be certain that the invoker will only allow the call to proceed if it is able to verify the values committed to (e.g. a nonce to protect against replay attacks). This certainty arises from the commit</code> value that is signed over by the user. This is the hash of values which the invoker will validate. A safe invoker should accept the values from the user and compute the commit hash itself. This ensures that invoker operated on the same input that user authorized.</p>
</p>
Using commit</code> as a hash of values allows for invokers to implement arbitrary constraints. For example, they could allow accounts to have N</code> parallel nonces. Or, they could allow a user to commit to multiple calls with a single signature. This would allow multi-tx flows, such as ERC-20</a> approve</code>-transfer</code> actions, to be condensed into a single transaction with a single signature verification. A commitment to multiple calls would look something like the diagram below.</p>
</p>
Another interesting use is to delegate control of the EOA to other key(s). This would mean the EOA signs a commit</code> message with the address of the key(s) and an access policy, if applicable. When the delegate wants to make a call as the EOA it will construct a signature over the invoker-specified call format and relay it (with the actual call data) onto chain with the signature and commit that granted it access to the account. The invoker will then be able to determine that the EOA has allowed this alternative key to make calls on its behalf.</p>
</p>
Invoker Contracts</h3>
The invoker contract is a trustless intermediary between the sponsor and sponsee. A sponsee signs over invoker</code> to require the transaction to be processed only by a contract they trust. This allows them to interact with sponsors without needing to trust them.</p>
Choosing an invoker is similar to choosing a smart contract wallet implementation. It's important to choose one that has been thoroughly reviewed, tested, and accepted by the community as secure. We expect a few invoker designs to be utilized by most major transaction relay providers, with a few outliers that offer more novel mechanisms.</p>
An important note is that invoker contracts MUST NOT</strong> be upgradeable. If an invoker can be redeployed to the same address with different code, it would be possible to redeploy the invoker with code that does not properly verify commit</code> and any account that signed a message over that invoker would be compromised. Although this sounds scary, it is no different than using a smart contract wallet via DELEGATECALL</code>. If the wallet is redeployed with different logic, all wallets using its code could be compromised.</p>
On Call Depth</h3>
The EVM limits the maximum number of nested calls, and naively allowing a sponsor to manipulate the call depth before reaching the invoker would introduce a griefing attack against the sponsee. That said, with the 63/64th gas rule, and the cost of AUTHCALL</code>, the stack is effectively limited to a much smaller depth than the hard maximum by the gas</code> parameter.</p>
It is, therefore, sufficient for the invoker to guarantee a minimum amount of gas, because there is no way to reach the hard maximum call depth with any reasonable (i.e. less than billions) amount of gas.</p>
Source of value</code></h3>
In previous iterations of this EIP, it was thought that deducting value from an EOA mid-execution was problematic. This was due to an invariant of pending transactions which allows tx pools to statically determine the validity of a given transaction.</p>
However, after further investigation we found that breaking the invariant is safe. This is mostly due to the fact that the worst case is similar in both instances.</p>
Currently an attacker can queue many transactions in the tx pool, across many accounts, and invalidate them all at once with a block where each of the queued accounts send a tx moving their entire balance. This attack will become easier and cheaper after this EIP, because it will no longer require direct access to the block builder and will not cost a full 21000 gas to originate each tx. However, the attack does not have a substantial impact on the network, so reducing the difficulty and cost is not of concern.</p>
Allowing tx.origin</code> as Signer</h3>
Allowing authorized</code> to equal tx.origin</code> enables simple transaction batching, where the sender of the outer transaction would be the signing account. The ERC-20 approve-then-transfer pattern, which currently requires two separate transactions, could be completed in a single transaction with this proposal.</p>
AUTH</code> allows for signatures to be signed by tx.origin</code>. For any such signatures, subsequent AUTHCALL</code>s have msg.sender == tx.origin</code> in their first layer of execution. Without EIP-3074, this situation can only ever arise in the topmost execution layer of a transaction. This EIP breaks that invariant and so affects smart contracts containing require(msg.sender == tx.origin)</code> checks. This check can be used for at least three purposes:</p>

Ensuring that msg.sender</code> is an EOA (given that tx.origin</code> always has to be an EOA). This invariant does not depend on the execution layer depth and, therefore, is not affected.</li>
Protecting against atomic sandwich attacks like flash loans, that rely on the ability to modify state before and after the execution of the target contract as part of the same atomic transaction. This protection would be broken by this EIP. However, relying on tx.origin</code> in this way is considered bad practice, and can already be circumvented by miners conditionally including transactions in a block.</li>
Preventing reentrancy.</li>
</ol>
Examples of (1) and (2) can be found in contracts deployed on Ethereum mainnet, with (1) being more common (and unaffected by this proposal.) On the other hand, use case (3) is more severely affected by this proposal, but the authors of this EIP did not find any examples of this form of reentrancy protection, though the search was non-exhaustive.</p>
This distribution of occurrences—many (1), some (2), and no (3)—is exactly what the authors of this EIP expect, because:</p>

Determining if msg.sender</code> is an EOA without tx.origin</code> is difficult (if not impossible.)</li>
The only execution context which is safe from atomic sandwich attacks is the topmost context, and tx.origin == msg.sender</code> is the only way to detect that context.</li>
In contrast, there are many direct and flexible ways of preventing reentrancy (ex. using a storage variable.) Since msg.sender == tx.origin</code> is only true in the topmost context, it would make an obscure tool for preventing reentrancy, rather than other more common approaches.</li>
</ul>
There are other approaches to mitigate this restriction which do not break the invariant:</p>

Set tx.origin</code> to a constant ENTRY_POINT</code> address for AUTHCALL</code>s.</li>
Set tx.origin</code> to the invoker address for AUTHCALL</code>s.</li>
Set tx.origin</code> to a special address derived from any of the sender, invoker, and/or signer addresses.</li>
Disallow authorized == tx.origin</code>. This would make the simple batching use cases impossible, but could be relaxed in the future.</li>
</ul>
AUTHCALL</code> cheaper than CALL</code> when sending value</h3>
Sending non-zero value with CALL</code> increases its cost by 9,000. Of that, 6,700 covers the increased overhead of the balance transfer and 2,300 is used as a stipend into the subcall to seed its gas counter. AUTHCALL</code> does not provide a stipend and thus only charges the base 6,700.</p>
In-Protocol Revocation</h3>
This EIP has gone back and forth</a> on how to deal with AUTH</code> message revocation. Without revocation, this EIP is a supremely powerful and flexible primitive for developers. However, it does have risk for users who use insecure and/or actively malicious invokers.</p>
Much of the risk is due to the new ability for users to batch many operations in a single transaction. It becomes easier for an account to be drained. This is a risk that will continue to grow, regardless of the adoption of this EIP, due to overwhelming desire for the feature and attempts to support it at the protocol level and at the app level.</p>
A new class of risk is introduced for insecure and buggy invokers. If an invoker has implemented replay protection, as per the authors' recommendation, this should substantially contain the blast radius. However, if the bug allows an adversary to circumvent the replay protection mechanism, it may give them full access to any EOA which has interacted with the vulnerable invoker.</p>
Although this is a truly catastrophic event which is not expected to be possible via reputable wallets, it is a serious consideration. Without in-protocol revocation, users have no way to remove their account from the vulnerable invoker.</p>
For this reason, AUTH</code> requires the nonce</code> in the message to be equal to the signer's current nonce. This way, a single tx from the EOA will cause the nonce to increase, invalidating all outstanding authorizations.</p>
Failing on EXTCODESIZE</code> check</h3>
In EIP-3607</a>, it was determined that the protocol should reject any transaction which originates from an account with code. Although this EIP focused on transaction origination, the authors of EIP-3074 feel the intention is clear: an account that has both code and a known private key should not be allowed to make arbitrary calls on behalf of said account. Therefore, the property is upheld in this EIP. For full rationale, please refer to EIP-3607</a>.</p>
Backwards Compatibility</h2>
Although this EIP poses no issues for backwards compatibility, there are concerns that it limits future changes to accounts by further enshrining ECDSA signatures. For example, it might be desirable to eradicate the concept of EOAs altogether, and replace them with smart contract wallets that emulate the same behavior. This is fully compatible with the EIP as written, however, it gets tricky if users can then elect to "upgrade" their smart contract wallets to use other methods of authentication -- e.g. convert into a multi-sig. Without any changes, AUTH</code> would not respect this new logic and continue allowing the old private key to perform actions on behalf of the account.</p>
A solution to this would be at the same time that EOAs are removed, to modify the logic of AUTH</code> to actually call into the account with some standard message and allow the account to determine if the signature / witness is valid. Further research should be done to understand how invokers would need to change in this situation and how best to write them in a future-compatible manner.</p>
Security Considerations</h2>
Secure Invokers</h3>
The following is a non-exhaustive list of checks/pitfalls/conditions that invokers should</em> be wary of:</p>

Replay protection (ex. a nonce) should be implemented by the invoker, and included in commit</code>. Without it, a malicious actor can reuse a signature, repeating its effects.</li>
value</code> should be included in commit</code>. Without it, a malicious sponsor could cause unexpected effects in the callee.</li>
gas</code> should be included in commit</code>. Without it, a malicious sponsor could cause the callee to run out of gas and fail, griefing the sponsee.</li>
addr</code> and calldata</code> should be included in commit</code>. Without them, a malicious actor may call arbitrary functions in arbitrary contracts.</li>
</ul>
A poorly implemented invoker can allow a malicious actor to take near complete control over a signer's EOA</em>.</p>
Allowing tx.origin</code> as Signer</h3>
Allowing authorized</code> to equal tx.origin</code> has the possibility to:</p>

Break atomic sandwich protections which rely on tx.origin</code>;</li>
Break reentrancy guards of the style require(tx.origin == msg.sender)</code>.</li>
</ul>
The authors of this EIP believe the risks of allowing authorized</code> to equal tx.origin</code> are acceptable for the reasons outlined in the Rationale section.</p>
Sponsored Transaction Relayers</h3>
It is possible for the authorized</code> account to cause sponsored transaction relayers to spend gas without being reimbursed by either invalidating the authorization (i.e. increasing the account's nonce) or by sweeping the relevant assets out of the account. Relayers should be designed with these cases in mind, possibly by requiring a bond to be deposited or by implementing a reputation system.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Wrapped Legacy Transactions
2020-09-12T00:00:00+00:00
Simple Summary</h2>
Two new transaction types for wrapping legacy transactions with and without a chain ID.</p>
Abstract</h2>
Introduces two new EIP-2718</a> transactions that are signature compatible with legacy transactions and can be automatically upgraded by any client.</p>

0x00 || ssz.serialize(yParity, r, s, rlp([nonce, gasPrice, gasLimit, to, value, data]))</code></li>
0x01 || ssz.serialize(yParity, r, s, rlp([nonce, gasPrice, gasLimit, to, value, data, chainId, 0, 0]))</code></li>
</ul>
Motivation</h2>
We would like to eventually deprecate legacy transactions so we no longer have to retain code in the networking and signer layer that deals with them.
However, we also want to ensure that signatures for transactions that were generated prior to that deprecation are still valid and funds don't end up stuck because of an inability to sign a new style transaction.
This EIP provides a mechanism for transmitting/including transactions in a way that is EIP-2718</a> compatible while still being signature compatible with legacy transactions.</p>
Specification</h2>
Definitions</h3>

||</code> is the byte/byte-array concatenation operator.</li>
yParity</code> is the parity (0 for even, 1 for odd) of the y</code> value of the curve point for which r</code> is the x</code> value in the secp256k1 signing process.</li>
</ul>
Transactions</h3>
As of FORK_BLOCK_NUMBER</code>, 0x00 || ssz.serialize(yParity, r, s, rlp([nonce, gasPrice, gasLimit, to, value, data]))</code> will be a valid transaction where:</p>

the RLP encoded transaction portion is signed/processed/handled exactly the same as legacy transactions were signed/processed/handled, with the exception of the final encoding</li>
TODO: Hashing or Merkleizing for block transaction root</li>
</ul>
As of FORK_BLOCK_NUMBER</code>, 0x01 || ssz.serialize(yParity, r, s, rlp([nonce, gasPrice, gasLimit, to, value, data, chainId, 0, 0]))</code> will be a valid transaction where:</p>

the RLP encoded transaction portion is signed/processed/handled exactly the same as legacy transactions were signed/processed/handled, with the exception of the final encoding</li>
TODO: Hashing or Merkleizing for block transaction root</li>
</ul>
The SSZ schema for both transaction types is:</p>
Transaction[</span></span>
  yParity: boolean,</span></span>
  r: bytes32,</span></span>
  s: bytes32,</span></span>
  signedData: bytes,</span></span>
]</span></span></code></pre>
Note: sszencode(yParity, r, s, rlp(...))</code> is the same as yParity || r || s || 0x45000000 || rlp(...)</code></p>
As of FORK_BLOCK_NUMBER</code>, rlp(nonce, gasPrice, gasLimit, to, value, data, v, r, s)</code> will no longer be a valid transaction in a block.</p>
Receipts</h3>
As of FORK_BLOCK_NUMBER</code>, 0 || ssz.serialize(status, cumulativeGasUsed, logsBloom, logs)</code> will be a valid receipt where:</p>

the ReceiptPayload</code> will be generated/processed/handled exactly the same as legacy receipts were processed/handled with the exception of its encoding</li>
TODO: Hashing or Merkleizing for block receipt root</li>
</ul>
As of FORK_BLOCK_NUMBER</code>, 1 || ssz.serialize(status, cumulativeGasUsed, logsBloom, logs)</code> will be a valid receipt where:</p>

the ReceiptPayload</code> will be generated/processed/handled exactly the same as legacy receipts were processed/handled with the exception of its encoding</li>
TODO: Hashing or Merkleizing for block receipt root</li>
</ul>
The SSZ schema for both receipt types is:</p>
Log[</span></span>
  address: bytes20,</span></span>
  topics: List[bytes32, 4],</span></span>
  data: List[uint8, 0xffffff],</span></span>
]</span></span>
Receipt[</span></span>
  status: uint8,</span></span>
  cumulativeGasUsed: uint64,</span></span>
  logsBloom: BitVector[2048],</span></span>
  logs: List[Log, 0xffffff],</span></span>
]</span></span></code></pre>
As of FORK_BLOCK_NUMBER</code>, rlp(status, cumulativeGasUsed, logsBloom, logs)</code> will no longer be a valid receipt in a block.</p>
Rationale</h2>
Signature doesn't include transaction type as first signature byte</h3>
These transaction types are explicitly designed to be signature compatible with legacy transactions, which means we cannot change the data being signed.
See Security Considerations section for more details.</p>
Two transaction types instead of one</h3>
With the introduction of typed transactions, we no longer need to do bit packing to avoid changing the shape of the signature.
Legacy transactions introduced chain ID in EIP-155</a> and wanted to avoid changing the transaction array length, so it bitpacked the chainID into the signature's v</code> value.
Since we no longer need to guarantee consistent payload lengths between transaction types, we have opted to have two transaction types with clear fields.</p>
Signature separate from signed data</h3>
When validating a signature, one must first separate out the signed data from the signature and then validate the signature against the signed data.
In the case of legacy transactions, this was a bit of a burden since you had to first RLP decode the transaction, then extract out the signature, then RLP encode a subset of the transaction.
EIP-155 made this process even worse by requiring the validator to further decode the v</code> signature value to extract the chain ID (if present) and include that in the signed data payload.
By having the signed data encoded exactly as it is signed, we make it so one can verify the transaction's signature without having to do any decoding before hand.
By having the signature SSZ encoded up front, we can easily extract the signature without even having to use a decoder.</p>
SSZ for serialization</h3>
There is a weak consensus that RLP is not a particularly good encoding scheme for hashed data partially due to its inability to be streamed.
SSZ is almost certainly going to be included in Ethereum at some point in the future, so clients likely have access to an SSZ decoder.
For this particular case, manual decoding without a full SSZ decoder isn't too complicated, though it does require doing a bit of "pointer math" since logs</code> is an array of variable length items.</p>
Deprecating legacy transactions</h3>
By deprecating legacy transactions, we make it easier for clients as they can always deal with typed transactions in blocks.</p>
Max length of logs and logs data</h3>
EIP-706</a> limits devp2p messages to 24 bit length, which gives us a pragmatic cap at that for any single transaction at the moment.
This number seems to far exceed what is reasonable anytime in the near future, so feels like as reasonable of a cap as any.</p>
Backwards Compatibility</h2>
The new transactions are signature compatible with legacy transactions.
Legacy transactions can be decoded and then encoded as type 0 or type 1 transactions.
This EIP does not introduce any deprecation process for legacy encoded transactions, though the authors do encourage client developers to upgrade legacy encoded transactions to typed transactions as soon as it is reasonable.</p>
The signature compatibility means that a client may see the same transaction encoded both ways.
In such a case the client can choose which to retain, but it is encouraged to retain the typed transaction rather than the legacy encoded transaction.
Since the two transactions would share a nonce, only one will ever be valid in a chain at a time.</p>
Test Cases</h2>
TBD</p>
Implementation</h2>
TBD</p>
Security Considerations</h2>
While EIP-2718</a> strongly recommends including the transaction type as the first byte of the signed data, we cannot accomplish that in this case because we need to remain signature compatible with legacy transactions.
Luckily, EIP-2718</a> also excludes transaction types 0xc0</code> to 0xfe</code> from valid transaction types, and the first byte of the signature in this case is in that range so we can be sure this will not conflict with any future transaction types.</p>
A signature for these transaction types does</strong> collide with legacy transactions, but the transactions will be processed the same so it doesn't matter if the transaction ends up included as a legacy transaction or a typed transaction.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Account Abstraction
2020-09-04T00:00:00+00:00
Simple Summary</h2>
Account abstraction (AA) allows a contract to be the top-level account that pays fees and starts transaction execution.</p>
Abstract</h2>
See also: https://ethereum-magicians.org/t/implementing-account-abstraction-as-part-of-eth1-x/4020</a> and the links therein for historical work and motivation.</strong></p>
Transaction validity, as of Muir Glacier, is defined rigidly by the protocol: ECDSA signature, a simple nonce, and account balance. Account abstraction extends the validity conditions of transactions with the execution of arbitrary EVM bytecode (with some limits on what state may be accessed.) To signal validity, we propose a new EVM opcode PAYGAS</code>, which also sets the gas price and gas limit the contract is willing to pay.</p>
We split account abstraction into two tiers: single-tenant AA</strong>, which is intended to support wallets or other use cases with few participants, and multi-tenant AA</strong>, which is intended to support applications with many participants (eg. tornado.cash, Uniswap).</p>
Motivation</h2>
The existing limitations preclude innovation in a number of important areas, particularly:</p>

Smart contract wallets that use signature verification other than ECDSA (eg. Schnorr, BLS, post-quantum...)</li>
Smart contract wallets that include features such as multisig verification or social recovery, reducing the highly prevalent risk of funds being lost or stolen</li>
Privacy-preserving systems like tornado.cash</a></li>
Attempts to improve gas efficiency of DeFi protocols by preventing transactions that don't satisfy high-level conditions (eg. existence of a matching order) from being included on chain</li>
Users being able to pay for transaction fees in a token other than ETH (eg. by converting that token into the ETH needed for fees inside the transaction in real-time)</li>
</ol>
Most of the above use cases are currently possible using intermediaries, most notably the Gas Station Network</a> and application-specific alternatives. These implementations are (i) technically inefficient, due to the extra 21000 gas to pay for the relayer, (ii) economically inefficient, as relayers need to make a profit on top of the gas fees that they pay. Additionally, use of intermediary protocols means that these applications cannot simply rely on base Ethereum infrastructure and need to rely on extra protocols that have smaller userbases and higher risk of no longer being available at some future date.</p>
Out of the five use cases above, single-tenant AA approximately supports (1) and (2), and multi-tenant AA approximately supports (3) and (4). We discuss the differences between the two tiers in the specification and rationale sections below.</p>
Specification</h2>
Single Tenant</h3>
After FORK_BLOCK</code>, the following changes will be recognized by the protocol.</p>
Constants</h4>
Constant</th> Value</th></tr></thead>

AA_ENTRY_POINT</code></strong></td> 0xffffffffffffffffffffffffffffffffffffffff</code></td></tr>
AA_TX_TYPE</code></strong></td> 2</code></td></tr>
FORK_BLOCK</code></strong></td> TBD</td></tr>
AA_BASE_GAS_COST</code></strong></td> 15000</td></tr>
</tbody></table>
New Transaction Type</h4>
A new EIP-2718</a> transaction with type AA_TX_TYPE</code> is introduced. Transactions of this type are referred to as "AA transactions". Their payload should be interpreted as rlp([nonce, target, data])</code>.</p>
The base gas cost of this transaction is set to AA_BASE_GAS_COST</code> instead of 21000 to reflect the lack of "intrinsic" ECDSA and signature.</p>
Nonces are processed analogously to existing transactions (check tx.nonce == tx.target.nonce</code>, transaction is invalid if this fails, otherwise proceed and immediately set tx.nonce += 1</code>).</p>
Note that this transaction type has no intrinsic gas limit; when beginning execution, the gas limit is simply set to the remaining gas in the block (ie. block.gas_limit</code> minus gas spent on previous transactions), and the PAYGAS</code> opcode (see below) can adjust the gas limit downwards.</p>
Transaction-wide global variables</h4>
Introduce some new transaction-wide global variables. These variables work similarly (in particular, have similar reversion logic) to the SSTORE refunds counter.</p>
Variable</th> Type</th> Initial value</th></tr></thead>

globals.transaction_fee_paid</code></td> bool</code></td> False if type(tx) == AA_TX_TYPE else True</code></td></tr>
globals.gas_price</code></td> int</code></td> 0 if type(tx) == AA_TX_TYPE else tx.gas_price</code></td></tr>
globals.gas_limit</code></td> int</code></td> 0 if type(tx) == AA_TX_TYPE else tx.gas_limit</code></td></tr>
</tbody></table>
NONCE (0x48)</code> Opcode</h4>
A new opcode NONCE (0x48)</code> is introduced, with gas cost G_base</code>, which pushes the nonce</code> of the callee onto the stack.</p>
PAYGAS (0x49)</code> Opcode</h4>
A new opcode PAYGAS (0x49)</code> is introduced, with gas cost G_base</code>. It takes two arguments off the stack: (top) version_number</code>, (second from top) memory_start</code>. In the initial implementation, it will assert version_number == 0</code> and read:</p>

gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])</code></li>
gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])</code></li>
</ul>
Both reads use similar mechanics to MLOAD and CALL, so memory expands if needed.</p>
Future hard forks may add support for different version numbers, in which case the opcode may take different-sized memory slices and interpret them differently. Two particular potential use cases are EIP 1559</a> and the escalator mechanism</a>.</p>
The opcode works as follows. If all three of the following conditions (in addition to the version number check above) are satisfied:</p>

The account's balance is >= gas_price * gas_limit</code></li>
globals.transaction_fee_paid == False</code></li>
We are in a top-level AA execution frame (ie. if the currently running EVM execution exits or reverts, the EVM execution of the entire transaction is finished)</li>
</ol>
Then do the following:</p>

Subtract gas_price * gas_limit</code> from the contract's balance</li>
Set globals.transaction_fee_paid</code> to True</code></li>
Set globals.gas_price</code> to gas_price</code>, and globals.gas_limit</code> to gas_limit</code></li>
Set the remaining gas in the current execution context to equal gas_limit</code> minus the gas that was already consumed</li>
</ul>
If any of the above three conditions are not satisfied, throw an exception.</p>
At the end of execution of an AA transaction, it is mandatory that globals.transaction_fee_paid == True</code>; if it is not, then the transaction is invalid. At the end of execution, the contract is refunded globals.gas_price * remaining_gas</code> for any remaining gas, and (globals.gas_limit - remaining_gas) * globals.gas_price</code> is transferred to the miner.</p>
PAYGAS</code> also serves as an EVM execution checkpoint</em>: if the top-level execution frame reverts after PAYGAS</code> has been called, then the execution only reverts up to the point right after PAYGAS</code> was called, and exits there. In that case, the contract receives no refund, and globals.gas_limit * globals.gas_price</code> is transferred to the miner.</p>
Replay Protection</h4>
One of the two following approaches must be implemented to safeguard against replay attacks.</p>
Require SET_INDESTRUCTIBLE</code></h5>
Require that contracts targeted by AA transactions begin with EIP-2937</a>'s SET_INDESTRUCTIBLE</code> opcode. AA transactions targeting contracts that do not begin with SET_INDESTRUCTIBLE</code> are invalid, and cannot be included in blocks.</p>
AA_PREFIX</code> would need to be modified to include this opcode.</p>
Preserve Nonce on SELFDESTRUCT</code></h5>
The other option is to preserve contract nonces across SELFDESTRUCT</code> invocations, instead of setting the nonce to zero.</p>
Miscellaneous</h4>

If CALLER (0x33)</code> is invoked in the first frame of
execution of a call initiated by an AA transaction, then it must return AA_ENTRY_POINT</code>.</li>
If ORIGIN (0x32)</code> is invoked in any frame of execution of an AA
transaction it must return AA_ENTRY_POINT</code>.</li>
The GASPRICE (0x3A)</code> opcode now pushes the value globals.gas_price</code></li>
</ul>
Note that the new definition of GASPRICE</code> does not lead to any changes in behavior in non-AA transactions, because globals.gas_price</code> is initialized to tx.gas_price</code> and cannot be changed as PAYGAS</code> cannot be called.</p>
Mining and Rebroadcasting Strategies</h4>
Much of the complexity in account abstraction originates from the strategies used by miners and validating nodes to determine whether or not to accept and rebroadcast transactions. Miners need to determine if a transaction will actually pay the fee if they include it after only a small amount of processing to avoid DoS attacks</a>. Validating nodes need to perform an essentially identical verification to determine whether or not to rebroadcast the transaction.</p>
By keeping the consensus changes minimal, this EIP allows for gradual introduction of AA mempool support by miners and validating nodes. Initial support would be focused on enabling simple, single-tenant use cases, while later steps would additionally allow for more complex, multi-tenant use cases. Earlier stages are deliberately more fully fleshed-out than later stages, as there is still more time before later stages need to be implemented.</p>
Transactions with Fixed Nonces</h5>
Constant</th> Value</th></tr></thead>

VERIFICATION_GAS_MULTIPLIER</code></td> 6</code></td></tr>
VERIFICATION_GAS_CAP</code></td> = VERIFICATION_GAS_MULTIPLIER * AA_BASE_GAS_COST = 90000</code></td></tr>
AA_PREFIX</code></td> if(msg.sender != shr(-1, 12)) { LOG1(msg.sender, msg.value); return }</code>; compilation to EVM TBD</td></tr>
</tbody></table>
When a node receives an AA transaction, they process it (i.e. attempt to execute it against the current chain head's post-state) to determine its validity, continuing to execute until one of several events happens:</p>

If the code of the target</code> is NOT prefixed with AA_PREFIX</code>, exit with failure</li>
If the execution hits any of the following, exit with failure:

An environment opcode (BLOCKHASH</code>, COINBASE</code>, TIMESTAMP</code>, NUMBER</code>, DIFFICULTY</code>, GASLIMIT</code>)</li>
BALANCE</code> (of any account, including the target</code> itself)</li>
An external call/create that changes the callee</code> to anything but the target</code> or a precompile (CALL</code>, CALLCODE</code>, STATICCALL</code>, CREATE</code>, CREATE2</code>).</li>
An external state access that reads code (EXTCODESIZE</code>, EXTCODEHASH</code>, EXTCODECOPY</code>, but also CALLCODE</code> and DELEGATECALL</code>), unless the address of the code that is read is the target</code>.</li>
</ul>
</li>
If the execution consumes more gas than VERIFICATION_GAS_CAP</code> (specified above), or more gas than is available in the block, exit with failure</li>
If the execution reaches PAYGAS</code>, then exit with success or failure depending on whether or not the balance is sufficient (e.g. balance >= gas_price * gas_limit</code>).</li>
</ul>
Nodes do not keep transactions with nonces higher than the current valid nonce in the mempool. If the mempool already contains a transaction with a currently valid nonce, another incoming transaction to the same contract and with the same nonce either replaces the existing one (if its gas price is sufficiently higher) or is dropped. Thus, the mempool keeps only at most one pending transaction per account.</p>
While processing a new block, take note of which accounts were the target</code> of an AA transaction (each block currently has 12500000</code> gas and an AA transaction costs >= 15000</code> so there would be at most 12500000 // 15000 = 833</code> targeted accounts). Drop all pending transactions targeting those accounts. All other transactions remain in the mempool.</p>
Single Tenant+</h3>
If the indestructible contracts EIP</a> is added, Single Tenant AA can be adapted to allow for DELEGATECALL</code> during transaction verification: during execution of a new AA transaction, external state access that reads code (EXTCODESIZE</code>, EXTCODEHASH</code>, EXTCODECOPY</code>, CALLCODE</code>, DELEGATECALL</code>) of any contract whose first byte is the SET_INDESTRUCTIBLE</code> opcode is no longer banned. However, calls to anything but the target</code> or a precompile that change the callee</code> (i.e., calls other than CALLCODE</code> and DELEGATECALL</code>) are still not permitted.</p>
If the IS_STATIC EIP</a> is added, the list of allowed prefixes can be extended to allow a prefix that enables incoming static calls but not state-changing calls.</p>
The list of allowed prefixes can also be extended to enable other benign use cases (eg. logging incoming payments).</p>
External calls into</em> AA accounts can be allowed as follows. We can add an opcode RESERVE_GAS</code>, which takes as argument a value N</code> and has simple behavior: immediately burn N</code> gas and add N</code> gas to the refund. We then add an allowed AA_PREFIX</code> that reserves >= AA_BASE_GAS_COST * 2</code> gas. This ensures that at least AA_BASE_GAS_COST</code> gas must be spent (as refunds can refund max 50% of total consumption) in order to call into an account and invalidate transactions targeting that account in the mempool, preserving that invariant.</p>
Note that accounts may also opt to set a higher RESERVE_GAS</code> value in order to safely have a higher VERIFICATION_GAS_CAP</code>; the goal would be to preserve a VERIFICATION_GAS_MULTIPLIER</code>-to-1 ratio between the minimum gas cost to edit an account (ie. half its RESERVE_GAS</code>) and the VERIFICATION_GAS_CAP</code> that is permitted that account. This would also preserve invariants around maximum reverification gas consumption that are implied by the previous section.</p>
Multi-Tenant & Beyond</h3>
In a later stage, we can add support for multiple pending transactions per account in the mempool. The main challenge here is that a single transaction can potentially cause state changes that invalidate all other transactions to that same account. Additionally, if we naively prioritize transactions by gasprice, there is an attack vector where the user willing to pay the highest gasprice publishes many (mutually exclusive) versions of their transaction with small alterations, thereby pushing everyone else's transactions out of the mempool.</p>
Here is a sketch of a strategy for mitigating this problem. We would require incoming transactions to contain an EIP-2930</a>-style access list detailing the storage slots that the transaction reads or modifies, and make it binding; that is, accesses outside the access list would be invalid. A transaction would only be included in the mempool if its access list is disjoint from the access lists of other transactions in the mempool (or if its gasprice is higher). An alternative way to think about this is to have per-storage-slot mempools instead of just per-account mempools, except a transaction could be part of multiple per-storage-slot mempools (if desired it could be capped to eg. 5 storage slots).</p>
Note also that multi-tenant AA will almost certainly require allowing miners to edit the nonces of incoming transactions to put them into sequence, with the result that the final hash of a transaction is unpredictable at publication time. Clients will need to explicitly work around this.</p>
More research is required to refine these ideas, and this is left for later work.</p>
Rationale</h2>
The core problem in an account abstraction setup is always that miners and network nodes need to be able to verify that a transaction that they attempt to include, or rebroadcast, will actually pay a fee. Currently, this is fairly simple, because a transaction is guaranteed to be includable and pay a fee as long as the signature and nonce are valid and the balance and gasprice are sufficient. These checks can be done quickly.</p>
In an account abstraction setup, the goal is to allow accounts to specify EVM code that can establish more flexible conditions for a transaction's validity, but with the requirement that this EVM code can be quickly verified, with the same safety properties as the existing setup.</p>
In a normal transaction, the top-level call goes from the tx.sender</code> to tx.to</code> and carries with it tx.value</code>. In an AA transaction, the top-level call goes from the entry point address</em> (0xFFFF...FF</code>) to the tx.target</code>.</p>
The top-level code execution is expected to be split into two phases: the shorter verification phase</strong> (before PAYGAS</code>) and the longer execution phase</strong> (after PAYGAS</code>). If execution throws an exception during the verification phase, the transaction is invalid, much like a transaction with an invalid signature in the current system. If execution throws an exception after the verification phase, the transaction pays fees, and so the miner can still include it.</p>
The transition between different stages of AA is entirely done through changes in miner strategy. The first stage supports single-tenant AA</strong>, where the only use cases that can be easily implemented are where the tx.target</code> is a contract representing a user account (that is, a smart contract wallet, eg. multisig). Later stages improve support for eg. logs and libraries, and also move toward supporting multi-tenant AA</strong>, where the goal is to try to support cases where the tx.target</code> represents an application</em> that processes incoming activity from multiple users.</p>
Nonces still enshrined in single-tenant AA</h3>
Nonces are still enforced in single-tenant AA to ensure that single-target AA does not break the invariant that each transaction (and hence each transaction hash) can only be included in the chain once. While there is some limited value in allowing arbitrary-order transaction inclusion in single-tenant AA, there is not enough value to justify breaking that invariant.</p>
Note that nonces in AA accounts do end up having a dual-purpose: they are both there for replay protection and for contract address generation when using the CREATE</code> opcode. This does mean that a single transaction could increment the nonce by more than 1. This is deemed acceptable, as the other mechanics introduced by AA already break the ability to easily verify that a chain longer than one transaction can be processed. However, we strongly recommend that AA contracts use CREATE2</code> instead of CREATE</code>.</p>
In multi-tenant AA, as mentioned above, nonces are expected to become malleable and applications that use multi-tenant AA systems would need to manage this.</p>
Nonces are exposed to the EVM</h3>
This is done to allow signature checking done in validation code to validate the nonce.</p>
Replay Protection</h3>
One of the above two approaches (requiring SET_INDESTRUCTIBLE</code> or modifying SELFDESTRUCT</code> behavior) must be implemented so that nonces cannot be reused. It must be a consensus change, and not simply part of AA_PREFIX</code>, so that transaction hash uniqueness is maintained.</p>
Miners refuse transactions that access external data or the target's own balance, before PAYGAS</h3>
An important property of traditional transactions is that activity happening as part of transactions that originate outside of some given account X cannot make transactions whose sender is X invalid. The only state change that an outside transaction can impose on X is increasing its balance, which cannot invalidate a transaction.</p>
Allowing AA contracts to access external data (both other accounts and environment variables such as GASPRICE, DIFFICULTY, etc.) before they call PAYGAS</code> (ie. during the verification phase) breaks this invariant. For example, imagine someone sends many thousands of AA transactions that perform an external call if FOO.get_number() != 5: throw()</code>. FOO.number</code> might be set to 5</code> when those transactions are all sent, but a single transaction to FOO</code> could set the number</code> to something else, invalidating all of the thousands of AA transactions</em> that depend on it. This would be a serious DoS vector.</p>
The one allowed exception is contracts that are indestructible (that is, whose first byte is the SET_INDESTRUCTIBLE</code> opcode defined in this EIP</a>). This is a safe exception, because the data that is being read cannot be changed.</p>
Disallowing reading BALANCE</code> blocks a milder attack vector: an attacker could force a transaction to be reprocessed at a mere cost of 6700 gas (not 15000 or 21000), in the worst case more than doubling the number of transactions that would need to be reprocessed.</p>
In the long term, AA could be expanded to allow reading external data, though protections such as mandatory access lists would be required.</p>
AA transactions must call contracts with prefix</h3>
The prelude is used to ensure that only</em> AA transactions can call the contract. This is another measure taken to ensure the invariant described above. If this check did not occur, it would be possible for a transaction originating outside some AA account X to call into X and make a storage change, forcing transactions targeting that account to be reprocessed at the cost of a mere 5000 gas.</p>
Multi-tenant AA</h3>
Multi-tenant AA extends single-tenant AA by better handling cases where distinct and uncoordinated users attempt to send transactions for/to the same account and those transactions may interfere with each other</strong>.</p>
We can understand the value of multi-tenant AA by examining two example use cases: (i) tornado.cash</a> and (ii) Uniswap</a>. In both of these cases, there is a single central contract that represents the application, and not any specific user. Nevertheless, there is important value in using abstraction to do application-specific validation of transactions.</p>
Tornado Cash</h4>
The tornado.cash workflow is as follows:</p>

A user sends a transaction to the TC contract, depositing some standard quantity of coins (eg. 1 ETH). A record of their deposit, containing the hash of a secret known by the user, is added to a Merkle tree whose root is stored in the TC contract.</li>
When that user later wants to withdraw, they generate and send a ZK-SNARK proving that they know a secret whose hash is in a leaf somewhere in the deposit tree (without revealing where). The TC contract verifies the ZK-SNARK, and also verifies that a nullifier value (also derivable from the secret) has not yet been spent. The contract sends 1 ETH to the user's desired address, and saves a record that the user's nullifier has been spent.</li>
</ol>
The privacy provided by TC arises because when a user makes a withdrawal, they can prove that it came from some</em> unique deposit, but no one other than the user knows which deposit it came from. However, implementing TC naively has a fatal flaw: the user usually does not yet have ETH in their withdrawal address, and if the user uses their deposit address to pay for gas, that creates an on-chain link between their deposit address and their withdrawal address.</p>
Currently, this is solved via relayers; a third-party relayer verifies the ZK-SNARK and unspent status of the nullifier, publishes the transaction using their own ETH to pay for gas, and collects the fee back from the user from the TC contract.</p>
AA allows this without relayers: the user could simply send an AA transaction targeting the TC contract, the ZK-SNARK verification and the nullifier checking can be done in the verification step, and PAYGAS can be called directly after that. This allows the withdrawer to pay for gas directly out of the coins going to their withdrawal address, avoiding the need for relayers or for an on-chain link to their deposit address.</p>
Note that fully implementing this functionality requires AA to be structured in a way that supports multiple users sending withdrawals at the same time (requiring nonces would make this difficult), and that allows a single account to support both AA transactions (the withdrawals) and externally-initiated calls (the deposits).</p>
Uniswap</h4>
A new version of Uniswap could be built that allows transactions to be sent that directly target the Uniswap contract. Users could deposit tokens into Uniswap ahead of time, and Uniswap would store their balances as well as a public key that transactions spending those balances could be verified against. An AA-initiated Uniswap trade would only be able to spend these internal balances.</p>
This would be useless for normal traders, as normal traders have their coins outside the Uniswap contract, but it would be a powerful boon to arbitrageurs. Arbitrageurs would deposit their coins into Uniswap, and they would be able to send transactions that perform arbitrage every time external market conditions change, and logic such as price limits could be enforced during the verification step. Hence, transactions that do not get in (eg. because some other arbitrageur made the trade first) would not be included on-chain, allowing arbitrageurs to not pay gas, and reducing the number of "junk" transactions that get included on-chain. This could significantly increase both de-facto blockchain scalability as well as market efficiency, as arbitrageurs would be able to much more finely correct for cross-exchange discrepancies between prices.</p>
Note that here also, Uniswap would need to support both AA transactions and externally-initiated calls.</p>
Backwards Compatibility</h2>
This AA implementation preserves the existing transaction type. The use of assert origin == caller</code> to verify that an account is an EOA remains sound, but is not extensible to AA accounts; AA transactions will always have origin == AA_ENTRY_POINT</code>.</p>
Badly-designed single-tenant AA contracts will break the transaction non-malleability invariant. That is, it is possible to take an AA transaction in-flight, modify it, and have the modified version still be valid; AA account contracts can be designed in such a way as to make that not possible, but it is their responsibility. Multi-tenant AA will break the transaction non-malleability invariant much more thoroughly, making the transaction hash unpredictable even for legitimate applications that use the multi-tenant AA features (though the invariant will not further break for applications that existed before then).</p>
AA contracts may not have replay protection unless they build it in explicitly; this can be done with the CHAINID (0x46)</code> opcode introduced in EIP 1344</a>.</p>
Test Cases</h2>
See: https://github.com/quilt/tests/tree/account-abstraction</a></p>
Implementation</h2>
See: https://github.com/quilt/go-ethereum/tree/account-abstraction</a></p>
Security Considerations</h2>
See https://ethresear.ch/t/dos-vectors-in-account-abstraction-aa-or-validation-generalization-a-case-study-in-geth/7937</a> for an analysis of DoS issues.</p>
Re-validation</h3>
When a transaction enters the mempool, the client is able to quickly ascertain whether the transaction is valid. Once it determines this, it can be confident that the transaction will continue to be valid unless a transaction from the same account invalidates it.</p>
There are, however, cases where an attacker can publish a transaction that invalidates existing transactions and requires the network to perform more recomputation than the computation in the transaction itself. The EIP maintains the invariant that recomputation is bounded to a theoretical maximum of six times the block gas limit in a single block; this is somewhat more expensive than before, but not that much more expensive.</p>
Peer denial-of-service</h4>
Denial-of-Service attacks are difficult to defend against, due to the difficulty in identifying sybils within a peer list. At any moment, one may decide (or be bribed) to initiate an attack. This is not a problem that Account Abstraction introduces. It can be accomplished against existing clients today by inundating a target with transactions whose signatures are invalid. However, due to the increased allotment of validation work allowed by AA, it's important to bound the amount of computation an adversary can force a client to expend with invalid transactions. For this reason, it's best for the miner to follow the recommended mining strategies.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Ethereum Provider Connect/Disconnect Events
2020-07-15T00:00:00+00:00
Simple Summary</h2>
When an Ethereum Provider becomes connected or disconnected, it will emit a connect</code>/disconnect</code> event.</p>
Abstract</h2>
The Provider is said to be “connected” when it can service RPC requests to at least one chain.
The Provider is said to be “disconnected” when it cannot service RPC requests to any chain at all.
When the Provider switches from a "connected" state to a "disconnected" state, it will emit a connect</code> event.
When the Provider switches from a "disconnected" state to a "connected" state, it will emit a disconnect</code> event.</p>
Motivation</h2>
When an application is hooked up to an Ethereum provider, there is value in having the application be alerted of connect/disconnect events that may occur so the application can appropriately inform the user of the situation.
It is left up to the application to decide whether to listen in on these events, and how to handle them.</p>
Specification</h2>
Definitions</h3>
Connected</h4>
The Provider is considered connected</code> when it is able to service RPC requests to at least one chain.</p>
Disconnected</h4>
The Provider is considered disconnected</code> when it is unable to service RPC requests to any chain.</p>
Events</h3>
connect</code></h4>
The Provider MUST</strong> emit a connect</code> event to all attached EIP-2700</a> listeners if it transitions from a disconnected</code> state to a connected</code> state.
All attached listeners MUST</strong> be called with the parameter { chainId }</code>.
chainId</code> MUST</strong> specify the integer ID of the connected chain encoded as a hexadecimal string.
If the Provider supports the eth_chainId</code> JSON-RPC method or a derivation of it, then the chainId</code> MUST</strong> match the return value of eth_chainId</code>.
The Provider MAY</strong> call the attached listeners in any order.</p>
Rationale</h2>
This EIP is mostly a retrospective EIP meaning it codifies an already existing specification so there isn’t a lot of room for improving things such as by having a connect/disconnect event per chain.</p>
Security Considerations</h2>
The relationship between Ethereum Provider and client is a trusted one, where it is assumed that the user implicitly trusts the Ethereum Provider which is how it managed to get injected into the client, or the client expressly pulled in a connection to it.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>
Appendix I: Examples</h2>
//</span> connect</span></span>
provider</span>.</span>on</span>(</span>'</span>connect</span>'</span>,</span> (</span>{</span> chainId</span> }</span>)</span> =></span> {</span></span>
  console</span>.</span>log</span>(</span>`</span>Provider connected to: </span>${</span>chainId</span>}</span>`</span>)</span>;</span></span>
}</span>)</span>;</span></span></code></pre>


Transaction Package
2020-06-16T00:00:00+00:00
Simple Summary</h2>
Creates a new transaction type which executes a package of one or more
transactions, while passing status information to subsequent transactions.</p>
Abstract</h2>
Introduce a new transaction type which includes a list of transactions that
must be executed serially by clients. Execution information (e.g. success,
gas_used, etc.) will be propagated forward to the next transaction.</p>
Motivation</h2>
Onboarding new users to Ethereum has been notoriously difficult due to the need
for new users to acquire enough ether to pay for their transactions. This
hurdle has seen a significant allocation of resources over the years to solve.
Today, that solution is meta-transactions. This is, unfortunately, a brittle
solution that requires signatures to be recovered within a smart contract to
authenticate the message. This EIP aims to provide a flexible framework for
relayers to "sponsor" many transactions at once, trustlessly.</p>
Meta-transactions often use relay contracts to maintain nonces and allow users
to pay for gas using alternative assets. They have historically been designed
to catch reversions in their inner transactions by only passing a portion of
the available gas to the subcall. This allows them to be certain the outer call
will have enough gas to complete any required account, like processing a gas
payment. This type of subcall has been considered bad practice for a long time,
but in the case of where you don't trust the subcalls, it is the only available
solution.</p>
Transaction packages are an alternative that allow multiple transactions to be
bundled into one package and executed atomically, similarly to how relay
contracts operate. Transactions are able to pass their result to subsequent
transactions. This allows for conditional workflows based on the outcome of
previous transactions. Although this functionality is already possible as
described above, workflows using transaction packages are more robust, because
they are protected from future changes to the gas schedule.</p>
An important byproduct of this EIP is that it also facilitates bundling
transactions for single users.</p>
Specification</h2>
Introduce a new EIP-2718</a> transaction type where id = 2</code>.</p>
Structure</h4>
struct TransactionPackage {</span></span>
    chain_id: u256,</span></span>
    children: [ChildPackage],</span></span>
    nonce: u64,</span></span>
    gas_price: u256,</span></span>
    v: u256,</span></span>
    r: u256,</span></span>
    s: u256</span></span>
}</span></span></code></pre>Hash</h5>
keccak256(rlp([2, chain_id, children, nonce, gas_price, v, r, s])</code></p>
Signature Hash</h5>
keccak256(rlp([2, chain_id, children, nonce, gas_price])</code></p>
Receipt</h5>
Each ChildTransaction</code> transaction will generate a ChildReceipt</code> after execution. Each
of these receipts will be aggregated into a Receipt</code>.</p>
type Receipt = [ChildReceipt]</span></span></code></pre>struct ChildReceipt {</span></span>
    status: u256,</span></span>
    cumulative_gas_used: u256,</span></span>
    logs_bloom: [u8; 256],</span></span>
    logs: [u8]</span></span>
}</span></span></code></pre>Child Transaction</h4>
Let ChildPackage</code> be interpreted as follows.</p>
struct ChildPackage {</span></span>
    type: u8,</span></span>
    nonce: u64,</span></span>
    transactions: [ChildTransaction],</span></span>
    max_gas_price: u256,</span></span>
    v: u256,</span></span>
    r: u256,</span></span>
    s: u256</span></span>
}</span></span></code></pre>struct ChildTransaction {</span></span>
    flags: u8,</span></span>
    to: Address,</span></span>
    value: u256,</span></span>
    data: [u8],</span></span>
    extra: [u8],</span></span>
    gas_limit: u256</span></span>
}</span></span></code></pre>Types</h5>
The type</code> field is used to denote whether the Child</code> signer wishes to
delegate the max_gas_price</code> and gas_limit</code> choice to the TransactionPackage</code>
signer.</p>
type</th> signature hash</th></tr></thead>

0x00</code></td> keccak256(rlp([0, nonce, transactions, max_gas_price])</code></td></tr>
0x01</code></td> keccak256(rlp([1, nonce, transactions_without_gas_limit])</code></td></tr>
</tbody></table>
Validity</h3>
A TransactionPackage</code> can be deemed valid or invalid as follows.</p>
fn</span> is_valid</span>(</span>config</span>:</span> &</span>Config</span>,</span> state</span>:</span> &</span>State</span>,</span> tx</span>:</span> TransactionPackage</span>)</span> bool</span> {</span></span>
    if</span> (</span></span>
        config</span>.</span>chain_id</span>(</span>)</span> !=</span> tx</span>.</span>chain_id </span>|</span>|</span></span>
        tx</span>.</span>children</span>.</span>len</span>(</span>)</span> ==</span> 0</span> |</span>|</span></span>
        state</span>.</span>nonce</span>(</span>tx</span>.</span>from</span>(</span>)</span>)</span> +</span> 1</span> !=</span> tx</span>.</span>nonce</span></span>
    )</span> {</span></span>
        return</span> false</span>;</span></span>
    }</span></span>
</span>
    let</span> cum_limit</span> =</span> tx</span>.</span>children</span>.</span>map</span>(</span>|</span>x</span>|</span> x</span>.</span>gas_limit</span>)</span>.</span>sum</span>(</span>)</span>;</span></span>
    if</span> state</span>.</span>balance</span>(</span>tx</span>.</span>from</span>(</span>)</span>)</span> <</span> cum_limit</span> *</span> tx</span>.</span>gas_price </span>+</span> intrinsic_gas</span>(</span>tx</span>)</span> {</span></span>
        return</span> false</span>;</span></span>
    }</span></span>
    </span></span>
    for</span> child</span> in</span> tx</span>.</span>children </span>{</span></span>
        if</span> (</span></span>
            child</span>.</span>nonce </span>!=</span> state</span>.</span>nonce</span>(</span>child</span>.</span>from</span>(</span>)</span>)</span> +</span> 1</span> |</span>|</span></span>
            child</span>.</span>value</span> ></span> state</span>.</span>balance</span>(</span>child</span>.</span>from</span>(</span>)</span>)</span> |</span>|</span></span>
            child</span>.</span>max_gas_price</span> <</span> tx</span>.</span>gas_price</span></span>
        )</span> {</span></span>
            return</span> false</span>;</span></span>
        }</span></span>
        </span></span>
        for</span> tx</span> in</span> child</span>.</span>txs </span>{</span></span>
            if</span> (</span></span>
                tx</span>.</span>flags </span>!=</span> 0</span> |</span>|</span></span>
                tx</span>.</span>extra</span>.</span>len</span>(</span>)</span> !=</span> 0</span> |</span>|</span></span>
                tx</span>.</span>gas_limit</span> <</span> intrinsic_gas</span>(</span>tx</span>)</span></span>
            )</span> {</span></span>
                return</span> false</span>;</span></span>
            }</span></span>
        }</span></span>
    }</span></span>
    </span></span>
    true</span></span>
}</span></span></code></pre>Results</h3>
Subsequent ChildTransaction</code>s will be able to receive the result of the
previous ChildTransaction</code> via RETURNDATACOPY (0x3E)</code> in first frame of
execution, before making any subcalls. Each element, except the last, will be
0</code>-padded left to 32 bytes.</p>
struct Result {</span></span>
    // Status of the previous transaction</span></span>
    success: bool,</span></span>
    </span></span>
    // Total gas used by the previous transaction</span></span>
    gas_used: u256,</span></span>
    </span></span>
    // Cumulative gas used by previous transactions</span></span>
    cum_gas_used: u256,</span></span>
    </span></span>
    // The size of the return value</span></span>
    return_size: u256,</span></span>
    </span></span>
    // The return value of the previous transaction</span></span>
    return_value: [u8]</span></span>
}</span></span></code></pre>Intrinsic Cost</h3>
Let the intrinsic cost of the transaction package be defined as follows:</p>
fn intrinsic_gas(tx: TransactionPackage) u256 {</span></span>
    let data_gas = tx.children.map(|c| c.txs.map(|t| data_cost(&c.data)).sum()).sum();</span></span>
    17000 + 8000 * tx.children.len() + data_gas</span></span>
}</span></span></code></pre>Execution</h3>
Transaction packages should be executed as follows:</p>

Deduct the cumulative cost from the outer signer's balance.</li>
Load the first child package, and execute the first child transaction.</li>
Record all state changes, logs, the receipt, and refund any unused gas.</li>
If there are no more child transactions, goto 8</code>.</li>
Compute Result</code> for the previously executed transaction.</li>
Prepare Result</code> to be available via return opcodes in the next
transaction's first frame.</li>
Execute the next transaction, then goto 3</code>.</li>
Load the next child package, then goto 7</code>.</li>
</ol>
Rationale</h2>
Each Child</code> has its own signature</h3>
For simplicity, the author has chosen to require each child package to specify
its own signature, even if the signer is the same as the package signer. This
choice is made to allow for maximum flexibility, with minimal client changes.
This transaction can still be used by a single user at the cost of only one
additional signature recovery.</p>
ChildPackage</code> specifies max_gas_price</code> instead of gas_price</code></h3>
Allowing child packages to specify a range of acceptable gas prices is
strictly more versatile than a static price. It gives relayers more flexibility
in terms of building transaction bundles, and it makes it possible for relayers
to try and achieve the best price for the transaction sender. With a fixed
price, the relayer may require the user to sign multiple different
transactions, with varying prices. This can be avoided by specifying a max
price, and communicating out-of-band how the urgency of the transaction (e.g.
the relayer should package it with the max price immediately vs. slowly
increasing the gas price).
A future transaction type can be specified with only a single
signature, if such an optimization is desired.</p>
ChildPackage</code> is also typed</h3>
The type element serves a modest role in the transaction type, denoting whether
the transaction signer wishes to delegate control of the gas price and gas
limit to the outer signer. This is a useful UX improvement when interacting
with a trusted relayer, as once the user decides to make a transaction the
relayer can ensure it is included on chain by choosing the best gas price and
limit.</p>
The flags</code> and extra</code> fields aren't used</h3>
These fields are included to better support future changes to the transaction
type. This would likely be used in conjunction with the flags</code> and type</code>
fields. A benefit of explicitly defining them is that specialized serialization
of RLP can be avoided, simplifying clients and downstream infrastructure. The
author believe the cost of 2 bytes per transaction is acceptable for smoother
integration of future features.</p>
Backwards Compatibility</h2>
Contracts which rely on ORIGIN (0x32) == CALLER (0x33) && RETURNDATASIZE (0x3D) == 0x00</code> will now always fail in transaction packages, unless they are
the first executed transaction. It’s unknown if any contracts conduct this
check.</p>
Test Cases</h2>
TBD</p>
Implementation</h2>
TBD</p>
Security Considerations</h2>
Managing packages efficiently in the mempool</h3>
The introduction of a new transaction type brings along new concerns regarding
the mempool. Done naively, it could turn into a DDoS vector for clients. This
EIP has been written to reduce as much validation complexity as possible.</p>
An existing invariant in the mempool that is desirable for new transactions to
maintain, is that transactions can be validated in constant time. This is also
possible for packaged transactions. There is an inherent 10Mb limit for RLPx
frames, so that would be the upper bound on transactions that could be included
in a package. On the other hand, clients can also just configure their own
bound locally (e.g. packages must be less than 1Mb). Validity can then be
determined by using the function above.</p>
Once a package has been validated, it must continuously be monitored for nonce
invalidations within its package. One potential way to achieve this efficiently
is to modify the mempool to operate on thin pointers to the underlying
transaction. This will allow packages to ingest as many "single" transactions,
simplifying the facilities for monitoring changes. These "parts" of the package
can maintain a pointer to a structure with pointers to all the parts of the
package. This way, as soon as one part becomes invalid, it can request the
parent to invalidate all outstanding parts of the package.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Sponsored, expiring and batch transactions.
2020-06-11T00:00:00+00:00
Simple Summary</h2>
Creates a new transaction type that supports sponsored transactions (separate gas payer from sender), batch transactions (multiple transactions executed in sequence), and expiring transactions (transactions which are not valid after a certain timestamp).</p>
Abstract</h2>
An EIP-2718 transaction with the type number 2</code> is a new type of transaction that includes support for:</p>

Sponsored Transactions</strong>: an optional additional signature from which the account that will pay for gas (GAS_PAYER</code>) can be recovered</li>
Batch Transactions</strong>: multiple transactions from the same sender that will be executed in sequence</li>
Expiring Transactions</strong>: an optional validUntil</code> field that makes the transaction invalid after a certain point in time</li>
</ol>
Motivation</h2>
Sponsored Transactions</h3>
With the advent of tokens and especially stable coins, it has become common for users to not hold ETH in an account while they may have other assets of value in that account.  Some users don't want to be exposed to the perceived volatility of ETH and instead would prefer to transact using other assets.  Unfortunately, since gas MUST</strong> be paid for with ETH, this prevents the user from transacting with their assets without first acquiring some ETH using some other means, and then using that ETH to pay fees.</p>
This EIP proposes a mechanism by which we can allow people to transact without ever having to own any ETH by allowing someone else to cover gas costs.  The arrangements that enable the covering of gas costs is out of scope for this EIP but it could be an extra-protocol monthly subscription, payment could occur as part of the transaction being submitted, the recipient may be willing to cover gas costs, or it could be a free service offered as a value-add by a company that you are working with.</p>
While it is possible to implement these sort of mechanisms at the individual contract layer, such solutions require integration by just about every contract and those solutions also end up depending on gas costs being stable with time in order to appropriately bake them into contracts without putting either party at risk of malicious participants in the system.  For this reason, it is believed that separating out GAS_PAYER</code> from msg.sender</code> at the protocol layer is valuable.</p>
Batch Transactions</h3>
Often times an EOA may want to execute a series of transactions with a strong guarantee that they happen in order with nothing occurring between them.  For example, one may want to send some tokens to a contract and then follow that up with another transaction that makes a contract call on the destination address that causes those tokens to be registered to them.  By supporting transaction batching at layer 1, we can ensure that the user can get strong guarantees at signing time of cross-transaction atomicity.</p>
Expiring Transactions</h3>

If any form of dust-account clearing is introduced, e.g. (https://github.com/ethereum/EIPs/issues/168), it will be necessary to introduce a replay protection, such as https://github.com/ethereum/EIPs/issues/169 . Having temporal replay protection removes the need to change nonce-behaviour in the state, since transactions would not be replayable at a later date than explicitly set by the user.</li>
In many cases, such as during ICOs, a lot of people want their transactions to either become included soon (within a couple of hours) or not at all. Currently, transactions are queued and may not execute for several days, at a cost for both the user (who ends up paying gas for a failing purchase) and the network, dealing with the large transaction queues.</li>
Node implementations have no commonly agreed metric for which transactions to keep, discard or propagate. Having a TTL on transactions would make it easier to remove stale transactions from the system.</li>
</ul>
Specification</h2>
Definitions</h3>
TransactionType</code></strong> 2.  See EIP-2718</a></p>
TransactionSubtype</code></strong> is either 1, 2, 3, or 4.</p>
ChainId</code></strong> The transaction is valid if this value is 0</code> or it is included in a block on a chain whose ID is equal to this value.</p>
ValidUntil</code></strong> The transaction is valid if this value is 0</code> or it is included in a block whose timestamp</code> is less than or equal to this value.</p>
YParity</code></strong> The parity (0 for even, 1 for odd) of the y-value of a secp256k1 signature.</p>
ChildTransaction</code></strong> A nested transaction consisting of [to, value, data]</code>.</p>
SenderPayload</code></strong> Defined based on the TransactionSubtype</code> as follows:</p>

[1, ChildTransaction[], nonce, ChainId, ValidUntil, gasLimit, gasPrice]</code></li>
[2, ChildTransaction[], nonce, ChainId, ValidUntil, gasLimit, gasPrice]</code></li>
[3, ChildTransaction[], nonce, ChainId, ValidUntil, gasLimit]</code></li>
[4, ChildTransaction[], nonce, ChainId, ValidUntil]</code></li>
</ol>
SenderSignature</code></strong> [YParity, r, s]</code> of secp256k1(keccak256(rlp([TransactionType, SenderPayload])))</code></p>
GasPayerPayload</code></strong> Defined based on the TransactionSubtype</code> as follows:</p>

[]</code></li>
[]</code></li>
[gasPrice]</code></li>
[gasLimit, gasPrice]</code></li>
</ol>
GasPayerSignature</code></strong> is []</code> for TransactionSubType</code> 1</code> or [YParity, r, s]</code> of secp256k1(keccak256(rlp([SenderPayload, SenderSignature, GasPayerPayload])))</code> for others.</p>
New Transaction Type</h3>
As of FORK_BLOCK_NUMBER</code> an EIP-2718</a> transaction with a TransactionType</code> of 2</code> will have its Payload</code> interpreted as an RLP encoded tuple of:</p>
[...SenderPayload, ...SenderSignature, ...GasPayerPayload, ...GasPayerSignature]</span></span></code></pre>
The address recovered from SenderSignature</code> is the address...</p>

...returned by the CALLER</code> opcode (0x33, aka msg.sender</code>) during the first call frame of the transaction</li>
...returned by the ORIGIN</code> opcode (0x32, aka tx.origin</code>)</li>
...whose nonce</code> is used</li>
...whose ETH balance is deducted if any value is attached to the transaction</li>
...whose ETH balance is deducted to pay for gas if GasPayerSignature</code> is not present</li>
</ol>
If GasPayerSignature</code> is present, then the address recovered from it is the address...</p>

...whose ETH balance is deducted to pay for gas</li>
</ol>
The base gas cost of transactions of this type will be TRANSACTION_TYPE_2_BASE_GAS_PRICE</code> + TRANSACTION_TYPE_2_CHILD_GAS_PRICE</code> * n</code>, rather than the cost associated with transactions of type 0</code> and legacy transactions.</p>
New Transaction Receipt</h3>
As of FORK_BLOCK_NUMBER</code> an EIP-2718</a> transaction receipt with a TransactionType</code> of 2</code> will have its Payload</code> interpreted as a rlp([status, cumulativeGasUsed, logsBloom, logs][])</code> where each item of the array corresponds to the child-transaction at matching offset in the transaction type 2 Payload</code>.</p>
Rationale</h2>
One Monolithic EIP</h3>
This EIP could be split up into multiple EIPs, one for each of the subtypes and one for the meta-type.  Alternatively, each of the subtypes could be a unique TransactionType.  The reason we chose to go with a single EIP with subtypes is because these 4 transactions all have a lot</em> in common and each separate EIP would be almost identical to the previous.  We felt that in this case, splitting into multiple EIPs wasn't worth the duplication of EIP content.</p>
ChainID not encoded with v</code></h3>
While we could save one byte in the common case by bundling the y-parity bit of the signature with the Chain ID like in EIP-155, this adds complexity to signing tools that the authors deem not worth it given the size of the transaction overall.</p>
Optionality of ChainID</h3>
Sometimes it is useful to have a transaction that can</em> be replayed on multiple chains.  An example of this is when you construct a vanity signature for a transaction and have the from</code> be whatever address that signature recovers to.  With the ability to have someone else be a gas payer (setting both the gas limit and the gas price), one can have transactions that deploy contracts which live at the same address on every chain.  While this can be accomplished with CREATE2 using legacy transactions, we have the opportunity here to simplify the process and enable potentially other future uses of deterministic transactions by making ChainID optional.</p>
Optionality of ValidUntil</h3>
A user can set ValidUntil</code> to a very large number which effectively makes it non-expiring.  By making ValidUntil</code> optional, we can save some bytes on the wire by allowing such transactions to simply have a 0</code> (1 byte in RLP) value for this field.</p>
SENDER</code> sets gasLimit</code> and gasPrice</code></h3>
This type of transaction is useful when the transaction may execute differently depending on what these values are set to.  By having the SENDER</code> set both, we ensure that the SENDER</code> has full control over the transaction details.</p>
SENDER</code> sets gasLimit</code>, GAS_PAYER</code> sets gasPrice</code></h3>
This type of transaction is useful when the transaction may execute differently depending on how much gas it is allowed (e.g., number of loops) but where the SENDER</code> would like to give the GAS_PAYER</code> the ability to price the transaction to maximize chances of inclusion.</p>
GAS_PAYER</code> sets gasLimit</code> and gasPrice</code></h3>
This type of transaction allows the SENDER</code> to define what they want to do, and leaves all worry about gas to the GAS_PAYER</code>.  This is useful for transactions where the sender doesn't care how much gas is used or the price that is paid and also either trusts the GAS_PAYER</code> to be non-malicious or doesn't care if the SENDER</code>'s nonce is increased.  Such situations are useful when you have extra-protocol trust between the SENDER</code> and GAS_PAYER</code> and you want to separate concerns (what to do vs how to get included) for security or complexity reasons.</p>
Nonces</h3>
The inner transaction needs a nonce to protect themselves from replay attacks.  Since the inner transaction has a nonce, we get replay protection on the outer transaction as well, so it is not critical for security to have multiple parties provide a nonce.</p>
We could have the GAS_PAYER</code> provide a second nonce, but this would increase the payload size and require GAS_PAYER</code> to do replace-by-fee (noisy for gossip) if they want to slip in a new (different inner) transaction with a higher gas price.  It would also create the possibility of a deadlock if the SENDER</code> nonces aren't ordered the same as the GAS_PAYER</code> nonces, and if the SENDER</code> nonce isn't the lowest valid nonce for the SENDER</code> then the GAS_PAYER</code> can't sign and submit yet.  Finally, client complexity increases slightly if a transaction has two nonces because you have to protect yourself from deadlocks and do more work to determine validity.</p>
ValidUntil</h3>
For the dust-account clearing usecase,</p>

This change is much less invasive in the consensus engine.

No need to maintain a consensus-field of 'highest-known-nonce' or cap the number of transactions from a sender in a block.</li>
Only touches the transaction validation part of the consensus engine</li>
Other schemas which uses the nonce</code> can have unintended side-effects,

such as inability to create contracts at certain addresses.</li>
more difficult to integrate with offline signers, since more elaborate nonce-schemes requires state access to determine.</li>
More intricate schemes like highest-nonce</code> are a lot more difficult, since highest-known-nonce will be a consensus-struct that is incremented and possibly reverted during transaction execution, requiring one more journalled field.</li>
</ul>
</li>
</ul>
</li>
</ul>
ValidUntil as timestamp instead of block number</h3>

The unix time is generally available in most settings, even on a computer which is offline. This means that even a setup where blockchain information is unavailable, the party signing a transaction can generate a transaction with the desired properties.</li>
The correlation between time and block number is not fixed; even though a 13s blocktime is 'desired', this varies due to both network hashrate and difficulty bomb progression.</li>
The block number is even more unreliable as a timestamp for testnets and private networks.</li>
unix time is more user-friendly, a user can more easily decide on reasonable end-date for a transaction, rather than a suitable number of valid blocks.</li>
</ul>
Backwards Compatibility</h2>
No known issues.</p>
Test Cases</h2>
Implementation</h2>
Security Considerations</h2>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Limit size of `initcode`
2020-05-18T00:00:00+00:00
Simple Summary</h2>
Enforce a maximum size limit (max_initcode_size</code>) of 49152</code> (0xc000</code>) for initcode</code>.</p>
Abstract</h2>
Enforce a maximum size limit (max_initcode_size</code>) for initcode</code>. If the size of initcode</code> exceeds max_initcode_size</code>, then contract creation fails with an out of gas error.</p>
Since EIP-170</a> was implemented, there has been a size limit of 24576</code> (0x6000</code>) on contract code. We propose to also limit the size of executable code to 2x</code> the above limit, i.e. 49152</code> (0xc000</code>).</p>
This also leads to two nice properties:</p>

instruction offset in code fits 16-bit value,</li>
code size fits 16-bit value.</li>
</ul>
Motivation</h2>
When a client executes initcode</code>, the client has to perform a jumpdest analysis. In some cases, the client also performs a hash</code> of the code:</p>

To use as a key in a mapping containing the result of a jumpdest analysis</li>
To use for address calculation within CREATE2</code>.</li>
</ul>
The work performed during a jumpdest analysis scales linearly with the size of the code. Currently, a transaction can expand the memory once, and reuse the same memory segment (with minor modifications) to force the client to perform a lot of analysis/hashing, leading to slow block processing.</p>
Historically, this was exploited in June 2017, precipitating the 1.6.5-patch release of geth</a></p>
The work performed during address calculation within CREATE2</code> is charged in proportion with size of the code.</p>
Specification</h2>
There are three situations where this is applicable:</p>

CREATE</code>,</li>
CREATE2</code>,</li>
creation using a transaction with empty receiver.</li>
</ul>
In all these (and future) cases, the EVM should fail with Out Of Gas error if the code has a length more than max_initcode_size</code>.</p>
Rationale</h2>
TBA</p>
Backwards Compatibility</h2>
This EIP requires a "network upgrade", since it modifies consensus-rules.</p>
Security Considerations</h2>
For client implementations, this EIP makes attacks based on jumpdest-analysis or hashing of code less problematic, so should increase the robustness of clients.</p>
For layer 2, this EIP introduces failure-modes where there previously were none. There could</em> exist factory-contracts which deploy multi-level contract hierarchies, such that the code for multiple contracts are included in the initcode of the first contract. The author(s) of this EIP are not aware of any such contracts.</p>
Test Cases</h2>
Test cases should include the following cases,</p>

CREATE</code>/CREATE2</code>/tx create</code> with initcode_size</code> at max_initcode_size</code></li>
CREATE</code>/CREATE2</code>/tx create</code> with initcode_size</code> at max_initcode_size+1</code></li>
</ul>
Implementation</h2>
TBA</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Updates and Updated-by Header
2020-01-06T00:00:00+00:00
Simple Summary</h2>
Adds EIP header options updates</code> and updated-by</code> to frontmatter of active</code> EIPs for use as needed.</p>
Abstract</h2>
EIP headers updates</code> and updated-by</code> are used for updating active</code> EIPs. This is to make the improvement process of EIPs more modular, and have updates to existing active</code> EIPs receive similar exposures to EIPs which replace existing final</code> EIPs.</p>
Motivation</h2>
Currently, EIP1 specifies EIP headers: updated</code>, replaces</code>, and superseded-by</code>. Headers replaces</code> and superseded-by</code> indicates when an entire EIP is being replaced by another EIP, indicating when an EIP is now historical, and is updated by a new standard.</p>
The header updated</code> indicates the date an EIP has received an update by EIP authors and editors, an example EIP being EIP1. updated</code> is reserved for EIPs in draft</code> or active</code> status.</p>
In the case of active</code> status, an EIP may receive an update, but these updates don't operate as with EIPs in final</code> status, where a historical EIP is created, and the new EIP is referenced by the historical one. While these updates are not kept immutably, updates to active EIPs can be done modularly by creating a new EIP that goes through the standard discussion and auditing process EIPs undergo. The EIP headers updates</code> and updated-by</code> are to facilitate this modularity. Creating a new EIP also provides sufficient notification to affected stakeholders of an active EIP before that EIP is updated</code>.</p>
Specification</h2>
updated-by</code></h3>
updated-by</code> is reserved for EIPs in active</code> status. For an EIP in status active</code>, updates to that EIP, which update the header updated</code>, should be started by opening a new EIP to start vetting for that update. When an active</code> EIP receives a new entry to header updated</code>, an associated updated-by</code> EIP listing should be included, where that newly listed EIP has reached final</code> status.</p>
updates</code> should be included as an EIP header, as all EIP headers, and include a reference to an EIP designation. When multiple EIP designations are referenced, each should be separated by a comma. Example:</p>
---</span></span>
updated-by: 9999, 9998, 9997</span></span>
---</span></span></code></pre>updates</code></h3>
updates</code> is reserved for EIPs updating EIPs in active</code> status. An EIP listed as updates</code> is implied to also be requires</code>; only updates</code> is needed for those EIP listings. Having an EIP listing updates</code> does not necessarily mean that referenced EIP must reference back with an updated-by</code> listing.</p>
updates</code> should be included as an EIP header, as all EIP headers, and include a reference to an EIP designation. When multiple EIP designations are referenced, each should be separated by a comma. Example:</p>
---</span></span>
updates: 1</span></span>
---</span></span></code></pre>Rationale</h2>
updates</code> and updated-by</code> apply only to EIPs in active</code> status as updates to EIPs in final</code> status are already handled by EIP headers superseded-by</code> and replaces</code>.</p>
The syntax should align with previous EIP header syntax, as this EIP is not updating syntax, simply adding header options.</p>
Backwards Compatibility</h2>
These EIP headers are optional and do not introduce compatibility issues.</p>
Implementation</h2>
An implementation is adding a header option.</p>
Security Considerations</h2>
This standard is informational and does not introduce technical security issues.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Simple Subroutines for the EVM
2019-10-17T00:00:00+00:00
Abstract</h2>
This proposal provides a complete</em>, efficient</em>, safe</em> and static</em> control-flow facility.</p>
It introduces two new opcodes to support calling and returning from subroutines:</p>

RJUMPSUB relative_offset</code> -- relative jump to subroutine</li>
RETURNSUB</code> -- return to PC</code> after most recent RJUMPSUB</code>.</li>
</ul>
It depends on the two new opcodes proposed by EIP-4200</a> to support static jumps:</p>

RJUMP relative_offset</code> — relative jump to PC + relative_offset</code></li>
RJUMPI relative_offset</code> — conditional relative jump</li>
</ul>
It deprecates JUMP</code> and JUMPI</code>, allowing valid code to support streaming, one-pass, and other near-linear compilers.</p>
In concert with EIP-3540</a> and EIP-3670</a> it ensures, at initialization time, that valid code will not execute invalid instructions or jump to invalid locations, will not underflow stack, will maintain consistent numbers of inputs and outputs for subroutines, and will have bounded stack height in the absence of recursion.</p>
This is among the simplest possible proposals that meets these requirements.</p>
Motivation</h2>
A complete control-flow facility.</h3>
Jumps, conditional jumps and subroutines were proposed by Alan Turing in 1945 as a means of organizing the logic of the code and the design of the memory crystals for his Automatic Computing Engine:</p>

We wish to be able to arrange that sequences of orders can divide at various points, continuing in different ways according to the outcome of the calculations to date...  We also wish to be able to arrange for the splitting up of operations into subsidiary operations... To start on a subsidiary operation we need only make a note of where we left off the major operation and then apply the first instruction of the subsidiary.  When the subsidiary is over we look up the note and continue with the major operation.</p>
— Alan Turing — in B.E. Carpenter, R.W. Doran, "The other Turing machine." The Computer Journal, Volume 20, Issue 3, January 1977.</p>
</blockquote>
In more contemporary terms, we have sequences of instructions, jumps and conditional jumps that divide sequences into blocks, subroutine calls, and a stack of addresses to return to.  The details vary, but similar facilities have proven their value across a long line of important machines over the last 75 years, including most all of the machines we have programmed or implemented -- physical machines including the Burroughs 5000, CDC 7600, IBM 360, DEC PDP-11 and VAX, Motorola 68000, Sun SPARC, and Intel x86s, as well as virtual machines for Scheme, Forth, Pascal, Java, Wasm, and others.</p>
Unlike these machines, the Ethereum Virtual Machine does not</em> provide subroutine operations. Instead, they must be synthesized using the dynamic JUMP</code> instruction, which takes its destination on the stack. Further, the EVM provides only</em> dynamic jumps, impeding the static analysis we need.</p>
Efficient control-flow.</h3>
Efficient to write by hand, compile from high level labguages, validate at deploy time, interpret by VMs, and compile to machine code.</p>
Static jumps, conditional jumps, and subroutines are sufficient and efficient in space and time, as shown by historical experience and as we will show for the EVM below.</p>
Safe control-flow.</h3>
The EVM has unusually high requirements for safety.  Not only do many smart contracts control inordinately large amounts of valuable Ether, but once placed on the blockchain any defects are visible to attackers and cannot be repaired.  We propose to statically validate important safety constraints on code at initialization time.</p>
Static control-flow.</h3>
The EVM's dynamic jumps cause two major problems. First, the need to synthesize static jumps and subroutines with dynamic jumps wastes space and gas with needlessly complex code, as we will show below.</p>
Worse, jumps that can dynamically branch to any destination in the code can cause quadratic "path explosions" when traversing the flow of control. For Ethereum, this is a denial-of-service vulnerability that prevents us, at initialization time, from validating the safe use of EVM code and from compiling EVM code to machine code.</p>
We need</em> static control-flow to validate program safety and to compile EVM bytecode to machine code -- in time and space linear in the size of the code.</p>
Specification</h2>
Opcodes</h3>
RJUMPSUB (0x5f) relative_offset</code></h4>
Transfers control to a subroutine.</p>

Decode the relative_offset</code> from the immediate data at PC</code>.</li>
Push the current PC + 3</code> to the return stack</code>.</li>
Set PC</code> to PC + relative_offset</code>.</li>
</ol>
The relative_offset</code> is relative to the current PC</code>. The offset is encoded as a two-byte, twos-complement signed integer, stored MSB-first.</p>
The gas cost is low</em>.</p>
RETURNSUB (0x5e)</code></h4>
Returns control to the caller of a subroutine.</p>

Pop the return stack</code> to PC</code>.</li>
</ol>
The gas cost is verylow</em>.</p>
Notes:</em></p>

Values popped off the return stack</code> do not need to be validated, since they are alterable only by RJUMPSUB</code> and RETURNSUB</code>.</em></li>
The description above lays out the semantics of these instructions in terms of a return stack</code>.  But the actual state of the return stack</code> is not observable by EVM code or consensus-critical to the protocol.  (For example, a node implementer may code RJUMPSUB</code> to unobservably push PC</code> on the return stack</code> rather than PC + 1</code>, which is allowed so long as RETURNSUB</code> observably returns control to the PC + 3</code> location.)</em></li>
</ul>
Validity</h3>
Execution</em> is defined in the Yellow Paper as a sequence of changes in the EVM state.  The conditions on valid code are preserved by state changes.  At runtime, if execution of an instruction would violate a condition the execution is in an exceptional halting state.  The Yellow Paper defines six such states.</p>

Insufficient gas</li>
More than 1024 stack items</li>
State modification during a static call</li>
Insufficient stack items</li>
Invalid jump destination</li>
Invalid instruction</li>
</ol>
We would like to consider EVM code valid iff no execution of the program can lead to an exceptional halting state.  In practice, we must test at runtime for the first three conditions.  We don’t know how much gas there will be, we don’t know how deep a recursion may go, analysis of stack depth even for non-recursive programs is nontrivial, and we don't know whether a call will be static.  All of the remaining conditions MUST be validated statically, in time and space quasi-linear in the size of the code.</p>
Static Constraints on Valid Code</h4>

Every instruction MUST be valid:

The JUMP</code> and JUMPI</code> instructions ARE NOT valid.</li>
</ul>
</li>
Every jump MUST be valid:

The RJUMP</code>, RJUMPI</code>, or RJUMPSUB</code> instructions MUST NOT address immediate data or addresses outside of their code section.</li>
</ul>
</li>
The stacks MUST be valid:

The number of items on the data stack</code> MUST always be positive.</li>
The number of items on the return stack </code>MUST always be positive.</li>
</ul>
</li>
The data stack MUST be consistently aligned:

The data stack height is

the absolute difference between the current stack pointer</code> and the stack pointer</code> on entry to the current subroutine.</li>
</ul>
</li>
It MUST be the same for every reachable path through a given PC</code> and</li>
MUST NOT exceed 1024.</li>
</ul>
</li>
</ul>
Rationale</h2>
This is a purely semantic specification, placing no constraints on the syntax of code sections beyond being a sequence of opcodes and immediate data – a subroutine is not a contiguous sequence of bytecode, it is a subgraph of the bytecode's control-flow graph.  The EVM is a simple state machine.  We only promise that valid code will not, as it were, jam up the gears of the machine.</p>
By avoiding syntactic constraints we allow for optimizations like tail call elimination, multiple-entry subroutines, moving "cold" code out of line, and other ways of reducing redundancy and keeping "hot" code in cache.   Since we wish to support one-pass compilation of EVM code to machine code it is crucial that the EVM code be as well optimized as possible up front.</p>
Validation</h3>
Rather than enforce constraints via syntax, we enforce them via validation.</p>
The constraints on valid code cover all of the exceptional halting states that we can validate and allow code to be validated and compiled in time and space quasi-linear in the size of the code.</p>
The RJUMP</code>, RJUMPI</code> and RJUMPSUB</code> instructions take their relative_offset</em> as immediate arguments, which cannot change at runtime.  Having constant destinations for all jumps means that all jump destinations can be validated at initialization time, not runtime.  Dynamic jumps can branch to any destination in the code, so exploitable quadratic "path explosions" are possible when traversing the control flow graph. Deprecating JUMP</code> and JUMPI</code> prevents this.</p>
Requiring a consistently aligned data stack</code></p>

prevents stack underflow</li>
ensures that all calls to a subroutine have the same number of inputs and the same number of outputs and</li>
ensures that stack height is bounded in the absence of recursion.</li>
</ul>
Requiring a consistently aligned data stack</code> also allows some algorithms that traverse the control-flow graph -- including code validation and compilation -- to break cycles at joins, again preventing quadratic path explosion.  When a traversal gets to a PC</code> it has visited before it is either at the beginning of a loop or the entry to a function.  Since the stack height at that PC</code> is constant we know that loops will not grow stack, and that the number of arguments to a subroutine will always be the same -- there may be no need to traverse that path again.</p>
Note: The JVM and Wasm enforce similar constraints for similar reasons.</em></p>
Alternative Designs</h3>
There are a few major designs for a subroutine facility, two of which are considered here.  The others are mostly not appropriate for the EVM, such as the Wheeler Jump -- self-modifying code that writes return addresses into called subroutines.</p>
1. Keep return addresses on a dedicated return stack.</em> Turing's design is often used by stack machines, including those for Forth, Java, Wasm, and others.  The data stack is used for computation, with a dedicated stack for return addresses.  A single instruction suffices to call, and another to return from a routine.</p>
2. Keep return addresses on the data stack.</em>  This design is often used by register machines, including those from CDC, IBM, DEC, Intel, and ARM.  The registers are used primarily for computation, and the stack maintains call frames for return addresses, arguments, and local variables.  On the EVM there are no registers for computation, so using the stack for both purposes can cause the sort of inefficiencies we see below.  Pascal p-code does use this design, but as part of a complex calling convention with dedicated registers.</p>
We prefer the dedicated return stack.</h4>

It maintains a clear separation between calculation and flow of control:

the data stack is free of vulnerable return addresses and</li>
it's impossible to overwrite the return stack.</li>
</ul>
</li>
It improves efficiency:

it uses native arithmetic rather than 256-bit EVM instructions for the return address,</li>
doesn't use up a data stack</code> slot for the return address and</li>
needs less motion of 256-bit data on the stack.</li>
</ul>
</li>
</ul>
Efficiency</h3>
We illustrate here how subroutine instructions can be used to reduce the complexity and gas costs of both ordinary and optimized subroutine calls compared to using JUMP</code>.</p>
Simple Subroutine Call</strong></h4>
Consider these examples of a fairly minimal subroutine, including the code to call it.</p>
Subroutine call, using RJUMPSUB</code>:</p>
SQUARE:</span></span>
    dup1            ; 3 gas</span></span>
    mul             ; 5 gas</span></span>
    returnsub       ; 3 gas</span></span>
</span>
CALL_SQUARE:</span></span>
    push 0x02       ; 3 gas</span></span>
    rjumpsub SQUARE ; 5 gas</span></span></code></pre>
Total gas: 19</em></p>
Subroutine call, using JUMP</code>:</p>
SQUARE:</span></span>
    jumpdest        ; 1 gas</span></span>
    swap1           ; 3 gas</span></span>
    dup1            ; 3 gas</span></span>
    mul             ; 5 gas</span></span>
    swap1           ; 3 gas</span></span>
    jump            ; 8 gas</span></span>
</span>
CALL_SQUARE:</span></span>
    jumpdest        ; 1 gas</span></span>
    push 0x02       ; 3 gas</span></span>
    push RTN_CALL:  ; 3 gas</span></span>
    push SQUARE     ; 3 gas</span></span>
    jump            ; 8 gas</span></span>
RTN_CALL:</span></span>
    jumpdest        ; 1 gas</span></span></code></pre>
Total: 41 gas</em>.</p>
Using RJUMPSUB</code> versus JUMP</code> saves 41 - 19 = 22 gas</em> — a 54%</em> improvement.</p>
Tail Call Optimization</strong></h4>
Of course in cases like this one we can optimize the tail call, so that the return from SQUARE</code> actually returns from TEST_SQUARE</code>.</p>
Tail call optimization, using RJUMPSUB</code> and RETURNSUB</code>:</p>
SQUARE:</span></span>
    dup1            ; 3 gas</span></span>
    mul             ; 5 gas</span></span>
    returnsub       ; 3 gas</span></span>
</span>
CALL_SQUARE:</span></span>
    push 0x02       ; 3 gas</span></span>
    rjump SQUARE    ; 3 gas</span></span></code></pre>
Total: 17 gas</em></p>
Tail call optimization, using JUMP</code>:</p>
SQUARE:</span></span>
    jumpdest        ; 1 gas</span></span>
    swap1           ; 3 gas</span></span>
    dup1            ; 3 gas</span></span>
    mul             ; 5 gas</span></span>
    swap2           ; 3 gas</span></span>
    jump            ; 8 gas</span></span>
</span>
CALL_SQUARE:</span></span>
    jumpdest        ; 1 gas</span></span>
    push 0x02       ; 3 gas</span></span>
    push SQUARE     ; 3 gas</span></span>
    jump            ; 8 gas</span></span></code></pre>
Total: 38 gas</em></p>
Using RJUMPSUB</code> versus JUMP</code> saves 38 - 17 = 21 gas</em> — a 55%</em> improvement.</p>
Efficiency Caveats</h4>
We can see that these instructions provide a simpler and more gas-efficient subroutine mechanism than using JUMP</code> — in our examples they cut gas use by about half.</p>
Clearly, the benefits of this efficiency are greater for programs that have been factored into smaller subroutines.  How small?  Wrapping code in a subroutine costs only 8 gas</em> using RJUMPSUB</code> and RETURNSUB</code> versus 30 gas</em> using JUMP</code>, PUSH</code> and SWAP</code> as above.</p>
Costs</h3>
The low</em> cost of RJUMPSUB</code> versus the mid</em> cost of JUMP</code> is justified by needing only to decode the immediate two byte destination to the PC</code> and push the return address on the return stack</code>, all using native arithmetic, versus using the data stack with emulated 256-bit instructions.</p>
The verylow</em> cost of RETURNSUB</code> is justified by needing only to pop the return stack</code> into the PC</code>.  Benchmarking will be needed to tell if the costs are well-balanced.</p>
Backwards Compatibility</h2>
These changes affect the semantics of existing EVM code: bytes that would have been interpreted as valid jump destinations may now be interpreted as immediate data.  Since this proposal depends on the Ethereum Object Format to signal the change this is not a practical issue.</p>
Test Cases</h2>
Simple routine</h3>
This should jump into a subroutine, back out and stop.</p>
Bytecode: 0x5f0003005e</code> (RJUMPSUB 3, RETURNSUB, STOP</code>)</p>
Pc</th> Op</th> Cost</th> Stack</th> RStack</th></tr></thead>

0</td> RJUMPSUB</td> 5</td> []</td> []</td></tr>
2</td> STOP</td> 0</td> []</td> []</td></tr>
3</td> RETURNSUB</td> 3</td> []</td> []</td></tr>
</tbody></table>
Output: 0x
Consumed gas: 10</code></p>
Two levels of subroutines</h3>
This should execute fine, going into one two depths of subroutines</p>
Bytecode: 0x5f00045F00025200</code> (RJUMPSUB 4, RJUMPSUB 2, RETURNSUB, RETURNSUB, STOP</code>)</p>
Pc</th> Op</th> Cost</th> Stack</th> RStack</th></tr></thead>

0</td> RJUMPSUB</td> 5</td> []</td> []</td></tr>
3</td> RJUMPSUB</td> 5</td> []</td> []</td></tr>
4</td> RETURNSUB</td> 5</td> []</td> []</td></tr>
5</td> RETURNSUB</td> 5</td> []</td> []</td></tr>
6</td> STOP</td> 0</td> []</td> []</td></tr>
</tbody></table>
Consumed gas: 20</code></p>
Failure 1: invalid jump</h3>
This should fail, since the given location is outside of the code-range.</p>
Bytecode: 0X5fff</code>(RJUMPSUB -1</code>)</p>
Pc</th> Op</th> Cost</th> Stack</th> RStack</th></tr></thead>

0</td> RJUMPSUB</td> 10</td> []</td> []</td></tr>
</tbody></table>
Error: at pc=0, op=RJUMPSUB: invalid jump destination</span></span></code></pre>Failure 2: shallow return stack</code></h3>
This should fail at first opcode, due to shallow return_stack</code></p>
Bytecode: 0x5e</code> (RETURNSUB</code>)</p>
Pc</th> Op</th> Cost</th> Stack</th> RStack</th></tr></thead>

0</td> RETURNSUB</td> 5</td> []</td> []</td></tr>
</tbody></table>
Error: at pc=0, op=RETURNSUB: invalid retsub</span></span></code></pre>Subroutine at end of code</h3>
In this example the RJUMPSUB is on the last byte of code. When the subroutine returns, it should hit the 'virtual stop' after</em> the bytecode, and not exit with error</p>
Bytecode: 0x5c00045e5fffff</code> (RJUMP 4, RETURNSUB, RJUMPSUB -1</code>)</p>
Pc</th> Op</th> Cost</th> Stack</th> RStack</th></tr></thead>

0</td> RJUMP</td> 5</td> []</td> []</td></tr>
3</td> RETURNSUB</td> 5</td> []</td> []</td></tr>
4</td> RJUMPSUB</td> 5</td> []</td> []</td></tr>
7</td> STOP</td> 0</td> []</td> []</td></tr>
</tbody></table>
Consumed gas: 15</code></p>
Reference Implementation</h2>
The following is a pseudo-Python implementation of an algorithm for predicating code validity.  An equivalent algorithm must be run at initialization time.</p>
This algorithm performs a symbolic execution of the program that recursively traverses the code</em>, emulating its control flow and stack use and checking for violations of the rules above.</p>
It runs in time equal to O(vertices + edges)</code> in the program's control-flow graph, where edges represent control flow and the vertices represent basic blocks</em> — thus the algorithm takes time proportional to the size of the code</em>. It maintains a stack of continuations for conditional jumps, the size of which is at most proportional to the size of the code</em>.</p>
Validation Function</h3>
** Note: this function is known to be incomplete and incorrect. **</p>
For simplicity's sake we assume that all jumpdest analysis and prior validation has been done, including EIP-3540, EIP-3670, and EIP-4200, so EOF headers and sections are well-formed, and there are no invalid instructions or jumps.  In practice, all passes of validation can be folded into a single loop no recursion.</p>
We also assume some helper functions.</p>

is_valid(opcode)</code> returns true iff opcode is valid.</li>
is_terminator(opcode)</code> returns true iff opcode is terminator.</li>
is_valid_jumpdest(pc)</code> returns true iff pc</code> is a valid jump destination.</li>
immediate_data(pc)</code> returns the immediate data for the instruction at pc</code>.</li>
immediate_size(opcode)</code> returns the size of the immediate data for an opcode.</li>
removed_items(opcode)</code> returns the number of items removed from the data_stack</code> by the opcode</code>.</li>
added_items(opcode)</code> returns the number of items added to the data_stack</code> by the opcode</code>.</li>
</ul>
# returns true iff code is valid</span></span>
def validate_code(code: bytes, pc: int, sp: int, bp: int) -> boolean:</span></span>
    continuations = []</span></span>
    do</span></span>
        while pc < len(code):</span></span>
            opcode = code[pc]</span></span>
            if !is_valid(opcode):</span></span>
                return false</span></span>
            if is_terminator(opcode):</span></span>
                return true</span></span>
</span>
            # check stack height and return if we have been here before</span></span>
            stack_height = sp - bp</span></span>
            if stack_height > 1024</span></span>
                return false</span></span>
            if pos in stack_heights:</span></span>
                if stack_height != stack_heights[pos]:</span></span>
                    return false</span></span>
                return true</span></span>
            else:</span></span>
                stack_heights[pos] = stack_height</span></span>
</span>
            if opcode == RJUMP:</span></span>
</span>
                # reset pc to destination of jump</span></span>
                jumpdest = immediate_data(pc)</span></span>
                pc += jumpdest</span></span>
                if !is_valid_jumpdest(pc)</span></span>
                    return false</span></span>
</span>
            elif opcode == RJUMPI:</span></span>
</span>
                jumpdest = pc + immediate_data(pc)</span></span>
                if !is_valid_jumpdest(pc)</span></span>
                    return false</span></span>
</span>
                # continue true side of conditional later</span></span>
                continations.push((jumpdest, sp, bp))</span></span>
</span>
                # continue false side of conditional now</span></span>
</span>
            elif opcode == RJUMPSUB:</span></span>
</span>
                # will enter subroutine at destination</span></span>
                bp = sp</span></span>
</span>
                # push return address and reset pc to destination</span></span>
                jumpdest = pc + immediate_data(pc)</span></span>
                if !is_valid_jumpdest(pc)</span></span>
                    return false</span></span>
                push(return_stack, pc + 3)</span></span>
                pc = jumpdest</span></span>
                continue</span></span>
</span>
            elif opcode == RETURNSUB:</span></span>
</span>
                # will return to subroutine at destination</span></span>
                bp = sp</span></span>
</span>
                # pop return address and check for preceding call</span></span>
                pc = pop(return_stack)</span></span>
                if code[pc - 3] != RJUMPSUB:</span></span>
                   return false</span></span>
</span>
            # apply instructions to stack</span></span>
            sp -= removed_items(opcode)</span></span>
            if sp < 0</span></span>
                return false</span></span>
            sp += added_items(opcode)</span></span>
</span>
            # Skip opcode and immediate data</span></span>
            pc += 1 + immediate_size(opcode)</span></span>
</span>
        while (pc, sp, bp) = continuations.pop()</span></span>
</span>
    return true</span></span></code></pre>Security Considerations</h2>
These changes introduce new flow control instructions.  They do not introduce any new security considerations. This EIP is intended to improve security by validating a higher level of safety for EVM code deployed on the blockchain.  The validation algorithm must be quasi-linear in time and space to not be a denial of service vulnerability.  The algorithm here makes one linear-time pass of the bytecode, and uses a stack of continuations that cannot exceed the number of RJUMPI</code> instructions in the code.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


"Hardfork Meta: Berlin"
2019-05-20T00:00:00+00:00
Abstract</h2>
This meta-EIP specifies the changes included in the Ethereum hardfork named Berlin.</p>
Specification</h2>

Codename: Berlin</li>
</ul>
In the current stage of coordination, the changes are tracked and discussed in the eth1.0-specs</a> repository.
For an accurate status please refer to the berlin.md</code></a> file.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Block Rewards Proposal for funding Eth1.x
2019-04-20T00:00:00+00:00
Simple Summary</h2>
Add 0.0055 ETH</code> per block for 18 months (A total of 17050 ETH) as a developer block reward reserved for funding specific Ethereum1.X working groups. The working groups are State rent (750k), Better sync (360k), Finality gadget (360k), Fee market (360k), Testing infrastructure (360k). Governance of the funds will be through a multisig of trusted individuals from the ecosystem including client teams, the foundation, and the community.</p>
EIP-1890</a> proposes a mechanism to capture a portion of block rewards for sustainably funding ongoing network development. That EIP sets values and addresses to zero and so does not actually collect any rewards. This proposal is to explicitly set those values and begin collecting a portion of block rewards for 18 months in order to fund Ethereum 1.X working groups and organization efforts. This funding will be used to repay an initial loan provided by investors in the community funding this work with a small amount of interest. After 18 months the block reward would again reduce to zero.</p>
Abstract</h2>
This EIP extends the mechanism established in EIP-1890 to add 0.0055 ETH</code> to the block reward for a specific distribution period of 3,100,000 BLOCKS</code>(≈ 18 months). The RECIPIENT_ADDRESS</code> is set to a smart contract with hardcoded denominations that distributes incoming ETH to a set of addresses for the purpose of Eth1.X development. The emission schedule would start at the hard fork block number and continue for 3,100,000 BLOCKS</code> (≈ 18 months) at which point the address and amount would again return to 0. Any further distribution would require a future hard fork.</p>
Motivation</h2>
The context for this proposal came from attending the Core Dev Eth1.X Meeting</a> in Berlin. Development is needed to move Eth1.X forward, and I observed that a lack of funding is the primary barrier to this work. This work can only be effectively conducted by working groups forming around these issues, and these working groups need funding in order to pay dedicated contractors and project managers. This proposal is a plan for funding these groups and supporting their operation.</p>
Specification</h2>
Two constants will be introduced:</p>

REWARD_DURATION_IN_BLOCKS</code>, which specifies the number of blocks after ISTANBUL_BLOCK_HEIGHT</code> when the reward collection will terminate (i.e., at block ISTANBUL_BLOCK_HEIGHT + REWARD_DURATION_IN_BLOCKS</code>)</li>
BENEFICIARY_ADDRESSES</code>, a list of tuples containing the address and the amount to be transferred to this address per block. These amounts will be determined as the loan is collected from participating organizations and the addresses for repayment will be specified by them. The total of the amounts will sum to 0.0055. At the end of REWARD_DURATION_IN_BLOCKS</code> the loan will be completely repaid.</li>
</ul>
</span>
REWARD_DURATION_IN_BLOCKS = 3100000</span></span>
DEVFUND_BLOCK_REWARD = 0.0055</span></span>
</span>
</span>
</span>
BENEFICIARY_ADDRESSES = [</span></span>
 (<address>, <amount_in_eth>),</span></span>
 (<address>, <amount_in_eth>)</span></span>
]</span></span></code></pre>
Beginning with block ISTANBUL_BLOCK_HEIGHT</code>, the reward is added to the participating addresses within BENEFICIARY_ADDRESSES</code> at each block until the end of the REWARD_DURATION_IN_BLOCKS</code>.</p>
IF (CURRENT_BLOCK - ISTANBUL_BLOCK_HEIGHT <= REWARD_DURATION_IN_BLOCKS)</span></span>
</span>
FOR BENEFICIARY in BENEFICIARY_ADDRESSES:</span></span>
  BENEFICIARY[0].balance += BENEFICIARY[1]</span></span>
</span></code></pre>Rewards Distribution Rationale</h2>
 Development loan repayment: 0.005 ETH per block: 15500 ETH total</span></span>
 Development loan interest (10% total over the period, simple interest): 0.0005 ETH per block: 1550 ETH total</span></span>
</span>
 Total Block Reward Increase = `0.0055` ETH per block: 17050 ETH Total</span></span></code></pre>
With a price of Ethereum at $150.00 this will raise approx USD $2,325,000.00 for developing Eth1.X over the next 18 months.</em></p>
 *Specific Addresses to be determined</p>

FAQ - Why hardcoded values?</a></li>
</ul>
Rationale</h2>
There has been great public debate concerning EIP-1890, and one of the primary concerns is that it is difficult to evaluate the proposal without more complete information on how funds would be raised, how they would be administered, and how they would be used. There is a need for funding Eth1.x development and it is currently unclear where those funds will come from. This proposal is intended to give a more comprehensive proposal for its funding. In the case that ETH1.x is fully funded before the Istanbul upgrade I will withdraw this EIP. Until that point I intend to continue championing this proposal as a valid funding mechanism for this work.</p>
Why a loan?</h3>
The Eth1x initiative needs funding now, not in 18 months. A loan is necessary to complete certain stages of work before the funding mechanism begins to provide funds. A loan would provide this necessary funding today, and the investors willing to front this cost can recoup their contribution + a reward of a fixed interest rate</em> for the risk on their loan. This arrangement will make it easier to find investors willing to participate who have sufficient funds.</p>
Loan Repayment</h3>
</p>
There is a risk that the investors lose part of their contribution in the case that this EIP is rejected by the community between the time the funds have been collected and the beginning of the payout schedule. In this case all remaining funds will be returned to the contributors. The interest on the loan is an incentive for investors to participate in spite of this risk. Their downside is limited to the amount of funds spent before this EIP is accepted or rejected, which should be no more than about 5%, while their upside consists of the 10% simple interest paid over the period.</p>
Development Loan</h3>
Development Loan: 0.005</code> over 3.1 Million blocks = 15500 ETH</p>
Funding Working Groups on 1.X</strong></p>

Funding Contractors, Coordinators, and project managers</li>
Working Groups defined with clear mandates</li>
</ul>
Budget</p>
Working groups</p>

State rent (750k)</li>
Better sync (360k)</li>
finality gadget (360k)</li>
Fee market (360k)</li>
testing infrastructure (360k)</li>
</ul>
ETH1.X Core Dev Gatherings</strong></p>
Funding hosting, traveling, and accommodations for necessary in-person gatherings of ETH1.X core developers similar to the Stanford and Berlin ETH1.X Core Dev Meeting held earlier this year.</p>
At the end of the 18 Months, the whole process would be torn down to prevent any internal tyranny of structurelessness forming within.</p>

FAQ - How will the funding of the devs be organized?</a></li>
</ul>
Accountability</h2>
The funds will be transferred into DAI and secured in a multi-sig comprised of members of the community. Representatives from the following groups will receive a key.</p>

EIP Editors</li>
Geth</li>
Parity</li>
ConsenSys/PegaSys (PegaSys)</li>
The Ethereum Foundation (Hudson Jameson)</li>
Community</li>
</ul>
Personal Notes and Disclosure</h2>
I want to address any concerns about conflicts of interests directly. My participation with Eth1.X currently has been as a volunteer. I am in talks about a possible funded role helping with testing and coordination. If my work for with Eth1.x is funded, I will accept no additional funding collected by the mechanism proposed in this EIP.</p>
Eth1.X is the now of Ethereum and I would like to see it succeed. This is the intent of my proposal.</p>
COI</h3>
Previously I was PM for Tennagraph, a signalling solution for Ethereum. An Aragon grant funded this project and was distributed through Giveth and an AragonDAO. I have not received any funding from the project beyond this grant. All of this is verifiable on-chain. I am stepping down from any paid role on the project to continue as an advisor. I am also stepping down as a moderator for stances as there is a COI moderating stances for EIPs I am working with directly.</p>
Disclaimer</h3>
I do not claim to represent the community with my views; any members who wish to join supporting me with this proposal are free to do so. This is as fair of a proposal as I can personally conceive.</p>
Backwards Compatibility</h2>
This EIP has no impact on backwards compatibility.</p>
Test Cases</h2>
Not Implemented</p>
Implementation</h2>
Not Implemented</p>
FAQ</h2>
Why Hardcoded Values?</h3>
Why not use a smart contract with some governance mechanism to allow changing the distribution of funds? Wouldn’t that be more flexible and effective?</p>
TLDR: This EIP is not about governance reform</em></p>
First, the payment of the loan will be hardcoded. Once agreed, the terms must be kept to give the lenders confidence in the repayment of the loan. As long as blocks are created the debt will be paid back. This is the essence of a trustless smart contract.</p>
After the loan, there is the option to allow the amounts (limited to less than .05ETH), and the locations (orgs that receive ecosystem funding) to be changed throughout the emission schedule. It is pretty easy to imagine a smart contract or DAO fulfilling this role. However, there are three classes of options available today we can consider when governing changes.</p>

Give the Keys to the Hands of the Few (Oligarchy)</strong></li>
</ul>
Create a multisig that allows a group of individuals to update the smart contract. The most likely candidates for this are the Core Devs themselves, but it could also be a trusted few from the community/stakeholders. No matter how you slice it, there is a fundamental issue in deciding who gets to decide. There currently is not a trusted/adopted governance mechanism to make these decisions within the Ethereum ecosystem. Also, preventing changing the contract in self interest is difficult without a well-engineered governance system of checks and balances. This EIP does not claim nor aim to solve these issues.</p>

Give the Keys to the Hands of the Many (Plutarchy)</strong></li>
</ul>
Allow ethereum holders with coin votes to update the smart contract. Using holographic consensus could overcome the issue of voter turnout as it scales as participation scales, even to the size of the whole network. This has some benefits as the entire network can participate. However, the problem is that some individuals in the network are over represented -- the wealthy. Without a solution to identity that has been agreed to and implemented by the entire Ethereum Network, there is no way around giving more power in votes to the rich. This EIP does not claim, nor aim to solve these issues.</p>

Use Ethereum Governance as it is Today</strong></li>
</ul>
Criticisms or support aside, there is a system that governs Ethereum today. It is a mix of rough consensus among core devs, miners running nodes, clients implementing changes, and stakeholders adopting those changes. It includes yelling or not yelling on twitter and reddit. It is complicated and I don’t claim to understand it. Even without a clear view of how it works, there is evidence of its existence. This evidence is there are changes that have allowed to be implemented, and changes that have not allowed to be implemented in Ethereum.</p>
I do not aim to change Ethereum governance. Because this EIP has hardcoded values, it must go through the existing governance process, whatever that is, before it is implemented. It will then continue to operate until the end of the emission schedule. This is intentional. This makes it uncapturable. No party other then the ecosystem itself can modify the contract once it has been deployed.</p>
This EIP is not about governance reform.</p>
Why not allow current client implementors fund this work? (EF, Consensys, Parity, etc...)</h3>
Historically there has been a precedent that the Ethereum Foundation is solely responsible for funding the development of Ethereum. This process has evolved as the development has become more distributed. Aya Miyaguchi observed in a recent Coindesk article</a>, “it really is not only Ethereum Foundation people who are building [Ethereum]”. Yes, we could rely on the Ethereum Foundation to fund Eth1.X. But, why should we? This is a call for the network to come together and fund its own development. Ethereum the network</em> is not owned by any one organization or group of people. We are lucky to have the EF and I consider this EIP in support of their coordination efforts.</p>
How Will Funding the Devs be Organized</h3>
I do not profess to know the best way to organize these funds. There is work already in progress to organize these efforts championed by Alexey Akhunov. The following is a quote from a recent medium article</a>:</p>

“Going from funding a few implementation teams continuously and letting them do 'their stuff' to funding more specific and temporary initiatives requires looking at funding through different lenses. How much 'due diligence' and oversight is too much (in terms of overhead), who can decide whether working groups actually deliver, etc. This is also solvable, and also more on this will come later (not in this post)."</p>
</blockquote>
My suggestion would be to create an Eth1.X core developer DAO using DaoStack</a> to coordinate membership and payment of the Core Devs, but ultimately they are capable of determining the system that works best for them. As long as the system is transparent and mature enough to distribute funds when the time comes, this is sufficient for now.</p>
Isn't a loan considered a security, or is it?</h3>
I am not a lawyer and will seek further guidance from lawyers in the field on this point in particular. From the research I have done and conversations I have had there is a very good argument that a loan of this nature will not be considered a security by the US Supreme Court.
As the result of REVES ET AL. v . ERNST YOUNG 1990</a>, the court stated that a home loan, consumer financing, a loan secured by a lien on a small business or some assets of a small business, short term notes, or notes that formalize a debt incurred in the ordinary course of business are not securities. If the note resembles the items listed above (home loans, etc.) then the note will not be deemed a security. The Supreme Court provided four factors to determine if a note sufficiently resembles the types of notes that are not classified as securities. (source</a>)</p>
Family Resemblance Test</strong></p>

The intentions of the company and the individual—if the company raised money for general use in a business enterprise, then the note is more likely to be a security; if the individual agreed to the loan primarily for the profit the note was expected to generate, the note is more likely to be a security.</li>
The plan of distribution—the more widely the note is offered, the more likely it is to be found a security.</li>
The expectations of the investing public—if the investors thought they were investing in a business to make a profit on their investment, the note is more likely to be found a security.</li>
Other risk-reducing factor—if the note is collateralized or otherwise less risky than common notes, the note is less likely to be found to be a security.</li>
</ol>
The loan is for the specific use of supporting Eth1.X research and development. The distribution will not be widely offered and the note will be collateralized by the network itself, provided in ETH and repaid in ETH. In coordinating the collection of these funds recognise I may be legally liable for some of this work and I will do all of the due dilegence I can, seek legal counsel, and accept any legal repercussions resulting from this work.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Commitment to Sustainable Ecosystem Funding
2019-03-31T00:00:00+00:00
Commitment to Sustainable Ecosystem Funding</h1>
Simple Summary</h2>
Ethereum currently provides a block reward to proof of work miners every block, but it does not capture any block rewards for ecosystem funding. This EIP adds a simple mechanism for capturing a portion of block rewards for ecosystem funding as a credible commitment to doing so in future, but it does not actually capture any such rewards.</p>
Abstract</h2>
A mechanism that allows specification of two parameters, a beneficiary address and a per-block reward denominated in wei, that allows a portion of block rewards to be captured for the purpose of ecosystem funding. Both values are set to zero.</p>
Motivation</h2>
In order for Ethereum to succeed, it needs talented, motivated researchers and developers to continue to develop and maintain the platform. Those talented researchers and developers deserve to be paid fairly for their work. At present there is no mechanism in the Ethereum ecosystem that rewards R&D teams fairly for their work on the platform.</p>
We recognize that, while technically trivial, the real challenge in inflation-based funding is social: how to fairly capture, govern, and distribute block rewards. It will take time to work out the answer to these questions. For this reason, this EIP only seeks to make a credible commitment on the part of core developers to securing the funding they need to keep Ethereum alive and healthy by adding a mechanism to do so, but the actual amount of rewards captured remains at zero, i.e., there is no change at present to Ethereum’s economics. Raising the amount captured above zero would require a future EIP.</p>
Specification</h2>
Two new constants are introduced: BENEFICIARY_ADDRESS, an Address, and DEVFUND_BLOCK_REWARD, an amount denominated in wei. Both are set to zero.</p>
Beginning with block ISTANBUL_BLOCK_HEIGHT, DEVFUND_BLOCK_REWARD wei is added to the balance of BENEFICIARY_ADDRESS at each block.</p>
We may optionally add another constant, DECAY_FACTOR, which specifies a linear or exponenential decay factor that reduces the reward at every block > ISTANBUL_BLOCK_HEIGHT until it decays to zero. For simplicity, it has been omitted from this proposal.</p>
Rationale</h2>
We believe that the technical design of this EIP is straightforward. The social rationale is explained in this article</a>.</p>
Backwards Compatibility</h2>
This EIP has no impact on backwards compatibility.</p>
Test Cases</h2>
This EIP makes no changes to existing state transitions. Existing consensus tests should be sufficient.</p>
Implementation</h2>
Reference implementations are included for the Trinity, go-ethereum, and parity clients.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Disable SSTORE with gasleft lower than call stipend
2019-01-15T00:00:00+00:00
Simple Summary</h2>
The proposal that had been accepted changes security properties of a large portion of an existing contract code base that may be infeasible to update and validate. This proposal will make the old assumptions hold even after a network upgrade.</p>
Abstract</h2>
EIP-1283</a> significantly lowers the gas costs of writing to contract's storage. This created a danger of a new kind of reentrancy attacks on existing contracts as Solidity by default grants a 'stipend' of 2300 gas to simple transfer calls.
This danger is easily mitigated if SSTORE is not allowed in low gasleft state, without breaking the backward compatibility and the original intention of this EIP.</p>
Motivation</h2>
An attack that is described in this article</a>.
Explicitly specifying the call stipend as an invariant will have a positive effect on Ethereum protocol security:
https://www.reddit.com/r/ethereum/comments/agdqsm/security_alert_ethereum_constantinople/ee5uvjt</p>
Specification</h2>
Add the following condition to the SSTORE opcode gas cost calculation:</p>

If gasleft</em> is less than or equal to 2300, fail the current call frame
with 'out of gas' exception.</li>
</ul>
Rationale</h2>
In order to keep in place the implicit reentrancy protection of existing contracts, transactions should not be allowed to modify state if the remaining gas is lower then the 2300 stipend given to 'transfer'/'send' in Solidity.
These are other proposed remediations and objections to implementing them:</p>

Drop EIP-1283 and abstain from modifying SSTORE cost

EIP-1283 is an important update</li>
It was accepted and implemented on test networks and in clients.</li>
</ul>
</li>
Add a new call context that permits LOG opcodes but not changes to state.

Adds another call type beyond existing regular/staticcall</li>
</ul>
</li>
Raise the cost of SSTORE to dirty slots to >=2300 gas

Makes net gas metering much less useful.</li>
</ul>
</li>
Reduce the gas stipend

Makes the stipend almost useless.</li>
</ul>
</li>
Increase the cost of writes to dirty slots back to 5000 gas, but add 4800 gas to the refund counter

Still doesn’t make the invariant explicit.</li>
Requires callers to supply more gas, just to have it refunded</li>
</ul>
</li>
Add contract metadata specifying per-contract EVM version, and only apply SSTORE changes to contracts deployed with the new version.</li>
</ul>
Backwards Compatibility</h2>
Performing SSTORE has never been possible with less than 5000 gas, so it does not introduce incompatibility to the Ethereum mainnet. Gas estimation should account for this requirement.</p>
Test Cases</h2>
Test cases for an implementation are mandatory for EIPs that are affecting consensus changes. Other EIPs can choose to include links to test cases if applicable.
TODO</p>
Implementation</h2>
TODO</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Storage Rent
2018-11-10T00:00:00+00:00
Abstract</h2>
This EIP describes a scheme to charge for data in state, and 'archive' data which is no longer being paid for. It also describes how resurrection of 'archived' data happens.</p>
Motivation</h2>
The Ethereum blockchain in its current form is not sustainable because it grows
indefinitely. This is true of any blockchain, but Ethereum grows faster than most chains.
Many implementation strategies to slow down growth exist. A common strategy is 'state
pruning' which discards historical state, keeping only the active copy of contract data
and a few recent versions to deal with short-range chain reorganizations. Several
implementations also employ compression techniques to keep the active copy of the state as
small as possible.</p>
A full node participating in consensus today requires storing large amounts of data even
with advanced storage optimizations applied. Future storage requirements are unbounded
because any data stored in a contract must be retained forever as dictated by the
protocol. This EIP attempts to correct this by adding new consensus rules that put an
upper bound on the size of the Ethereum state.</p>
Adding these new rules changes fundamental guarantees of the system and requires a hard
fork. Users of Ethereum already pay for the creation and modification of accounts and
their storage entries. Under the rules introduced in this EIP, users must also pay to keep
accounts accessible. A similar rent scheme was proposed in EIP-103</a> but rejected
even back then because the proposal would've upset peoples expectations. As implementers
of Ethereum, we still feel that state rent is the right path to long-term sustainability
of the Ethereum blockchain and that its undesirable implications can be overcome with
off-protocol tooling and careful design.</p>
Specification</h2>
The cost of storing an account over time is called rent</code>. The amount of rent</code> due depends
on the size of the account. The ether</code> that is paid for rent</code> is destroyed. The rent</code> is deducted whenever an account is touched.</p>
rent</code> can be paid from the account's regular balance</code> or from its 'rent balance'. Accounts
can be endowed with rent balance</code> through a new EVM opcode. When rent</code> is charged, it is
first taken from the rent balance</code>. When rent balance</code> is zero, it is instead charged from the account's regular balance</code> instead.</p>
The reason to separate balance</code> and rent balance</code> is that certain contracts do not accept ether</code> sends, or always send the entire balance off to some other destination. For these cases, a separaterent balance</code> is required.</p>
When an account's balance</code> is insufficient to pay rent, the account becomes inactive</code>. Its
storage and contract code are removed. Inactive accounts cannot be interacted with, i.e.
it behaves as if it has no contract code.</p>
Inactive accounts can be restored by re-uploading their storage. To restore an inactive
account A</code>, a new account B</code> is created with arbitrary code and its storage modified
with SSTORE</code> operations until it matches the storage root of A</code>. Account B</code> can restore
A</code> through the RESTORETO</code> opcode. This means the cost of restoring an account is
equivalent to recreating it via successive SSTORE</code> operations.</p>
Changes To State</h3>
At the top level, a new key size</code> is added to the accounts trie. This key tracks the
total number of trie nodes across all accounts, including storage trie nodes. To track
rent, the structure of account entries is changed as well.</p>
Before processing the block in which this EIP becomes active, clients iterate the whole
state once to count the number of trie nodes and to change the representation of all
accounts to the new format.</p>
Account Representation</h4>
account = [nonce, balance, storageroot, codehash, rentbalance, rentblock, storagesize]</span></span></code></pre>
Each account gets three additional properties: rentbalance</code>, rentblock</code> and
storagesize</code>.</p>
The rentbalace</code> field tracks the amount of rent balance</code> available to the account. Upon
self-destruction any remaining rent balance</code> is transferred to the beneficiary. Any
modification of the account recomputes its current rent balance</code>.</p>
The rentblock</code> field tracks the block number in which the rent balance</code> was last
recomputed. Upon creation, this field is initialized with the current block number.
rentblock</code> is also updated with the current block number whenever the account is
modified.</p>
The storagesize</code> field tracks the amount of storage related to the account. It is a
number containing the number of storage slots currently set. The storagesize</code> of an
inactive account is zero.</p>
Charging Rent</h3>
There is a new protocol constant MAX_STORAGE_SIZE</code> that specifies the upper bound on the
number of state tree nodes:</p>
MAX_STORAGE_SIZE</span> =</span> 2</span>**</span>32</span> #</span> ~160GB of state</span></span></code></pre>
A 'storage fee factor' for each block is derived from this constant such that fees
increase as the limit is approached.</p>
def</span> storagefee_factor</span>(</span>block</span>)</span>:</span></span>
    ramp</span> =</span> MAX_STORAGE_SIZE</span> /</span> (</span>MAX_STORAGE_SIZE</span> -</span> total_storage_size</span>(</span>block</span>)</span>)</span></span>
    return</span> 2</span>**</span>22</span> *</span> ramp</span></span></code></pre>
When a block is processed, rent</code> is deducted from all accounts modified by transactions in
the block after the transactions have been processed. The amount due for each account is
based on the account's storage size.</p>
def</span> rent</span>(</span>prestate</span>,</span> poststate</span>,</span> addr</span>,</span> currentblock</span>)</span>:</span></span>
    fee</span> =</span> 0</span></span>
    for</span> b</span> in</span> range</span>(</span>prestate</span>[</span>addr</span>]</span>.</span>rentblock</span>+</span>1</span>,</span> currentblock</span>-</span>1</span>)</span>:</span></span>
        fee</span> +=</span> storagefee_factor</span>(</span>b</span>)</span> *</span> prestate</span>[</span>addr</span>]</span>.</span>storagesize</span></span>
    return</span> fee</span> +</span> storagefee_factor</span>(</span>currentblock</span>)</span> *</span> poststate</span>[</span>addr</span>]</span>.</span>storagesize</span></span>
</span>
def</span> charge_rent</span>(</span>prestate</span>,</span> poststate</span>,</span> addr</span>,</span> currentblock</span>)</span>:</span></span>
    fee</span> =</span> rent</span>(</span>prestate</span>,</span> poststate</span>,</span> addr</span>,</span> currentblock</span>)</span></span>
    if</span> fee</span> <=</span> poststate</span>[</span>addr</span>]</span>.</span>rentbalance</span>:</span></span>
        poststate</span>[</span>addr</span>]</span>.</span>rentbalance</span> -=</span> fee</span></span>
    else</span>:</span></span>
        fee</span> -=</span> poststate</span>[</span>addr</span>]</span>.</span>rentbalance</span></span>
        poststate</span>[</span>addr</span>]</span>.</span>rentbalance</span> =</span> 0</span></span>
        poststate</span>[</span>addr</span>]</span>.</span>balance</span> -=</span> min</span>(</span>poststate</span>[</span>addr</span>]</span>.</span>balance</span>,</span> fee</span>)</span></span>
    poststate</span>[</span>addr</span>]</span>.</span>rentblock</span> =</span> currentblock</span></span></code></pre>New EVM Opcodes</h3>
PAYRENT <amount> <addr></code></h4>
At any time, the rent balance</code> of an account may be topped up by the PAYRENT</code> opcode.
PAYRENT</code> deducts the given amount of ether</code> from the account executing the opcode and adds
it to the rent balance</code> of the address specified as beneficiary.</p>
Any participant can pay the rent for any other participant.</p>
Gas cost: TBD</p>
RENTBALANCE <addr></code></h4>
The rent balance</code> of an account may be queried through the RENTBALANCE</code> opcode. It pushes the
rentbalance</code> field of the given address to the stack.</p>
Gas cost: like EXTCODEHASH</code>.</p>
SSIZE <addr></code></h4>
This opcode pushes the storagesize</code> field of the given account to the stack.</p>
Gas cost: like EXTCODEHASH</code>.</p>
RESTORETO <addr> <codeaddr></code></h4>
This opcode restores the inactive account at the given address. This is a bit like
SELFDESTRUCT</code> but has more specific semantics.</p>
The account at addr</code> must be inactive</code> (i.e. have storagesize</code> zero) and its
storageroot</code> must match the storageroot</code> of the contract executing RESTORETO</code>. The
codeaddr</code> specifies the address of a contract from which code is taken. The code of the
codeaddr</code> account must match the codehash</code> of addr</code>.</p>
If all these preconditions are met, RESTORETO</code> transfers the storage of the account
executing the opcode to addr</code> and resets its storagesize</code> to the full size of the
storage. The code of addr</code> is restored as well. RESTORETO</code> also transfers any remaining
balance and rent balance to addr</code>. The contract executing RESTORETO</code> is deleted.</p>
Gas cost: TBD</p>
Rationale</h2>
Why do we need a separate rent balance?</h3>
Accounts need a separate rent balance because some contracts are non-payable, i.e. they
reject regular value transfers. Such contracts might not be able to keep themselves alive,
but users of those contracts can keep them alive by paying rent for them.</p>
Having the additional balance also makes things easier for contracts that hold balance on
behalf of a user. Consider the canonical crowdfunding example, a contract which changes
behavior once a certain balance is reached and which tracks individual user's balances.
Deducting rent from the main balance of the contract would mess up the contract's
accounting, leaving it unable to pay back users accurately if the threshold balance isn't
reached.</p>
Why restoration?</h3>
One of the fundamental guarantees provided by Ethereum is that changes to contract storage
can only be made by the contract itself and storage will persist forever. If you hold a
token balance in a contract, you'll have those tokens forever. By adding restoration, we
can maintain this guarantee to a certain extent.</p>
Implementation Impact</h3>
The proposed changes tries to fit within the existing state transition model. Note that
there is no mechanism for deactivating accounts the moment they can't pay rent. Users must
touch accounts to ensure their storage is removed because we'd need to track all accounts
and their rent requirements in an auxlilary data structure otherwise.</p>
Backwards Compatibility</h2>
TBA</p>
Test Cases</h2>
TBA</p>
Implementation</h2>
TBA</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Transparent Contract Standard
2018-10-31T00:00:00+00:00
Replaced by EIP-2535 Diamond Standard</a>.</p>
Simple Summary</h2>
This standard provides a contract architecture that makes upgradeable contracts flexible, unlimited in size, and transparent.</p>
A transparent contract publicly documents the full history of all changes made to it.</p>
All changes to a transparent contract are reported in a standard format.</p>
Abstract</h2>
A transparent contract is a proxy contract design pattern that provides the following:</p>

A way to add, replace and remove multiple functions of a contract atomically (at the same time).</li>
Standard events to show what functions are added, replaced and removed from a contract, and why the changes are made.</li>
A standard way to query a contract to discover and retrieve information about all functions exposed by it.</li>
Solves the 24KB maximum contract size limitation, making the maximum contract size of a transparent contract practically unlimited. This standard makes the worry about contract size a thing of the past.</li>
Enables an upgradeable contract to become immutable in the future if desired.</li>
</ol>
Motivation</h2>
A fundamental benefit of Ethereum contracts is that their code is immutable, thereby acquiring trust by trustlessness. People do not have to trust others if it is not possible for a contract to be changed.</p>
However, a fundamental problem with trustless contracts that cannot be changed is that they cannot be changed.</p>
Bugs</h4>
Bugs and security vulnerabilities are unwittingly written into immutable contracts that ruin them.</p>
Improvements</h4>
Immutable, trustless contracts cannot be improved, resulting in increasingly inferior contracts over time.</p>
Contract standards evolve, new ones come out. People, groups and organizations learn over time what people want and what is better and what should be built next. Contracts that cannot be improved not only hold back the authors that create them, but everybody who uses them.</p>
Upgradeable Contracts vs. Centralized Private Database</h4>
Why have an upgradeable contract instead of a centralized, private, mutable database?
Here are some reasons:</p>

Because of the openness of storage data and verified code, it is possible to show a provable history of trustworthiness.</li>
Because of the openness, bad behavior can be spotted and reported when it happens.</li>
Independent security and domain experts can review the change history of contracts and vouch for their history of trustworthiness.</li>
It is possible for an upgradeable contract to become immutable and trustless.</li>
An upgradeable contract can have parts of it that are not upgradeable and so are partially immutable and trustless.</li>
</ol>
Immutability</h4>
In some cases immutable, trustless contracts are the right fit. This is the case when a contract is only needed for a short time or it is known ahead of time that there will never be any reason to change or improve it.</p>
Middle Ground</h3>
Transparent contracts provide a middle ground between immutable trustless contracts that can't be improved and upgradeable contracts that can't be trusted.</p>
Purposes</h3>

Create upgradeable contracts that earn trust by showing a provable history of trustworthiness.</li>
Document the development of contracts so their development and change is provably public and can be understood.</li>
Create upgradeable contracts that can become immutable in the future if desired.</li>
Create contracts that are not limited by a max size.</li>
</ol>
Benefits & Use Cases</h3>
This standard is for use cases that benefit from the following:</p>

The ability to add, replace or remove multiple functions of a contract atomically (at the same time).</li>
Each time a function is added, replaced or removed, it is documented with events.</li>
Build trust over time by showing all changes made to a contract.</li>
Unlimited contract size.</li>
The ability to query information about functions currently supported by the contract.</li>
One contract address that provides all needed functionality and never needs to be replaced by another contract address.</li>
The ability for a contract to be upgradeable for a time, and then become immutable.</li>
Add trustless guarantees to a contract with "unchangeable functions".</li>
</ol>
New Software Possibilities</h3>
This standard enables a form of contract version control software to be written.</p>
Software and user interfaces can be written to filter the FunctionUpdate</code> and CommitMessage</code> events of a contract address. Such software can show the full history of changes of any contract that implements this standard.</p>
User interfaces and software can also use this standard to assist or automate changes of contracts.</p>
Specification</h2>

Note:</strong>
The solidity delegatecall</code> opcode enables a contract to execute a function from another contract, but it is executed as if the function was from the calling contract. Essentially delegatecall</code> enables a contract to "borrow" another contract's function. Functions executed with delegatecall</code> affect the storage variables of the calling contract, not the contract where the functions are defined.</p>
</blockquote>
General Summary</h3>
A transparent contract delegates or forwards function calls to it to other contracts using delegatecode</code>.</p>
A transparent contract has an updateContract</code> function that enables multiple functions to be added, replaced or removed.</p>
An event is emitted for every function that is added, replaced or removed so that all changes to a contract can be tracked in a standard way.</p>
A transparent contract is a contract that implements and complies with the design points below.</p>
Terms</h3>

In this standard a delegate contract</strong> is a contract that a transparent contract fallback function forwards function calls to using delegatecall</code>.</li>
In this standard an unchangeable function</strong> is a function that is defined directly in a transparent contract and so cannot be replaced or removed.</li>
</ol>
Design Points</h3>
A contract is a transparent contract if it implements the following design points:</p>

A transparent contract is a contract that contains a fallback function, a constructor, and zero or more unchangeable functions that are defined directly within it.</li>
The constructor of a transparent contract associates the updateContract</code> function with a contract that implements the ERC1538 interface. The updateContract</code> function can be an "unchangeable function" that is defined directly in the transparent contract or it can be defined in a delegate contract. Other functions can also be associated with contracts in the constructor.</li>
After a transparent contract is deployed functions are added, replaced and removed by calling the updateContract</code> function.</li>
The updateContract</code> function associates functions with contracts that implement those functions, and emits the CommitMessage</code> and FunctionUpdate</code> events that document function changes.</li>
The FunctionUpdate</code> event is emitted for each function that is added, replaced or removed. The CommitMessage</code> event is emitted one time for each time the updateContract</code> function is called and is emitted after any FunctionUpdate</code> events are emitted.</li>
The updateContract</code> function can take a list of multiple function signatures in its _functionSignatures</code> parameter and so add/replace/remove multiple functions at the same time.</li>
When a function is called on a transparent contract it executes immediately if it is an "unchangeable function". Otherwise the fallback function is executed. The fallback function finds the delegate contract associated with the function and executes the function using delegatecall</code>. If there is no delegate contract for the function then execution reverts.</li>
The source code of a transparent contract and all delegate contracts used by it are publicly viewable and verified.</li>
</ol>
The transparent contract address is the address that users interact with. The transparent contract address never changes. Only delegate addresses can change by using the updateContracts</code> function.</p>
Typically some kind of authentication is needed for adding/replacing/removing functions from a transparent contract, however the scheme for authentication or ownership is not part of this standard</strong>.</p>
Example</h3>
Here is an example of an implementation of a transparent contract. Please note that the example below is an example only.  It is not the standard</strong>. A contract is a transparent contract when it implements and complies with the design points listed above.</p>
pragma</span> solidity</span> ^0.5.7</span>;</span></span>
</span>
contract</span> ExampleTransparentContract</span> {</span></span>
  //</span> owner of the contract</span></span>
  address</span> internal</span> contractOwner</span>;</span></span>
  event</span> OwnershipTransferred</span>(</span>address</span> indexed</span> previousOwner</span>, </span>address</span> indexed</span> newOwner</span>)</span>;</span></span>
</span>
  //</span> maps functions to the delegate contracts that execute the functions</span></span>
  //</span> funcId => delegate contract</span></span>
  mapping</span>(</span>bytes4</span> =></span> address</span>)</span> internal</span> delegates</span>;</span></span>
</span>
  //</span> maps each function signature to its position in the funcSignatures array.</span></span>
  //</span> signature => index+1</span></span>
  mapping</span>(</span>bytes</span> =></span> uint256</span>)</span> internal</span> funcSignatureToIndex</span>;</span></span>
    </span></span>
  event</span> CommitMessage</span>(</span>string</span> message</span>)</span>;</span></span>
  event</span> FunctionUpdate</span>(</span>bytes4</span> indexed</span> functionId</span>, </span>address</span> indexed</span> oldDelegate</span>, </span>address</span> indexed</span> newDelegate</span>, </span>string</span> functionSignature</span>)</span>;</span></span>
  </span></span>
  //</span> this is an example of an "unchangeable function".</span></span>
  //</span> return the delegate contract address for the supplied function signature</span></span>
  function</span> delegateAddress</span>(</span>string</span> calldata</span> _functionSignature</span>)</span> external</span> view</span> returns</span>(</span>address</span>)</span> {</span></span>
    require</span>(</span>funcSignatureToIndex</span>[</span>bytes</span>(</span>_functionSignature</span>)</span>]</span> !=</span> 0</span>,</span> "Function signature not found."</span>)</span>;</span></span>
    return</span> delegates</span>[</span>bytes4</span>(</span>keccak256</span>(</span>bytes</span>(</span>_functionSignature</span>)</span>)</span>)</span>]</span>;</span></span>
  }</span></span>
  </span></span>
  //</span> add a function using the updateContract function</span></span>
  //</span> this is an internal helper function</span></span>
  function</span> addFunction</span>(</span>address</span> _erc1538Delegate</span>,</span> address</span> contractAddress</span>,</span> string</span> memory</span> _functionSignatures</span>,</span> string</span> memory</span> _commitMessage</span>)</span> internal</span> {</span>    </span></span>
    //</span> 0x03A9BCCF == bytes4(keccak256("updateContract(address,string,string)"))</span></span>
    bytes</span> memory</span> funcdata </span>=</span> abi</span>.</span>encodeWithSelector</span>(</span>0x03A9BCCF</span>,</span> contractAddress</span>,</span> _functionSignatures</span>,</span> _commitMessage</span>)</span>;</span></span>
    bool</span> success</span>;</span></span>
    assembly</span> {</span></span>
      success </span>:=</span> delegatecall</span>(</span>gas</span>,</span> _erc1538Delegate</span>,</span> add</span>(</span>funcdata</span>,</span> 0x20</span>)</span>,</span> mload</span>(</span>funcdata</span>)</span>,</span> funcdata</span>,</span> 0</span>)</span></span>
    }</span></span>
    require</span>(</span>success</span>,</span> "Adding a function failed"</span>)</span>;</span>   </span></span>
  }</span></span>
</span>
  constructor</span>(</span>address</span> _erc1538Delegate</span>)</span> public</span> {</span></span>
    contractOwner </span>=</span> msg.sender</span>;</span></span>
    emit</span> OwnershipTransferred</span>(</span>address</span>(</span>0</span>)</span>,</span> msg.sender</span>)</span>;</span></span>
</span>
    //</span> adding ERC1538 updateContract function</span></span>
    bytes</span> memory</span> signature </span>=</span> "updateContract(address,string,string)"</span>;</span></span>
    bytes4</span> funcId </span>=</span> bytes4</span>(</span>keccak256</span>(</span>signature</span>)</span>)</span>;</span></span>
    delegates</span>[</span>funcId</span>]</span> =</span> _erc1538Delegate</span>;</span></span>
    emit</span> FunctionUpdate</span>(</span>funcId</span>,</span> address</span>(</span>0</span>)</span>,</span> _erc1538Delegate</span>,</span> string</span>(</span>signature</span>)</span>)</span>;</span></span>
    emit</span> CommitMessage</span>(</span>"Added ERC1538 updateContract function at contract creation"</span>)</span>;</span></span>
	</span></span>
    //</span> associate "unchangeable functions" with this transparent contract address</span></span>
    //</span> prevents function selector clashes with delegate contract functions</span></span>
    //</span> uses the updateContract function</span></span>
    string</span> memory</span> functions </span>=</span> "delegateAddress(string)"</span>;</span></span>
    addFunction</span>(</span>_erc1538Delegate</span>,</span> address</span>(</span>this</span>)</span>,</span> functions</span>,</span> "Associating unchangeable functions"</span>)</span>;</span></span>
	</span></span>
    //</span> adding ERC1538Query interface functions</span></span>
    functions </span>=</span> "functionByIndex(uint256)functionExists(string)delegateAddresses()delegateFunctionSignatures(address)functionById(bytes4)functionBySignature(string)functionSignatures()totalFunctions()"</span>;</span>    </span></span>
    //</span> "0x01234567891011121314" is an example address of an ERC1538Query delegate contract</span></span>
    addFunction</span>(</span>_erc1538Delegate</span>,</span> 0x01234567891011121314</span>,</span> functions</span>,</span> "Adding ERC1538Query functions"</span>)</span>;</span></span>
    </span></span>
    //</span> additional functions could be added at this point</span></span>
  }</span></span>
</span>
  //</span> Making the fallback function payable makes it work for delegate contract functions </span></span>
  //</span> that are payable and not payable.</span></span>
  function</span>(</span>)</span> external</span> payable</span> {</span></span>
    //</span> Delegate every function call to a delegate contract</span></span>
    address</span> delegate </span>=</span> delegates</span>[</span>msg</span>.</span>sig</span>]</span>;</span></span>
    require</span>(</span>delegate </span>!=</span> address</span>(</span>0</span>)</span>,</span> "Function does not exist."</span>)</span>;</span></span>
    assembly</span> {</span></span>
      let</span> ptr </span>:=</span> mload</span>(</span>0x40</span>)</span></span>
      calldatacopy</span>(</span>ptr</span>,</span> 0</span>,</span> calldatasize</span>)</span></span>
      let</span> result </span>:=</span> delegatecall</span>(</span>gas</span>,</span> delegate</span>,</span> ptr</span>,</span> calldatasize</span>,</span> 0</span>,</span> 0</span>)</span></span>
      let</span> size </span>:=</span> returndatasize</span></span>
      returndatacopy</span>(</span>ptr</span>,</span> 0</span>,</span> size</span>)</span></span>
      switch result</span></span>
      case </span>0</span> {</span>revert</span>(</span>ptr</span>,</span> size</span>)</span>}</span></span>
      default </span>{</span>return</span> (</span>ptr</span>,</span> size</span>)</span>}</span></span>
    }</span></span>
  }</span></span>
}</span></span></code></pre>
As can be seen in the above example, every function call is delegated to a delegate contract, unless the function is defined directly in the transparent contract (making it an unchangeable function).</p>
The constructor function adds the updateContract</code> function to the transparent contract, which is then used to add other functions to the transparent contract.</p>
Each time a function is added to a transparent contract the events CommitMessage</code> and FunctionUpdate</code> are emitted to document exactly what functions where added or replaced and why.</p>
The delegate contract that implements the updateContract</code> function implements the following interface:</p>
ERC1538 Interface</h3>
pragma</span> solidity</span> ^0.5.7</span>;</span></span>
</span>
///</span> @title</span> ERC1538 Transparent Contract Standard</span></span>
///</span> @dev</span> Required interface</span></span>
///</span>  Note</span>: the ERC-165 identifier for this interface is 0x61455567</span></span>
interface</span> ERC1538</span> {</span></span>
  ///</span> @dev</span> This emits when one or a set of functions are updated in a transparent contract.</span></span>
  ///</span>  The message string should give a short description of the change and why</span></span>
  ///</span>  the change was made.</span></span>
  event</span> CommitMessage</span>(</span>string</span> message</span>)</span>;</span></span>
  </span></span>
  ///</span> @dev</span> This emits for each function that is updated in a transparent contract.</span></span>
  ///</span>  functionId is the bytes4 of the keccak256 of the function signature.</span></span>
  ///</span>  oldDelegate is the delegate contract address of the old delegate contract if</span></span>
  ///</span>  the function is being replaced or removed.</span></span>
  ///</span>  oldDelegate is the zero value address(0) if a function is being added for the</span></span>
  ///</span>  first time.</span></span>
  ///</span>  newDelegate is the delegate contract address of the new delegate contract if </span></span>
  ///</span>  the function is being added for the first time or if the function is being </span></span>
  ///</span>  replaced.</span></span>
  ///</span>  newDelegate is the zero value address(0) if the function is being removed.</span></span>
  event</span> FunctionUpdate</span>(</span></span>
    bytes4</span> indexed</span> functionId</span>, </span></span>
    address</span> indexed</span> oldDelegate</span>, </span></span>
    address</span> indexed</span> newDelegate</span>, </span></span>
    string</span> functionSignature</span></span>
  )</span>;</span></span>
</span>
  ///</span> @notice</span> Updates functions in a transparent contract.</span></span>
  ///</span> @dev</span> If the value of _delegate is zero then the functions specified </span></span>
  ///</span>  in _functionSignatures are removed.</span></span>
  ///</span>  If the value of _delegate is a delegate contract address then the functions </span></span>
  ///</span>  specified in _functionSignatures will be delegated to that address.</span></span>
  ///</span> @param</span> _delegate</span> The address of a delegate contract to delegate to or zero</span></span>
  ///</span>        to remove functions.      </span></span>
  ///</span> @param</span> _functionSignatures</span> A list of function signatures listed one after the other</span></span>
  ///</span> @param</span> _commitMessage</span> A short description of the change and why it is made</span></span>
  ///</span>        This message is passed to the CommitMessage event.          </span></span>
  function</span> updateContract</span>(</span>address</span> _delegate</span>,</span> string</span> calldata</span> _functionSignatures</span>,</span> string</span> calldata</span> _commitMessage</span>)</span> external</span>;</span>  </span></span>
}</span></span></code></pre>Function Signatures String Format</h3>
The text format for the _functionSignatures</code> parameter is simply a string of function signatures. For example: "myFirstFunction()mySecondFunction(string)"</code> This format is easy to parse and is concise.</p>
Here is an example of calling the updateContract</code> function that adds the ERC721 standard functions to a transparent contract:</p>
functionSignatures</span> =</span> "</span>approve(address,uint256)balanceOf(address)getApproved(uint256)isApprovedForAll(address,address)ownerOf(uint256)safeTransferFrom(address,address,uint256)safeTransferFrom(address,address,uint256,bytes)setApprovalForAll(address,bool)transferFrom(address,address,uint256)</span>"</span></span>
tx</span> =</span> await</span> transparentContract</span>.</span>updateContract</span>(</span>erc721Delegate</span>.</span>address</span>,</span> functionSignatures</span>,</span> "</span>Adding ERC721 functions</span>"</span>)</span>;</span></span></code></pre>Removing Functions</h3>
Functions are removed by passing address(0)</code> as the first argument to the updateContract</code> function. The list of functions that are passed in are removed.</p>
Source Code Verification</h3>
The transparent contract source code and the source code for the delegate contracts should be verified in a provable way by a third party source such as etherscan.io.</p>

Function Selector Clash</h3>
A function selector clash occurs when a function is added to a contract that hashes to the same four-byte hash as an existing function. This is unlikely to occur but should be prevented in the implementation of the updateContract</code> function. See the reference implementation of ERC1538</a> to see an example of how function clashes can be prevented.</p>
ERC1538Query</h3>
Optionally, the function signatures of a transparent contract can be stored in an array in the transparent contract and queried to get what functions the transparent contract supports and what their delegate contract addresses are.</p>
The following is an optional interface for querying function information from a transparent contract:</p>
pragma</span> solidity</span> ^0.5.7</span>;</span></span>
</span>
interface</span> ERC1538Query</span> {</span></span>
    </span></span>
  ///</span> @notice</span> Gets the total number of functions the transparent contract has.</span></span>
  ///</span> @return</span> The</span> number of functions the transparent contract has,</span></span>
  ///</span>  not including the fallback function.</span></span>
  function</span> totalFunctions</span>(</span>)</span> external</span> view</span> returns</span>(</span>uint256</span>)</span>;</span></span>
	</span></span>
  ///</span> @notice</span> Gets information about a specific function</span></span>
  ///</span> @dev</span> Throws if `_index` >= `totalFunctions()`</span></span>
  ///</span> @param</span> _index</span> The index position of a function signature that is stored in an array</span></span>
  ///</span> @return</span> The</span> function signature, the function selector and the delegate contract address</span></span>
  function</span> functionByIndex</span>(</span>uint256</span> _index</span>)</span> </span></span>
    external</span> </span></span>
    view</span> </span></span>
    returns</span>(</span></span>
      string</span> memory</span> functionSignature</span>,</span> </span></span>
      bytes4</span> functionId</span>,</span> </span></span>
      address</span> delegate</span></span>
    )</span>;</span></span>
	</span></span>
  ///</span> @notice</span> Checks to see if a function exists</span></span>
  ///</span> @param</span> The</span> function signature to check</span></span>
  ///</span> @return</span> True</span> if the function exists, false otherwise</span></span>
  function</span> functionExists</span>(</span>string</span> calldata</span> _functionSignature</span>)</span> external</span> view</span> returns</span>(</span>bool</span>)</span>;</span></span>
	</span></span>
  ///</span> @notice</span> Gets all the function signatures of functions supported by the transparent contract</span></span>
  ///</span> @return</span> A</span> string containing a list of function signatures</span></span>
  function</span> functionSignatures</span>(</span>)</span> external</span> view</span> returns</span>(</span>string</span> memory</span>)</span>;</span></span>
	</span></span>
  ///</span> @notice</span> Gets all the function signatures supported by a specific delegate contract</span></span>
  ///</span> @param</span> _delegate</span> The delegate contract address</span></span>
  ///</span> @return</span> A</span> string containing a list of function signatures</span></span>
  function</span> delegateFunctionSignatures</span>(</span>address</span> _delegate</span>)</span> external</span> view</span> returns</span>(</span>string</span> memory</span>)</span>;</span></span>
	</span></span>
  ///</span> @notice</span> Gets the delegate contract address that supports the given function signature</span></span>
  ///</span> @param</span> The</span> function signature</span></span>
  ///</span> @return</span> The</span> delegate contract address</span></span>
  function</span> delegateAddress</span>(</span>string</span> calldata</span> _functionSignature</span>)</span> external</span> view</span> returns</span>(</span>address</span>)</span>;</span></span>
	</span></span>
  ///</span> @notice</span> Gets information about a function</span></span>
  ///</span> @dev</span> Throws if no function is found</span></span>
  ///</span> @param</span> _functionId</span> The id of the function to get information about</span></span>
  ///</span> @return</span> The</span> function signature and the contract address</span></span>
  function</span> functionById</span>(</span>bytes4</span> _functionId</span>)</span> </span></span>
    external</span> </span></span>
    view</span> </span></span>
    returns</span>(</span></span>
      string</span> memory</span> signature</span>,</span> </span></span>
      address</span> delegate</span></span>
    )</span>;</span></span>
	</span></span>
  ///</span> @notice</span> Get all the delegate contract addresses used by the transparent contract</span></span>
  ///</span> @return</span> An</span> array of all delegate contract addresses</span></span>
  function</span> delegateAddresses</span>(</span>)</span> external</span> view</span> returns</span>(</span>address</span>[</span>]</span> memory</span>)</span>;</span></span>
}</span></span></code></pre>
See the reference implementation of ERC1538</a> to see how this is implemented.</p>
The text format for the list of function signatures returned from the delegateFunctionSignatures</code> and functionSignatures</code> functions is simply a string of function signatures. Here is an example of such a string: "approve(address,uint256)balanceOf(address)getApproved(uint256)isApprovedForAll(address,address)ownerOf(uint256)safeTransferFrom(address,address,uint256)safeTransferFrom(address,address,uint256,bytes)setApprovalForAll(address,bool)transferFrom(address,address,uint256)"</code></p>
How To Deploy A Transparent Contract</h3>

Create and deploy to a blockchain a contract that implements the ERC1538 interface. You can skip this step if there is already such a contract deployed to the blockchain.</li>
Create your transparent contract with a fallback function as given above. Your transparent contract also needs a constructor that adds the updateContract</code> function.</li>
Deploy your transparent contract to a blockchain. Pass in the address of the ERC1538 delegate contract to your constructor if it requires it.</li>
</ol>
See the reference implementation</a> for examples of these contracts.</p>
Wrapper Contract for Delegate Contracts that Depend on Other Delegate Contracts</h3>
In some cases some delegate contracts may need to call external/public functions that reside in other delegate contracts. A convenient way to solve this problem is to create a contract that contains empty implementations of functions that are needed and import and extend this contract in delegate contracts that call functions from other delegate contracts. This enables delegate contracts to compile without having to provide implementations of the functions that are already given in other delegate contracts. This is a way to save gas, prevent reaching the max contract size limit, and prevent duplication of code. This strategy was given by @amiromayer. See his comment for more information.</a> Another way to solve this problem is to use assembly to call functions provided by other delegate contracts.</p>
Decentralized Authority</h3>
It is possible to extend this standard to add consensus functionality such as an approval function that multiple different people call to approve changes before they are submitted with the updateContract</code> function. Changes only go into effect when the changes are fully approved. The CommitMessage</code> and  FunctionUpdate</code> events should only be emitted when changes go into effect.</p>
Security</h2>

This standard refers to owner(s)</strong> as one or more individuals that have the power to add/replace/remove functions of an upgradeable contract.</p>
</blockquote>
General</h3>
The owners(s) of an upgradeable contract have the ability to alter, add or remove data from the contract's data storage. Owner(s) of a contract can also execute any arbitrary code in the contract on behalf of any address. Owners(s) can do these things by adding a function to the contract that they call to execute arbitrary code. This is an issue for upgradeable contracts in general and is not specific to transparent contracts.</p>

Note:</strong> The design and implementation of contract ownership is not</strong> part of this standard. The examples given in this standard and in the reference implementation are just examples</strong> of how it could be done.</p>
</blockquote>
Unchangeable Functions</h3>
"Unchangeable functions" are functions defined in a transparent contract itself and not in a delegate contract. The owner(s) of a transparent contract are not able to replace these functions. The use of unchangeable functions is limited because in some cases they can still be manipulated if they read or write data to the storage of the transparent contract. Data read from the transparent contract's storage could have been altered by the owner(s) of the contract. Data written to the transparent contract's storage can be undone or altered by the owner(s) of the contract.</p>
In some cases unchangeble functions add trustless guarantees to a transparent contract.</p>
Transparency</h3>
Contracts that implement this standard emit an event every time a function is added, replaced or removed. This enables people and software to monitor the changes to a contract. If any bad acting function is added to a contract then it can be seen. To comply with this standard all source code of a transparent contract and delegate contracts must be publicly available and verified.</p>
Security and domain experts can review the history of change of any transparent contract to detect any history of foul play.</p>
Rationale</h2>
String of Function Signatures Instead of bytes4[] Array of Function Selectors</h3>
The updateContract</code> function takes a string</code> list of functions signatures as an argument instead of a bytes4[]</code> array of function selectors for three reasons:</p>

Passing in function signatures enables the implementation of updateContract</code> to prevent selector clashes.</li>
A major part of this standard is to make upgradeable contracts more transparent by making it easier to see what has changed over time and why. When a function is added, replaced or removed its function signature is included in the FunctionUpdate event that is emitted. This makes it relatively easy to write software that filters the events of a contract to display to people what functions have been added/removed and changed over time without needing access to the source code or ABI of the contract. If only four-byte function selectors were provided this would not be possible.</li>
By looking at the source code of a transparent contract it is not possible to see all the functions that it supports. This is why the ERC1538Query interface exists, so that people and software have a way to look up and examine or show all functions currently supported by a transparent contract. Function signatures are used so that ERC1538Query functions can show them.</li>
</ol>
Gas Considerations</h3>
Delegating function calls does have some gas overhead. This is mitigated in two ways:</p>

Delegate contracts can be small, reducing gas costs. Because it costs more gas to call a function in a contract with many functions than a contract with few functions.</li>
Because transparent contracts do not have a max size limitation it is possible to add gas optimizing functions for use cases. For example someone could use a transparent contract to implement the ERC721 standard and implement batch transfer functions from the ERC1412 standard</a> to help reduce gas (and make batch transfers more convenient).</li>
</ol>
Storage</h3>
The standard does not specify how data is stored or organized by a transparent contract. But here are some suggestions:</p>
Inherited Storage</strong></p>


The storage variables of a transparent contract consist of the storage variables defined in the transparent contract source code and the source code of delegate contracts that have been added.</p>
</li>

A delegate contract can use any storage variable that exists in a transparent contract as long as it defines within it all the storage variables that exist, in the order that they exist, up to and including the ones being used.</p>
</li>

A delegate contract can create new storage variables as long as it has defined, in the same order, all storage variables that exist in the transparent contract.</p>
</li>
</ol>
Here is a simple way inherited storage could be implemented:</p>

Create a storage contract that contains the storage variables that your transparent contract and delegate contracts will use.</li>
Make your delegate contracts inherit the storage contract.</li>
If you want to add a new delegate contract that adds new storage variables then create a new storage contract that adds the new storage variables and inherits from the old storage contract. Use your new storage contract with your new delegate contract.</li>
Repeat steps 2 or 3 for every new delegate contract.</li>
</ol>
Unstructured Storage</strong></p>
Assembly is used to store and read data at specific storage locations. An advantage to this approach is that previously used storage locations don't have to be defined or mentioned in a delegate contract if they aren't used by it.</p>
Eternal Storage</strong></p>
Data can be stored using a generic API based on the type of data. See ERC930 for more information.</a></p>
Becoming Immutable</h3>
It is possible to make a transparent contract become immutable. This is done by calling the updateContract</code> function to remove the updateContract</code> function. With this gone it is no longer possible to add, replace and remove functions.</p>
Versions of Functions</h3>
Software or a user can verify what version of a function is called by getting the delegate contract address of the function. This can be done by calling the delegateAddress</code> function from the ERC1538Query interface if it is implemented. This function takes a function signature as an argument and returns the delegate contract address where it is implemented.</p>
Best Practices, Tools and More Information</h3>

More information, tools, tutorials and best practices concerning transparent contracts need to be developed and published.</p>
</blockquote>
Below is a growing list of articles concerning transparent contracts and their use.  If you have an article about transparent contracts you would like to share then please submit a comment to this issue about it to get it added.</p>
ERC1538: Future Proofing Smart Contracts and Tokens</a></p>
The ERC1538 improving towards the “transparent contract” standard</a></p>
Inspiration</h3>
This standard was inspired by ZeppelinOS's implementation of Upgradeability with vtables</a>.</p>
This standard was also inspired by the design and implementation of the Mokens contract</a> from the Mokens project</a>. The Mokens contract has been upgraded to implement this standard</a>.</p>
Backwards Compatibility</h2>
This standard makes a contract compatible with future standards and functionality because new functions can be added and existing functions can be replaced or removed.</p>
This standard future proofs a contract.</p>
Implementation</h2>
A reference implementation of this standard is given in the transparent-contracts-erc1538</a> repository.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Ethash 1a
2018-08-26T00:00:00+00:00
Motivation</h2>
Provide minimal set of changes to Ethash algorithm to hinder and delay the adoption of ASIC based mining.</p>
Specification</h2>


Define hash function fnv1a()</code> as</p>
def</span> fnv1a</span>(</span>v1</span>,</span> v2</span>)</span>:</span></span>
    return</span> (</span>(</span>v1</span> ^</span> v2</span>)</span> *</span> FNV1A_PRIME</span>)</span> %</span> 2</span>**</span>32</span></span></code></pre>
where FNV1A_PRIME</code> is 16777499 or 16777639.</p>
</li>

Change the hash function that determines the DAG item index in Ethash algorithm from fnv()</code> to new fnv1a()</code>.
In Main Loop</a> change</p>
p</span> =</span> fnv</span>(</span>i</span> ^</span> s</span>[</span>0</span>]</span>,</span> mix</span>[</span>i</span> %</span> w</span>]</span>)</span> %</span> (</span>n</span> //</span> mixhashes</span>)</span> *</span> mixhashes</span></span></code></pre>
to</p>
p</span> =</span> fnv1a</span>(</span>i</span> ^</span> s</span>[</span>0</span>]</span>,</span> mix</span>[</span>i</span> %</span> w</span>]</span>)</span> %</span> (</span>n</span> //</span> mixhashes</span>)</span> *</span> mixhashes</span></span></code></pre></li>
</ol>
Rationale</h2>
The usual argument for decentralization and network security.</p>
Unless programmable, an ASIC is hardwired to perform sequential operations in a given order. fnv1a changes the order in which an exclusive-or and a multiply are applied, effectively disabling the current wave of ASICS. A second objective is minimize ethash changes to be the least disruptive, to facilitate rapid development, and to lower the analysis and test requirements. Minimizing changes to ethash reduces risk associated with updating all affected network components, and also reduces the risk of detuning existing GPUs. It's expected that this specific change would have no effect on existing GPU performance.</p>
Changing fnv to fnv1a has no cryptographic implications. It is merely an efficient hash function with good dispersion characteristics used to scramble DAG indexing. We remain focused on risk mitigation by reducing the need for rigorous cryptographic analysis.</p>
FNV Primes</h3>
The 16777639 satisfies all requirements from Wikipedia</a>.</p>
The 16777499 is preferred by FNV authors but not used in the reference FNV implementation because of historical reasons.
See A few remarks on FNV primes</a>.</p>
Copyright</h2>
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License</a>.</p>


Remove Difficulty Bomb
2018-07-21T00:00:00+00:00
Simple Summary</h2>
The average block times are increasing due to the difficulty bomb (also known as the "ice age</em>") slowly accelerating. This EIP proposes to remove the difficulty increase over time and replace it with a fixed difficulty targeting 15 second blocks.</p>
Abstract</h2>
Starting with FORK_BLOCK_NUMBER</code> the client will calculate the difficulty without considering the current block number.</p>
Motivation</h2>
The difficulty bomb operates under the assumption that miners decide what code economic participants are running, rather than economic participants deciding for themselves.  In reality, miners will mine whatever chain is most profitable and the most profitable chain is the one that economic participants use.  If 99% of miners mine a chain that no economic participants use then that chain will have no value and the miners will cease mining of it in favor of some other chain that does have economic participants.  Another way to put this is that miners will follow economic participants, not the other way around.</p>
Specification</h2>
Remove Difficulty</h4>
For the purposes of calc_difficulty</code>, if block.number >= FORK_BLOCK_NUMBER</code> then change the epsilon component to 0</code> rather than having it be a function of block number.</p>
Rationale</h2>
With the difficulty bomb removed, when Casper is released it will be up to economic participants to decide whether they want the features that Casper enables or not.  If they do not want Casper, they are free to continue running unpatched clients and participating in the Ethereum network as it exists today.  This freedom of choice is the cornerstone of DLTs and making it hard for people to make that choice (by creating an artificial pressure) does not work towards that goal of freedom of choice.  If the development team is not confident that economic participants will want Casper, then they should re-evaluate their priorities rather than trying to force Casper onto users.</p>
Author Personal Note: I think we will see almost all economic participants in Ethereum switch to PoS/Sharding without any extra pressure beyond client defaults.</p>
Backwards Compatibility</h2>
This EIP is not forward compatible and introduces backwards incompatibilities in the difficulty calculation. Therefore, it should be included in a scheduled hardfork at a certain block number.</p>
Test Cases</h2>
Test cases shall be created once the specification is to be accepted by the developers or implemented by the clients.</p>
Implementations</h2>
The yellow paper implements this change in https://github.com/ethereum/yellowpaper/pull/710</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Oracle Interface
2018-06-13T00:00:00+00:00
Simple Summary</h2>
A standard interface for oracles.</p>
Abstract</h2>
In order for ethereum smart contracts to interact with off-chain systems, oracles must be used. These oracles report values which are normally off-chain, allowing smart contracts to react to the state of off-chain systems. A distinction and a choice is made between push and pull based oracle systems. Furthermore, a standard interface for oracles is described here, allowing different oracle implementations to be interchangeable.</p>
Motivation</h2>
The Ethereum ecosystem currently has many different oracle implementations available, but they do not provide a unified interface. Smart contract systems would be locked into a single set of oracle implementations, or they would require developers to write adapters/ports specific to the oracle system chosen in a given project.</p>
Beyond naming differences, there is also the issue of whether or not an oracle report-resolving transaction pushes</em> state changes by calling affected contracts, or changes the oracle state allowing dependent contracts to pull</em> the updated value from the oracle. These differing system semantics could introduce inefficiencies when adapting between them.</p>
Ultimately, the value in different oracle systems comes from their underlying resolution mechanics, and points where these systems are virtually identical should be standardized.</p>
These oracles may be used for answering questions about "real-world events", where each ID can be correlated with a specification of a question and its answers (so most likely for prediction markets, basically).</p>
Another use case could be for decision-making processes, where the results given by the oracle represent decisions made by the oracle (e.g. futarchies). DAOs may require their use in decision making processes.</p>
Both the ID and the results are intentionally unstructured so that things like time series data (via splitting the ID) and different sorts of results (like one of a few, any subset of up to 256, or some value in a range with up to 256 bits of granularity) can be represented.</p>
Specification</h2>

  Oracle</dt>
  
An entity which reports data to the blockchain.</dd>
  
Oracle consumer</dt>
  
A smart contract which receives data from an oracle.</dd>
  
ID</dt>
  
A way of indexing the data which an oracle reports. May be derived from or tied to a question for which the data provides the answer.</dd>
  
Result</dt>
  
Data associated with an id which is reported by an oracle. This data oftentimes will be the answer to a question tied to the id. Other equivalent terms that have been used include: answer, data, outcome.</dd>
  
Report</dt>
  A pair (ID, result) which an oracle sends to an oracle consumer.</dd>
</dl>
interface</span> OracleConsumer</span> {</span></span>
    function</span> receiveResult</span>(</span>bytes32</span> id</span>,</span> bytes</span> result</span>)</span> external</span>;</span></span>
}</span></span></code></pre>
receiveResult</code> MUST revert if the msg.sender</code> is not an oracle authorized to provide the result</code> for that id</code>.</p>
receiveResult</code> MUST revert if receiveResult</code> has been called with the same id</code> before.</p>
receiveResult</code> MAY revert if the id</code> or result</code> cannot be handled by the consumer.</p>
Consumers MUST coordinate with oracles to determine how to encode/decode results to and from bytes</code>. For example, abi.encode</code> and abi.decode</code> may be used to implement a codec for results in Solidity. receiveResult</code> SHOULD revert if the consumer receives a unexpected result format from the oracle.</p>
The oracle can be any Ethereum account.</p>
Rationale</h2>
The specs are currently very similar to what is implemented by ChainLink (which can use any arbitrarily-named callback) and Oraclize (which uses __callback</code>).</p>
With this spec, the oracle pushes</em> state to the consumer, which must react accordingly to the updated state. An alternate pull</em>-based interface can be prescribed, as follows:</p>
Alternate Pull-based Interface</h3>
Here are alternate specs loosely based on Gnosis prediction market contracts v1. Reality Check also exposes a similar endpoint (getFinalAnswer</code>).</p>
interface</span> Oracle</span> {</span></span>
    function</span> resultFor</span>(</span>bytes32</span> id</span>)</span> external</span> view</span> returns</span> (</span>bytes</span> result</span>)</span>;</span></span>
}</span></span></code></pre>
resultFor</code> MUST revert if the result for an id</code> is not available yet.</p>
resultFor</code> MUST return the same result for an id</code> after that result is available.</p>
Push vs Pull</h3>
Note that push-based interfaces may be adapted into pull-based interfaces. Simply deploy an oracle consumer which stores the result received and implements resultFor</code> accordingly.</p>
Similarly, every pull-based system can be adapted into a push-based system: just add a method on the oracle smart contract which takes an oracle consumer address and calls receiveResult</code> on that address.</p>
In both cases, an additional transaction would have to be performed, so the choice to go with push or pull should be based on the dominant use case for these oracles.</p>
In the simple case where a single account has the authority to decide the outcome of an oracle question, there is no need to deploy an oracle contract and store the outcome on that oracle contract. Similarly, in the case where the outcome comes down to a vote, existing multisignature wallets can be used as the authorized oracle.</p>
Multiple Oracle Consumers</h4>
In the case that many oracle consumers depend on a single oracle result and all these consumers expect the result to be pushed to them, the push and pull adaptations mentioned before may be combined if the pushing oracle cannot be trusted to send the same result to every consumer (in a sense, this forwards the trust to the oracle adaptor implementation).</p>
In a pull-based system, each of the consumers would have to be called to pull the result from the oracle contract, but in the proposed push-based system, the adapted oracle would have to be called to push the results to each of the consumers.</p>
Transaction-wise, both systems are roughly equivalent in efficiency in this scenario, but in the push-based system, there's a need for the oracle consumers to store the results again, whereas in the pull-based system, the consumers may continue to refer to the oracle for the results. Although this may be somewhat less efficient, requiring the consumers to store the results can also provide security guarantees, especially with regards to result immutability.</p>
Result Immutability</h4>
In both the proposed specification and the alternate specification, results are immutable once they are determined. This is due to the expectation that typical consumers will require results to be immutable in order to determine a resulting state consistently. With the proposed push-based system, the consumer enforces the result immutability requirement, whereas in the alternate pull-based system, either the oracle would have to be trusted to implement the spec correctly and enforce the immutability requirement, or the consumer would also have to handle result immutability.</p>
For data which mutates over time, the id</code> field may be structured to specify "what" and "when" for the data (using 128 bits to specify "when" is still safe for many millennia).</p>
Implementation</h2>

Tidbit</a> tracks this EIP.</li>
</ul>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Revised Ethereum Smart Contract Packaging Standard
2018-06-01T00:00:00+00:00
This ERC has been abandoned in favor of the EthPM V3 smart contract packaging standard defined in ERC-2678</a></p>
Simple Summary</h1>
A data format describing a smart contract software package.</p>
Abstract</h1>
This EIP defines a data format for package manifest</em> documents,
representing a package of one or more smart contracts, optionally
including source code and any/all deployed instances across multiple
networks. Package manifests are minified JSON objects, to be distributed
via content addressable storage networks, such as IPFS.</p>
This document presents a natural language description of a formal
specification for version 2</strong> of this format.</p>
Motivation</h1>
This standard aims to encourage the Ethereum development ecosystem
towards software best practices around code reuse. By defining an open,
community-driven package data format standard, this effort seeks to
provide support for package management tools development by offering a
general-purpose solution that has been designed with observed common
practices in mind.</p>
As version 2 of this specification, this standard seeks to address a
number of areas of improvement found for the previous version (defined
in
EIP-190</a>).
This version:</p>


Generalizes storage URIs to represent any content addressable URI
scheme, not only IPFS.</p>
</li>

Renames release lockfile</em> to package manifest</em>.</p>
</li>

Adds support for languages other than Solidity by generalizing the
compiler information format.</p>
</li>

Redefines link references to be more flexible, to represent
arbitrary gaps in bytecode (besides only addresses), in a more
straightforward way.</p>
</li>

Forces format strictness, requiring that package manifests contain
no extraneous whitespace, and sort object keys in alphabetical
order, to prevent hash mismatches.</p>
</li>
</ul>
</div>
Specification</h1>
This document defines the specification for an EthPM package manifest. A
package manifest provides metadata about a Package</a>, and
in most cases should provide sufficient information about the packaged
contracts and its dependencies to do bytecode verification of its
contracts.</p>

Note</strong></p>
A hosted
version</a> of this
specification is available via GitHub Pages. This EIP and the hosted
HTML document were both autogenerated from the same documentation
source.</p>
</blockquote>
Guiding Principles</h2>
This specification makes the following assumptions about the document
lifecycle.</p>


Package manifests are intended to be generated programmatically by
package management software as part of the release process.</p>
</li>

Package manifests will be consumed by package managers during tasks
like installing package dependencies or building and deploying new
releases.</p>
</li>

Package manifests will typically not</strong> be stored alongside the
source, but rather by package registries or</em> referenced by package
registries and stored in something akin to IPFS.</p>
</li>
</ol>
Conventions</h2>
RFC2119</h3>
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”,
“SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this
document are to be interpreted as described in RFC 2119.</p>

https://www.ietf.org/rfc/rfc2119.txt</a></li>
</ul>
Prefixed vs Unprefixed</h3>
A prefixed</a> hexadecimal value begins with 0x</code>.
Unprefixed</a> values have no prefix. Unless otherwise
specified, all hexadecimal values should</strong> be represented with the
0x</code> prefix.</p>
</colgroup>






Prefixed</p></td>
0xdeadbeef</code></p></td>
</tr>

Unprefixed</p></td>
deadbeef</code></p></td>
</tr>
</tbody>
</table>
Document Format</h2>
The canonical format is a single JSON object. Packages must</strong> conform
to the following serialization rules.</p>


The document must</strong> be tightly packed, meaning no linebreaks or
extra whitespace.</p>
</li>

The keys in all objects must be sorted alphabetically.</p>
</li>

Duplicate keys in the same object are invalid.</p>
</li>

The document must</strong> use
UTF-8</a>
encoding.</p>
</li>

The document must</strong> not have a trailing newline.</p>
</li>
</ul>
Document Specification</h2>
The following fields are defined for the package. Custom fields may</strong>
be included. Custom fields should</strong> be prefixed with x-</code> to prevent
name collisions with future versions of the specification.</p>
</colgroup>






See Also</p></td>
Formalized (JSON-Schema</a>) version of this specification: package.spec.json</a></p></td>
</tr>

Jump To</p></td>
Definitions</a></p></td>
</tr>
</tbody>
</table>
</div>
EthPM Manifest Version: manifest_version</code></h3>
The manifest_version</code> field defines the specification version that this
document conforms to. Packages must</strong> include this field.</p>
</colgroup>






Required</p></td>
Yes</p></td>
</tr>

Key</p></td>
manifest_version</code></p></td>
</tr>

Type</p></td>
String</p></td>
</tr>

Allowed Values</p></td>
2</code></p></td>
</tr>
</tbody>
</table>
</div>
Package Name: package_name</code></h3>
The package_name</code> field defines a human readable name for this package.
Packages must</strong> include this field. Package names must</strong> begin with
a lowercase letter and be comprised of only lowercase letters, numeric
characters, and the dash character -</code>. Package names must</strong> not
exceed 214 characters in length.</p>
</colgroup>






Required</p></td>
Yes</p></td>
</tr>

Key</p></td>
package_name</code></p></td>
</tr>

Type</p></td>
String</p></td>
</tr>

Format</p></td>
must</strong> match the regular expression ^[a-zA-Z][a-zA-Z0-9_]{0,255}$</code></p></td>
</tr>
</tbody>
</table>
Package Meta: meta</code></h3>
The meta</code> field defines a location for metadata about the package which
is not integral in nature for package installation, but may be important
or convenient to have on-hand for other reasons. This field should</strong>
be included in all Packages.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Key</p></td>
meta</code></p></td>
</tr>

Type</p></td>
Package Meta Object</a></p></td>
</tr>
</tbody>
</table>
Version: version</code></h3>
The version</code> field declares the version number of this release. This
value must</strong> be included in all Packages. This value should</strong>
conform to the semver</a> version
numbering specification.</p>
</colgroup>






Required</p></td>
Yes</p></td>
</tr>

Key</p></td>
version</code></p></td>
</tr>

Type</p></td>
String</p></td>
</tr>
</tbody>
</table>
Sources: sources</code></h3>
The sources</code> field defines a source tree that should</strong> comprise the
full source tree necessary to recompile the contracts contained in this
release. Sources are declared in a key/value mapping.</p>
</colgroup>






Key</p></td>
sources</code></p></td>
</tr>

Type</p></td>
Object (String: String)</p></td>
</tr>

Format</p></td>
See Below.</p></td>
</tr>
</tbody>
</table>
Format</h4>
Keys must</strong> be relative filesystem paths beginning with a ./</code>.</p>
Paths must</strong> resolve to a path that is within the current working
directory.</p>
Values must</strong> conform to one of</em> the following formats.</p>


Source string.</p>
</li>

Content Addressable URI</a>.</p>
</li>
</ul>
When the value is a source string the key should be interpreted as a
file path.</p>


If the resulting document is a directory the key should be
interpreted as a directory path.</p>
</li>

If the resulting document is a file the key should be interpreted as
a file path.</p>
</li>
</ul>
Contract Types: contract_types</code></h3>
The contract_types</code> field holds the Contract
Types</a> which have been included in this release.
Packages</a> should</strong> only include contract types that
can be found in the source files for this package. Packages should
not</strong> include contract types from dependencies. Packages should not</strong>
include abstract contracts in the contract types section of a release.</p>
</colgroup>






Key</p></td>
contract_types</code></p></td>
</tr>

Type</p></td>
Object (String: Contract Type Object</a>)</p></td>
</tr>

Format</p></td>
Keys must</strong> be valid Contract Aliases</a>.</p>
Values must</strong> conform to the Contract Type Object</a> definition.</p></td>
</tr>
</tbody>
</table>
Deployments: deployments</code></h3>
The deployments</code> field holds the information for the chains on which
this release has Contract Instances</a> as well
as the Contract Types</a> and other deployment
details for those deployed contract instances. The set of chains defined
by the *BIP122 URI <#bip122-uris>*</code> keys for this object must</strong> be
unique.</p>
</colgroup>






Key</p></td>
deployments</code></p></td>
</tr>

Type</p></td>
Object (String: Object(String: Contract Instance Object</a>))</p></td>
</tr>

Format</p></td>
See Below.</p></td>
</tr>
</tbody>
</table>
Format</h4>
Keys must</strong> be a valid BIP122 URI chain definition.</p>
Values must</strong> be objects which conform to the following format.</p>


Keys must</strong> be valid Contract Instance
Names</a>.</p>
</li>

Values must</strong> be a valid Contract Instance
Object</a>.</p>
</li>
</ul>
Build Dependencies: build_dependencies</code></h3>
The build_dependencies</code> field defines a key/value mapping of Ethereum
Packages</a> that this project depends on.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Key</p></td>
build_dependencies</code></p></td>
</tr>

Type</p></td>
Object (String: String)</p></td>
</tr>

Format</p></td>
Keys must</strong> be valid package names</a> matching the regular expression [a-z][-a-z0-9]{0,213}</code>.</p>
Values must</strong> be valid IPFS URIs which resolve to a valid package.</p></td>
</tr>
</tbody>
</table>
Definitions</h2>
Definitions for different objects used within the Package. All objects
allow custom fields to be included. Custom fields should</strong> be prefixed
with x-</code> to prevent name collisions with future versions of the
specification.</p>
</div>
The Link Reference</em> Object</h3>
A Link Reference</a> object has the following
key/value pairs. All link references are assumed to be associated with
some corresponding Bytecode</a>.</p>
Offsets: offsets</code></h4>
The offsets</code> field is an array of integers, corresponding to each of
the start positions where the link reference appears in the bytecode.
Locations are 0-indexed from the beginning of the bytes representation
of the corresponding bytecode. This field is invalid if it references a
position that is beyond the end of the bytecode.</p>
</colgroup>






Required</p></td>
Yes</p></td>
</tr>

Type</p></td>
Array</p></td>
</tr>
</tbody>
</table>
Length: length</code></h4>
The length</code> field is an integer which defines the length in bytes of
the link reference. This field is invalid if the end of the defined link
reference exceeds the end of the bytecode.</p>
</colgroup>






Required</p></td>
Yes</p></td>
</tr>

Type</p></td>
Integer</p></td>
</tr>
</tbody>
</table>
Name: name</code></h4>
The name</code> field is a string which must</strong> be a valid
Identifier</a>. Any link references which should</strong> be
linked with the same link value should</strong> be given the same name.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Type</p></td>
String</p></td>
</tr>

Format</p></td>
must</strong> conform to the Identifier</a> format.</p></td>
</tr>
</tbody>
</table>
</div>
The Link Value</em> Object</h3>
Describes a single Link Value</a>.</p>
A Link Value object</strong> is defined to have the following key/value
pairs.</p>
</div>
Offsets: offsets</code></h4>
The offsets</code> field defines the locations within the corresponding
bytecode where the value</code> for this link value was written. These
locations are 0-indexed from the beginning of the bytes representation
of the corresponding bytecode.</p>
</colgroup>






Required</p></td>
Yes</p></td>
</tr>

Type</p></td>
Integer</p></td>
</tr>

Format</p></td>
See Below.</p></td>
</tr>
</tbody>
</table>
Format</strong></p>
Array of integers, where each integer must</strong> conform to all of the
following.</p>


greater than or equal to zero</p>
</li>

strictly less than the length of the unprefixed hexadecimal
representation of the corresponding bytecode.</p>
</li>
</ul>
Type: type</code></h4>
The type</code> field defines the value</code> type for determining what is
encoded when linking</a> the corresponding bytecode.</p>
</colgroup>






Required</p></td>
Yes</p></td>
</tr>

Type</p></td>
String</p></td>
</tr>

Allowed Values</p></td>
"literal"</code> for bytecode literals</p>
"reference"</code> for named references to a particular Contract Instance</a></p></td>
</tr>
</tbody>
</table>
Value: value</code></h4>
The value</code> field defines the value which should be written when
linking</a> the corresponding bytecode.</p>
</colgroup>






Required</p></td>
Yes</p></td>
</tr>

Type</p></td>
String</p></td>
</tr>

Format</p></td>
Determined based on type</code>, see below.</p></td>
</tr>
</tbody>
</table>
Format</strong></p>
For static value literals</em> (e.g. address), value must</strong> be a byte
string</em></p>
To reference the address of a Contract
Instance</a> from the current package the value
should be the name of that contract instance.</p>


This value must</strong> be a valid contract instance name.</p>
</li>

The chain definition under which the contract instance that this
link value belongs to must contain this value within its keys.</p>
</li>

This value may not</strong> reference the same contract instance that
this link value belongs to.</p>
</li>
</ul>
To reference a contract instance from a Package</a> from
somewhere within the dependency tree the value is constructed as
follows.</p>


Let [p1, p2, .. pn]</code> define a path down the dependency tree.</p>
</li>

Each of p1, p2, pn</code> must</strong> be valid package names.</p>
</li>

p1</code> must</strong> be present in keys of the build_dependencies</code> for the
current package.</p>
</li>

For every pn</code> where n > 1</code>, pn</code> must</strong> be present in the keys
of the build_dependencies</code> of the package for pn-1</code>.</p>
</li>

The value is represented by the string
<p1>:<p2>:<...>:<pn>:<contract-instance></code> where all of <p1></code>,
<p2></code>, <pn></code> are valid package names and <contract-instance></code> is
a valid Contract Name</a>.</p>
</li>

The <contract-instance></code> value must</strong> be a valid Contract
Instance Name</a>.</p>
</li>

Within the package of the dependency defined by <pn></code>, all of the
following must be satisfiable:</p>


There must</strong> be exactly</em> one chain defined under the
deployments</code> key which matches the chain definition that this
link value is nested under.</p>
</li>

The <contract-instance></code> value must</strong> be present in the keys
of the matching chain.</p>
</li>
</ul>
</li>
</ul>
The Bytecode</em> Object</h3>
A bytecode object has the following key/value pairs.</p>
Bytecode: bytecode</code></h4>
The bytecode</code> field is a string containing the 0x</code> prefixed
hexadecimal representation of the bytecode.</p>
</colgroup>






Required</p></td>
Yes</p></td>
</tr>

Type</p></td>
String</p></td>
</tr>

Format</p></td>
0x</code> prefixed hexadecimal.</p></td>
</tr>
</tbody>
</table>
Link References: link_references</code></h4>
The link_references</code> field defines the locations in the corresponding
bytecode which require linking</a>.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Type</p></td>
Array</p></td>
</tr>

Format</p></td>
All values must</strong> be valid Link Reference objects</a>. See also below.</p></td>
</tr>
</tbody>
</table>
Format</strong></p>
This field is considered invalid if any</em> of the Link
References</a> are invalid when applied to the
corresponding bytecode</code> field, or</em> if any of the link references
intersect.</p>
Intersection is defined as two link references which overlap.</p>
Link Dependencies: link_dependencies</code></h4>
The link_dependencies</code> defines the Link Values</a> that
have been used to link the corresponding bytecode.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Type</p></td>
Array</p></td>
</tr>

Format</p></td>
All values must</strong> be valid Link Value objects</a>. See also below.</p></td>
</tr>
</tbody>
</table>
Format</strong></p>
Validation of this field includes the following:</p>


Two link value objects must not</strong> contain any of the same values
for offsets</code>.</p>
</li>

Each link value object</a> must</strong> have a
corresponding link reference object</a> under
the link_references</code> field.</p>
</li>

The length of the resolved value</code> must</strong> be equal to the length</code>
of the corresponding Link Reference</a>.</p>
</li>
</ul>
</div>
The Package Meta</em> Object</h3>
The Package Meta</em> object is defined to have the following key/value
pairs.</p>
Authors: authors</code></h4>
The authors</code> field defines a list of human readable names for the
authors of this package. Packages may</strong> include this field.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Key</p></td>
authors</code></p></td>
</tr>

Type</p></td>
Array (String)</p></td>
</tr>
</tbody>
</table>
License: license</code></h4>
The license</code> field declares the license under which this package is
released. This value should</strong> conform to the
SPDX</a>
format. Packages should</strong> include this field.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Key</p></td>
license</code></p></td>
</tr>

Type</p></td>
String</p></td>
</tr>
</tbody>
</table>
Description: description</code></h4>
The description</code> field provides additional detail that may be relevant
for the package. Packages may</strong> include this field.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Key</p></td>
description</code></p></td>
</tr>

Type</p></td>
String</p></td>
</tr>
</tbody>
</table>
Keywords: keywords</code></h4>
The keywords</code> field provides relevant keywords related to this package.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Key</p></td>
keywords</code></p></td>
</tr>

Type</p></td>
List of Strings</p></td>
</tr>
</tbody>
</table>
Links: links</code></h4>
The links</code> field provides URIs to relevant resources associated with
this package. When possible, authors should</strong> use the following keys
for the following common resources.</p>


website</code>: Primary website for the package.</p>
</li>

documentation</code>: Package Documentation</p>
</li>

repository</code>: Location of the project source code.</p>
</li>
</ul>
</colgroup>






Key</p></td>
links</code></p></td>
</tr>

Type</p></td>
Object (String: String)</p></td>
</tr>
</tbody>
</table>
</div>
The Contract Type</em> Object</h3>
A Contract Type</em> object is defined to have the following key/value
pairs.</p>
Contract Name: contract_name</code></h4>
The contract_name</code> field defines the Contract
Name</a> for this Contract
Type</a>.</p>
</colgroup>






Required</p></td>
If the Contract Name</a> and Contract Alias</a> are not the same.</p></td>
</tr>

Type</p></td>
String</p></td>
</tr>

Format</p></td>
must</strong> be a valid Contract Name</a>.</p></td>
</tr>
</tbody>
</table>
Deployment Bytecode: deployment_bytecode</code></h4>
The deployment_bytecode</code> field defines the bytecode for this Contract
Type</a>.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Type</p></td>
Object</p></td>
</tr>

Format</p></td>
must</strong> conform to the Bytecode Object</a> format.</p></td>
</tr>
</tbody>
</table>
Runtime Bytecode: runtime_bytecode</code></h4>
The runtime_bytecode</code> field defines the unlinked 0x</code>-prefixed runtime
portion of Bytecode</a> for this Contract
Type</a>.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Type</p></td>
Object</p></td>
</tr>

Format</p></td>
must</strong> conform to the Bytecode Object</a> format.</p></td>
</tr>
</tbody>
</table>
ABI: abi</code></h4>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Type</p></td>
List</p></td>
</tr>

Format</p></td>
must</strong> conform to the Ethereum Contract ABI JSON format</a>.</p></td>
</tr>
</tbody>
</table>
Natspec: natspec</code></h4>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Type</p></td>
Object</p></td>
</tr>

Format</p></td>
The union of the UserDoc</a> and DevDoc</a> formats.</p></td>
</tr>
</tbody>
</table>
Compiler: compiler</code></h4>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Type</p></td>
Object</p></td>
</tr>

Format</p></td>
must</strong> conform to the Compiler Information object</a> format.</p></td>
</tr>
</tbody>
</table>
</div>
The Contract Instance</em> Object</h3>
A Contract Instance Object</strong> represents a single deployed Contract
Instance</a> and is defined to have the following
key/value pairs.</p>
Contract Type: contract_type</code></h4>
The contract_type</code> field defines the Contract
Type</a> for this Contract
Instance</a>. This can reference any of the
contract types included in this Package</a> or</em> any of the
contract types found in any of the package dependencies from the
build_dependencies</code> section of the Package
Manifest</a>.</p>
</colgroup>






Required</p></td>
Yes</p></td>
</tr>

Type</p></td>
String</p></td>
</tr>

Format</p></td>
See Below.</p></td>
</tr>
</tbody>
</table>
Format</strong></p>
Values for this field must</strong> conform to one of</em> the two formats
herein.</p>
To reference a contract type from this Package, use the format
<contract-alias></code>.</p>


The <contract-alias></code> value must</strong> be a valid Contract
Alias</a>.</p>
</li>

The value must</strong> be present in the keys of the contract_types</code>
section of this Package.</p>
</li>
</ul>
To reference a contract type from a dependency, use the format
<package-name>:<contract-alias></code>.</p>


The <package-name></code> value must</strong> be present in the keys of the
build_dependencies</code> of this Package.</p>
</li>

The <contract-alias></code> value must</strong> be a valid Contract
Alias</a>.</p>
</li>

The resolved package for <package-name></code> must contain the
<contract-alias></code> value in the keys of the contract_types</code>
section.</p>
</li>
</ul>
Address: address</code></h4>
The address</code> field defines the Address</a> of the
Contract Instance</a>.</p>
</colgroup>






Required</p></td>
Yes</p></td>
</tr>

Type</p></td>
String</p></td>
</tr>

Format</p></td>
Hex encoded 0x</code> prefixed Ethereum address matching the regular expression 0x[0-9a-fA-F]{40}</code>.</p></td>
</tr>
</tbody>
</table>
Transaction: transaction</code></h4>
The transaction</code> field defines the transaction hash in which this
Contract Instance</a> was created.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Type</p></td>
String</p></td>
</tr>

Format</p></td>
0x</code> prefixed hex encoded transaction hash.</p></td>
</tr>
</tbody>
</table>
Block: block</code></h4>
The block</code> field defines the block hash in which this the transaction
which created this contract instance</em> was mined.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Type</p></td>
String</p></td>
</tr>

Format</p></td>
0x</code> prefixed hex encoded block hash.</p></td>
</tr>
</tbody>
</table>
</div>
Runtime Bytecode: runtime_bytecode</code></h4>
The runtime_bytecode</code> field defines the runtime portion of bytecode for
this Contract Instance</a>. When present, the
value from this field supersedes the runtime_bytecode</code> from the
Contract Type</a> for this Contract
Instance</a>.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Type</p></td>
Object</p></td>
</tr>

Format</p></td>
must</strong> conform to the Bytecode Object</a> format.</p></td>
</tr>
</tbody>
</table>
Every entry in the link_references</code> for this bytecode must</strong> have a
corresponding entry in the link_dependencies</code> section.</p>
Compiler: compiler</code></h4>
The compiler</code> field defines the compiler information that was used
during compilation of this Contract Instance</a>.
This field should</strong> be present in all Contract
Types</a> which include bytecode</code> or
runtime_bytecode</code>.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Type</p></td>
Object</p></td>
</tr>

Format</p></td>
must</strong> conform to the Compiler Information Object</a> format.</p></td>
</tr>
</tbody>
</table>
</div>
The Compiler Information</em> Object</h3>
The compiler</code> field defines the compiler information that was used
during compilation of this Contract Instance</a>.
This field should</strong> be present in all contract instances that locally
declare runtime_bytecode</code>.</p>
A Compiler Information</em> object is defined to have the following
key/value pairs.</p>
Name name</code></h4>
The name</code> field defines which compiler was used in compilation.</p>
</colgroup>






Required</p></td>
Yes</p></td>
</tr>

Key</p></td>
name</code></p></td>
</tr>

Type</p></td>
String</p></td>
</tr>
</tbody>
</table>
Version: version</code></h4>
The version</code> field defines the version of the compiler. The field
should</strong> be OS agnostic (OS not included in the string) and take the
form of either the stable version in
semver</a> format or if built on a
nightly should be denoted in the form of <semver>-<commit-hash></code> ex:
0.4.8-commit.60cc1668</code>.</p>
</colgroup>






Required</p></td>
Yes</p></td>
</tr>

Key</p></td>
version</code></p></td>
</tr>

Type</p></td>
String</p></td>
</tr>
</tbody>
</table>
Settings: settings</code></h4>
The settings</code> field defines any settings or configuration that was used
in compilation. For the "solc"</code> compiler, this should</strong> conform to
the Compiler Input and Output
Description</a>.</p>
</colgroup>






Required</p></td>
No</p></td>
</tr>

Key</p></td>
settings</code></p></td>
</tr>

Type</p></td>
Object</p></td>
</tr>
</tbody>
</table>
BIP122 URIs</h3>
BIP122 URIs are used to define a blockchain via a subset of the
BIP-122</a>
spec.</p>
blockchain://<genesis_hash>/block/<latest confirmed block hash></span></span></code></pre>
The <genesis hash></code> represents the blockhash of the first block on the
chain, and <latest confirmed block hash></code> represents the hash of the
latest block that’s been reliably confirmed (package managers should be
free to choose their desired level of confirmations).</p>
Rationale</h1>
The following use cases were considered during the creation of this
specification.</p>
</colgroup>






owned</p></td>
A package which contains contracts which are not meant to be used by themselves but rather as base contracts to provide functionality to other contracts through inheritance.</p></td>
</tr>

transferable</p></td>
A package which has a single dependency.</p></td>
</tr>

standard-token</p></td>
A package which contains a reusable contract.</p></td>
</tr>

safe-math-lib</p></td>
A package which contains deployed instance of one of the package contracts.</p></td>
</tr>

piper-coin</p></td>
A package which contains a deployed instance of a reusable contract from a dependency.</p></td>
</tr>

escrow</p></td>
A package which contains a deployed instance of a local contract which is linked against a deployed instance of a local library.</p></td>
</tr>

wallet</p></td>
A package with a deployed instance of a local contract which is linked against a deployed instance of a library from a dependency.</p></td>
</tr>

wallet-with-send</p></td>
A package with a deployed instance which links against a deep dependency.</p></td>
</tr>
</tbody>
</table>
Each use case builds incrementally on the previous one.</p>
A full listing of Use
Cases</a>
can be found on the hosted version of this specification.</p>
Glossary</h1>
</div>
ABI</h2>
The JSON representation of the application binary interface. See the
official
specification</a>
for more information.</p>
</div>
Address</h2>
A public identifier for an account on a particular chain</p>
</div>
Bytecode</h2>
The set of EVM instructions as produced by a compiler. Unless otherwise
specified this should be assumed to be hexadecimal encoded, representing
a whole number of bytes, and prefixed</a> with 0x</code>.</p>
Bytecode can either be linked or unlinked. (see
Linking</a>)</p>
</colgroup>






Unlinked Bytecode</p></td>
The hexadecimal representation of a contract’s EVM instructions that contains sections of code that requires linking</a> for the contract to be functional.</p>
The sections of code which are unlinked must</strong> be filled in with zero bytes.</p>
Example</strong>: 0x606060405260e06000730000000000000000000000000000000000000000634d536f</code></p></td>
</tr>

Linked Bytecode</p></td>
The hexadecimal representation of a contract’s EVM instructions which has had all Link References</a> replaced with the desired Link Values</a>.</p>
Example</strong>: 0x606060405260e06000736fe36000604051602001526040518160e060020a634d536f</code></p></td>
</tr>
</tbody>
</table>
</div>
Chain Definition</h2>
This definition originates from BIP122
URI</a>.</p>
A URI in the format blockchain://<chain_id>/block/<block_hash></code></p>


chain_id</code> is the unprefixed hexadecimal representation of the
genesis hash for the chain.</p>
</li>

block_hash</code> is the unprefixed hexadecimal representation of the
hash of a block on the chain.</p>
</li>
</ul>
A chain is considered to match a chain definition if the genesis
block hash matches the chain_id</code> and the block defined by block_hash</code>
can be found on that chain. It is possible for multiple chains to match
a single URI, in which case all chains are considered valid matches</p>
</div>
Content Addressable URI</h2>
Any URI which contains a cryptographic hash which can be used to verify
the integrity of the content found at the URI.</p>
The URI format is defined in RFC3986</p>
It is recommended</strong> that tools support IPFS and Swarm.</p>
</div>
Contract Alias</h2>
This is a name used to reference a specific Contract
Type</a>. Contract aliases must</strong> be unique within a
single Package</a>.</p>
The contract alias must</strong> use one of</em> the following naming schemes:</p>


<contract-name></code></p>
</li>

<contract-name>[<identifier>]</code></p>
</li>
</ul>
The <contract-name></code> portion must</strong> be the same as the Contract
Name</a> for this contract type.</p>
The [<identifier>]</code> portion must</strong> match the regular expression
\[[-a-zA-Z0-9]{1,256}]</code>.</p>
</div>
Contract Instance</h2>
A contract instance a specific deployed version of a Contract
Type</a>.</p>
All contract instances have an Address</a> on some specific
chain.</p>
</div>
Contract Instance Name</h2>
A name which refers to a specific Contract
Instance</a> on a specific chain from the
deployments of a single Package</a>. This name must</strong> be
unique across all other contract instances for the given chain. The name
must conform to the regular expression [a-zA-Z][a-zA-Z0-9_]{0,255}</code></p>
In cases where there is a single deployed instance of a given Contract
Type</a>, package managers should</strong> use the
Contract Alias</a> for that contract type for this
name.</p>
In cases where there are multiple deployed instances of a given contract
type, package managers should</strong> use a name which provides some added
semantic information as to help differentiate the two deployed instances
in a meaningful way.</p>
</div>
Contract Name</h2>
The name found in the source code that defines a specific Contract
Type</a>. These names must</strong> conform to the regular
expression [a-zA-Z][-a-zA-Z0-9_]{0,255}</code>.</p>
There can be multiple contracts with the same contract name in a
projects source files.</p>
</div>
Contract Type</h2>
Refers to a specific contract in the package source. This term can be
used to refer to an abstract contract, a normal contract, or a library.
Two contracts are of the same contract type if they have the same
bytecode.</p>
Example:</p>
contract Wallet {</span></span>
    ...</span></span>
}</span></span></code></pre>
A deployed instance of the Wallet</code> contract would be of type
Wallet</code>.</p>
</div>
Identifier</h2>
Refers generally to a named entity in the Package</a>.</p>
A string matching the regular expression [a-zA-Z][-_a-zA-Z0-9]{0,255}</code></p>
</div>
Link Reference</h2>
A location within a contract’s bytecode which needs to be linked. A link
reference has the following properties.</p>
</colgroup>






offset</code></p></td>
Defines the location within the bytecode where the link reference begins.</p></td>
</tr>

length</code></p></td>
Defines the length of the reference.</p></td>
</tr>

name</code></p></td>
(optional.) A string to identify the reference</p></td>
</tr>
</tbody>
</table>
</div>
Link Value</h2>
A link value is the value which can be inserted in place of a Link
Reference</a></p>
</div>
Linking</h2>
The act of replacing Link References</a> with Link
Values</a> within some Bytecode</a>.</p>
</div>
Package</h2>
Distribution of an application’s source or compiled bytecode along with
metadata related to authorship, license, versioning, et al.</p>
For brevity, the term Package</strong> is often used metonymously to mean
Package Manifest</a>.</p>
</div>
Package Manifest</h2>
A machine-readable description of a package (See
Specification</a> for information about the format
for package manifests.)</p>
</div>
Prefixed</h2>
Bytecode</a> string with leading 0x</code>.</p>
</colgroup>






Example</p></td>
0xdeadbeef</code></p></td>
</tr>
</tbody>
</table>
</div>
Unprefixed</h2>
Not Prefixed</a>.</p>
</colgroup>






Example</p></td>
deadbeef</code></p></td>
</tr>
</tbody>
</table>
Backwards Compatibility</h1>
This specification supports backwards compatibility by use of the
manifest_version</a> property. This
specification corresponds to version 2</code> as the value for that field.</p>
Implementations</h1>
This submission aims to coincide with development efforts towards
widespread implementation in commonly-used development tools.</p>
The following tools are known to have begun or are nearing completion of
a supporting implementation.</p>


Truffle</a></p>
</li>

Populus</a></p>
</li>

Embark</a></p>
</li>
</ul>
Full support in implementation may</strong> require Further
Work</a>, specified below.</p>
Further Work</h1>
This EIP addresses only the data format for package descriptions.
Excluded from the scope of this specification are:</p>


Package registry interface definition</p>
</li>

Tooling integration, or how packages are stored on disk.</p>
</li>
</ul>
These efforts should</strong> be considered separate, warranting future
dependent EIP submssions.</p>
Acknowledgements</h1>
The authors of this document would like to thank the original authors of
EIP-190</a>,
ETHPrize</a> for their funding
support, all community
contributors</a>,
and the Ethereum community at large.</p>
Copyright</h1>
Copyright and related rights waived via CC0</a>.</p>


Restore Contract Code at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4
2018-04-04T00:00:00+00:00
Simple Summary</h2>
This document proposes to restore the contract code of the WalletLibrary</code>
contract at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4</code> with a patched version.
The contract was accidentally self-destructed and renders a significant amount
of Ether inaccessible.</p>
Abstract</h2>
The WalletLibrary</code> contract was used by the
Parity Wallet</a> to reduce gas costs for users deploying
multi-signature wallets on the Ethereum blockchain. It contained basic
functionality such as confirming or revoking multi-signature transactions for
any wallet deployed that depends on this library. The
accidental self-destruction</a>
of the library contract caused significant amounts of Ether and other assets
owned by many different parties to be inaccessible. This proposal suggests
restoring the WalletLibrary</code> by a
patched</a> version to allow the
owners of the dependent multi-signature wallets regain access to their assets.</p>
Motivation</h2>
This proposal is necessary because the Ethereum protocol does not allow the
restoration of self-destructed contracts and there is no other simple way to
enable the affected users and companies regaining access to their tokens and
Ether. In opposite to previously discussed proposals, this will not change any
EVM semantics and tries to achieve the goal of unfreezing the funds by a single
state transition as specified in the next section.</p>
Specification</h2>
The self-destructed contract code at
0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4</code></a>
shall be replaced with a patched version of the
walletLibrary.sol</code></a>
as reviewed, tested, and approved in
parity-contracts/0x863df6bfa4</a>:</p>
{</span></span>
	"</span>object</span>"</span>:</span> "</span>606060405234156200000d57fe5b5b6000808054806001018281620000259190620002d9565b916000526020600020900160005b6000909190916101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff160217905550506200012081805480602002602001604051908101604052809291908181526020018280548015620000fd57602002820191906000526020600020905b8160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019060010190808311620000b2575b505050505060016000620001286401000000000262001d46176401000000009004565b5b5062000330565b600060015411156200013a5760006000fd5b6200015981620001806401000000000262001d71176401000000009004565b620001798383620001c26401000000000262001d9c176401000000009004565b5b5b505050565b60006001541115620001925760006000fd5b80600281905550620001b7620002c16401000000000262001bcf176401000000009004565b6004819055505b5b50565b600060006001541115620001d65760006000fd5b600082111515620001e75760006000fd5b81835110151515620001f95760006000fd5b8251600181905550600090505b8251811015620002b35782818151811015156200021f57fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff16600582600101610100811015156200025357fe5b0160005b508190555080600101610105600085848151811015156200027457fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b80600101905062000206565b816000819055505b5b505050565b60006201518042811515620002d257fe5b0490505b90565b815481835581811511620003035781836000526020600020918201910162000302919062000308565b5b505050565b6200032d91905b80821115620003295760008160009055506001016200030f565b5090565b90565b611ebf80620003406000396000f300606060405236156100ef576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063173825d91461016d5780632f54bf6e146101a35780634123cb6b146101f157806352375093146102175780635c52c2f51461023d578063659010e71461024f5780637065cb4814610275578063746c9171146102ab578063797af627146102d1578063b20d30a91461030d578063b61d27f61461032d578063b75c7dc61461039c578063ba51a6df146103c0578063c2cf7326146103e0578063c41a360a1461043b578063f00d4b5d1461049b578063f1736d86146104f0575b61016b5b6000341115610168577fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c3334604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018281526020019250505060405180910390a15b5b565b005b341561017557fe5b6101a1600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610516565b005b34156101ab57fe5b6101d7600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610659565b604051808215151515815260200191505060405180910390f35b34156101f957fe5b610201610691565b6040518082815260200191505060405180910390f35b341561021f57fe5b610227610697565b6040518082815260200191505060405180910390f35b341561024557fe5b61024d61069d565b005b341561025757fe5b61025f6106d7565b6040518082815260200191505060405180910390f35b341561027d57fe5b6102a9600480803573ffffffffffffffffffffffffffffffffffffffff169060200190919050506106dd565b005b34156102b357fe5b6102bb610829565b6040518082815260200191505060405180910390f35b34156102d957fe5b6102f360048080356000191690602001909190505061082f565b604051808215151515815260200191505060405180910390f35b341561031557fe5b61032b6004808035906020019091905050610dcc565b005b341561033557fe5b61037e600480803573ffffffffffffffffffffffffffffffffffffffff169060200190919080359060200190919080359060200190820180359060200191909192905050610e06565b60405180826000191660001916815260200191505060405180910390f35b34156103a457fe5b6103be60048080356000191690602001909190505061127d565b005b34156103c857fe5b6103de6004808035906020019091905050611392565b005b34156103e857fe5b61042160048080356000191690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190505061141a565b604051808215151515815260200191505060405180910390f35b341561044357fe5b610459600480803590602001909190505061149c565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34156104a357fe5b6104ee600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff169060200190919050506114bf565b005b34156104f857fe5b610500611672565b6040518082815260200191505060405180910390f35b600060003660405180838380828437820191505092505050604051809103902061053f81611678565b156106535761010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561057f57610652565b600160015403600054111561059357610652565b6000600583610100811015156105a557fe5b0160005b5081905550600061010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055506105e6611890565b6105ee6119d0565b7f58619076adf5bb0943d100ef88d52d7c3fd691b19d3a9071b555b651fbf418da83604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390a15b5b5b505050565b6000600061010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541190505b919050565b60015481565b60045481565b6000366040518083838082843782019150509250505060405180910390206106c481611678565b156106d35760006003819055505b5b5b50565b60035481565b60003660405180838380828437820191505092505050604051809103902061070481611678565b156108245761071282610659565b1561071c57610823565b610724611890565b60fa600154101515610739576107386119d0565b5b60fa60015410151561074a57610823565b6001600081548092919060010191905055508173ffffffffffffffffffffffffffffffffffffffff1660056001546101008110151561078557fe5b0160005b508190555060015461010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055507f994a936646fe87ffe4f1e469d3d6aa417d6b855598397f323de5b449f765f0c382604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390a15b5b5b5050565b60005481565b600060008261083d81611678565b15610dc45760006101086000866000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff161415806108c757506000610108600086600019166000191681526020019081526020016000206001015414155b80610906575060006101086000866000191660001916815260200190815260200160002060020180546001816001161561010002031660029004905014155b15610dc25760006101086000866000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff161415610a5057610a496101086000866000191660001916815260200190815260200160002060010154610108600087600019166000191681526020019081526020016000206002018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610a3f5780601f10610a1457610100808354040283529160200191610a3f565b820191906000526020600020905b815481529060010190602001808311610a2257829003601f168201915b5050505050611b37565b9150610b71565b6101086000856000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166101086000866000191660001916815260200190815260200160002060010154610108600087600019166000191681526020019081526020016000206002016040518082805460018160011615610100020316600290048015610b4a5780601f10610b1f57610100808354040283529160200191610b4a565b820191906000526020600020905b815481529060010190602001808311610b2d57829003601f168201915b505091505060006040518083038185876185025a03f1925050501515610b705760006000fd5b5b7fe3a3a4111a84df27d76b68dc721e65c7711605ea5eee4afd3a9c58195217365c338561010860008860001916600019168152602001908152602001600020600101546101086000896000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1661010860008a6000191660001916815260200190815260200160002060020187604051808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200186600019166000191681526020018581526020018473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001828103825284818154600181600116156101000203166002900481526020019150805460018160011615610100020316600290048015610d475780601f10610d1c57610100808354040283529160200191610d47565b820191906000526020600020905b815481529060010190602001808311610d2a57829003601f168201915b505097505050505050505060405180910390a16101086000856000191660001916815260200190815260200160002060006000820160006101000a81549073ffffffffffffffffffffffffffffffffffffffff02191690556001820160009055600282016000610db79190611be6565b505060019250610dc3565b5b5b5b5050919050565b600036604051808383808284378201915050925050506040518091039020610df381611678565b15610e0157816002819055505b5b5b5050565b60006000610e1333610659565b1561127357600084849050148015610e305750610e2f85611b51565b5b80610e3d57506001600054145b15610fed5760008673ffffffffffffffffffffffffffffffffffffffff161415610ea457610e9d8585858080601f016020809104026020016040519081016040528093929190818152602001838380828437820191505050505050611b37565b9050610ef3565b8573ffffffffffffffffffffffffffffffffffffffff168585856040518083838082843782019150509250505060006040518083038185876185025a03f1925050501515610ef25760006000fd5b5b7f9738cd1a8777c86b011f7b01d87d484217dc6ab5154a9d41eda5d14af8caf292338688878786604051808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018681526020018573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018281038252858582818152602001925080828437820191505097505050505050505060405180910390a1611271565b6000364360405180848480828437820191505082815260200193505050506040518091039020915060006101086000846000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16148015611099575060006101086000846000191660001916815260200190815260200160002060010154145b80156110d85750600061010860008460001916600019168152602001908152602001600020600201805460018160011615610100020316600290049050145b1561118f57856101086000846000191660001916815260200190815260200160002060000160006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff160217905550846101086000846000191660001916815260200190815260200160002060010181905550838361010860008560001916600019168152602001908152602001600020600201919061118d929190611c2e565b505b6111988261082f565b1515611270577f1733cbb53659d713b79580f79f3f9ff215f78a7c7aa45890f3b89fc5cddfbf328233878988886040518087600019166000191681526020018673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018581526020018473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018281038252848482818152602001925080828437820191505097505050505050505060405180910390a15b5b5b5b5b50949350505050565b60006000600061010560003373ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054925060008314156112be5761138c565b8260020a9150610106600085600019166000191681526020019081526020016000209050600082826001015416111561138b5780600001600081548092919060010191905055508181600101600082825403925050819055507fc7fb647e59b18047309aa15aad418e5d7ca96d173ad704f1031a2c3d7591734b3385604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200182600019166000191681526020019250505060405180910390a15b5b50505050565b6000366040518083838082843782019150509250505060405180910390206113b981611678565b15611415576001548211156113cd57611414565b816000819055506113dc611890565b7facbdb084c721332ac59f9b8e392196c9eb0e4932862da8eb9beaf0dad4f550da826040518082815260200191505060405180910390a15b5b5b5050565b600060006000600061010660008760001916600019168152602001908152602001600020925061010560008673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561147f5760009350611493565b8160020a9050600081846001015416141593505b50505092915050565b6000600560018301610100811015156114b157fe5b0160005b505490505b919050565b60006000366040518083838082843782019150509250505060405180910390206114e881611678565b1561166b576114f683610659565b156115005761166a565b61010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561153b5761166a565b611543611890565b8273ffffffffffffffffffffffffffffffffffffffff166005836101008110151561156a57fe5b0160005b5081905550600061010560008673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508161010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055507fb532073b38c83145e3e5135377a08bf9aab55bc0fd7c1179cd4fb995d2a5159c8484604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019250505060405180910390a15b5b5b50505050565b60025481565b600060006000600061010560003373ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054925060008314156116bb57611888565b6101066000866000191660001916815260200190815260200160002091506000826000015414156117455760005482600001819055506000826001018190555061010780548091906001016117109190611cae565b826002018190555084610107836002015481548110151561172d57fe5b906000526020600020900160005b5081600019169055505b8260020a90506000818360010154161415611887577fe1c52dc63b719ade82e8bea94cc41a0d5d28e4aaf536adb5e9cccc9ff8c1aeda3386604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200182600019166000191681526020019250505060405180910390a16001826000015411151561185e57610107610106600087600019166000191681526020019081526020016000206002015481548110151561180a57fe5b906000526020600020900160005b5060009055610106600086600019166000191681526020019081526020016000206000600082016000905560018201600090556002820160009055505060019350611888565b8160000160008154809291906001900391905055508082600101600082825417925050819055505b5b5b505050919050565b60006000610107805490509150600090505b818110156119bc576101086000610107838154811015156118bf57fe5b906000526020600020900160005b50546000191660001916815260200190815260200160002060006000820160006101000a81549073ffffffffffffffffffffffffffffffffffffffff021916905560018201600090556002820160006119269190611be6565b505060006001026101078281548110151561193d57fe5b906000526020600020900160005b5054600019161415156119b05761010660006101078381548110151561196d57fe5b906000526020600020900160005b505460001916600019168152602001908152602001600020600060008201600090556001820160009055600282016000905550505b5b8060010190506118a2565b61010760006119cb9190611cda565b5b5050565b6000600190505b600154811015611b33575b60015481108015611a095750600060058261010081101515611a0057fe5b0160005b505414155b15611a1b5780806001019150506119e2565b5b6001600154118015611a4557506000600560015461010081101515611a3d57fe5b0160005b5054145b15611a625760016000815480929190600190039190505550611a1c565b60015481108015611a8b57506000600560015461010081101515611a8257fe5b0160005b505414155b8015611aac5750600060058261010081101515611aa457fe5b0160005b5054145b15611b2e57600560015461010081101515611ac357fe5b0160005b505460058261010081101515611ad957fe5b0160005b508190555080610105600060058461010081101515611af857fe5b0160005b50548152602001908152602001600020819055506000600560015461010081101515611b2457fe5b0160005b50819055505b6119d7565b5b50565b600081516020830184f09050803b15610000575b92915050565b6000611b5c33610659565b15611bc957600454611b6c611bcf565b1115611b89576000600381905550611b82611bcf565b6004819055505b600354826003540110158015611ba55750600254826003540111155b15611bc3578160036000828254019250508190555060019050611bc8565b600090505b5b5b919050565b60006201518042811515611bdf57fe5b0490505b90565b50805460018160011615610100020316600290046000825580601f10611c0c5750611c2b565b601f016020900490600052602060002090810190611c2a9190611cfc565b5b50565b828054600181600116156101000203166002900490600052602060002090601f016020900481019282601f10611c6f57803560ff1916838001178555611c9d565b82800160010185558215611c9d579182015b82811115611c9c578235825591602001919060010190611c81565b5b509050611caa9190611cfc565b5090565b815481835581811511611cd557818360005260206000209182019101611cd49190611d21565b5b505050565b5080546000825590600052602060002090810190611cf89190611d21565b5b50565b611d1e91905b80821115611d1a576000816000905550600101611d02565b5090565b90565b611d4391905b80821115611d3f576000816000905550600101611d27565b5090565b90565b60006001541115611d575760006000fd5b611d6081611d71565b611d6a8383611d9c565b5b5b505050565b60006001541115611d825760006000fd5b80600281905550611d91611bcf565b6004819055505b5b50565b600060006001541115611daf5760006000fd5b600082111515611dbf5760006000fd5b81835110151515611dd05760006000fd5b8251600181905550600090505b8251811015611e85578281815181101515611df457fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff1660058260010161010081101515611e2757fe5b0160005b50819055508060010161010560008584815181101515611e4757fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b806001019050611ddd565b816000819055505b5b5050505600a165627a7a7230582016889f0740f073d397f9d00b0d19900fb050b957e3e2942f861085beb9baab180029</span>"</span>,</span></span>
	"</span>opcodes</span>"</span>:</span> "</span>PUSH1 0x60 PUSH1 0x40 MSTORE CALLVALUE ISZERO PUSH3 0xD JUMPI INVALID JUMPDEST JUMPDEST PUSH1 0x0 DUP1 DUP1 SLOAD DUP1 PUSH1 0x1 ADD DUP3 DUP2 PUSH3 0x25 SWAP2 SWAP1 PUSH3 0x2D9 JUMP JUMPDEST SWAP2 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST PUSH1 0x0 SWAP1 SWAP2 SWAP1 SWAP2 PUSH2 0x100 EXP DUP2 SLOAD DUP2 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MUL NOT AND SWAP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND MUL OR SWAP1 SSTORE POP POP PUSH3 0x120 DUP2 DUP1 SLOAD DUP1 PUSH1 0x20 MUL PUSH1 0x20 ADD PUSH1 0x40 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 SWAP3 SWAP2 SWAP1 DUP2 DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP1 SLOAD DUP1 ISZERO PUSH3 0xFD JUMPI PUSH1 0x20 MUL DUP3 ADD SWAP2 SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 JUMPDEST DUP2 PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 PUSH1 0x1 ADD SWAP1 DUP1 DUP4 GT PUSH3 0xB2 JUMPI JUMPDEST POP POP POP POP POP PUSH1 0x1 PUSH1 0x0 PUSH3 0x128 PUSH5 0x100000000 MUL PUSH3 0x1D46 OR PUSH5 0x100000000 SWAP1 DIV JUMP JUMPDEST JUMPDEST POP PUSH3 0x330 JUMP JUMPDEST PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH3 0x13A JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST PUSH3 0x159 DUP2 PUSH3 0x180 PUSH5 0x100000000 MUL PUSH3 0x1D71 OR PUSH5 0x100000000 SWAP1 DIV JUMP JUMPDEST PUSH3 0x179 DUP4 DUP4 PUSH3 0x1C2 PUSH5 0x100000000 MUL PUSH3 0x1D9C OR PUSH5 0x100000000 SWAP1 DIV JUMP JUMPDEST JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH3 0x192 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP1 PUSH1 0x2 DUP2 SWAP1 SSTORE POP PUSH3 0x1B7 PUSH3 0x2C1 PUSH5 0x100000000 MUL PUSH3 0x1BCF OR PUSH5 0x100000000 SWAP1 DIV JUMP JUMPDEST PUSH1 0x4 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH3 0x1D6 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST PUSH1 0x0 DUP3 GT ISZERO ISZERO PUSH3 0x1E7 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP2 DUP4 MLOAD LT ISZERO ISZERO ISZERO PUSH3 0x1F9 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP3 MLOAD PUSH1 0x1 DUP2 SWAP1 SSTORE POP PUSH1 0x0 SWAP1 POP JUMPDEST DUP3 MLOAD DUP2 LT ISZERO PUSH3 0x2B3 JUMPI DUP3 DUP2 DUP2 MLOAD DUP2 LT ISZERO ISZERO PUSH3 0x21F JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x20 ADD SWAP1 PUSH1 0x20 MUL ADD MLOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH1 0x5 DUP3 PUSH1 0x1 ADD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH3 0x253 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP DUP1 PUSH1 0x1 ADD PUSH2 0x105 PUSH1 0x0 DUP6 DUP5 DUP2 MLOAD DUP2 LT ISZERO ISZERO PUSH3 0x274 JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x20 ADD SWAP1 PUSH1 0x20 MUL ADD MLOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP JUMPDEST DUP1 PUSH1 0x1 ADD SWAP1 POP PUSH3 0x206 JUMP JUMPDEST DUP2 PUSH1 0x0 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST PUSH1 0x0 PUSH3 0x15180 TIMESTAMP DUP2 ISZERO ISZERO PUSH3 0x2D2 JUMPI INVALID JUMPDEST DIV SWAP1 POP JUMPDEST SWAP1 JUMP JUMPDEST DUP2 SLOAD DUP2 DUP4 SSTORE DUP2 DUP2 ISZERO GT PUSH3 0x303 JUMPI DUP2 DUP4 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP2 DUP3 ADD SWAP2 ADD PUSH3 0x302 SWAP2 SWAP1 PUSH3 0x308 JUMP JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST PUSH3 0x32D SWAP2 SWAP1 JUMPDEST DUP1 DUP3 GT ISZERO PUSH3 0x329 JUMPI PUSH1 0x0 DUP2 PUSH1 0x0 SWAP1 SSTORE POP PUSH1 0x1 ADD PUSH3 0x30F JUMP JUMPDEST POP SWAP1 JUMP JUMPDEST SWAP1 JUMP JUMPDEST PUSH2 0x1EBF DUP1 PUSH3 0x340 PUSH1 0x0 CODECOPY PUSH1 0x0 RETURN STOP PUSH1 0x60 PUSH1 0x40 MSTORE CALLDATASIZE ISZERO PUSH2 0xEF JUMPI PUSH1 0x0 CALLDATALOAD PUSH29 0x100000000000000000000000000000000000000000000000000000000 SWAP1 DIV PUSH4 0xFFFFFFFF AND DUP1 PUSH4 0x173825D9 EQ PUSH2 0x16D JUMPI DUP1 PUSH4 0x2F54BF6E EQ PUSH2 0x1A3 JUMPI DUP1 PUSH4 0x4123CB6B EQ PUSH2 0x1F1 JUMPI DUP1 PUSH4 0x52375093 EQ PUSH2 0x217 JUMPI DUP1 PUSH4 0x5C52C2F5 EQ PUSH2 0x23D JUMPI DUP1 PUSH4 0x659010E7 EQ PUSH2 0x24F JUMPI DUP1 PUSH4 0x7065CB48 EQ PUSH2 0x275 JUMPI DUP1 PUSH4 0x746C9171 EQ PUSH2 0x2AB JUMPI DUP1 PUSH4 0x797AF627 EQ PUSH2 0x2D1 JUMPI DUP1 PUSH4 0xB20D30A9 EQ PUSH2 0x30D JUMPI DUP1 PUSH4 0xB61D27F6 EQ PUSH2 0x32D JUMPI DUP1 PUSH4 0xB75C7DC6 EQ PUSH2 0x39C JUMPI DUP1 PUSH4 0xBA51A6DF EQ PUSH2 0x3C0 JUMPI DUP1 PUSH4 0xC2CF7326 EQ PUSH2 0x3E0 JUMPI DUP1 PUSH4 0xC41A360A EQ PUSH2 0x43B JUMPI DUP1 PUSH4 0xF00D4B5D EQ PUSH2 0x49B JUMPI DUP1 PUSH4 0xF1736D86 EQ PUSH2 0x4F0 JUMPI JUMPDEST PUSH2 0x16B JUMPDEST PUSH1 0x0 CALLVALUE GT ISZERO PUSH2 0x168 JUMPI PUSH32 0xE1FFFCC4923D04B559F4D29A8BFC6CDA04EB5B0D3C460751C2402C5C5CC9109C CALLER CALLVALUE PUSH1 0x40 MLOAD DUP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x175 JUMPI INVALID JUMPDEST PUSH2 0x1A1 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x516 JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x1AB JUMPI INVALID JUMPDEST PUSH2 0x1D7 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x659 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 ISZERO ISZERO ISZERO ISZERO DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x1F9 JUMPI INVALID JUMPDEST PUSH2 0x201 PUSH2 0x691 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x21F JUMPI INVALID JUMPDEST PUSH2 0x227 PUSH2 0x697 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x245 JUMPI INVALID JUMPDEST PUSH2 0x24D PUSH2 0x69D JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x257 JUMPI INVALID JUMPDEST PUSH2 0x25F PUSH2 0x6D7 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x27D JUMPI INVALID JUMPDEST PUSH2 0x2A9 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x6DD JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x2B3 JUMPI INVALID JUMPDEST PUSH2 0x2BB PUSH2 0x829 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x2D9 JUMPI INVALID JUMPDEST PUSH2 0x2F3 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH1 0x0 NOT AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x82F JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 ISZERO ISZERO ISZERO ISZERO DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x315 JUMPI INVALID JUMPDEST PUSH2 0x32B PUSH1 0x4 DUP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0xDCC JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x335 JUMPI INVALID JUMPDEST PUSH2 0x37E PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 DUP3 ADD DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP2 SWAP1 SWAP2 SWAP3 SWAP1 POP POP PUSH2 0xE06 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x3A4 JUMPI INVALID JUMPDEST PUSH2 0x3BE PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH1 0x0 NOT AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x127D JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x3C8 JUMPI INVALID JUMPDEST PUSH2 0x3DE PUSH1 0x4 DUP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x1392 JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x3E8 JUMPI INVALID JUMPDEST PUSH2 0x421 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH1 0x0 NOT AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x141A JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 ISZERO ISZERO ISZERO ISZERO DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x443 JUMPI INVALID JUMPDEST PUSH2 0x459 PUSH1 0x4 DUP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x149C JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST CALLVALUE ISZERO PUSH2 0x4A3 JUMPI INVALID JUMPDEST PUSH2 0x4EE PUSH1 0x4 DUP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 DUP1 CALLDATALOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND SWAP1 PUSH1 0x20 ADD SWAP1 SWAP2 SWAP1 POP POP PUSH2 0x14BF JUMP JUMPDEST STOP JUMPDEST CALLVALUE ISZERO PUSH2 0x4F8 JUMPI INVALID JUMPDEST PUSH2 0x500 PUSH2 0x1672 JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x0 PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0x53F DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0x653 JUMPI PUSH2 0x105 PUSH1 0x0 DUP5 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD SWAP2 POP PUSH1 0x0 DUP3 EQ ISZERO PUSH2 0x57F JUMPI PUSH2 0x652 JUMP JUMPDEST PUSH1 0x1 PUSH1 0x1 SLOAD SUB PUSH1 0x0 SLOAD GT ISZERO PUSH2 0x593 JUMPI PUSH2 0x652 JUMP JUMPDEST PUSH1 0x0 PUSH1 0x5 DUP4 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x5A5 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP PUSH1 0x0 PUSH2 0x105 PUSH1 0x0 DUP6 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP PUSH2 0x5E6 PUSH2 0x1890 JUMP JUMPDEST PUSH2 0x5EE PUSH2 0x19D0 JUMP JUMPDEST PUSH32 0x58619076ADF5BB0943D100EF88D52D7C3FD691B19D3A9071B555B651FBF418DA DUP4 PUSH1 0x40 MLOAD DUP1 DUP3 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH2 0x105 PUSH1 0x0 DUP5 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD GT SWAP1 POP JUMPDEST SWAP2 SWAP1 POP JUMP JUMPDEST PUSH1 0x1 SLOAD DUP2 JUMP JUMPDEST PUSH1 0x4 SLOAD DUP2 JUMP JUMPDEST PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0x6C4 DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0x6D3 JUMPI PUSH1 0x0 PUSH1 0x3 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST JUMPDEST POP JUMP JUMPDEST PUSH1 0x3 SLOAD DUP2 JUMP JUMPDEST PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0x704 DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0x824 JUMPI PUSH2 0x712 DUP3 PUSH2 0x659 JUMP JUMPDEST ISZERO PUSH2 0x71C JUMPI PUSH2 0x823 JUMP JUMPDEST PUSH2 0x724 PUSH2 0x1890 JUMP JUMPDEST PUSH1 0xFA PUSH1 0x1 SLOAD LT ISZERO ISZERO PUSH2 0x739 JUMPI PUSH2 0x738 PUSH2 0x19D0 JUMP JUMPDEST JUMPDEST PUSH1 0xFA PUSH1 0x1 SLOAD LT ISZERO ISZERO PUSH2 0x74A JUMPI PUSH2 0x823 JUMP JUMPDEST PUSH1 0x1 PUSH1 0x0 DUP2 SLOAD DUP1 SWAP3 SWAP2 SWAP1 PUSH1 0x1 ADD SWAP2 SWAP1 POP SSTORE POP DUP2 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH1 0x5 PUSH1 0x1 SLOAD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x785 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP PUSH1 0x1 SLOAD PUSH2 0x105 PUSH1 0x0 DUP5 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP PUSH32 0x994A936646FE87FFE4F1E469D3D6AA417D6B855598397F323DE5B449F765F0C3 DUP3 PUSH1 0x40 MLOAD DUP1 DUP3 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMPDEST POP POP JUMP JUMPDEST PUSH1 0x0 SLOAD DUP2 JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 DUP3 PUSH2 0x83D DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0xDC4 JUMPI PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND EQ ISZERO DUP1 PUSH2 0x8C7 JUMPI POP PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD SLOAD EQ ISZERO JUMPDEST DUP1 PUSH2 0x906 JUMPI POP PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV SWAP1 POP EQ ISZERO JUMPDEST ISZERO PUSH2 0xDC2 JUMPI PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND EQ ISZERO PUSH2 0xA50 JUMPI PUSH2 0xA49 PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD SLOAD PUSH2 0x108 PUSH1 0x0 DUP8 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP1 PUSH1 0x1F ADD PUSH1 0x20 DUP1 SWAP2 DIV MUL PUSH1 0x20 ADD PUSH1 0x40 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 SWAP3 SWAP2 SWAP1 DUP2 DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP1 ISZERO PUSH2 0xA3F JUMPI DUP1 PUSH1 0x1F LT PUSH2 0xA14 JUMPI PUSH2 0x100 DUP1 DUP4 SLOAD DIV MUL DUP4 MSTORE SWAP2 PUSH1 0x20 ADD SWAP2 PUSH2 0xA3F JUMP JUMPDEST DUP3 ADD SWAP2 SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 JUMPDEST DUP2 SLOAD DUP2 MSTORE SWAP1 PUSH1 0x1 ADD SWAP1 PUSH1 0x20 ADD DUP1 DUP4 GT PUSH2 0xA22 JUMPI DUP3 SWAP1 SUB PUSH1 0x1F AND DUP3 ADD SWAP2 JUMPDEST POP POP POP POP POP PUSH2 0x1B37 JUMP JUMPDEST SWAP2 POP PUSH2 0xB71 JUMP JUMPDEST PUSH2 0x108 PUSH1 0x0 DUP6 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH2 0x108 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD SLOAD PUSH2 0x108 PUSH1 0x0 DUP8 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD PUSH1 0x40 MLOAD DUP1 DUP3 DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP1 ISZERO PUSH2 0xB4A JUMPI DUP1 PUSH1 0x1F LT PUSH2 0xB1F JUMPI PUSH2 0x100 DUP1 DUP4 SLOAD DIV MUL DUP4 MSTORE SWAP2 PUSH1 0x20 ADD SWAP2 PUSH2 0xB4A JUMP JUMPDEST DUP3 ADD SWAP2 SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 JUMPDEST DUP2 SLOAD DUP2 MSTORE SWAP1 PUSH1 0x1 ADD SWAP1 PUSH1 0x20 ADD DUP1 DUP4 GT PUSH2 0xB2D JUMPI DUP3 SWAP1 SUB PUSH1 0x1F AND DUP3 ADD SWAP2 JUMPDEST POP POP SWAP2 POP POP PUSH1 0x0 PUSH1 0x40 MLOAD DUP1 DUP4 SUB DUP2 DUP6 DUP8 PUSH2 0x8502 GAS SUB CALL SWAP3 POP POP POP ISZERO ISZERO PUSH2 0xB70 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST JUMPDEST PUSH32 0xE3A3A4111A84DF27D76B68DC721E65C7711605EA5EEE4AFD3A9C58195217365C CALLER DUP6 PUSH2 0x108 PUSH1 0x0 DUP9 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD SLOAD PUSH2 0x108 PUSH1 0x0 DUP10 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH2 0x108 PUSH1 0x0 DUP11 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD DUP8 PUSH1 0x40 MLOAD DUP1 DUP8 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD DUP6 DUP2 MSTORE PUSH1 0x20 ADD DUP5 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP1 PUSH1 0x20 ADD DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP5 DUP2 DUP2 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV DUP1 ISZERO PUSH2 0xD47 JUMPI DUP1 PUSH1 0x1F LT PUSH2 0xD1C JUMPI PUSH2 0x100 DUP1 DUP4 SLOAD DIV MUL DUP4 MSTORE SWAP2 PUSH1 0x20 ADD SWAP2 PUSH2 0xD47 JUMP JUMPDEST DUP3 ADD SWAP2 SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 JUMPDEST DUP2 SLOAD DUP2 MSTORE SWAP1 PUSH1 0x1 ADD SWAP1 PUSH1 0x20 ADD DUP1 DUP4 GT PUSH2 0xD2A JUMPI DUP3 SWAP1 SUB PUSH1 0x1F AND DUP3 ADD SWAP2 JUMPDEST POP POP SWAP8 POP POP POP POP POP POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 PUSH2 0x108 PUSH1 0x0 DUP6 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 PUSH1 0x0 DUP3 ADD PUSH1 0x0 PUSH2 0x100 EXP DUP2 SLOAD SWAP1 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MUL NOT AND SWAP1 SSTORE PUSH1 0x1 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x2 DUP3 ADD PUSH1 0x0 PUSH2 0xDB7 SWAP2 SWAP1 PUSH2 0x1BE6 JUMP JUMPDEST POP POP PUSH1 0x1 SWAP3 POP PUSH2 0xDC3 JUMP JUMPDEST JUMPDEST JUMPDEST JUMPDEST POP POP SWAP2 SWAP1 POP JUMP JUMPDEST PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0xDF3 DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0xE01 JUMPI DUP2 PUSH1 0x2 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST JUMPDEST POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH2 0xE13 CALLER PUSH2 0x659 JUMP JUMPDEST ISZERO PUSH2 0x1273 JUMPI PUSH1 0x0 DUP5 DUP5 SWAP1 POP EQ DUP1 ISZERO PUSH2 0xE30 JUMPI POP PUSH2 0xE2F DUP6 PUSH2 0x1B51 JUMP JUMPDEST JUMPDEST DUP1 PUSH2 0xE3D JUMPI POP PUSH1 0x1 PUSH1 0x0 SLOAD EQ JUMPDEST ISZERO PUSH2 0xFED JUMPI PUSH1 0x0 DUP7 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND EQ ISZERO PUSH2 0xEA4 JUMPI PUSH2 0xE9D DUP6 DUP6 DUP6 DUP1 DUP1 PUSH1 0x1F ADD PUSH1 0x20 DUP1 SWAP2 DIV MUL PUSH1 0x20 ADD PUSH1 0x40 MLOAD SWAP1 DUP2 ADD PUSH1 0x40 MSTORE DUP1 SWAP4 SWAP3 SWAP2 SWAP1 DUP2 DUP2 MSTORE PUSH1 0x20 ADD DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP POP POP POP POP PUSH2 0x1B37 JUMP JUMPDEST SWAP1 POP PUSH2 0xEF3 JUMP JUMPDEST DUP6 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP6 DUP6 DUP6 PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x0 PUSH1 0x40 MLOAD DUP1 DUP4 SUB DUP2 DUP6 DUP8 PUSH2 0x8502 GAS SUB CALL SWAP3 POP POP POP ISZERO ISZERO PUSH2 0xEF2 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST JUMPDEST PUSH32 0x9738CD1A8777C86B011F7B01D87D484217DC6AB5154A9D41EDA5D14AF8CAF292 CALLER DUP7 DUP9 DUP8 DUP8 DUP7 PUSH1 0x40 MLOAD DUP1 DUP8 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP7 DUP2 MSTORE PUSH1 0x20 ADD DUP6 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP1 PUSH1 0x20 ADD DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP6 DUP6 DUP3 DUP2 DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP8 POP POP POP POP POP POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 PUSH2 0x1271 JUMP JUMPDEST PUSH1 0x0 CALLDATASIZE NUMBER PUSH1 0x40 MLOAD DUP1 DUP5 DUP5 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP4 POP POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 SWAP2 POP PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP5 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 SWAP1 SLOAD SWAP1 PUSH2 0x100 EXP SWAP1 DIV PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND EQ DUP1 ISZERO PUSH2 0x1099 JUMPI POP PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP5 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD SLOAD EQ JUMPDEST DUP1 ISZERO PUSH2 0x10D8 JUMPI POP PUSH1 0x0 PUSH2 0x108 PUSH1 0x0 DUP5 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV SWAP1 POP EQ JUMPDEST ISZERO PUSH2 0x118F JUMPI DUP6 PUSH2 0x108 PUSH1 0x0 DUP5 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 ADD PUSH1 0x0 PUSH2 0x100 EXP DUP2 SLOAD DUP2 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MUL NOT AND SWAP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND MUL OR SWAP1 SSTORE POP DUP5 PUSH2 0x108 PUSH1 0x0 DUP5 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x1 ADD DUP2 SWAP1 SSTORE POP DUP4 DUP4 PUSH2 0x108 PUSH1 0x0 DUP6 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD SWAP2 SWAP1 PUSH2 0x118D SWAP3 SWAP2 SWAP1 PUSH2 0x1C2E JUMP JUMPDEST POP JUMPDEST PUSH2 0x1198 DUP3 PUSH2 0x82F JUMP JUMPDEST ISZERO ISZERO PUSH2 0x1270 JUMPI PUSH32 0x1733CBB53659D713B79580F79F3F9FF215F78A7C7AA45890F3B89FC5CDDFBF32 DUP3 CALLER DUP8 DUP10 DUP9 DUP9 PUSH1 0x40 MLOAD DUP1 DUP8 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD DUP7 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP6 DUP2 MSTORE PUSH1 0x20 ADD DUP5 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP1 PUSH1 0x20 ADD DUP3 DUP2 SUB DUP3 MSTORE DUP5 DUP5 DUP3 DUP2 DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP8 POP POP POP POP POP POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMPDEST JUMPDEST JUMPDEST POP SWAP5 SWAP4 POP POP POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH1 0x0 PUSH2 0x105 PUSH1 0x0 CALLER PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD SWAP3 POP PUSH1 0x0 DUP4 EQ ISZERO PUSH2 0x12BE JUMPI PUSH2 0x138C JUMP JUMPDEST DUP3 PUSH1 0x2 EXP SWAP2 POP PUSH2 0x106 PUSH1 0x0 DUP6 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SWAP1 POP PUSH1 0x0 DUP3 DUP3 PUSH1 0x1 ADD SLOAD AND GT ISZERO PUSH2 0x138B JUMPI DUP1 PUSH1 0x0 ADD PUSH1 0x0 DUP2 SLOAD DUP1 SWAP3 SWAP2 SWAP1 PUSH1 0x1 ADD SWAP2 SWAP1 POP SSTORE POP DUP2 DUP2 PUSH1 0x1 ADD PUSH1 0x0 DUP3 DUP3 SLOAD SUB SWAP3 POP POP DUP2 SWAP1 SSTORE POP PUSH32 0xC7FB647E59B18047309AA15AAD418E5D7CA96D173AD704F1031A2C3D7591734B CALLER DUP6 PUSH1 0x40 MLOAD DUP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST POP POP POP POP JUMP JUMPDEST PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0x13B9 DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0x1415 JUMPI PUSH1 0x1 SLOAD DUP3 GT ISZERO PUSH2 0x13CD JUMPI PUSH2 0x1414 JUMP JUMPDEST DUP2 PUSH1 0x0 DUP2 SWAP1 SSTORE POP PUSH2 0x13DC PUSH2 0x1890 JUMP JUMPDEST PUSH32 0xACBDB084C721332AC59F9B8E392196C9EB0E4932862DA8EB9BEAF0DAD4F550DA DUP3 PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMPDEST POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH1 0x0 PUSH1 0x0 PUSH2 0x106 PUSH1 0x0 DUP8 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SWAP3 POP PUSH2 0x105 PUSH1 0x0 DUP7 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD SWAP2 POP PUSH1 0x0 DUP3 EQ ISZERO PUSH2 0x147F JUMPI PUSH1 0x0 SWAP4 POP PUSH2 0x1493 JUMP JUMPDEST DUP2 PUSH1 0x2 EXP SWAP1 POP PUSH1 0x0 DUP2 DUP5 PUSH1 0x1 ADD SLOAD AND EQ ISZERO SWAP4 POP JUMPDEST POP POP POP SWAP3 SWAP2 POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x5 PUSH1 0x1 DUP4 ADD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x14B1 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD SWAP1 POP JUMPDEST SWAP2 SWAP1 POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 CALLDATASIZE PUSH1 0x40 MLOAD DUP1 DUP4 DUP4 DUP1 DUP3 DUP5 CALLDATACOPY DUP3 ADD SWAP2 POP POP SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 SHA3 PUSH2 0x14E8 DUP2 PUSH2 0x1678 JUMP JUMPDEST ISZERO PUSH2 0x166B JUMPI PUSH2 0x14F6 DUP4 PUSH2 0x659 JUMP JUMPDEST ISZERO PUSH2 0x1500 JUMPI PUSH2 0x166A JUMP JUMPDEST PUSH2 0x105 PUSH1 0x0 DUP6 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD SWAP2 POP PUSH1 0x0 DUP3 EQ ISZERO PUSH2 0x153B JUMPI PUSH2 0x166A JUMP JUMPDEST PUSH2 0x1543 PUSH2 0x1890 JUMP JUMPDEST DUP3 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH1 0x5 DUP4 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x156A JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP PUSH1 0x0 PUSH2 0x105 PUSH1 0x0 DUP7 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP DUP2 PUSH2 0x105 PUSH1 0x0 DUP6 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP PUSH32 0xB532073B38C83145E3E5135377A08BF9AAB55BC0FD7C1179CD4FB995D2A5159C DUP5 DUP5 PUSH1 0x40 MLOAD DUP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 JUMPDEST JUMPDEST JUMPDEST POP POP POP POP JUMP JUMPDEST PUSH1 0x2 SLOAD DUP2 JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH1 0x0 PUSH1 0x0 PUSH2 0x105 PUSH1 0x0 CALLER PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SLOAD SWAP3 POP PUSH1 0x0 DUP4 EQ ISZERO PUSH2 0x16BB JUMPI PUSH2 0x1888 JUMP JUMPDEST PUSH2 0x106 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 SWAP2 POP PUSH1 0x0 DUP3 PUSH1 0x0 ADD SLOAD EQ ISZERO PUSH2 0x1745 JUMPI PUSH1 0x0 SLOAD DUP3 PUSH1 0x0 ADD DUP2 SWAP1 SSTORE POP PUSH1 0x0 DUP3 PUSH1 0x1 ADD DUP2 SWAP1 SSTORE POP PUSH2 0x107 DUP1 SLOAD DUP1 SWAP2 SWAP1 PUSH1 0x1 ADD PUSH2 0x1710 SWAP2 SWAP1 PUSH2 0x1CAE JUMP JUMPDEST DUP3 PUSH1 0x2 ADD DUP2 SWAP1 SSTORE POP DUP5 PUSH2 0x107 DUP4 PUSH1 0x2 ADD SLOAD DUP2 SLOAD DUP2 LT ISZERO ISZERO PUSH2 0x172D JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST POP DUP2 PUSH1 0x0 NOT AND SWAP1 SSTORE POP JUMPDEST DUP3 PUSH1 0x2 EXP SWAP1 POP PUSH1 0x0 DUP2 DUP4 PUSH1 0x1 ADD SLOAD AND EQ ISZERO PUSH2 0x1887 JUMPI PUSH32 0xE1C52DC63B719ADE82E8BEA94CC41A0D5D28E4AAF536ADB5E9CCCC9FF8C1AEDA CALLER DUP7 PUSH1 0x40 MLOAD DUP1 DUP4 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD DUP3 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP3 POP POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 LOG1 PUSH1 0x1 DUP3 PUSH1 0x0 ADD SLOAD GT ISZERO ISZERO PUSH2 0x185E JUMPI PUSH2 0x107 PUSH2 0x106 PUSH1 0x0 DUP8 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x2 ADD SLOAD DUP2 SLOAD DUP2 LT ISZERO ISZERO PUSH2 0x180A JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST POP PUSH1 0x0 SWAP1 SSTORE PUSH2 0x106 PUSH1 0x0 DUP7 PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 PUSH1 0x0 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x1 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x2 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE POP POP PUSH1 0x1 SWAP4 POP PUSH2 0x1888 JUMP JUMPDEST DUP2 PUSH1 0x0 ADD PUSH1 0x0 DUP2 SLOAD DUP1 SWAP3 SWAP2 SWAP1 PUSH1 0x1 SWAP1 SUB SWAP2 SWAP1 POP SSTORE POP DUP1 DUP3 PUSH1 0x1 ADD PUSH1 0x0 DUP3 DUP3 SLOAD OR SWAP3 POP POP DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST JUMPDEST POP POP POP SWAP2 SWAP1 POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH2 0x107 DUP1 SLOAD SWAP1 POP SWAP2 POP PUSH1 0x0 SWAP1 POP JUMPDEST DUP2 DUP2 LT ISZERO PUSH2 0x19BC JUMPI PUSH2 0x108 PUSH1 0x0 PUSH2 0x107 DUP4 DUP2 SLOAD DUP2 LT ISZERO ISZERO PUSH2 0x18BF JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST POP SLOAD PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 PUSH1 0x0 DUP3 ADD PUSH1 0x0 PUSH2 0x100 EXP DUP2 SLOAD SWAP1 PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF MUL NOT AND SWAP1 SSTORE PUSH1 0x1 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x2 DUP3 ADD PUSH1 0x0 PUSH2 0x1926 SWAP2 SWAP1 PUSH2 0x1BE6 JUMP JUMPDEST POP POP PUSH1 0x0 PUSH1 0x1 MUL PUSH2 0x107 DUP3 DUP2 SLOAD DUP2 LT ISZERO ISZERO PUSH2 0x193D JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST POP SLOAD PUSH1 0x0 NOT AND EQ ISZERO ISZERO PUSH2 0x19B0 JUMPI PUSH2 0x106 PUSH1 0x0 PUSH2 0x107 DUP4 DUP2 SLOAD DUP2 LT ISZERO ISZERO PUSH2 0x196D JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 ADD PUSH1 0x0 JUMPDEST POP SLOAD PUSH1 0x0 NOT AND PUSH1 0x0 NOT AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 PUSH1 0x0 PUSH1 0x0 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x1 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE PUSH1 0x2 DUP3 ADD PUSH1 0x0 SWAP1 SSTORE POP POP JUMPDEST JUMPDEST DUP1 PUSH1 0x1 ADD SWAP1 POP PUSH2 0x18A2 JUMP JUMPDEST PUSH2 0x107 PUSH1 0x0 PUSH2 0x19CB SWAP2 SWAP1 PUSH2 0x1CDA JUMP JUMPDEST JUMPDEST POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x1 SWAP1 POP JUMPDEST PUSH1 0x1 SLOAD DUP2 LT ISZERO PUSH2 0x1B33 JUMPI JUMPDEST PUSH1 0x1 SLOAD DUP2 LT DUP1 ISZERO PUSH2 0x1A09 JUMPI POP PUSH1 0x0 PUSH1 0x5 DUP3 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1A00 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD EQ ISZERO JUMPDEST ISZERO PUSH2 0x1A1B JUMPI DUP1 DUP1 PUSH1 0x1 ADD SWAP2 POP POP PUSH2 0x19E2 JUMP JUMPDEST JUMPDEST PUSH1 0x1 PUSH1 0x1 SLOAD GT DUP1 ISZERO PUSH2 0x1A45 JUMPI POP PUSH1 0x0 PUSH1 0x5 PUSH1 0x1 SLOAD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1A3D JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD EQ JUMPDEST ISZERO PUSH2 0x1A62 JUMPI PUSH1 0x1 PUSH1 0x0 DUP2 SLOAD DUP1 SWAP3 SWAP2 SWAP1 PUSH1 0x1 SWAP1 SUB SWAP2 SWAP1 POP SSTORE POP PUSH2 0x1A1C JUMP JUMPDEST PUSH1 0x1 SLOAD DUP2 LT DUP1 ISZERO PUSH2 0x1A8B JUMPI POP PUSH1 0x0 PUSH1 0x5 PUSH1 0x1 SLOAD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1A82 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD EQ ISZERO JUMPDEST DUP1 ISZERO PUSH2 0x1AAC JUMPI POP PUSH1 0x0 PUSH1 0x5 DUP3 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1AA4 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD EQ JUMPDEST ISZERO PUSH2 0x1B2E JUMPI PUSH1 0x5 PUSH1 0x1 SLOAD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1AC3 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD PUSH1 0x5 DUP3 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1AD9 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP DUP1 PUSH2 0x105 PUSH1 0x0 PUSH1 0x5 DUP5 PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1AF8 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP SLOAD DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP PUSH1 0x0 PUSH1 0x5 PUSH1 0x1 SLOAD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1B24 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP JUMPDEST PUSH2 0x19D7 JUMP JUMPDEST JUMPDEST POP JUMP JUMPDEST PUSH1 0x0 DUP2 MLOAD PUSH1 0x20 DUP4 ADD DUP5 CREATE SWAP1 POP DUP1 EXTCODESIZE ISZERO PUSH2 0x0 JUMPI JUMPDEST SWAP3 SWAP2 POP POP JUMP JUMPDEST PUSH1 0x0 PUSH2 0x1B5C CALLER PUSH2 0x659 JUMP JUMPDEST ISZERO PUSH2 0x1BC9 JUMPI PUSH1 0x4 SLOAD PUSH2 0x1B6C PUSH2 0x1BCF JUMP JUMPDEST GT ISZERO PUSH2 0x1B89 JUMPI PUSH1 0x0 PUSH1 0x3 DUP2 SWAP1 SSTORE POP PUSH2 0x1B82 PUSH2 0x1BCF JUMP JUMPDEST PUSH1 0x4 DUP2 SWAP1 SSTORE POP JUMPDEST PUSH1 0x3 SLOAD DUP3 PUSH1 0x3 SLOAD ADD LT ISZERO DUP1 ISZERO PUSH2 0x1BA5 JUMPI POP PUSH1 0x2 SLOAD DUP3 PUSH1 0x3 SLOAD ADD GT ISZERO JUMPDEST ISZERO PUSH2 0x1BC3 JUMPI DUP2 PUSH1 0x3 PUSH1 0x0 DUP3 DUP3 SLOAD ADD SWAP3 POP POP DUP2 SWAP1 SSTORE POP PUSH1 0x1 SWAP1 POP PUSH2 0x1BC8 JUMP JUMPDEST PUSH1 0x0 SWAP1 POP JUMPDEST JUMPDEST JUMPDEST SWAP2 SWAP1 POP JUMP JUMPDEST PUSH1 0x0 PUSH3 0x15180 TIMESTAMP DUP2 ISZERO ISZERO PUSH2 0x1BDF JUMPI INVALID JUMPDEST DIV SWAP1 POP JUMPDEST SWAP1 JUMP JUMPDEST POP DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV PUSH1 0x0 DUP3 SSTORE DUP1 PUSH1 0x1F LT PUSH2 0x1C0C JUMPI POP PUSH2 0x1C2B JUMP JUMPDEST PUSH1 0x1F ADD PUSH1 0x20 SWAP1 DIV SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 DUP2 ADD SWAP1 PUSH2 0x1C2A SWAP2 SWAP1 PUSH2 0x1CFC JUMP JUMPDEST JUMPDEST POP JUMP JUMPDEST DUP3 DUP1 SLOAD PUSH1 0x1 DUP2 PUSH1 0x1 AND ISZERO PUSH2 0x100 MUL SUB AND PUSH1 0x2 SWAP1 DIV SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 PUSH1 0x1F ADD PUSH1 0x20 SWAP1 DIV DUP2 ADD SWAP3 DUP3 PUSH1 0x1F LT PUSH2 0x1C6F JUMPI DUP1 CALLDATALOAD PUSH1 0xFF NOT AND DUP4 DUP1 ADD OR DUP6 SSTORE PUSH2 0x1C9D JUMP JUMPDEST DUP3 DUP1 ADD PUSH1 0x1 ADD DUP6 SSTORE DUP3 ISZERO PUSH2 0x1C9D JUMPI SWAP2 DUP3 ADD JUMPDEST DUP3 DUP2 GT ISZERO PUSH2 0x1C9C JUMPI DUP3 CALLDATALOAD DUP3 SSTORE SWAP2 PUSH1 0x20 ADD SWAP2 SWAP1 PUSH1 0x1 ADD SWAP1 PUSH2 0x1C81 JUMP JUMPDEST JUMPDEST POP SWAP1 POP PUSH2 0x1CAA SWAP2 SWAP1 PUSH2 0x1CFC JUMP JUMPDEST POP SWAP1 JUMP JUMPDEST DUP2 SLOAD DUP2 DUP4 SSTORE DUP2 DUP2 ISZERO GT PUSH2 0x1CD5 JUMPI DUP2 DUP4 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP2 DUP3 ADD SWAP2 ADD PUSH2 0x1CD4 SWAP2 SWAP1 PUSH2 0x1D21 JUMP JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST POP DUP1 SLOAD PUSH1 0x0 DUP3 SSTORE SWAP1 PUSH1 0x0 MSTORE PUSH1 0x20 PUSH1 0x0 SHA3 SWAP1 DUP2 ADD SWAP1 PUSH2 0x1CF8 SWAP2 SWAP1 PUSH2 0x1D21 JUMP JUMPDEST JUMPDEST POP JUMP JUMPDEST PUSH2 0x1D1E SWAP2 SWAP1 JUMPDEST DUP1 DUP3 GT ISZERO PUSH2 0x1D1A JUMPI PUSH1 0x0 DUP2 PUSH1 0x0 SWAP1 SSTORE POP PUSH1 0x1 ADD PUSH2 0x1D02 JUMP JUMPDEST POP SWAP1 JUMP JUMPDEST SWAP1 JUMP JUMPDEST PUSH2 0x1D43 SWAP2 SWAP1 JUMPDEST DUP1 DUP3 GT ISZERO PUSH2 0x1D3F JUMPI PUSH1 0x0 DUP2 PUSH1 0x0 SWAP1 SSTORE POP PUSH1 0x1 ADD PUSH2 0x1D27 JUMP JUMPDEST POP SWAP1 JUMP JUMPDEST SWAP1 JUMP JUMPDEST PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH2 0x1D57 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST PUSH2 0x1D60 DUP2 PUSH2 0x1D71 JUMP JUMPDEST PUSH2 0x1D6A DUP4 DUP4 PUSH2 0x1D9C JUMP JUMPDEST JUMPDEST JUMPDEST POP POP POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH2 0x1D82 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP1 PUSH1 0x2 DUP2 SWAP1 SSTORE POP PUSH2 0x1D91 PUSH2 0x1BCF JUMP JUMPDEST PUSH1 0x4 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST POP JUMP JUMPDEST PUSH1 0x0 PUSH1 0x0 PUSH1 0x1 SLOAD GT ISZERO PUSH2 0x1DAF JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST PUSH1 0x0 DUP3 GT ISZERO ISZERO PUSH2 0x1DBF JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP2 DUP4 MLOAD LT ISZERO ISZERO ISZERO PUSH2 0x1DD0 JUMPI PUSH1 0x0 PUSH1 0x0 REVERT JUMPDEST DUP3 MLOAD PUSH1 0x1 DUP2 SWAP1 SSTORE POP PUSH1 0x0 SWAP1 POP JUMPDEST DUP3 MLOAD DUP2 LT ISZERO PUSH2 0x1E85 JUMPI DUP3 DUP2 DUP2 MLOAD DUP2 LT ISZERO ISZERO PUSH2 0x1DF4 JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x20 ADD SWAP1 PUSH1 0x20 MUL ADD MLOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND PUSH1 0x5 DUP3 PUSH1 0x1 ADD PUSH2 0x100 DUP2 LT ISZERO ISZERO PUSH2 0x1E27 JUMPI INVALID JUMPDEST ADD PUSH1 0x0 JUMPDEST POP DUP2 SWAP1 SSTORE POP DUP1 PUSH1 0x1 ADD PUSH2 0x105 PUSH1 0x0 DUP6 DUP5 DUP2 MLOAD DUP2 LT ISZERO ISZERO PUSH2 0x1E47 JUMPI INVALID JUMPDEST SWAP1 PUSH1 0x20 ADD SWAP1 PUSH1 0x20 MUL ADD MLOAD PUSH20 0xFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF AND DUP2 MSTORE PUSH1 0x20 ADD SWAP1 DUP2 MSTORE PUSH1 0x20 ADD PUSH1 0x0 SHA3 DUP2 SWAP1 SSTORE POP JUMPDEST DUP1 PUSH1 0x1 ADD SWAP1 POP PUSH2 0x1DDD JUMP JUMPDEST DUP2 PUSH1 0x0 DUP2 SWAP1 SSTORE POP JUMPDEST JUMPDEST POP POP POP JUMP STOP LOG1 PUSH6 0x627A7A723058 SHA3 AND DUP9 SWAP16 SMOD BLOCKHASH CREATE PUSH20 0xD397F9D00B0D19900FB050B957E3E2942F861085 0xbe 0xb9 0xba 0xab XOR STOP 0x29 </span>"</span>,</span></span>
	"</span>sourceMap</span>"</span>:</span> "</span>2715:10853:0:-;;;3523:112;;;;;;;3552:18;3574:8;:27;;;;;;;;;;;:::i;:::-;;;;;;;;;;;3596:3;3574:27;;;;;;;;;;;;;;;;;;;;;;;3605:26;3616:8;3605:26;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;3626:1;3629;3605:10;;;;;:26;;;:::i;:::-;3523:112;;2715:10853;;7697:168;7585:1;7571:11;;:15;7567:26;;;7588:5;;;7567:26;7800:23;7813:9;7800:12;;;;;:23;;;:::i;:::-;7827:34;7842:7;7851:9;7827:14;;;;;:34;;;:::i;:::-;7595:1;7697:168;;;;:::o;6966:115::-;7585:1;7571:11;;:15;7567:26;;;7588:5;;;7567:26;7048:6;7033:12;:21;;;;7070:7;:5;;;;;:7;;;:::i;:::-;7058:9;:19;;;;7595:1;6966:115;;:::o;3977:349::-;4171:6;7585:1;7571:11;;:15;7567:26;;;7588:5;;;7567:26;4088:1;4076:9;:13;4068:22;;;;;;;;4120:9;4102:7;:14;:27;;4094:36;;;;;;;;4148:7;:14;4134:11;:28;;;;4180:1;4171:10;;4166:131;4187:7;:14;4183:1;:18;4166:131;;;4238:7;4246:1;4238:10;;;;;;;;;;;;;;;;;;4233:16;;4215:8;4228:1;4224;:5;4215:15;;;;;;;;;;;;:34;;;;;4291:1;4287;:5;4254:12;:30;4272:7;4280:1;4272:10;;;;;;;;;;;;;;;;;;4267:16;;4254:30;;;;;;;;;;;:38;;;;4166:131;4203:3;;;;;4166:131;;;4313:9;4300:10;:22;;;;7595:1;3977:349;;;;:::o;12529:73::-;12572:4;12593:6;12587:3;:12;;;;;;;;12580:19;;12529:73;;:::o;2715:10853::-;;;;;;;;;;;;;;;;;;;;;;;;;;;;:::i;:::-;;;;;:::o;:::-;;;;;;;;;;;;;;;;;;;;;;;;;;;:::o;:::-;;;;;;;</span>"</span>,</span></span>
	"</span>linkReferences</span>"</span>:</span> {</span>}</span></span>
}</span></span></code></pre>
To verify the byte-code above, a patched version is deployed at
0x21C9E434c669c4d73f55215A6F2130A185E127AC</code></a>
to be reviewed. The compiler settings used can be extracted from the following
meta-data:</p>
{</span>"</span>compiler</span>"</span>:</span>{</span>"</span>version</span>"</span>:</span>"</span>0.4.10+commit.f0d539ae</span>"</span>}</span>,</span>"</span>language</span>"</span>:</span>"</span>Solidity</span>"</span>,</span>"</span>output</span>"</span>:</span>{</span>"</span>abi</span>"</span>:</span>[</span>{</span>"</span>constant</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>_owner</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>removeOwner</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>true</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>_addr</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>isOwner</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>bool</span>"</span>}</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>true</span>,</span>"</span>inputs</span>"</span>:</span>[</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>m_numOwners</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>uint256</span>"</span>}</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>true</span>,</span>"</span>inputs</span>"</span>:</span>[</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>m_lastDay</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>uint256</span>"</span>}</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>resetSpentToday</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>true</span>,</span>"</span>inputs</span>"</span>:</span>[</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>m_spentToday</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>uint256</span>"</span>}</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>_owner</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>addOwner</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>true</span>,</span>"</span>inputs</span>"</span>:</span>[</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>m_required</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>uint256</span>"</span>}</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>_h</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>bytes32</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>confirm</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>o_success</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>bool</span>"</span>}</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>_newLimit</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>uint256</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>setDailyLimit</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>_to</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>,</span>{</span>"</span>name</span>"</span>:</span>"</span>_value</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>uint256</span>"</span>}</span>,</span>{</span>"</span>name</span>"</span>:</span>"</span>_data</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>bytes</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>execute</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>o_hash</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>bytes32</span>"</span>}</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>_operation</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>bytes32</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>revoke</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>_newRequired</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>uint256</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>changeRequirement</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>true</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>_operation</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>bytes32</span>"</span>}</span>,</span>{</span>"</span>name</span>"</span>:</span>"</span>_owner</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>hasConfirmed</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>bool</span>"</span>}</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>true</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>ownerIndex</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>uint256</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>getOwner</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>_from</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>,</span>{</span>"</span>name</span>"</span>:</span>"</span>_to</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>changeOwner</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>constant</span>"</span>:</span>true</span>,</span>"</span>inputs</span>"</span>:</span>[</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>m_dailyLimit</span>"</span>,</span>"</span>outputs</span>"</span>:</span>[</span>{</span>"</span>name</span>"</span>:</span>"</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>uint256</span>"</span>}</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>function</span>"</span>}</span>,</span>{</span>"</span>inputs</span>"</span>:</span>[</span>]</span>,</span>"</span>payable</span>"</span>:</span>false</span>,</span>"</span>type</span>"</span>:</span>"</span>constructor</span>"</span>}</span>,</span>{</span>"</span>payable</span>"</span>:</span>true</span>,</span>"</span>type</span>"</span>:</span>"</span>fallback</span>"</span>}</span>,</span>{</span>"</span>anonymous</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>owner</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>operation</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>bytes32</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>Confirmation</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>event</span>"</span>}</span>,</span>{</span>"</span>anonymous</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>owner</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>operation</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>bytes32</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>Revoke</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>event</span>"</span>}</span>,</span>{</span>"</span>anonymous</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>oldOwner</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>newOwner</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>OwnerChanged</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>event</span>"</span>}</span>,</span>{</span>"</span>anonymous</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>newOwner</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>OwnerAdded</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>event</span>"</span>}</span>,</span>{</span>"</span>anonymous</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>oldOwner</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>OwnerRemoved</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>event</span>"</span>}</span>,</span>{</span>"</span>anonymous</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>newRequirement</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>uint256</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>RequirementChanged</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>event</span>"</span>}</span>,</span>{</span>"</span>anonymous</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>_from</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>value</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>uint256</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>Deposit</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>event</span>"</span>}</span>,</span>{</span>"</span>anonymous</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>owner</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>value</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>uint256</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>to</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>data</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>bytes</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>created</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>SingleTransact</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>event</span>"</span>}</span>,</span>{</span>"</span>anonymous</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>owner</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>operation</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>bytes32</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>value</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>uint256</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>to</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>data</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>bytes</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>created</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>MultiTransact</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>event</span>"</span>}</span>,</span>{</span>"</span>anonymous</span>"</span>:</span>false</span>,</span>"</span>inputs</span>"</span>:</span>[</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>operation</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>bytes32</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>initiator</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>value</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>uint256</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>to</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>address</span>"</span>}</span>,</span>{</span>"</span>indexed</span>"</span>:</span>false</span>,</span>"</span>name</span>"</span>:</span>"</span>data</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>bytes</span>"</span>}</span>]</span>,</span>"</span>name</span>"</span>:</span>"</span>ConfirmationNeeded</span>"</span>,</span>"</span>type</span>"</span>:</span>"</span>event</span>"</span>}</span>]</span>,</span>"</span>devdoc</span>"</span>:</span>{</span>"</span>methods</span>"</span>:</span>{</span>}</span>}</span>,</span>"</span>userdoc</span>"</span>:</span>{</span>"</span>methods</span>"</span>:</span>{</span>}</span>}</span>}</span>,</span>"</span>settings</span>"</span>:</span>{</span>"</span>compilationTarget</span>"</span>:</span>{</span>"</span>browser/WalletLibrary.sol</span>"</span>:</span>"</span>WalletLibrary</span>"</span>}</span>,</span>"</span>libraries</span>"</span>:</span>{</span>}</span>,</span>"</span>optimizer</span>"</span>:</span>{</span>"</span>enabled</span>"</span>:</span>false</span>,</span>"</span>runs</span>"</span>:</span>200</span>}</span>,</span>"</span>remappings</span>"</span>:</span>[</span>]</span>}</span>,</span>"</span>sources</span>"</span>:</span>{</span>"</span>browser/WalletLibrary.sol</span>"</span>:</span>{</span>"</span>keccak256</span>"</span>:</span>"</span>0xf72fcdc85e15f93172878ca6a61fb81604d1052e9e724bc3896d65b3b4ab1bb0</span>"</span>,</span>"</span>urls</span>"</span>:</span>[</span>"</span>bzzr://009bd59bd78f59804eaffb6111d341caea58888f8e5b5f75aebdf009fc6136c0</span>"</span>]</span>}</span>}</span>,</span>"</span>version</span>"</span>:</span>1</span>}</span></span></code></pre>
The differences to the originally deployed contract code can be reviewed at:</p>

parity-contracts/0x863df6bfa4#2</a>:
Remove the selfdestruct()</code></li>
parity-contracts/0x863df6bfa4#3</a>:
Initialize the library owner to 0x0</code></li>
</ul>
The following sections propose two equivalent specifications, 999a and 999b,
which technically achieve the same results. To implement this proposal only one
of them has to be applied.</p>
Direct State Transition via Bytecode (999a)</h3>
At CNSTNTNPL_FORK_BLKNUM</code>, directly recreate the account
0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4</code> with the following parameters:</p>

Nonce: 0x1</code></li>
Code:</li>
</ul>
0x606060405236156100ef576000357c0100000000000000000000000000000000000000000000000000000000900463ffffffff168063173825d91461016d5780632f54bf6e146101a35780634123cb6b146101f157806352375093146102175780635c52c2f51461023d578063659010e71461024f5780637065cb4814610275578063746c9171146102ab578063797af627146102d1578063b20d30a91461030d578063b61d27f61461032d578063b75c7dc61461039c578063ba51a6df146103c0578063c2cf7326146103e0578063c41a360a1461043b578063f00d4b5d1461049b578063f1736d86146104f0575b61016b5b6000341115610168577fe1fffcc4923d04b559f4d29a8bfc6cda04eb5b0d3c460751c2402c5c5cc9109c3334604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018281526020019250505060405180910390a15b5b565b005b341561017557fe5b6101a1600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610516565b005b34156101ab57fe5b6101d7600480803573ffffffffffffffffffffffffffffffffffffffff16906020019091905050610659565b604051808215151515815260200191505060405180910390f35b34156101f957fe5b610201610691565b6040518082815260200191505060405180910390f35b341561021f57fe5b610227610697565b6040518082815260200191505060405180910390f35b341561024557fe5b61024d61069d565b005b341561025757fe5b61025f6106d7565b6040518082815260200191505060405180910390f35b341561027d57fe5b6102a9600480803573ffffffffffffffffffffffffffffffffffffffff169060200190919050506106dd565b005b34156102b357fe5b6102bb610829565b6040518082815260200191505060405180910390f35b34156102d957fe5b6102f360048080356000191690602001909190505061082f565b604051808215151515815260200191505060405180910390f35b341561031557fe5b61032b6004808035906020019091905050610dcc565b005b341561033557fe5b61037e600480803573ffffffffffffffffffffffffffffffffffffffff169060200190919080359060200190919080359060200190820180359060200191909192905050610e06565b60405180826000191660001916815260200191505060405180910390f35b34156103a457fe5b6103be60048080356000191690602001909190505061127d565b005b34156103c857fe5b6103de6004808035906020019091905050611392565b005b34156103e857fe5b61042160048080356000191690602001909190803573ffffffffffffffffffffffffffffffffffffffff1690602001909190505061141a565b604051808215151515815260200191505060405180910390f35b341561044357fe5b610459600480803590602001909190505061149c565b604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390f35b34156104a357fe5b6104ee600480803573ffffffffffffffffffffffffffffffffffffffff1690602001909190803573ffffffffffffffffffffffffffffffffffffffff169060200190919050506114bf565b005b34156104f857fe5b610500611672565b6040518082815260200191505060405180910390f35b600060003660405180838380828437820191505092505050604051809103902061053f81611678565b156106535761010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561057f57610652565b600160015403600054111561059357610652565b6000600583610100811015156105a557fe5b0160005b5081905550600061010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055506105e6611890565b6105ee6119d0565b7f58619076adf5bb0943d100ef88d52d7c3fd691b19d3a9071b555b651fbf418da83604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390a15b5b5b505050565b6000600061010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020541190505b919050565b60015481565b60045481565b6000366040518083838082843782019150509250505060405180910390206106c481611678565b156106d35760006003819055505b5b5b50565b60035481565b60003660405180838380828437820191505092505050604051809103902061070481611678565b156108245761071282610659565b1561071c57610823565b610724611890565b60fa600154101515610739576107386119d0565b5b60fa60015410151561074a57610823565b6001600081548092919060010191905055508173ffffffffffffffffffffffffffffffffffffffff1660056001546101008110151561078557fe5b0160005b508190555060015461010560008473ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055507f994a936646fe87ffe4f1e469d3d6aa417d6b855598397f323de5b449f765f0c382604051808273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200191505060405180910390a15b5b5b5050565b60005481565b600060008261083d81611678565b15610dc45760006101086000866000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff161415806108c757506000610108600086600019166000191681526020019081526020016000206001015414155b80610906575060006101086000866000191660001916815260200190815260200160002060020180546001816001161561010002031660029004905014155b15610dc25760006101086000866000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff161415610a5057610a496101086000866000191660001916815260200190815260200160002060010154610108600087600019166000191681526020019081526020016000206002018054600181600116156101000203166002900480601f016020809104026020016040519081016040528092919081815260200182805460018160011615610100020316600290048015610a3f5780601f10610a1457610100808354040283529160200191610a3f565b820191906000526020600020905b815481529060010190602001808311610a2257829003601f168201915b5050505050611b37565b9150610b71565b6101086000856000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff166101086000866000191660001916815260200190815260200160002060010154610108600087600019166000191681526020019081526020016000206002016040518082805460018160011615610100020316600290048015610b4a5780601f10610b1f57610100808354040283529160200191610b4a565b820191906000526020600020905b815481529060010190602001808311610b2d57829003601f168201915b505091505060006040518083038185876185025a03f1925050501515610b705760006000fd5b5b7fe3a3a4111a84df27d76b68dc721e65c7711605ea5eee4afd3a9c58195217365c338561010860008860001916600019168152602001908152602001600020600101546101086000896000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1661010860008a6000191660001916815260200190815260200160002060020187604051808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200186600019166000191681526020018581526020018473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001828103825284818154600181600116156101000203166002900481526020019150805460018160011615610100020316600290048015610d475780601f10610d1c57610100808354040283529160200191610d47565b820191906000526020600020905b815481529060010190602001808311610d2a57829003601f168201915b505097505050505050505060405180910390a16101086000856000191660001916815260200190815260200160002060006000820160006101000a81549073ffffffffffffffffffffffffffffffffffffffff02191690556001820160009055600282016000610db79190611be6565b505060019250610dc3565b5b5b5b5050919050565b600036604051808383808284378201915050925050506040518091039020610df381611678565b15610e0157816002819055505b5b5b5050565b60006000610e1333610659565b1561127357600084849050148015610e305750610e2f85611b51565b5b80610e3d57506001600054145b15610fed5760008673ffffffffffffffffffffffffffffffffffffffff161415610ea457610e9d8585858080601f016020809104026020016040519081016040528093929190818152602001838380828437820191505050505050611b37565b9050610ef3565b8573ffffffffffffffffffffffffffffffffffffffff168585856040518083838082843782019150509250505060006040518083038185876185025a03f1925050501515610ef25760006000fd5b5b7f9738cd1a8777c86b011f7b01d87d484217dc6ab5154a9d41eda5d14af8caf292338688878786604051808773ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018681526020018573ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018281038252858582818152602001925080828437820191505097505050505050505060405180910390a1611271565b6000364360405180848480828437820191505082815260200193505050506040518091039020915060006101086000846000191660001916815260200190815260200160002060000160009054906101000a900473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16148015611099575060006101086000846000191660001916815260200190815260200160002060010154145b80156110d85750600061010860008460001916600019168152602001908152602001600020600201805460018160011615610100020316600290049050145b1561118f57856101086000846000191660001916815260200190815260200160002060000160006101000a81548173ffffffffffffffffffffffffffffffffffffffff021916908373ffffffffffffffffffffffffffffffffffffffff160217905550846101086000846000191660001916815260200190815260200160002060010181905550838361010860008560001916600019168152602001908152602001600020600201919061118d929190611c2e565b505b6111988261082f565b1515611270577f1733cbb53659d713b79580f79f3f9ff215f78a7c7aa45890f3b89fc5cddfbf328233878988886040518087600019166000191681526020018673ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018581526020018473ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff168152602001806020018281038252848482818152602001925080828437820191505097505050505050505060405180910390a15b5b5b5b5b50949350505050565b60006000600061010560003373ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054925060008314156112be5761138c565b8260020a9150610106600085600019166000191681526020019081526020016000209050600082826001015416111561138b5780600001600081548092919060010191905055508181600101600082825403925050819055507fc7fb647e59b18047309aa15aad418e5d7ca96d173ad704f1031a2c3d7591734b3385604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200182600019166000191681526020019250505060405180910390a15b5b50505050565b6000366040518083838082843782019150509250505060405180910390206113b981611678565b15611415576001548211156113cd57611414565b816000819055506113dc611890565b7facbdb084c721332ac59f9b8e392196c9eb0e4932862da8eb9beaf0dad4f550da826040518082815260200191505060405180910390a15b5b5b5050565b600060006000600061010660008760001916600019168152602001908152602001600020925061010560008673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561147f5760009350611493565b8160020a9050600081846001015416141593505b50505092915050565b6000600560018301610100811015156114b157fe5b0160005b505490505b919050565b60006000366040518083838082843782019150509250505060405180910390206114e881611678565b1561166b576114f683610659565b156115005761166a565b61010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020549150600082141561153b5761166a565b611543611890565b8273ffffffffffffffffffffffffffffffffffffffff166005836101008110151561156a57fe5b0160005b5081905550600061010560008673ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055508161010560008573ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055507fb532073b38c83145e3e5135377a08bf9aab55bc0fd7c1179cd4fb995d2a5159c8484604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020018273ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff1681526020019250505060405180910390a15b5b5b50505050565b60025481565b600060006000600061010560003373ffffffffffffffffffffffffffffffffffffffff16815260200190815260200160002054925060008314156116bb57611888565b6101066000866000191660001916815260200190815260200160002091506000826000015414156117455760005482600001819055506000826001018190555061010780548091906001016117109190611cae565b826002018190555084610107836002015481548110151561172d57fe5b906000526020600020900160005b5081600019169055505b8260020a90506000818360010154161415611887577fe1c52dc63b719ade82e8bea94cc41a0d5d28e4aaf536adb5e9cccc9ff8c1aeda3386604051808373ffffffffffffffffffffffffffffffffffffffff1673ffffffffffffffffffffffffffffffffffffffff16815260200182600019166000191681526020019250505060405180910390a16001826000015411151561185e57610107610106600087600019166000191681526020019081526020016000206002015481548110151561180a57fe5b906000526020600020900160005b5060009055610106600086600019166000191681526020019081526020016000206000600082016000905560018201600090556002820160009055505060019350611888565b8160000160008154809291906001900391905055508082600101600082825417925050819055505b5b5b505050919050565b60006000610107805490509150600090505b818110156119bc576101086000610107838154811015156118bf57fe5b906000526020600020900160005b50546000191660001916815260200190815260200160002060006000820160006101000a81549073ffffffffffffffffffffffffffffffffffffffff021916905560018201600090556002820160006119269190611be6565b505060006001026101078281548110151561193d57fe5b906000526020600020900160005b5054600019161415156119b05761010660006101078381548110151561196d57fe5b906000526020600020900160005b505460001916600019168152602001908152602001600020600060008201600090556001820160009055600282016000905550505b5b8060010190506118a2565b61010760006119cb9190611cda565b5b5050565b6000600190505b600154811015611b33575b60015481108015611a095750600060058261010081101515611a0057fe5b0160005b505414155b15611a1b5780806001019150506119e2565b5b6001600154118015611a4557506000600560015461010081101515611a3d57fe5b0160005b5054145b15611a625760016000815480929190600190039190505550611a1c565b60015481108015611a8b57506000600560015461010081101515611a8257fe5b0160005b505414155b8015611aac5750600060058261010081101515611aa457fe5b0160005b5054145b15611b2e57600560015461010081101515611ac357fe5b0160005b505460058261010081101515611ad957fe5b0160005b508190555080610105600060058461010081101515611af857fe5b0160005b50548152602001908152602001600020819055506000600560015461010081101515611b2457fe5b0160005b50819055505b6119d7565b5b50565b600081516020830184f09050803b15610000575b92915050565b6000611b5c33610659565b15611bc957600454611b6c611bcf565b1115611b89576000600381905550611b82611bcf565b6004819055505b600354826003540110158015611ba55750600254826003540111155b15611bc3578160036000828254019250508190555060019050611bc8565b600090505b5b5b919050565b60006201518042811515611bdf57fe5b0490505b90565b50805460018160011615610100020316600290046000825580601f10611c0c5750611c2b565b601f016020900490600052602060002090810190611c2a9190611cfc565b5b50565b828054600181600116156101000203166002900490600052602060002090601f016020900481019282601f10611c6f57803560ff1916838001178555611c9d565b82800160010185558215611c9d579182015b82811115611c9c578235825591602001919060010190611c81565b5b509050611caa9190611cfc565b5090565b815481835581811511611cd557818360005260206000209182019101611cd49190611d21565b5b505050565b5080546000825590600052602060002090810190611cf89190611d21565b5b50565b611d1e91905b80821115611d1a576000816000905550600101611d02565b5090565b90565b611d4391905b80821115611d3f576000816000905550600101611d27565b5090565b90565b60006001541115611d575760006000fd5b611d6081611d71565b611d6a8383611d9c565b5b5b505050565b60006001541115611d825760006000fd5b80600281905550611d91611bcf565b6004819055505b5b50565b600060006001541115611daf5760006000fd5b600082111515611dbf5760006000fd5b81835110151515611dd05760006000fd5b8251600181905550600090505b8251811015611e85578281815181101515611df457fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff1660058260010161010081101515611e2757fe5b0160005b50819055508060010161010560008584815181101515611e4757fe5b9060200190602002015173ffffffffffffffffffffffffffffffffffffffff168152602001908152602001600020819055505b806001019050611ddd565b816000819055505b5b5050505600a165627a7a7230582084feb3505964efa62a6ffa78d913a175fe7bc168dd50067d25b1d5ddb6d10a1e0029</span></span></code></pre>

Storage:

0x0000000000000000000000000000000000000000000000000000000000000000</code>:
0x0000000000000000000000000000000000000000000000000000000000000001</code></li>
0x0000000000000000000000000000000000000000000000000000000000000001</code>:
0x0000000000000000000000000000000000000000000000000000000000000001</code></li>
0x0000000000000000000000000000000000000000000000000000000000000004</code>:
0x00000000000000000000000000000000000000000000000000000000000044e1</code></li>
0xa5baec7d73105a3c7298203bb205bbc41b63fa384ae73a6016b890a7ca29ae2d</code>:
0x0000000000000000000000000000000000000000000000000000000000000001</code></li>
</ul>
</li>
</ul>
The balance of the account shall be left unchanged.</p>
Alternate Specification via Codehash (999b)</h3>
At CNSTNTNPL_FORK_BLKNUM</code>, directly recreate the account
0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4</code> with the following parameters:</p>

Nonce: 0x1</code></li>
Storage:

0x0000000000000000000000000000000000000000000000000000000000000000</code>:
0x0000000000000000000000000000000000000000000000000000000000000001</code></li>
0x0000000000000000000000000000000000000000000000000000000000000001</code>:
0x0000000000000000000000000000000000000000000000000000000000000001</code></li>
0x0000000000000000000000000000000000000000000000000000000000000004</code>:
0x00000000000000000000000000000000000000000000000000000000000044e1</code></li>
0xa5baec7d73105a3c7298203bb205bbc41b63fa384ae73a6016b890a7ca29ae2d</code>:
0x0000000000000000000000000000000000000000000000000000000000000001</code></li>
</ul>
</li>
</ul>
In addition, the codehash at that address shall be replaced by the codehash at
address 0x21C9E434c669c4d73f55215A6F2130A185E127AC</code>. The codehash is
0x6209d55547da7b035d54ef8d73275e863d3072b91da6ace1614fa6381f4e2c09</code>. The
balance of the account shall be left unchanged.</p>
Rationale</h2>
The design decision to restore the WalletLibrary</code> contract code in a single
state transition was made after lengthy discussions of
alternate proposals</a>
that explored different ways to improve the Ethereum protocol to allow contract
revivals by adding different built-in contracts. It was eventually concluded
that all of these proposals changing the EVM semantics around self-destructed
contracts were introducing unwanted side-effects and
potential risks</a>
to the existing smart-contract ecosystem on the Ethereum platform.</p>
The total supply of Ether is neither changed nor does this proposal require the
transfer of any tokens or assets including Ether. It is assumed that this change
is aligned with the interests both of (A) Parity Technologies that intended to
provide a smart-contracts library for multi-signature wallets to last forever
for its users and (B) the users of the multi-signature wallets that meant to
safely store their assets in a contract accessible any time they desire. Lastly,
the client-side implementation cost of this proposal is estimated to be low. A
sample implementation will be attached and linked in the following sections.</p>
Backwards Compatibility</h2>
This proposal introduces backwards incompatibilities in the state of the
contract at 0x863DF6BFa4469f3ead0bE8f9F2AAE51c91A907b4</code>. The Ethereum protocol
does not allow the restoration of self-destructed contracts. To implement this
on the Ethereum blockchain, it is recommended to add the necessary state
transition in a future hard-fork at a well-defined block number, e.g.,
CNSTNTNPL_FORK_BLKNUM</code> for the Constantinople milestone which is supposed to be
the next scheduled hard-fork on the Ethereum road-map.</p>
Implementation</h2>
A proof-of-concept implementation is available for the Parity client on branch
a5-eip999-poc</code></a>
(#8406</a>). A sample chain
configuration for Parity can be found at the same branch in
multisig_test.json</code></a>
describing the state change as specified above.</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Reward clients for a sustainable network
2018-03-01T00:00:00+00:00
A reward for running a full node is deprecated, but the proposal for a reward for clients remains</h2>
While Casper validators are incentivized to validate transactions, there are still no incentives for relaying blocks and storing data (which includes state). This paper is more a high-level analysis and discussion rather than attempting to provide a concrete solution. Pocket Network</a> is a separate blockchain being designed as of Sept 2018 that incentivises relaying transactions, that is intended to be compatible with other blockchains. Note also that Rocket Pool</a> is under development and is planned to be a pool for Casper, which will help to incentivise running a full node. Another alternative is VIPnode</a> which charges fees to light clients for full nodes that serve them. In light of these solutions being developed, perhaps a more appropriate approach to generally rewarding clients would be to incentivize bandwidth (relaying and downloading), storage and I/O (while computation is already incentivized with gas for miners and will be for proposers under sharding and Casper). Note also that notaries will be incentivized to download collations under sharding. Outdated (Casper FFG will be implemented with Ethereum 2.0 with sharding: shasper</a>): given that it looks like Casper FFG will be implemented soon, to minimize undue complexity to the protocol, incentivizing validation in the mean time may be considered not worthwhile. For a previous version of the proposal containing a proposal for rewarding a full node, refer to here</a>.</p>
Simple Summary</h2>
When each transaction is validated, give a reward to clients for developing the client.</p>
Abstract</h2>
The tragedy of the commons is a phenomenon that is well known in many sectors, most notably in regard to sustainability. It involves the over-utilization of shared finite resources, which detriments all participants and stakeholders involved (which in the case of a global public good can be everyone, including future generations). Without proper management of public resources, a tragedy of the commons can occur. Internalizing externalities (where externalities can be broadly defined as effects that are not accounted for in the intrinsic price of a good, service or resource) is one way of incentivizing the proper management of resources, although other methods that actually properly manage them are necessary. This EIP proposes to make a change to the protocol to provide a reward to clients for providing the software that enables Ethereum to function, where the reward can include a proportion of transaction fees (reducing the full proportion that the miner currently receives), and some newly minted ETH. Thus, clients are incentivized to maintain and improve the security and health of the Ethereum protocol and ecosystem. To summarize the mechanism in the proposal, a user agent is attached to a transaction, where this user agent contains a vector with the index of a client address in an access list. The client address could be inserted by the client and verified that it is the same as a read-only constant in the client's storage.</p>
Reward mechanisms that are external to being built in to the protocol are beyond the scope of this EIP. Such extra-protocol reward methods include state channel payments for extra services such as light client servers providing faster information such as receipts; state channel payments for buying state reads from full nodes; archival services (which is only applicable to future proposed versions of Ethereum with stateless clients); and tokens for the client and running full nodes.</p>
Motivation</h2>
Currently there is a lack of incentives for anyone to run a full node, while joining a mining pool is not really economical if one has to purchase a mining rig (several GPUs) now, since there is unlikely to be a return on investment by the time that Ethereum transitions to hybrid Proof-of-Work/Proof-of-Stake with Casper FFG</a>, then full PoS with CBC Casper</a>.</p>
Additionally, providing a reward for clients gives a revenue stream that is independent of state channels or other layer 2 mechanisms, which are less secure, although this insecurity can be offset by mechanisms such as insurance, bonded payments and time locks. Rationalising that investors may invest in a client because it is an enabler for the Ethereum ecosystem (and thus opening up investment opportunities) may not scale very well, and it seems that it is more sustainable to monetize the client as part of the service(s) that it provides.</p>
While it may be argued that the funds raised by the Ethereum pre-mine (the pre-ICO and the ICO) can be used to fund client development, that argument is questionable, since Parity is VC-funded, and other clients such as Prysmatic Labs 1</a>, 2</a>, 3</a> and exthereum</a> have received funding from other parties, whereas perhaps they would not have needed to do so if there was sufficient funding from the Ethereum pre-mine funds. Drops of Diamond</a> is yet to receive any funding.</p>
Incentivizing client development would more directly incentivize resource provision in the protocol, preventing a tragedy of the commons, where there is an extreme lack of supply and excess demand, leading to the protocol being unusable.</p>
See here</a> for an analysis in the context of Bitcoin, PoW, and a hybrid PoW/PoS protocol. While Ethereum has a gas limit, the section points out that this is not enough as the market cap increases and the incentive to attack the network increases, while the ratio of security costs to transaction fees does not, while PoS will further alleviate the problem. However, the section points out that PoS is not enough, since the costs of propagating, verifying and storing transactions are not incentivised. Note that the "Proof of Activity: Extending Bitcoin’s Proof of Work via Proof of Stake" paper also contains a scheme for incentivizing a target participation level.</p>

The word “activity” in the phrase Proof of  Activity emphasizes the point that only active stakeholders who maintain a full online node get rewarded, in exchange for the vital services that they provide for the network.  This stands in contrast to earlier Proof  of  Stake schemes in which offline stake can accumulate weight over time, and may ultimately be utilized in double-spending attacks.</p>
</blockquote>
We can also incentivize full nodes to propagate transactions and to store transactions or state, in addition to verifying them. While these first two incentivizations are outside the scope of this EIP, there are proposals here</a> and here</a>, respectively.</p>
Implementing this as a layer 2 solution may not ensure the sustainability of the protocol, since not everyone would use it; if the protocol doesn't have any cost for full nodes to validate transactions, then people will take advantage of that and not use the layer 2 solution. It seems that you should at least have the part where the reward is provided in protocol, but then that and the user agent signature doesn't really add anything else to the protocol, so doing some part in-protocol and some part e.g. the verification or a verification-game off-protocol could be done, but it's already done in protocol. Note also that some computationally expensive tasks are too challenging to feasibly do in protocol, e.g. due to not fitting in the gas limit, could be done with Truebit, where verifiers have an incentive.</p>
Not providing incentives for clients is an issue now as there is less incentive to build a client that aligns with the needs of users, funds need to be raised externally to the protocol to fund client development, which is not as decentralized. If only a smaller subset is able to fund client development, such as VCs, angel investors and institutional investors, that may not align well with the interests of all current and potential stakeholders of Ethereum (which includes future stakeholders). Ostensibly, one of the goals of Ethereum is to decentralize everything, including wealth, or in other words, to improve wealth equality. Not providing incentives for full nodes validating transactions may not seem like as much of an issue now, but not doing so could hinder the growth of the protocol. Of course, incentives aren't enough, it also needs to be technically decentralized so that it is ideally possible for a low-end mainstream computer or perhaps even a mobile or embedded IoT device to be a verifying full node, or at least to be able to help with securing the network if it is deemed impractical for them to be a full node.</p>
Note that with a supply cap (as in EIP-960</a>, the issuance can be prevented from increasing indefinitely. Alternatively, it could at least be reduced (still potentially but not necessarily to zero, or to the same rate at which Ether is burnt when slashing participants, such as validators under a Casper PoS scheme or notaries under a sharding scheme), e.g. by hard forks, or as per EIP-1015</a>, an on-chain contract governed by a decision assembly that gets signalling from other contracts that represent some set of stakeholders.</p>
Specification</h2>
Add a new field to each block called PrevBlockVerifications</code>, which is an arbitrary, unlimited size byte array. When a client verifies that a previous block is valid</a>, the client appends a user agent to PrevBlockVerifications via an opcode in a transaction, PREV_BLOCK_VERIF. The user agent is a vector with the  immutable fields: the blockhash of the block that is validated, and the index of a client address in an access list (details are below). A miner validates a transaction before including it in a block, however they are not able to change these fields of the vector because they're immutable.</p>
Send 0.15 ETH to the client (see the rationale below), when the block is processed. The amounts could include a proportion of transaction fees (while the miner would then receive less), which would reduce newly issued ETH. These amounts are specified in new ClientReward</code> fields in the block.</p>
In order to only incentivize verifying recent blocks, assert that the block number corresponding to a blockhash is less than 400 blocks ago.</p>
Attacks and added specifications to prevent them</h3>
A miner could create a client and fill their block with transactions that only contain the PREV_BLOCK_VERIF opcode (or alternatively, arbitrarily complex transactions, still with the opcode), with previous blockhashes that they have validated and the address of their client. To prevent this, state would have to store a list containing lists, with each sublist listing the blockhashes up to 400 blocks ago that correspond to a miner, then a miner (or a proposer under Casper CBC) could have to put down a deposit, and be slashed if the proposer inserts such a transaction (that contains a blockhash which they have already proposed, not just in a block but at any time previously). Updating the state to remove blockhashes more than 400 blocks ago would add additional overhead, although you could add an extra window for older blocks, say 120,000 blocks (roughly every 3 weeks), still ignore blocks that are older than 400 blocks ago, and remove these older 120,000 blocks every 120,000 blocks. An attacker could bribe a miner/proposer to include transactions like above that contain an address of a client in the access list which they own. However, the above slashing condition should disincentivize this.</p>
More details on the access list</h3>
The access list prevents anyone inserting any address to the first element of the vector, where there may be a way to prevent censorship and centralization of authority of who decides to register new addresses in the list, e.g. on-chain governance with signalling (possibly similar to EIP-1015</a>, which also specifies an alternative way of sending funds) or a layer 2 proof of authority network where new addresses can be added via a smart contract. Note that there may be serious drawbacks to implementing either of these listed examples. There is a refutation of on-chain governance</a> as well as of plutocracy</a>. Proof of Authority</a> isn't suitable for a public network since it doesn't distribute trust well. However, using signalling in layer 2 contracts is more acceptable, but Vlad Zamfir argues that using that to influence outcomes in the protocol can disenfranchise miners from being necessary participants in the governance process. Thus, in light of these counterpoints, having an access list may not be suitable until a decentralized, trustless way of maintaining it is implemented and ideally accepted by the majority of a random sample that represents the population of Ethereum users.</p>
However, another alternative to managing the access list would be to have decentralized verification that the address produced from querying an index in the access list does correspond to that of a "legitimate" client. Part of this verification would involve checking that there is a client that claims that this address is owned by them, that they are happy to receive funds in this manner and agree or arranged to putting the address in the access list, and that the client passes all tests in the Ethereum test suite</a>. However, this last proviso would then preclude new clients being funded from the start of development, although such would-be clients would not be able to receive funds in-protocol until they implement the client anyway (as an aside, they could raise funds in various ways—a DAII, pronounced die-yee, is recommended, while a platform for DAIIs is under development by Dogezer</a>). All of this could be done off-chain, and if anyone found that some address in the access list was not legitimate, then they could challenge that address with a proof of illegitimacy, and the participant that submitted the address to the access list could be slashed (while they must hold a deposit in order to register and keep an address in the access list).</p>
Additionally, it should help with being only able to read the client's address from the client, and the whole transaction could revert if the address is not in the access list. You could provide the index of the address in the access list, and then you could assert</code> that the address found at that index matches that which can be read by the client (where the latter would be a read-only address).</p>
Rationale</h2>
A rough qualitative analysis of fees</h3>
As of May 4 2018, there are 16428 nodes</a>. Assume that an annual cost for an average client developer organisation is $1 million per annum. Projecting forward (and noting that the number of nodes should increase substantially if this EIP was implemented, thus aiding Ethereum's goal of decentralizing everything) assume that there are 10 clients. Thus let us assume that the number of nodes doubles to 30000 nodes within 5 years (this assumption is probably conservative, even if it is forward looking). Assume for simplicity that the costs of a client are entirely covered by this block reward.</p>
Average cost per client = number of nodes * Block reward per client / number of clients</p>
Block reward per client (worse case for ETH price) = Average revenue per client * number of clients / (ETH exchange rate * number of nodes)</p>
= $2,000,000 * 10 / (500 * 30,000)</p>
= 1.333333333 ETH</p>
Block reward per client (better case) = $1,000,000 * 10 / (2000 * 30,000) = 0.166666667 ETH</p>
Suppose that we use a block reward of 0.15 ETH for clients.</p>

More rationale (outdated by above)</h3>
The amount of computation to validate a transaction will be the same as a miner, since the transaction will need to be executed. Thus, if there would be transaction fees for validating full nodes and clients, and transactions need to be executed by validators just like miners have to, it makes sense to have them calculated in the same way as gas fees for miners. This would controversially increase the amount of transaction fees a lot, since there can be many validators for a transaction. In other words, it is controversial whether to provide the same amount of transaction fee for a full node validator as for a miner (which in one respect is fair, since the validator has to do the same amount of computation), or prevent transaction fees from rising much higher, and have a transaction fee for a full node as, say, the transaction fee for a miner, divided by the average number of full nodes validating a transaction. The latter option seems even more controversial (but is still better than the status quo), since while there would be more of an incentive to run a full node than there is now with no incentive, validators would be paid less for performing the same amount of computation.</p>
And as for the absolute amounts, this will require data analysis, but clearly a full node should receive much less than a miner for processing a transaction in a block, since there are many transactions in a block, and there are many confirmations of a block. Data analysis could involve calculating the average number of full nodes verifying transactions in a block. Macroeconomic analysis could entail the economic security benefit that full nodes provide to the network.</p>
Now, as to the ratio of rewards to the client vs the full node, as an initial guess I would suggest something like 99:1. Why such a big difference? Well, I would guess that clients spend roughly 99 times more time on developing and maintaining the client than a full node user spends running and maintaining a full node. During a week there might be several full-time people working on the client, but a full node might only spend half an hour (or less) initially setting it up, plus running it, plus electricity and internet costs. Full node operators probably don't need to upgrade their computer (and buying a mining rig isn't worth it with Casper PoS planning on being implemented soon).</p>
However, on further analysis, clients would also get the benefit of a large volume of rewards from every full node running the client, so to incentivise full node operation further, the ratio could change to say, 4:1, or even 1:1, and of course could be adjusted with even further actual data analysis, rather than speculation.</p>
Providing rewards to full node validators and to clients would increase the issuance. In order to maintain the issuance at current levels, this EIP could also reduce the mining reward (despite being reduced previously with the Byzantium release in October 2017 from 5 ETH to 3 ETH), but that would generate more controversy and discussion.</p>
Another potential point of controversy with rewarding clients and full nodes is that the work previously done by them has not been paid for until now (except of course by the Ethereum Foundation or Parity VCs funding the work), so existing clients may say that this EIP gives an advantage to new entrants. However, this doesn't hold up well, because existing clients have the first mover advantage, with much development to create useful and well-used products.</p>
There is a tradeoff. Higher fees means you may cut out poor people and people who just don't want to pay fees. But if a laptop can run a full node and get paid for it then that would offset the fees through usage. Full nodes do provide a security benefit, so the total fees given could at least be some fraction of this benefit. Fees that go towards client development incentivise a higher quality client. To me, I think it makes more sense to internalize costs as much as possible: for computation, storage, bandwidth, I/O, client development, running full nodes, mining/validating, etc. You avoid a tragedy of the commons through externalizing costs. The more you internalize costs, the more sustainable it is, and the less you rely on rich people being generous, etc. (Although, getting philosophical, ultimately you can't force rich people to be generous, they have to do so out of the kindness of their hearts.)</p>
Regarding rewards for full nodes, in the draft phase 1 sharding spec</a> proposers acting as full nodes have rewards for proposing blobs (without execution) or later in phase 3 transactions (with execution) to be included into collations/blocks. So that would help. However, full nodes that do not act as proposers and just verify transactions, or full state nodes</a>, are still not incentivized.</p>
Note that while further quantitative analysis to specify fees should be done, some level of experimentation after implementing this method on-chain may be necessary.</p>
Security</h3>
All of the below struck out information should be prevented via using an access list and verifying that the read-only address provided by the client matches with an address in the access list, as well as using a layer 2 solution such as a PoA network for censorship resistance and minimization of centralization in the access list.</p>
Further discussion is at https://ethresear.ch/t/incentives-for-running-full-ethereum-nodes/1239.</p>
Backwards Compatibility</h2>
Introducing in-protocol fees is a backwards-incompatible change, so would be introduced in a hard-fork.</p>
Test Cases</h2>
TODO</p>
Implementation</h2>
TODO</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Simpler NFT standard with batching and native atomic swaps
2018-02-08T00:00:00+00:00
Summary</h2>
A simple non fungible token standard that allows batching tokens into lots and settling p2p atomic transfers in one transaction. You can test out an example implementation on rinkeby here: https://rinkeby.etherscan.io/address/0xffab5ce7c012bc942f5ca0cd42c3c2e1ae5f0005 and view the repo here: https://github.com/alpha-wallet/ERC-Example</p>
Purpose</h2>
While other standards allow the user to transfer a non-fungible token, they require one transaction per token, this is heavy on gas and partially responsible for clogging the ethereum network. There are also few definitions for how to do a simple atomic swap.</p>
Rinkeby example</h2>
This standard has been implemented in an example contract on rinkeby: https://rinkeby.etherscan.io/address/0xffab5ce7c012bc942f5ca0cd42c3c2e1ae5f0005</p>
Specification</h2>
function name() constant returns (string name)</h3>
returns the name of the contract e.g. CarLotContract</p>
function symbol() constant returns (string symbol)</h3>
Returns a short string of the symbol of the in-fungible token, this should be short and generic as each token is non-fungible.</p>
function balanceOf(address _owner) public view returns (uint256[] balance)</h3>
Returns an array of the users balance.</p>
function transfer(address _to, uint256[] _tokens) public;</h3>
Transfer your unique tokens to an address by adding an array of the token indices. This compares favourable to ERC721 as you can transfer a bulk of tokens in one go rather than one at a time. This has a big gas saving as well as being more convenient.</p>
function transferFrom(address _from, address _to, uint256[] _tokens) public;</h3>
Transfer a variable amount of tokens from one user to another. This can be done from an authorised party with a specified key e.g. contract owner.</p>
Optional functions</h2>
function totalSupply() constant returns (uint256 totalSupply);</h3>
Returns the total amount of tokens in the given contract, this should be optional as assets might be allocated and issued on the fly. This means that supply is not always fixed.</p>
function ownerOf(uint256 _tokenId) public view returns (address _owner);</h3>
Returns the owner of a particular token, I think this should be optional as not every token contract will need to track the owner of a unique token and it costs gas to loop and map the token id owners each time the balances change.</p>
function trade(uint256 expiryTimeStamp, uint256[] tokenIndices, uint8 v, bytes32 r, bytes32 s) public payable</h3>
A function which allows a user to sell a batch of non-fungible tokens without paying for the gas fee (only the buyer has to) in a p2p atomic swap. This is achieved by signing an attestation containing the amount of tokens to sell, the contract address, an expiry timestamp, the price and a prefix containing the ERC spec name and chain id. A buyer can then pay for the deal in one transaction by attaching the appropriate ether to satisfy the deal.</p>
This design is also more efficient as it allows orders to be done offline until settlement as opposed to creating orders in a smart contract and updating them. The expiry timestamp protects the seller against people using old orders.</p>
This opens up the gates for a p2p atomic swap but should be optional to this standard as some may not have use for it.</p>
Some protections need to be added to the message such as encoding the chain id, contract address and the ERC spec name to prevent replays and spoofing people into signing message that allow a trade.</p>
Interface</h2>
contract</span> ERC165</span> </span></span>
{</span></span>
            ///</span> @notice</span> Query if a contract implements an interface</span></span>
            ///</span> @param</span> interfaceID</span> The interface identifier, as specified in ERC-165</span></span>
            ///</span> @dev</span> Interface identification is specified in ERC-165. This function</span></span>
            ///</span>  uses less than 30,000 gas.</span></span>
            ///</span> @return</span> `true` if the contract implements `interfaceID` and</span></span>
            ///</span>  `interfaceID` is not 0xffffffff, `false` otherwise</span></span>
            function</span> supportsInterface</span>(</span>bytes4</span> interfaceID</span>)</span> external</span> view</span> returns</span> (</span>bool</span>)</span>;</span></span>
}</span></span>
</span>
interface</span> ERC875</span> /*</span> is ERC165 </span>*/</span></span>
{</span></span>
  event</span> Transfer</span>(</span>address</span> indexed</span> _from</span>, </span>address</span> indexed</span> _to</span>, </span>uint256</span>[</span>]</span> tokenIndices</span>)</span>;</span></span>
</span>
  function</span> name</span>(</span>)</span> constant</span> public</span> returns</span> (</span>string</span> name</span>)</span>;</span></span>
  function</span> symbol</span>(</span>)</span> constant</span> public</span> returns</span> (</span>string</span> symbol</span>)</span>;</span></span>
  function</span> balanceOf</span>(</span>address</span> _owner</span>)</span> public</span> view</span> returns</span> (</span>uint256</span>[</span>]</span> _balances</span>)</span>;</span></span>
  function</span> transfer</span>(</span>address</span> _to</span>,</span> uint256</span>[</span>]</span> _tokens</span>)</span> public</span>;</span></span>
  function</span> transferFrom</span>(</span>address</span> _from</span>,</span> address</span> _to</span>,</span> uint256</span>[</span>]</span> _tokens</span>)</span> public</span>;</span></span>
}</span></span>
</span>
//</span>If you want the standard functions with atomic swap trading added</span></span>
interface</span> ERC875WithAtomicSwapTrading</span> is</span> ERC875</span> {</span></span>
    function</span> trade</span>(</span></span>
        uint256</span> expiryTimeStamp</span>,</span> </span></span>
        uint256</span>[</span>]</span> tokenIndices</span>,</span></span>
        uint8</span> v</span>,</span> </span></span>
        bytes32</span> r</span>,</span> </span></span>
        bytes32</span> s</span></span>
    )</span> public</span> payable</span>;</span></span>
}</span></span></code></pre>Example implementation</h2>
Please visit this repo</a> to see an example implementation</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


URI Scheme with Metadata, Value and Bytecode
2016-02-17T00:00:00+00:00
Abstract</h2>
This proposal (inspired by BIP 21) defines a format for encoding a transaction into a URI, including a recipient, number of ethers (possibly zero), and optional bytecode.</p>
Motivation</h2>
Imagine these scenarios:</p>
* An exchange or a instant converter like ShapeShift wants to create a single Ethereum address for payments that will be converted into credit in their internal system or output bitcoin to an address.</span></span>
* A store wants to show a QR code to a client that will pop up a payment for exactly 12.34 ethers, which contains metadata on the product being bought.</span></span>
* A betting site wants to provide a link that the user can click on his site and it will open a default Ethereum wallet and execute a specific contract with given parameters.</span></span>
* A dapp in Mist wants to simply ask the user to sign a transaction with a specific ABI in a single call.</span></span></code></pre>
In all these scenarios, the provider wants to internally set up a transaction, with a recipient, an associated number of ethers (or none) and optional bytecode, all without requiring any fuss from the end user that is expected simply to choose a sender and authorise the transaction.</p>
Currently implementations for this are wonky: ShapeShift creates tons of temporary addresses and uses an internal system to check which one correspond to which metadata, there isn't any standard way for stores that want payment in ether to put specific metadata about price on the call and any app implementing contracts will have to use different solutions depending on the client they are targeting.</p>
The proposal goes beyond address, and also includes optional bytecode and value. Of course this would make the link longer, but it should not be something visible to the user. Instead it should be shown as a visual code (QR or otherwise), a link, or some other way to pass the information.</p>
If properly implemented in all wallets, this should make execution of contracts directly from wallets much simpler as the wallet client only needs to put the bytecode obtained by reading the QR code.</p>
Specification</h2>
If we follow the bitcoin standard, the result would be:</p>
 ethereum:<address>[?value=<value>][?gas=<suggestedGas>][?data=<bytecode>]</span></span></code></pre>
Other data could be added, but ideally the client should take them from elsewhere in the blockchain, so instead of having a label</code> or a message</code> to be displayed to the users, these should be read from an identity system or metadata on the transaction itself.</p>
Example 1</h3>
Clicking this link would open a transaction that would try to send 5 unicorns</em> to address deadbeef</em>. The user would then simply approve, based on each wallet UI.</p>
 ethereum:0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7?gas=100000&data=0xa9059cbb00000000000000000000000000000000000000000000000000000000deadbeef0000000000000000000000000000000000000000000000000000000000000005</span></span></code></pre>Without Bytecode</h4>
Alternatively, the bytecode could be generated by the client and the request would be in plain text:</p>
 ethereum:<address>[?value=<value>][?gas=<suggestedGas>][?function=nameOfFunction(param)]</span></span></code></pre>Example 2</h3>
This is the same function as above, to send 5 unicorns from he sender to deadbeef</em>, but now with a more readable function, which the client converts to bytecode.</p>
 ethereum:0x89205A3A3b2A69De6Dbf7f01ED13B2108B2c43e7?gas=100000&function=transfer(address 0xdeadbeef, uint 5)</span></span></code></pre>Rationale</h2>
TODO</p>
Security Considerations</h2>
TODO</p>
Copyright</h2>
Copyright and related rights waived via CC0</a>.</p>


Addition of CALLDEPTH opcode
2015-11-19T00:00:00+00:00
Abstract</h1>
This is a proposal to add a new opcode, CALLDEPTH</code>. The CALLDEPTH</code> opcode would return the remaining available call stack depth.</p>
Motivation</h1>
There is a limit specifying how deep contracts can call other contracts; the call stack. The limit is currently 256</code>. If a contract invokes another contract (either via CALL</code> or CALLCODE</code>), the operation will fail if the call stack depth limit has been reached.</p>
This behaviour makes it possible to subject a contract to a "call stack attack" [1]. In such an attack, an attacker first creates a suitable depth of the stack, e.g. by recursive calls. After this step, the attacker invokes the targeted contract. If the targeted calls another contract, that call will fail. If the return value is not properly checked to see if the call was successful, the consequences could be damaging.</p>
Example:</p>

Contract A</code> wants to be invoked regularly, and pays Ether to the invoker in every block.</li>
When contract A</code> is invoked, it calls contracts B</code> and C</code>, which consumes a lot of gas. After invocation, contract A</code> pays Ether to the caller.</li>
Malicious user X</code> ensures that the stack depth is shallow before invoking A. Both calls to B</code> and C</code> fail, but X</code> can still collect the reward.</li>
</ol>
It is possible to defend against this in two ways:</p>

Check return value after invocation.</li>
Check call stack depth experimentally. A library [2] by Piper Merriam exists for this purpose. This method is quite costly in gas.</li>
</ol>
[1] a.k.a "shallow stack attack" and "stack attack". However, to be precise, the word ''stack'' has a different meaning within the EVM, and is not to be confused with the ''call stack''.</p>
[2] https://github.com/pipermerriam/ethereum-stack-depth-lib</p>
Specification</h1>
The opcode CALLDEPTH</code> should return the remaining call stack depth. A value of 0</code> means that the call stack is exhausted, and no further calls can be made.</p>
Rationale</h1>
The actual call stack depth, as well as the call stack depth limit, are present in the EVM during execution, but just not available within the EVM. The implementation should be fairly simple and would provide a cheap and way to protect against call stack attacks.</p>
Implementation</h1>
Not implemented.</p>