diff --git a/_includes/toc.html b/_includes/toc.html
new file mode 100644
index 0000000..9c5bbf6
--- /dev/null
+++ b/_includes/toc.html
@@ -0,0 +1,96 @@
+{% capture tocWorkspace %}
+{% comment %}
+ Version 1.0.10
+ https://github.com/allejo/jekyll-toc
+
+ "...like all things liquid - where there's a will, and ~36 hours to spare, there's usually a/some way" ~jaybe
+
+ Usage:
+ {% include toc.html html=content sanitize=true class="inline_toc" id="my_toc" h_min=2 h_max=3 %}
+
+ Parameters:
+ * html (string) - the HTML of compiled markdown generated by kramdown in Jekyll
+
+ Optional Parameters:
+ * sanitize (bool) : false - when set to true, the headers will be stripped of any HTML in the TOC
+ * class (string) : '' - a CSS class assigned to the TOC
+ * id (string) : '' - an ID to assigned to the TOC
+ * h_min (int) : 1 - the minimum TOC header level to use; any header lower than this value will be ignored
+ * h_max (int) : 6 - the maximum TOC header level to use; any header greater than this value will be ignored
+ * ordered (bool) : false - when set to true, an ordered list will be outputted instead of an unordered list
+ * item_class (string) : '' - add custom class(es) for each list item; has support for '%level%' placeholder, which is the current heading level
+ * baseurl (string) : '' - add a base url to the TOC links for when your TOC is on another page than the actual content
+ * anchor_class (string) : '' - add custom class(es) for each anchor element
+
+ Output:
+ An ordered or unordered list representing the table of contents of a markdown block. This snippet will only
+ generate the table of contents and will NOT output the markdown given to it
+{% endcomment %}
+
+{% capture my_toc %}{% endcapture %}
+{% assign orderedList = include.ordered | default: false %}
+{% assign minHeader = include.h_min | default: 1 %}
+{% assign maxHeader = include.h_max | default: 6 %}
+{% assign nodes = include.html | split: ' maxHeader %}
+ {% continue %}
+ {% endif %}
+
+ {% if firstHeader %}
+ {% assign firstHeader = false %}
+ {% assign minHeader = headerLevel %}
+ {% endif %}
+
+ {% assign indentAmount = headerLevel | minus: minHeader %}
+ {% assign _workspace = node | split: '' | first }}>{% endcapture %}
+ {% assign header = _workspace[0] | replace: _hAttrToStrip, '' %}
+
+ {% assign space = '' %}
+ {% for i in (1..indentAmount) %}
+ {% assign space = space | prepend: ' ' %}
+ {% endfor %}
+
+ {% if include.item_class and include.item_class != blank %}
+ {% capture listItemClass %}{:.{{ include.item_class | replace: '%level%', headerLevel }}}{% endcapture %}
+ {% endif %}
+
+ {% capture heading_body %}{% if include.sanitize %}{{ header | strip_html }}{% else %}{{ header }}{% endif %}{% endcapture %}
+ {% capture my_toc %}{{ my_toc }}
+{{ space }}{{ listModifier }} {{ listItemClass }} [{{ heading_body | replace: "|", "\|" }}]({% if include.baseurl %}{{ include.baseurl }}{% endif %}#{{ html_id }}){% if include.anchor_class %}{:.{{ include.anchor_class }}}{% endif %}{% endcapture %}
+{% endfor %}
+
+{% if include.class and include.class != blank %}
+ {% capture my_toc %}{:.{{ include.class }}}
+{{ my_toc | lstrip }}{% endcapture %}
+{% endif %}
+
+{% if include.id %}
+ {% capture my_toc %}{: #{{ include.id }}}
+{{ my_toc | lstrip }}{% endcapture %}
+{% endif %}
+{% endcapture %}{% assign tocWorkspace = '' %}{{ my_toc | markdownify | strip }}
diff --git a/_layouts/eip.html b/_layouts/eip.html
new file mode 100644
index 0000000..084e316
--- /dev/null
+++ b/_layouts/eip.html
@@ -0,0 +1,149 @@
+---
+layout: default
+---
+
+
+
CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
+LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN
+ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
+INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
+REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS
+PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM
+THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED
+HEREUNDER.
+
+
+
Statement of Purpose
+
+
The laws of most jurisdictions throughout the world automatically confer
+exclusive Copyright and Related Rights (defined below) upon the creator
+and subsequent owner(s) (each and all, an “owner”) of an original work of
+authorship and/or a database (each, a “Work”).
+
+
Certain owners wish to permanently relinquish those rights to a Work for
+the purpose of contributing to a commons of creative, cultural and
+scientific works (“Commons”) that the public can reliably and without fear
+of later claims of infringement build upon, modify, incorporate in other
+works, reuse and redistribute as freely as possible in any form whatsoever
+and for any purposes, including without limitation commercial purposes.
+These owners may contribute to the Commons to promote the ideal of a free
+culture and the further production of creative, cultural and scientific
+works, or to gain reputation or greater distribution for their Work in
+part through the use and efforts of others.
+
+
For these and/or other purposes and motivations, and without any
+expectation of additional consideration or compensation, the person
+associating CC0 with a Work (the “Affirmer”), to the extent that he or she
+is an owner of Copyright and Related Rights in the Work, voluntarily
+elects to apply CC0 to the Work and publicly distribute the Work under its
+terms, with knowledge of his or her Copyright and Related Rights in the
+Work and the meaning and intended legal effect of CC0 on those rights.
+
+
+
Copyright and Related Rights. A Work made available under CC0 may be
+protected by copyright and related or neighboring rights (“Copyright and
+Related Rights”). Copyright and Related Rights include, but are not
+limited to, the following:
+
+
+
i. the right to reproduce, adapt, distribute, perform, display,
+ communicate, and translate a Work;
+ ii. moral rights retained by the original author(s) and/or performer(s);
+iii. publicity and privacy rights pertaining to a person’s image or
+ likeness depicted in a Work;
+ iv. rights protecting against unfair competition in regards to a Work,
+ subject to the limitations in paragraph 4(a), below;
+ v. rights protecting the extraction, dissemination, use and reuse of data
+ in a Work;
+ vi. database rights (such as those arising under Directive 96/9/EC of the
+ European Parliament and of the Council of 11 March 1996 on the legal
+ protection of databases, and under any national implementation
+ thereof, including any amended or successor version of such
+ directive); and
+vii. other similar, equivalent or corresponding rights throughout the
+ world based on applicable law or treaty, and any national
+ implementations thereof.
+
+
+
+
Waiver. To the greatest extent permitted by, but not in contravention
+of, applicable law, Affirmer hereby overtly, fully, permanently,
+irrevocably and unconditionally waives, abandons, and surrenders all of
+Affirmer’s Copyright and Related Rights and associated claims and causes
+of action, whether now known or unknown (including existing as well as
+future claims and causes of action), in the Work (i) in all territories
+worldwide, (ii) for the maximum duration provided by applicable law or
+treaty (including future time extensions), (iii) in any current or future
+medium and for any number of copies, and (iv) for any purpose whatsoever,
+including without limitation commercial, advertising or promotional
+purposes (the “Waiver”). Affirmer makes the Waiver for the benefit of each
+member of the public at large and to the detriment of Affirmer’s heirs and
+successors, fully intending that such Waiver shall not be subject to
+revocation, rescission, cancellation, termination, or any other legal or
+equitable action to disrupt the quiet enjoyment of the Work by the public
+as contemplated by Affirmer’s express Statement of Purpose.
+
+
+
Public License Fallback. Should any part of the Waiver for any reason
+be judged legally invalid or ineffective under applicable law, then the
+Waiver shall be preserved to the maximum extent permitted taking into
+account Affirmer’s express Statement of Purpose. In addition, to the
+extent the Waiver is so judged Affirmer hereby grants to each affected
+person a royalty-free, non transferable, non sublicensable, non exclusive,
+irrevocable and unconditional license to exercise Affirmer’s Copyright and
+Related Rights in the Work (i) in all territories worldwide, (ii) for the
+maximum duration provided by applicable law or treaty (including future
+time extensions), (iii) in any current or future medium and for any number
+of copies, and (iv) for any purpose whatsoever, including without
+limitation commercial, advertising or promotional purposes (the
+“License”). The License shall be deemed effective as of the date CC0 was
+applied by Affirmer to the Work. Should any part of the License for any
+reason be judged legally invalid or ineffective under applicable law, such
+partial invalidity or ineffectiveness shall not invalidate the remainder
+of the License, and in such case Affirmer hereby affirms that he or she
+will not (i) exercise any of his or her remaining Copyright and Related
+Rights in the Work or (ii) assert any associated claims and causes of
+action with respect to the Work, in either case contrary to Affirmer’s
+express Statement of Purpose.
+
+
+
Limitations and Disclaimers.
+
+
+
+
a. No trademark or patent rights held by Affirmer are waived, abandoned,
+ surrendered, licensed or otherwise affected by this document.
+ b. Affirmer offers the Work as-is and makes no representations or
+ warranties of any kind concerning the Work, express, implied,
+ statutory or otherwise, including without limitation warranties of
+ title, merchantability, fitness for a particular purpose, non
+ infringement, or the absence of latent or other defects, accuracy, or
+ the present or absence of errors, whether or not discoverable, all to
+ the greatest extent permissible under applicable law.
+ c. Affirmer disclaims responsibility for clearing rights of other persons
+ that may apply to the Work or any use thereof, including without
+ limitation any person’s Copyright and Related Rights in the Work.
+ Further, Affirmer disclaims responsibility for obtaining any necessary
+ consents, permissions or other rights required for any use of the
+ Work.
+ d. Affirmer understands and acknowledges that Creative Commons is not a
+ party to this document and has no duty or obligation with respect to
+ this CC0 or use of the Work.
+
+
+
+
+
+
+
+
+
+
diff --git a/_site/LICENSE.md b/_site/LICENSE.md
new file mode 100644
index 0000000..0e259d4
--- /dev/null
+++ b/_site/LICENSE.md
@@ -0,0 +1,121 @@
+Creative Commons Legal Code
+
+CC0 1.0 Universal
+
+ CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
+ LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN
+ ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
+ INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
+ REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS
+ PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM
+ THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED
+ HEREUNDER.
+
+Statement of Purpose
+
+The laws of most jurisdictions throughout the world automatically confer
+exclusive Copyright and Related Rights (defined below) upon the creator
+and subsequent owner(s) (each and all, an "owner") of an original work of
+authorship and/or a database (each, a "Work").
+
+Certain owners wish to permanently relinquish those rights to a Work for
+the purpose of contributing to a commons of creative, cultural and
+scientific works ("Commons") that the public can reliably and without fear
+of later claims of infringement build upon, modify, incorporate in other
+works, reuse and redistribute as freely as possible in any form whatsoever
+and for any purposes, including without limitation commercial purposes.
+These owners may contribute to the Commons to promote the ideal of a free
+culture and the further production of creative, cultural and scientific
+works, or to gain reputation or greater distribution for their Work in
+part through the use and efforts of others.
+
+For these and/or other purposes and motivations, and without any
+expectation of additional consideration or compensation, the person
+associating CC0 with a Work (the "Affirmer"), to the extent that he or she
+is an owner of Copyright and Related Rights in the Work, voluntarily
+elects to apply CC0 to the Work and publicly distribute the Work under its
+terms, with knowledge of his or her Copyright and Related Rights in the
+Work and the meaning and intended legal effect of CC0 on those rights.
+
+1. Copyright and Related Rights. A Work made available under CC0 may be
+protected by copyright and related or neighboring rights ("Copyright and
+Related Rights"). Copyright and Related Rights include, but are not
+limited to, the following:
+
+ i. the right to reproduce, adapt, distribute, perform, display,
+ communicate, and translate a Work;
+ ii. moral rights retained by the original author(s) and/or performer(s);
+iii. publicity and privacy rights pertaining to a person's image or
+ likeness depicted in a Work;
+ iv. rights protecting against unfair competition in regards to a Work,
+ subject to the limitations in paragraph 4(a), below;
+ v. rights protecting the extraction, dissemination, use and reuse of data
+ in a Work;
+ vi. database rights (such as those arising under Directive 96/9/EC of the
+ European Parliament and of the Council of 11 March 1996 on the legal
+ protection of databases, and under any national implementation
+ thereof, including any amended or successor version of such
+ directive); and
+vii. other similar, equivalent or corresponding rights throughout the
+ world based on applicable law or treaty, and any national
+ implementations thereof.
+
+2. Waiver. To the greatest extent permitted by, but not in contravention
+of, applicable law, Affirmer hereby overtly, fully, permanently,
+irrevocably and unconditionally waives, abandons, and surrenders all of
+Affirmer's Copyright and Related Rights and associated claims and causes
+of action, whether now known or unknown (including existing as well as
+future claims and causes of action), in the Work (i) in all territories
+worldwide, (ii) for the maximum duration provided by applicable law or
+treaty (including future time extensions), (iii) in any current or future
+medium and for any number of copies, and (iv) for any purpose whatsoever,
+including without limitation commercial, advertising or promotional
+purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each
+member of the public at large and to the detriment of Affirmer's heirs and
+successors, fully intending that such Waiver shall not be subject to
+revocation, rescission, cancellation, termination, or any other legal or
+equitable action to disrupt the quiet enjoyment of the Work by the public
+as contemplated by Affirmer's express Statement of Purpose.
+
+3. Public License Fallback. Should any part of the Waiver for any reason
+be judged legally invalid or ineffective under applicable law, then the
+Waiver shall be preserved to the maximum extent permitted taking into
+account Affirmer's express Statement of Purpose. In addition, to the
+extent the Waiver is so judged Affirmer hereby grants to each affected
+person a royalty-free, non transferable, non sublicensable, non exclusive,
+irrevocable and unconditional license to exercise Affirmer's Copyright and
+Related Rights in the Work (i) in all territories worldwide, (ii) for the
+maximum duration provided by applicable law or treaty (including future
+time extensions), (iii) in any current or future medium and for any number
+of copies, and (iv) for any purpose whatsoever, including without
+limitation commercial, advertising or promotional purposes (the
+"License"). The License shall be deemed effective as of the date CC0 was
+applied by Affirmer to the Work. Should any part of the License for any
+reason be judged legally invalid or ineffective under applicable law, such
+partial invalidity or ineffectiveness shall not invalidate the remainder
+of the License, and in such case Affirmer hereby affirms that he or she
+will not (i) exercise any of his or her remaining Copyright and Related
+Rights in the Work or (ii) assert any associated claims and causes of
+action with respect to the Work, in either case contrary to Affirmer's
+express Statement of Purpose.
+
+4. Limitations and Disclaimers.
+
+ a. No trademark or patent rights held by Affirmer are waived, abandoned,
+ surrendered, licensed or otherwise affected by this document.
+ b. Affirmer offers the Work as-is and makes no representations or
+ warranties of any kind concerning the Work, express, implied,
+ statutory or otherwise, including without limitation warranties of
+ title, merchantability, fitness for a particular purpose, non
+ infringement, or the absence of latent or other defects, accuracy, or
+ the present or absence of errors, whether or not discoverable, all to
+ the greatest extent permissible under applicable law.
+ c. Affirmer disclaims responsibility for clearing rights of other persons
+ that may apply to the Work or any use thereof, including without
+ limitation any person's Copyright and Related Rights in the Work.
+ Further, Affirmer disclaims responsibility for obtaining any necessary
+ consents, permissions or other rights required for any use of the
+ Work.
+ d. Affirmer understands and acknowledges that Creative Commons is not a
+ party to this document and has no duty or obligation with respect to
+ this CC0 or use of the Work.
diff --git a/_site/RIPS/rip-7212.html b/_site/RIPS/rip-7212.html
new file mode 100644
index 0000000..aa39f40
--- /dev/null
+++ b/_site/RIPS/rip-7212.html
@@ -0,0 +1,510 @@
+
+
+
+
+
+
+
+ EIP-7212: Precompile for secp256r1 Curve Support
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
This proposal creates a precompiled contract that performs signature verifications in the “secp256r1” elliptic curve by given parameters of message hash, r and s components of the signature, x and y coordinates of the public key. So that, any EVM chain - principally Ethereum rollups - will be able to integrate this precompiled contract easily.
+
+
+
+
+ Motivation
+
+
+
+
+
“secp256r1” elliptic curve is a standardized curve by NIST which has the same calculations by different input parameters with “secp256k1” elliptic curve used by the “ecrecover” precompiled contract. The cost of combined attacks and the security conditions are almost the same for both curves. Adding a precompiled contract which is similar to “ecrecover” can provide signature verifications using the “secp256r1” elliptic curve in the smart contracts and multi-faceted benefits can occur. One important factor is that this curve is widely used and supported in many modern devices such as Apple’s Secure Enclave, Webauthn, Android Keychain which proves the user adoption. Additionally, the introduction of this precompiled contract could enable valuable features in the account abstraction which allows more efficient and flexible management of accounts by transaction signs in mobile devices.
+Most of the modern devices and applications rely on the “secp256r1” elliptic curve. The addition of this precompiled contract enables the verification of device native transaction signing mechanisms. For example:
+
+
+
Apple’s Secure Enclave: There is a separate “Trusted Execution Environment” in Apple hardware which can sign arbitrary messages and can only be accessed by biometric identification.
+
Webauthn: Web Authentication (WebAuthn) is a web standard published by the World Wide Web Consortium (W3C). WebAuthn aims to standardize an interface for authenticating users to web-based applications and services using public-key cryptography. It is being used by almost all of the modern web browsers.
+
Android Keystore: Android Keystore is an API that manages the private keys and signing methods. The private keys are not processed while using Keystore as the applications’ signing method. Also, it can be done in the “Trusted Execution Environment” in the microchip.
+
Passkeys: Passkeys is utilizing FIDO Alliance and W3C standards. It replaces passwords with cryptographic key-pairs which is also can be used for the elliptic curve cryptography.
+
+
+
Modern devices have these signing mechanisms that are designed to be more secure and they are able to sign transaction data, but none of the current wallets are utilizing these signing mechanisms. So, these secure signing methods can be enabled by the proposed precompiled contract to initiate the transactions natively from the devices and also, can be used for the key management. This proposal aims to reach maximum security and convenience for the key management.
+
+
+
+
+ Specification
+
+
+
+
+
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.
+
+
As of FORK_TIMESTAMP in the integrated EVM chain, add precompiled contract P256VERIFY for signature verifications in the “secp256r1” elliptic curve at address PRECOMPILED_ADDRESS in 0x100 (indicates 0x0000000000000000000000000000000000000100).
+
+
+
+
+ Elliptic Curve Information
+
+
+
+
+
“secp256r1” is a specific elliptic curve, also known as “P-256” and “prime256v1” curves. The curve is defined with the following equation and domain parameters:
+
+
# curve: short weierstrass form
+y^2 ≡ x^3 + ax + b
+
+# p: curve prime field modulus
+0xffffffff00000001000000000000000000000000ffffffffffffffffffffffff
+
+# a: elliptic curve short weierstrass first coefficient
+0xffffffff00000001000000000000000000000000fffffffffffffffffffffffc
+
+# b: elliptic curve short weierstrass second coefficient
+0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b
+
+# G: base point of the subgroup
+(0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296,
+ 0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5)
+
+# n: subgroup order (number of points)
+0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551
+
+# h: cofactor of the subgroup
+0x1
+
+
The signature verifying algorithm takes the signed message hash, the signature components provided by the “secp256r1” curve algorithm, and the public key derived from the signer private key. The verification can be done with the following steps:
+
+
# h (message hash)
+# pubKey = (public key of the signer private key)
+
+# Calculate the modular inverse of the signature proof:
+s1 = s^(−1) (mod n)
+
+# Recover the random point used during the signing:
+R' = (h * s1) * G + (r * s1) * pubKey
+
+# Take from R' its x-coordinate:
+r' = R'.x
+
+# Calculate the signature validation result by comparing whether:
+r' == r
+
+
+
+
+
+
+ Required Checks in Verification
+
+
+
+
+
The following requirements MUST be checked by the precompiled contract to verify signature components are valid:
+
+
+
Verify that the r and s values are in (0, n) (exclusive) where n is the order of the subgroup.
+
Verify that the point formed by (x, y) is on the curve and that both x and y are in [0, p) (inclusive 0, exclusive p) where p is the prime field modulus. Note that many implementations use (0, 0) as the reference point at infinity, which is not on the curve and should therefore be rejected.
+
+
+
+
+
+ Precompiled Contract Specification
+
+
+
+
+
The P256VERIFY precompiled contract is proposed with the following input and outputs, which are big-endian values:
+
+
+
Input data: 160 bytes of data including:
+
+
32 bytes of the signed data hash
+
32 bytes of the r component of the signature
+
32 bytes of the s component of the signature
+
32 bytes of the x coordinate of the public key
+
32 bytes of the y coordinate of the public key
+
+
+
Output data: 32 bytes of result data and error
+
+
If the signature verification process succeeds, it returns 1 in 32 bytes format.
+
+
+
+
+
+
+
+ Precompiled Contract Gas Usage
+
+
+
+
+
The use of signature verification cost by P256VERIFY is 3450 gas. Following reasons and calculations are provided in the Rationale and Test Cases sections.
+
+
+
+
+ Rationale
+
+
+
+
+
“secp256r1” ECDSA signatures consist of v, r, and s components. While the v value makes it possible to recover the public key of the signer, most signers do not generate the v component of the signature since r and s are sufficient for verification. In order to provide an exact and more compatible implementation, verification is preferred over recovery for the precompile.
+
+
Existing P256 implementations verify (x, y, r, s) directly. We’ve chosen to match this style here, encoding each argument for the EVM as a uint256.
+
+
This is different from the ecrecover precompiled address specification. The advantage is that it 1. follows the NIST specification (as defined in NIST FIPS 186-5 Digital Signature Standard (DSS)), 2. matches the rest of the (large) P256 ecosystem, and most importantly 3. allows execution clients to use existing well-vetted verifier implementations and test vectors.
+
+
Another important difference is that the NIST FIPS 186-5 specification does not include a malleability check. We’ve matched that here in order to maximize compatibility with the large existing NIST P-256 ecosystem.
+
+
Wrapper libraries SHOULD add a malleability check by default, with functions wrapping the raw precompile call (exact NIST FIPS 186-5 spec, without malleability check) clearly identified. For example, P256.verifySignature and P256.verifySignatureWithoutMalleabilityCheck. Adding the malleability check is straightforward and costs minimal gas.
+
+
The PRECOMPILED_ADDRESS is chosen as 0x100 as P256VERIFY is the first precompiled contract presented as an RIP, and the address is the first available address in the precompiled address set that is reserved for the RIP precompiles.
+
+
The gas cost is proposed by comparing the performance of the P256VERIFY and the ECRECOVER precompiled contract which is implemented in the EVM at 0x01 address. It is seen that “secp256r1” signature verification is ~15% slower (elaborated in test cases) than “secp256k1” signature recovery, so 3450 gas is proposed by comparison which causes similar “mgas/op” values in both precompiled contracts.
+
+
+
+
+ Backwards Compatibility
+
+
+
+
+
No backward compatibility issues found as the precompiled contract will be added to PRECOMPILED_ADDRESS at the next available address in the precompiled address set.
+
+
+
+
+ Test Cases
+
+
+
+
+
Functional tests are applied for multiple cases in the reference implementation of P256VERIFY precompiled contract and they succeed. Benchmark tests are also applied for both P256VERIFY and ECRECOVER with some pre-calculated data and signatures in the “go-ethereum”s precompile testing structure to propose a meaningful gas cost for the “secp256r1” signature verifications by the precompiled contract implemented in the reference implementation. The benchmark test results by example data in the assets can be checked:
Implementation of the P256VERIFY precompiled contract is applied to go-ethereum client to create a reference. Also, a “secp256r1” package has already been included in the Besu Native library which is used by Besu client. Other client implementations are in the future roadmap.
+
+
+
+
+ Security Considerations
+
+
+
+
+
The changes are not directly affecting the protocol security, it is related with the applications using P256VERIFY for the signature verifications. The “secp256r1” curve has been using in many other protocols and services and there is not any security issues in the past.
Combining the EIP-2938
+and ERC-4337
+into a comprehensive Native Account Abstraction proposal.
+
+
We propose splitting the Ethereum transaction scope into multiple steps: validations, execution,
+and post-transaction logic.
+Transaction validity is determined by the result of the validation steps of a transaction.
+
+
We further separate transaction validation for the purposes of authorization and the gas fee payment,
+allowing contract B to pay gas for a transaction that will be executed from account contract A.
+
+
The benefits are in backward compatibility with the emerging ERC-4337 ecosystem while achieving the
+long-term goal of Native Account Abstraction.
+
+
+
+
+ Motivation
+
+
+
+
+
ERC-4337 can do a lot as a purely voluntary ERC. However, any of the out-of-protocol ways of achieving
+Account Abstraction faces several drawbacks compared to native support. There are a few key areas where
+it is weaker than a truly in-protocol solution:
+
+
+
+
Existing users cannot benefit from it or upgrade to use it without moving all their assets and activity
+to a new account.
+
+
+
Extra gas overhead of ~42k for a basic UserOperation compared to ~21k for a basic transaction.
+
+
+
Less benefit from in-protocol censorship resistance techniques such as crLists, which target transactions
+and would miss UserOperations.
+
+
+
Relying on a significantly smaller set of participating nodes and non-standard RPC methods like
+eth_sendRawTransactionConditional.
+
+
+
Inability to use tx.origin or contracts that rely on it as it returns the meaningless address of a bundler.
+
+
+
+
EIP-2938 defines a very mature alternative approach to Account Abstraction. However, it does not translate
+well to the architecture of ERC-4337 that is being used in production without any protocol changes.
+Therefore, the implementation of EIP-2938 will not benefit as much from the production experience gained by using
+ERC-4337 and from maintaining backward compatibility with it.
+
+
There is also a possibility that at some point in the future, the EOAs on Ethereum will be replaced with pre-deployed
+smart contracts. This, however, is impossible without an addition of Native Account Abstraction to the protocol.
A new EIP-2718 transaction with type AA_TX_TYPE is introduced. Transactions of this type are referred to as
+“AA transactions”. Their payload should be interpreted as:
The base gas cost of this transaction is set to AA_BASE_GAS_COST instead of 21000 to reflect the lack of “intrinsic”
+ECDSA signature verification.
+
+
If paymasterData is specified, its first 20 bytes contain the address of a paymaster contract.
+
+
If deployerData is specified, its first 20 bytes contain the address of a deployer contract.
+
+
+
+
+ Optional “transaction counter header”
+
+
+
+
+
In some cases the block builders may want to split up an array of type AA_TX_TYPE transactions into individual
+batches of transactions that perform validations and executions separately.
+
+
Without a header transaction type this would only be possible by creating an artificial legacy type transaction.
+Instead, we propose to introduce an explicit “counter” transaction subtype.
The blockNumber and txIndex parameters are added to the hash to achieve unique header transaction IDs.
+
+
The header transactions are only used to help execution clients determine how many of the AA_TX_TYPE transactions
+belong to each individual batch.
+The block is not valid if a header transaction is located anywhere except before an AA_TX_TYPE transactions.
+If a header transaction is included all AA_TX_TYPE transactions in the block must be covered by one.
+
+
Header transactions do not affect blockchain state and do not cost any gas.
+
+
+
+
+ Non-sequential nonce support
+
+
+
+
+
Before RIP-7560, for accounts with associated code (smart contracts), the account nonce is only used and incremented
+when the account executes the CREATE (0xf0) opcode.
+
+
However, with Smart Contract Accounts this creates a bottleneck for some use-cases.
+For example, an account that is operated by multiple participants simultaneously will require these participants
+to coordinate their transactions to avoid invalidating each other.
+
+
Another example when this can also be a limitation is a case where there are separate execution flows.
+A configuration change may require multiple participants to co-sign a transaction but a regular operation does not.
+With sequential nonces, all operations will have to be halted until the configuration change is executed.
+
+
To address it we propose an introduction of a separate 2-dimensional nonce used when contracts initiate a transaction.
+
+
The nonce parameter of the transaction is to be interpreted as uint192 key || uint64 seq value.
+The contract account nonce is then defined as a mapping address account => uint192 key => uint64 seq.
+This approach guarantees unique transaction nonce and hash but removes the requirement of nonce being sequential
+numbers.
+
+
This nonce is exposed to the EVM in a NonceManager pre-deployed contract located at the AA_NONCE_MANAGER address.
If paymaster is not specified, the maxPossibleGasCost is charged up-front, before any computation is done in any
+execution frame, from the balance of the sender address.
+If paymaster is specified, the gas cost is charged from its balance.
+The transaction is invalid if the balance of the account that is being pre-charged,
+whether it is a sender or a paymaster, is insufficient.
+After the transaction finishes its execution, the address that was pre-charged may receive a gas refund.
+
+
+
+
+ Gas fees charged for transaction input
+
+
+
+
+
For all the existing transaction types, G_txdatazero (4 gas) and G_txdatanonzero (16 gas) per byte is
+charged for the data parameter.
+
+
Transaction Type AA_TX_TYPE introduces the following dynamic length inputs: callData, paymasterData,
+deployerData, signature. Each of these parameters’ gas cost is counted towards transaction data cost.
+This transaction data gas cost is referred to as calldataCost and is subtracted from the validationGasLimit
+before execution of the transaction.
+The transaction is considered INVALID if validationGasLimit is smaller than calldataCost.
+
+
+
+
+ Builder Fee
+
+
+
+
+
As we need to account for an additional off-chain work that block builders have to perform to
+include AA_TX_TYPE transactions in their blocks, as well as a potential L1 gas cost for builders
+operating on L2 rollups, and given that this work does not correspond to the amount of gas spent on
+validation and is not linked to the gas price, the sender may decide
+to pay an extra builderFee as a “tip” to the block builder.
+
+
This value is denominated in wei and is passed from the sender, or the paymaster if it is specified,
+to the coinbase of the current block as part of the gas pre-charge.
+
+
+
+
+ Unused gas penalty charge
+
+
+
+
+
Transactions of type AA_TX_TYPE that reserve a lot of gas for themselves using validationGasLimit,
+paymasterGasLimit and callGasLimit fields but do not use the reserved gas present a challenge for
+block builders. This is especially demanding in case a gas used by a transaction can be significantly different
+based on its position within a block, as such transactions may cause the block builder to iterate its algorithm
+many times until a fully utilized block is discovered.
+
+
A penalty of UNUSED_GAS_PENALTY percent of the entire unused gas limit is charged from the
+transaction sender or paymaster.
+
+
The total gas limit is calculated as totalLimit = validationGasLimit + paymasterGasLimit + callGasLimit.
+The totalGasUsed is calculated as a sum of all gas used during the transaction.
+The unused gas is calculated as unusedGas = totalLimit - totalGasUsed.
+
+
+
+
+ Multiple execution frames for a single transaction
+
+
+
+
+
All existing transaction types only have an implicit validation phase where balance, nonce, and signature are checked,
+and a single top-level execution frame with
+tx.origin == msg.sender which is the address that is determined by a transaction ECDSA signature.
+
+
When processing a transaction of type AA_TX_TYPE, however, multiple execution frames will be created.
+The full list of possible frames tries to replicate the ERC-4337 flow:
+
+
+
Validation Phase
+
+
nonce validation and increment frame (required)
+
sender deployment frame (once per account)
+
sender validation frame (required)
+
paymaster validation frame (optional)
+
+
+
Execution Phase
+
+
sender execution frame (required)
+
paymaster post-transaction frame (optional)
+
+
+
+
+
All execution frames in the “Validation Phase” must be completed successfully without reverting, and the return value
+for sender and paymaster validation frames must include MAGIC_VALUE_SENDER and MAGIC_VALUE_PAYMASTER accrodingly
+in order for the transaction to be considered valid for a given position in a block.
+
+
In terms of block validity, all validation and execution frames may read and write any state when included in the block.
+However, the AA transactions in the mempool SHOULD be bound by storage access rules to avoid DoS on block builders.
+These rules are defined in ERC-7562.
+
+
In all top-level frames, the global variables have the following meaning:
+
+
+
+
+
Opcode Name
+
Solidity Equivalent
+
Value
+
+
+
+
+
CALLER
+
msg.sender
+
The AA_ENTRY_POINT address. AA_SENDER_CREATOR for the “deployment frame”.
+
+
+
ORIGIN
+
tx.origin
+
The transaction sender address
+
+
+
CALLDATA*
+
msg.data
+
The transaction data is set to inputs of the corresponding frame
+
+
+
+
+
+
+
+ Nonce validation frame
+
+
+
+
+
The NonceManager is invoked with the following data:
+
+
abi.encodePacked(sender,nonce)
+
+
+
+
+
+ Sender deployment frame
+
+
+
+
+
The deployer address is invoked with the deployerData[20:] as call data input.
+It is important that the deployer is not invoked from the AA_ENTRY_POINT but from the AA_SENDER_CREATOR.
+This is necessary to guarantee that AA_ENTRY_POINT may never initiate a call to a sender execution function
+without first completing a successful validation.
+
+
The gas limit of this frame is set to validationGasLimit.
+The amount of gas used by this frame is referred to as senderCreationGasUsed.
+
+
The sender deployment frame MUST result in the sender address becoming
+initialized with contract code.
+
+
+
+
+ Sender validation frame
+
+
+
+
+
We define the following Solidity struct to represent the AA transaction on-chain:
The gas limit of this frame is set to validationGasLimit - senderCreationGasUsed - calldataCost.
+The transaction parameter is interpreted as an ABI encoding of TransactionType4.
+The txHash parameter represents the hash of the AA_TX_TYPE transaction with empty signature, as defined in section
+Calculation of Transaction Type AA_TX_TYPE hash.
+The version parameter is added in order to maintain the Solidity method ID in case of changes to this struct
+in future revisions of this EIP.
+
+
The amount of gas used by this frame is referred to as senderValidationGasUsed.
+
+
The frame must return 32 bytes validationData that is interpreted as:
In order to allow a gas estimation to determine the amount of gas that this frame
+requires to complete successfully while not having the actual signature value, this function
+should avoid reverting on invalid signature, and should return a value different from MAGIC_VALUE_SENDER.
+
+
Type of the validUntil is 6-byte timestamp value, or zero for “infinite”. The transaction is valid only up to this time.
+Type of the validAfter is 6-byte timestamp. The transaction is valid only after this time.
+
+
The validateTransaction function can choose to revert on any condition that can be satisfied during gas estimation.
+
+
+
+
+ Paymaster validation frame
+
+
+
+
+
The paymaster of the transaction, if specified, is invoked with the following data:
The gas limit of this frame is set to paymasterGasLimit.
+
+
The amount of gas used by this frame is referred to as paymasterValidationGasUsed.
+
+
The transaction parameter is interpreted as an ABI encoding of TransactionType4.
+The txHash parameter represents the hash of the AA_TX_TYPE transaction with empty signature, as defined in section
+Calculation of Transaction Type AA_TX_TYPE hash.
+
+
The frame must return a bytes array that is interpreted as:
Same as in the sender validation frame, in order to support gas estimation this
+frame should return a value different from MAGIC_VALUE_PAYMASTER for conditions that cannot be satisfied
+before signing.
+
+
The size of the context byte array may not exceed MAX_CONTEXT_SIZE for a transaction to be considered valid.
+
+
+
+
+ Sender execution frame
+
+
+
+
+
The sender address is invoked with callData input.
+
+
The gas limit of this frame is set to callGasLimit.
+Calculation of the calldataCost value is defined in the
+Gas fees charged for transaction input section.
+The amount of gas used by this frame is referred to as gasUsedByExecution.
+
+
The validation frames do not revert if the execution frame reverts.
+The postPaymasterTransaction may still be called with a success: false flag.
+
+
+
+
+ Paymaster post-transaction frame
+
+
+
+
+
After the sender execution frame is over the paymaster may need to perform some post-transaction logic,
+for instance to perform some kind of cleanup or bookkeeping.
+If the gas payment validation returned a non-zero context, the paymaster is invoked again
+with the following inputs:
The actualGasCost parameter is the actual amount paid by the paymaster for this transaction,
+and success indicates whether this transaction’s execution frame completed without revert.
+
+
The gas limit of this frame is set to paymasterGasLimit - paymasterValidationGasUsed.
+
+
Revert in the postPaymasterTransaction frame reverts the transaction’s execution frame as well.
+The validation frames do not revert if the postPaymasterTransaction frame reverts.
+The gas fees charged from the paymaster will still include the gas cost of the reverted execution frame.
+
+
+
+
+ Execution flow diagram
+
+
+
+
+
The execution flow determined by an Account Abstraction Transaction is visualised by the following flow diagram:
+
+
+Execution flow for the Native Account Abstraction Transactions
In order to defend from DoS attack vectors, the block builders performing mempool transaction validation SHOULD consider
+the opcode banning and storage access rules described in ERC-7562.
+
+
Block validation takes roughly the same amount of work as without AA transactions.
+In any case, validation must execute the entire block in order to verify the state change.
+During this execution, it currently verifies signatures, nonces, and gas payment.
+With Account Abstraction, it will also verify that all the validation frames were successful.
+There is a slight increase in required memory mostly used to store the context value that is passed from
+the paymaster validation frame to its post-transaction frame.
+
+
As long as all transaction validation steps return correct values the block is considered valid.
+Block builders who are willing to relax the rules applied to the validation frames MAY do so.
+
+
Such transactions MUST NOT be propagated through the default transaction mempool as they will be rejected by the nodes
+and the sending node will be blocked as a spammer.
+They may be propagated in the alternative mempool that allows them explicitly as defined in ERC-7562.
+
+
+
+
+ All validation state changes apply before all execution ones
+
+
+
+
+
Filling a block with AA transactions must not be a challenge for the block builder.
+However, if each transaction during its execution can alter any state that affects the validity of another transaction
+in the mempool, the block builder will be forced to revalidate all transactions in the mempool after each inclusion.
+
+
We mitigate that by applying all changes in all the validation frames of a sequence of AA transactions first
+and all execution frames apply immediately after that.
+
+
In theory, the validation frames can also invalidate each other, but we define ways to prevent that by applying
+certain rules for the mempool transactions in ERC-7562.
+
+
A builder that chooses not to enforce the rules from ERC-7562 must take care to re-validate each transaction
+against the mid-block state at the position where it is being included into a block.
+Otherwise, the resulting block is likely to end up being invalid.
+
+
+
+
+ Block structure diagram
+
+
+
+
+
Here is a visual representation of a block that contains multiple Account Abstraction Transactions.
+The validation parts of AA transactions are executed as separate transactions,
+but are not represented as separate transactions in the block data.
+
+
+The structure of a block containing multiple Native Account Abstraction Transactions
+
+
Zooming into a single transaction, the validation part of an AA transaction may include multiple exectution frames:
+
+
+Frames within a single Native Account Abstraction Transaction within a block
The validation frames of the AA_TX_TYPE transaction are represented as individual virtual transactions by the clients.
+They are assigned their own sequential transactionIndex, and their transactionHash is defined as
+(AA_TX_TYPE transaction hash + 1).
+
+
All block-related RPC methods, like eth_getBlockByHash and eth_getBlockByNumber, must include these virtual
+transactions as part of the transactions field and include validation in the block transaction count.
+
+
All transaction-related RPC methods, like eth_getTransactionByHash and eth_getTransactionReceipt, must
+accept the virtual transaction hash as input and return the details calculated as if the validation was a
+separate transaction.
+
+
There is a number of behaviours that define transaction-wide effects in Ethereum.
+This list includes, but is not limited to:
Any such behaviour has separate effects in the “Validation Virtual Transaction” and “Execution Transaction”.
+
+
Gas refunds are issued at the end of the entire transaction only.
+
+
+
+
+ Transaction validity time range parameters
+
+
+
+
+
The Paymaster validation frame and the Sender validation frame each return values validUntil and validAfter.
+If the transaction is initiated by an EOA, these fields may be encoded into unused bits of the nonce.
+
+
These values allow the sender and paymaster contracts to specify
+a time range for the blocks the transaction will be valid for.
+
+
Transaction cannot be included in a block outside of this time range.
+If included, such a block is considered invalid.
+
+
Passing validUntil = 0 and validAfter = 0 disables the check.
+
+
+
+
+ Calculation of Transaction Type AA_TX_TYPE hash
+
+
+
Note that the chainId and accessList parameters are included in the transaction hash calculation but are not
+available on-chain as part of the TransactionType4 struct.
+
+
In order to calculate the transaction hash that will be used during the signing of the transaction and validation of
+the transaction signature by the sender, the value of the signature parameter is considered to be an empty
+byte array.
+
+
+
+
+ Accepting EOA account as sender to achieve native gas abstraction
+
+
+
+
+
In case the sender address does not have any code deployed and the deployerData length is zero,
+interpret the signature parameter as (y_parity, r, s) and the nonce parameter
+as (validUntil, validAfter, nonce).
+Replace the sender validation frame with default ECDSA signature validation.
+Also check the block timestamp is within the [validUntil, validAfter] range.
+
+
The base transaction gas cost, in this case, is increased by AA_ECRECOVER_COST.
+
+
The callData parameter in this case is interpreted as following:
+
+
+target || value || data
+
+
+
+
+
+
+ Execution layer block validation
+
+
+
+
+
When validating a block, the validity conditions for a block are extended as follows:
+
+
+for txIndex := 0; txIndex < range block.Transactions.Len(); txIndex++ {
+
+ // 1. Save the current transaction
+ txCurr = block.Transactions[txIndex]
+
+ if (txCurr.Type() == AccountAbstractionTransaction) {
+
+ // 2. Start running validations for AA transactions
+ for j := txIndex; j < range block.Transactions().Len(); j++ {
+ tx = block.Transactions[j]
+
+ // 3. Stop after encountering a non-AA transaction (or reaching the end of the block)
+ if (tx.Type() != AccountAbstractionTransaction) {
+ break
+ }
+ context[j], paymasterValidationGasUsed[j], error := validateAccountAbstractionTransaction(tx)
+ assert error == nil
+ }
+
+ // 4. If all validations are successful, go back to the saved tx index and run all executions
+ for j := txIndex; j < range block.Transactions().Len(); j++ {
+ tx = block.Transactions[j]
+ if (tx.Type() != AccountAbstractionTransaction) {
+ break
+ }
+
+ retCall, error := evm.Call(
+ from: AA_ENTRY_POINT,
+ to: sender,
+ input: callData,
+ gas: callGasLimit)
+
+ txIndex := j // transaction executed - no need to revisit in the outer loop
+
+
+ // 5. Run paymaster's post-transaction logic if necessary
+ if (context[j].Len() == 0){
+ continue
+ }
+
+ paymasterPostTransactionInput := ABI.encodeWithSelector('postPaymasterTransaction', success, actualGasCost, context[j])
+ retPostTransaction, error := evm.Call(
+ from: AA_ENTRY_POINT,
+ to: paymaster,
+ input: paymasterPostTransactionInput,
+ gas: paymasterGasLimit - paymasterValidationGasUsed[j])
+ }
+ }
+ else {
+ // handle other types of transactions
+ evm.Apply(txCurr)
+ }
+}
+
+
+
+
+
+
+ RPC methods (eth namespace)
+
+
+
+
+
+
+
+ eth_sendTransaction and eth_sendRawTransaction
+
+
+
+
+
Accepts Transaction Type AA_TX_TYPE.
+
+
Return values unchanged for a successful call.
+
+
In case of failure, MUST return an error result object, with code and message.
+The error code and message SHOULD be set as follows:
+
+
+
+
code: -32500 - transaction validation failed by sender.
+The message field SHOULD be set to the revert message from the sender.
+
+
+
code: -32501 - transaction validation failed by paymaster.
+The message field SHOULD be set to the revert message from the paymaster.
+
+
+
code: -32502 - transaction rejected because of storage or opcode rules violation in a validation frame.
+The message field SHOULD be set to the location and description of the violated rule.
+
+
+
code: -32503 - Transaction out of time range.
+
+
+
code: -32504 - transaction rejected because paymaster is throttled or banned, as defined by ERC-7562.
+
+
+
code: -32505 - transaction rejected because factory is throttled or banned.
+
+
+
code: -32506 - transaction rejected because sender is throttled or banned.
+
+
+
+
+
+
+ eth_signTransaction
+
+
+
+
+
Accepts Transaction Type AA_TX_TYPE.
+
+
Returns the RLP-encoded transaction object with value for the signature field that makes the AA_TX_TYPE
+transaction valid.
+
+
Returns error object if this operation cannot be performed by the RPC endpoint.
+
+
+
+
+ eth_getTransactionReceipt
+
+
+
+
+
Accepts the hash of a virtual transaction that encapsulates the validation frames of the AA_TX_TYPE transaction.
+This transaction’s ID is defined as (AA_TX_TYPE transaction hash + 1).
+
+
If an AA transaction is included in a block, returns the following values in addition to the existing fields:
+
+
+
+
+
Name
+
Value
+
+
+
+
+
sender
+
Address of the sender of this transaction
+
+
+
nonce
+
The transaction nonce value
+
+
+
paymaster
+
Address of the Paymaster if it is paying for the transaction, null otherwise
+
+
+
deployer
+
Address of the Deployer if it is included in the transaction, null otherwise
+
+
+
senderCreationGasUsed
+
The amount of gas actually used by the sender deployment frame
+
+
+
senderValidationGasUsed
+
The amount of gas actually used by the sender validation frame
+
+
+
paymasterValidationGasUsed
+
The amount of gas actually used by the paymaster validation frame
+
+
+
+
+
Accepts hash of Transaction Type AA_TX_TYPE.
+
+
If an AA transaction is included in a block, returns the following values in addition to the existing fields:
+
+
+
+
+
Name
+
Value
+
+
+
+
+
status
+
Either 1 (success) or 0 (failure) status of the execution frame
+
+
+
executionGasUsed
+
The amount of gas actually used by the execution frame
+
+
+
postPaymasterTransactionStatus
+
Either 1 (success), 0 (failure), or null (did not run) status of the postPaymasterTransaction frame
+
+
+
postPaymasterTransactionGasUsed
+
The amount of gas actually used by the paymaster postPaymasterTransaction frame
+
+
+
+
+
Note that the field to is not included as there is no clear target in an AA_TX_TYPE transaction.
+
+
+
+
+ eth_call
+
+
+
+
+
Accepts Transaction Type AA_TX_TYPE with all fields except from and callData optional.
If provided with paymasterData and deployerData also executes the corresponding frame.
+
+
If any of the frames reverts the call returns the revert data of each reverted frame.
+
+
+
+
+ eth_estimateGasAccountAbstraction
+
+
+
+
+
Accepts Transaction Type AA_TX_TYPE with fields validationGasLimit, paymasterGasLimit, callGasLimit optional.
+
+
Optionally accepts the State Override Set to allow users to modify the state during the gas estimation.
+This field as well as its behavior is equivalent to the ones defined for eth_call RPC method.
Note that the deployerData and paymasterData fields are required for a consistent result.
+
+
As mentioned earlier, the sender and paymaster contracts should not revert on the validation failure
+and should return a value different from MAGIC_VALUE_SENDER or MAGIC_VALUE_PAYMASTER accordingly
+in order to enable gas estimation.
+
+
One acceptable way to achieve this behavior for Smart Contract Accounts is to compare the signature parameter to
+a predetermined “dummy signature” and to return without reverting in case the values match.
+This will not result in transaction being authorized as long as returned value does not include MAGIC_VALUE_SENDER.
+
+
+
+
+ Rationale
+
+
+
+
+
+
+
+ Using Solidity method selectors in a Core EIP
+
+
+
+
+
The contracts that have a role in this Account Abstraction proposal, such as sender or paymaster,
+MUST know which code to execute and understand the calldata provided to them in order to validate the transaction.
+
+
We argue that the most straightforward implementation is to rely on Solidity 4-byte method selectors as it is an
+established de-facto standard.
While it may seem like allowing EOAs to initiate AA_TX_TYPE transactions contradicts the purpose of Account Abstraction, we argue that this
+may actually be important for the adoption of Smart Contract Accounts.
+
+
It will enable all existing EOAs to benefit from the improved UX features like gas abstraction and validity ranges.
This EIP preserves most of the design elements established by the ERC-4337. This allows the same client code and smart
+contracts to be used in both systems with minimal to no modifications, while providing significant UX improvements.
+
+
Existing contracts are not significantly affected by the change.
+The assumption that tx.origin is guaranteed to be an EOA is no longer valid.
+The assumption that tx.origin is the address that pays for the current transaction is no longer valid as well.
+
+
Any code that expects a single top-level execution frame for an Ethereum transaction will have to accommodate
+the new transaction type.
+
+
EIP-3607 introduces a ban on transactions from senders with deployed code.
+This limitation does not apply to AA_TX_TYPE transactions.
+
+
+
+
+ Migration path for existing ERC-4337 projects and further roadmap
+
+
+
+
+
+
+
+ Existing bundlers can co-exist on the network
+
+
+
+
+
The ERC-4337 is not a protocol change and may remain operational in parallel to this EIP indefinitely.
+Given the similarity to ERC-4337, the same block builders may easily support both ERC-4337 and AA_TX_TYPE transactions.
+
+
+
+
+ Accounts need to upgrade their EntryPoint to an adapter contract
+
+
+
+
+
The team behind ERC-4337 will provide a reference implementation of a contract converting
+the ABI of the paymaster and sender contracts. This adapter can be set as a trusted
+EntryPoint address by the ERC-4337 contracts.
+
+
+
+
+ Supporting ERC-4337 RPC calls as a compatibility layer
+
+
+
+
+
The sender contracts MAY support both ERC-4337 and AA_TX_TYPE transactions during a transition period,
+as long as this EIP may be adopted by some chains and not by others.
+
+
+
+
+ Security Considerations
+
+
+
+
+
This EIP creates a complex and sophisticated mechanism and aims to expand the usage of Smart Contract Accounts.
+All of it creates a lot of new risk vectors and attack surfaces.
+
+
The following is a non-exhaustive list of known security considerations regarding Native Account Abstraction.
+
+
+
+
+ Attacks on validation-execution separation
+
+
+
+
+
The state that exists at the end of the validation frame may be observed or modified by unrelated contracts before
+the execution frame begins.
+Sender contracts must take great care in making sure their code does not make any false assumptions.
+
+
+
+
+ DoS attacks on block builders
+
+
+
+
+
The amount of computation and available memory that is necessary to maintain a mempool and produce valid blocks is
+increased significantly.
+
+
+
+
+ Directly charging the balance of a contract
+
+
+
+
+
This EIP adds a new way for a smart contract to have its balance charged simply by returning a valid value from a
+function with method ID that corresponds to validateTransaction, validatePaymasterTransaction.
+
+
This creates a new kind of risk for contracts that accidentally or maliciously contain such methods but are not public
+about the fact that these contracts can be used as a sender or a paymaster in an AA_TX_TYPE transaction.
+
+
This is somewhat mitigated by requiring these contracts to return MAGIC_VALUE_SENDER or MAGIC_VALUE_PAYMASTER,
+however code reviewers should still be aware of this.
+
+
+
+
+ Observing revert reasons in a validation frame
+
+
+
+
+
Existing transaction types get included in a block even if reverted and provide a revert reason for debugging purposes.
+There is a very short list of things that can cause a transaction not to be included on-chain:
+
+
+
low gas fee
+
insufficient balance
+
invalid nonce
+
censorship
+
+
+
This is not the case for reverts that occur in the validation phase of an AA_TX_TYPE transaction.
+In order to address this developers should track the validity of these transactions being signed and are encouraged
+to rely on the validUntil time range parameter to guarantee a transaction that has not been included in the intended time
+will not become valid again unexpectedly for the user who had sent it.
Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards. Network upgrades are discussed separately in the Ethereum Project Management repository.
+
+
Contributing
+
First review EIP-1. Then clone the repository and add your EIP to it. There is a template EIP here. Then submit a Pull Request to Ethereum's EIPs repository.
+
+
EIP status terms
+
+
Idea - An idea that is pre-draft. This is not tracked within the EIP Repository.
+
Draft - The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.
+
Review - An EIP Author marks an EIP as ready for and requesting Peer Review.
+
Last Call - This is the final review window for an EIP before moving to FINAL. An EIP editor will assign Last Call status and set a review end date (`last-call-deadline`), typically 14 days later. If this period results in necessary normative changes it will revert the EIP to Review.
+
Final - This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.
+
Stagnant - Any EIP in Draft or Review if inactive for a period of 6 months or greater is moved to Stagnant. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to Draft.
+
Withdrawn - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.
+
Living - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.
+
+
+
EIP Types
+
+
EIPs are separated into a number of types, and each has its own list of EIPs.
+
+
Standard Track (2)
+
Describes any change that affects most or all Ethereum implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard EIPs can be broken down into the following categories.
Improvements requiring a consensus fork (e.g. EIP-5, EIP-211), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, the PoA algorithm for testnets described in EIP-225).
Includes improvements around devp2p (EIP-8) and Light Ethereum Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.
Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (EIP-6) and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.
Application-level standards and conventions, including contract standards such as token standards (EIP-20), name registries (EIP-137), URI schemes (EIP-681), library/package formats (EIP-190), and account abstraction (EIP-4337).
Describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP.
+
+
+
+
+
+
diff --git a/_site/rss/all.xml b/_site/rss/all.xml
new file mode 100644
index 0000000..47718d4
--- /dev/null
+++ b/_site/rss/all.xml
@@ -0,0 +1,1650 @@
+
+
+
+ Ethereum EIPs
+ A feed of all EIPs
+ http://localhost:4000
+
+ Sat, 03 Feb 2024 00:10:05 +0530
+
+
+
+
+ /
+
+ <style type="text/css" media="screen">
+ .container {
+ margin: 10px auto;
+ max-width: 600px;
+ text-align: center;
+ }
+ h1 {
+ margin: 30px 0;
+ font-size: 4em;
+ line-height: 1;
+ letter-spacing: -1px;
+ }
+</style>
+
+<div class="container">
+ <h1>404</h1>
+ <p><strong>Page not found :(</strong></p>
+ <p>The requested page could not be found.</p>
+</div>
+
+
+ http://localhost:4000/404
+ http://localhost:4000/404
+
+
+
+ All
+ /
+
+ <style type="text/css">
+ .eiptable .title {
+ width: 67%;
+ }
+
+ .eiptable .author {
+ width: 33%;
+ }
+</style>
+
+
+
+
+
+
+
+
+ <h2 id="final">Final</h2>
+ <table class="eiptable">
+ <thead>
+
+ <tr><th class="eipnum">Number</th><th class="title">Title</th><th class="author">Author</th></tr>
+
+ </thead>
+
+ <tr>
+ <td class="eipnum"><a href="/RIPS/rip-7212">7212</a></td>
+
+ <td class="title">Precompile for secp256r1 Curve Support</td>
+ <td class="author">Ulaş Erdoğan (<a href="https://github.com/ulerdogan">@ulerdogan</a>), Doğan Alpaslan (<a href="https://github.com/doganalpaslan">@doganalpaslan</a>)</td>
+ </tr>
+
+ </table>
+
+
+
+
+
+
+
+
+
+
+
+
+
+ <h2 id="draft">Draft</h2>
+ <table class="eiptable">
+ <thead>
+
+ <tr><th class="eipnum">Number</th><th class="title">Title</th><th class="author">Author</th></tr>
+
+ </thead>
+
+ <tr>
+ <td class="eipnum"><a href="/RIPS/rip-7560">7560</a></td>
+
+ <td class="title">Native Account Abstraction</td>
+ <td class="author">Vitalik Buterin (<a href="https://github.com/vbuterin">@vbuterin</a>), Yoav Weiss (<a href="https://github.com/yoavw">@yoavw</a>), Alex Forshtat (<a href="https://github.com/forshtat">@forshtat</a>), Dror Tirosh (<a href="https://github.com/drortirosh">@drortirosh</a>), Shahaf Nacson (<a href="https://github.com/shahafn">@shahafn</a>)</td>
+ </tr>
+
+ </table>
+
+
+
+
+
+
+
+
+
+
+
+
+
+ http://localhost:4000/all
+ http://localhost:4000/all
+
+
+
+
+ /
+
+ <?xml version="1.0" encoding="UTF-8"?>
+<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
+ <channel>
+ <title>Ethereum EIPs</title>
+ <description>A feed of all EIPs</description>
+ <link>{{ site.url }}</link>
+ <atom:link href="{{ site.url }}/all.xml" rel="self" type="application/rss+xml" />
+ <lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate>
+ {% assign eips = site.pages | sort: 'eip' %}
+ {% for eip in eips %}
+ <item>
+ <title>{{ eip.title | xml_escape }}</title>
+ <category>{{ eip.type | xml_escape }}/{{ eip.category | xml_escape }}</category>
+ {% if eip.discussions-to %}
+ <comments>{{ eip.discussions-to | xml_escape }}</comments>
+ {% endif %}
+ <description>{{ eip.content | xml_escape }}</description>
+ <pubDate>{{ eip.created | date_to_rfc822 }}</pubDate>
+ <link>{{ site.url }}{{ eip.url }}</link>
+ <guid isPermaLink="true">{{ site.url }}{{ eip.url }}</guid>
+ </item>
+ {% endfor %}
+ </channel>
+</rss>
+
+
+ http://localhost:4000/rss/all.xml
+ http://localhost:4000/rss/all.xml
+
+
+
+ Core
+ /
+
+ {% assign eips=site.pages|where:"type","Standards Track"|where:"category","Core" %}
+{% include eiptable.html eips=eips %}
+
+
+ http://localhost:4000/core
+ http://localhost:4000/core
+
+
+
+
+ /
+
+ <?xml version="1.0" encoding="UTF-8"?>
+<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
+ <channel>
+ <title>Ethereum EIPs - Last Call Review</title>
+ <description>All EIPs which are in the "last call" status, please help review these and provide your feedback!</description>
+ <link>{{ site.url }}</link>
+ <atom:link href="{{ site.url }}/rss/last-call.xml" rel="self" type="application/rss+xml" />
+ <lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate>
+ {% assign eips = site.pages | sort: 'eip' %}
+ {% for eip in eips %}
+ {% if eip.category == "ERC" %}
+ {% if eip.status == "Last Call" %}
+ {% capture description %}
+ <p><strong>EIP #{{ eip.eip }} - {{eip.title }}</strong> is in Last Call status. It is authored by {{ eip.author }} and was originally created {{ eip.created }}. It is in the {{ eip.category }} category of type {{ eip.type }}. Please review and note any changes that should block acceptance.</p>
+ {% if eip.discussions-to %}
+ <p>The author has requested that discussions happen at the following URL: <a href="{{ eip.discussions-to }}">{{ eip.discussions-to }}</a></p>
+ {% endif %}
+ <hr />
+ {{ eip.content }}
+ {% endcapture %}
+ <item>
+ <title>{{ eip.title | xml_escape }}</title>
+ <description>{{ description | xml_escape }}</description>
+ <pubDate>{{ eip.created | date_to_rfc822 }}</pubDate>
+ <link>{{ site.url }}/{{ eip.url }}</link>
+ <guid isPermaLink="true">{{ site.url }}/{{ eip.url }}</guid>
+ </item>
+ {% endif %}
+ {% endif %}
+ {% endfor %}
+ </channel>
+</rss>
+
+
+ http://localhost:4000/rss/erc-last-call.xml
+ http://localhost:4000/rss/erc-last-call.xml
+
+
+
+
+ /
+
+ <?xml version="1.0" encoding="UTF-8"?>
+<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
+ <channel>
+ <title>Ethereum ERCs</title>
+ <description>All updates for ERCs</description>
+ <link>{{ site.url }}</link>
+ <atom:link href="{{ site.url }}/rss/erc.xml" rel="self" type="application/rss+xml" />
+ <lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate>
+ {% assign eips = site.pages | sort: 'eip' %}
+ {% for eip in eips %}
+ {% if eip.category == "ERC" %}
+ {% capture description %}
+ <p><strong>EIP #{{ eip.eip }} - {{eip.title }}</strong> is in the {{ eip.category }} category of type {{ eip.type }} and was just updated.</p>
+ {% if eip.discussions-to %}
+ <p>The author has requested that discussions happen at the following URL: <a href="{{ eip.discussions-to }}">{{ eip.discussions-to }}</a></p>
+ {% endif %}
+ <hr />
+ {{ eip.content }}
+ {% endcapture %}
+ <item>
+ <title>{{ eip.title | xml_escape }}</title>
+ <description>{{ description | xml_escape }}</description>
+ <pubDate>{{ eip.created | date_to_rfc822 }}</pubDate>
+ <link>{{ site.url }}/{{ eip.url }}</link>
+ <guid isPermaLink="true">{{ site.url }}/{{ eip.url }}</guid>
+ </item>
+ {% endif %}
+ {% endfor %}
+ </channel>
+</rss>
+
+
+ http://localhost:4000/rss/erc.xml
+ http://localhost:4000/rss/erc.xml
+
+
+
+ Home
+ /
+
+ <h1 class="page-heading">EIPs
+ <a href="https://discord.io/EthCatHerders"><img src="https://dcbadge.vercel.app/api/server/Nz6rtfJ8Cu?style=flat" alt="Discord channel for ECH eip-editer"></a>
+ <a href="https://discord.gg/EVTQ9crVgQ"><img src="https://dcbadge.vercel.app/api/server/EVTQ9crVgQ?style=flat" alt="Discord channel for Eth R&D eip-editing"></a>
+ <a href="https://discord.gg/mRzPXmmYEA"><img src="https://dcbadge.vercel.app/api/server/mRzPXmmYEA?style=flat" alt="Discord server for discussions about proposals that impact Ethereum wallets"></a>
+
+ <a href="rss/last-call.xml"><img src="https://img.shields.io/badge/rss-Last Calls-red.svg" alt="RSS"></a>
+ <a href="rss/nonerc.xml"><img src="https://img.shields.io/badge/rss-All except ERC-red.svg" alt="RSS"></a>
+ <a href="https://eepurl.com/ikqNIP"><img src="https://img.shields.io/badge/-email%20alerts-red.svg" alt="RSS"></a>
+</h1>
+<p>Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards. Network upgrades are discussed separately in the <a target="_blank" href="https://github.com/ethereum/pm/">Ethereum Project Management</a> repository.</p>
+
+<h2>Contributing</h2>
+<p>First review <a href="EIPS/eip-1">EIP-1</a>. Then clone the repository and add your EIP to it. There is a <a href="https://github.com/ethereum/EIPs/blob/master/eip-template.md?plain=1">template EIP here</a>. Then submit a Pull Request to Ethereum's <a href="https://github.com/ethereum/EIPs">EIPs repository</a>.</p>
+
+<h2>EIP status terms</h2>
+<ul>
+ <li><strong>Idea</strong> - An idea that is pre-draft. This is not tracked within the EIP Repository.
+ <li><strong>Draft</strong> - The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.</li>
+ <li><strong>Review</strong> - An EIP Author marks an EIP as ready for and requesting Peer Review.</li>
+ <li><strong>Last Call</strong> - This is the final review window for an EIP before moving to FINAL. An EIP editor will assign Last Call status and set a review end date (`last-call-deadline`), typically 14 days later. If this period results in necessary normative changes it will revert the EIP to Review.</li>
+ <li><strong>Final</strong> - This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.</li>
+ <li><strong>Stagnant</strong> - Any EIP in Draft or Review if inactive for a period of 6 months or greater is moved to Stagnant. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to Draft.</li>
+ <li><strong>Withdrawn</strong> - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.</li>
+ <li><strong>Living</strong> - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.</li>
+</ul>
+
+<h2>EIP Types</h2>
+
+<p>EIPs are separated into a number of types, and each has its own list of EIPs.</p>
+
+<h3>Standard Track ({{site.pages|where:"type","Standards Track"|size}})</h3>
+<p>Describes any change that affects most or all Ethereum implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard EIPs can be broken down into the following categories.</p>
+
+<h4><a href="{{"core"|relative_url}}">Core</a> ({{site.pages|where:"type","Standards Track"|where:"category","Core"|size}})</h4>
+<p>Improvements requiring a consensus fork (e.g. <a href="./EIPS/eip-5">EIP-5</a>, <a href="./EIPS/eip-211">EIP-211</a>), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, the PoA algorithm for testnets described in <a href="./EIPS/eip-225">EIP-225</a>).</p>
+
+<h4><a href="{{"networking"|relative_url}}">Networking</a> ({{site.pages|where:"type","Standards Track"|where:"category","Networking"|size}})</h4>
+<p>Includes improvements around devp2p (<a href="./EIPS/eip-8">EIP-8</a>) and Light Ethereum Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.</p>
+
+<h4><a href="{{"interface"|relative_url}}">Interface</a> ({{site.pages|where:"type","Standards Track"|where:"category","Interface"|size}})</h4>
+<p>Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (<a href="./EIPS/eip-6">EIP-6</a>) and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.</p>
+
+<h4><a href="{{"erc"|relative_url}}">ERC</a> ({{site.pages|where:"type","Standards Track"|where:"category","ERC"|size}})</h4>
+<p>Application-level standards and conventions, including contract standards such as token standards (<a href="./EIPS/eip-20">EIP-20</a>), name registries (<a href="./EIPS/eip-137">EIP-137</a>), URI schemes (<a href="./EIPS/eip-681">EIP-681</a>), library/package formats (<a href="./EIPS/eip-190">EIP-190</a>), and account abstraction (<a href="./EIPS/eip-4337">EIP-4337</a>).</p>
+
+<h3><a href="{{"meta"|relative_url}}">Meta</a> ({{site.pages|where:"type","Meta"|size}})</h3>
+<p>Describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP.</p>
+
+
+ http://localhost:4000/
+ http://localhost:4000/
+
+
+
+
+ /
+
+ <?xml version="1.0" encoding="UTF-8"?>
+<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
+ <channel>
+ <title>Ethereum EIPs - Last Call Review</title>
+ <description>All EIPs which are in the two-week "last call" status, please help review these and provide your feedback!</description>
+ <link>{{ site.url }}</link>
+ <atom:link href="{{ site.url }}/rss/last-call.xml" rel="self" type="application/rss+xml" />
+ <lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate>
+ {% assign eips = site.pages | sort: 'eip' %}
+ {% for eip in eips %}
+ {% if eip.status == "Last Call" %}
+ {% capture description %}
+ <p><strong>EIP #{{ eip.eip }} - {{eip.title }}</strong> is in Last Call status. It is authored by {{ eip.author }} and was originally created {{ eip.created }}. It is in the {{ eip.category }} category of type {{ eip.type }}. Please review and note any changes that should block acceptance.</p>
+ {% if eip.discussions-to %}
+ <p>The author has requested that discussions happen at the following URL: <a href="{{ eip.discussions-to }}">{{ eip.discussions-to }}</a></p>
+ {% endif %}
+ <hr />
+ {{ eip.content }}
+ {% endcapture %}
+ <item>
+ <title>{{ eip.title | xml_escape }}</title>
+ <description>{{ description | xml_escape }}</description>
+ <pubDate>{{ eip.created | date_to_rfc822 }}</pubDate>
+ <link>{{ site.url }}/{{ eip.url }}</link>
+ <guid isPermaLink="true">{{ site.url }}/{{ eip.url }}</guid>
+ </item>
+ {% endif %}
+ {% endfor %}
+ </channel>
+</rss>
+
+
+ http://localhost:4000/rss/last-call.xml
+ http://localhost:4000/rss/last-call.xml
+
+
+
+
+ /
+
+ <?xml version="1.0" encoding="UTF-8"?>
+<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
+ <channel>
+ <title>Ethereum EIPs - Last Call Review</title>
+ <description>All EIPs which are in the two-week "last call" status, please help review these and provide your feedback!</description>
+ <link>{{ site.url }}</link>
+ <atom:link href="{{ site.url }}/rss/last-call.xml" rel="self" type="application/rss+xml" />
+ <lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate>
+ {% assign eips = site.pages | sort: 'eip' %}
+ {% for eip in eips %}
+ {% unless eip.category == "ERC" %}
+ {% if eip.status == "Last Call" %}
+ {% capture description %}
+ <p><strong>EIP #{{ eip.eip }} - {{eip.title }}</strong> is in Last Call status. It is authored by {{ eip.author }} and was originally created {{ eip.created }}. It is in the {{ eip.category }} category of type {{ eip.type }}. Please review and note any changes that should block acceptance.</p>
+ {% if eip.discussions-to %}
+ <p>The author has requested that discussions happen at the following URL: <a href="{{ eip.discussions-to }}">{{ eip.discussions-to }}</a></p>
+ {% endif %}
+ <hr />
+ {{ eip.content }}
+ {% endcapture %}
+ <item>
+ <title>{{ eip.title | xml_escape }}</title>
+ <description>{{ description | xml_escape }}</description>
+ <pubDate>{{ eip.created | date_to_rfc822 }}</pubDate>
+ <link>{{ site.url }}/{{ eip.url }}</link>
+ <guid isPermaLink="true">{{ site.url }}/{{ eip.url }}</guid>
+ </item>
+ {% endif %}
+ {% endunless %}
+ {% endfor %}
+ </channel>
+</rss>
+
+
+ http://localhost:4000/rss/nonerc-last-call.xml
+ http://localhost:4000/rss/nonerc-last-call.xml
+
+
+
+
+ /
+
+ <?xml version="1.0" encoding="UTF-8"?>
+<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
+ <channel>
+ <title>Ethereum EIPs</title>
+ <description>All EIPs that are not ERCs</description>
+ <link>{{ site.url }}</link>
+ <atom:link href="{{ site.url }}/rss/last-call.xml" rel="self" type="application/rss+xml" />
+ <lastBuildDate>{{ site.time | date_to_rfc822 }}</lastBuildDate>
+ {% assign eips = site.pages | sort: 'eip' %}
+ {% for eip in eips %}
+ {% unless eip.category == "ERC" %}
+ {% if eip.status == "Last Call" %}
+ {% capture description %}
+ <p><strong>EIP #{{ eip.eip }} - {{eip.title }}</strong> is in Last Call status. It is authored by {{ eip.author }} and was originally created {{ eip.created }}. It is in the {{ eip.category }} category of type {{ eip.type }}. Please review and note any changes that should block acceptance.</p>
+ {% if eip.discussions-to %}
+ <p>The author has requested that discussions happen at the following URL: <a href="{{ eip.discussions-to }}">{{ eip.discussions-to }}</a></p>
+ {% endif %}
+ <hr />
+ {{ eip.content }}
+ {% endcapture %}
+ <item>
+ <title>{{ eip.title | xml_escape }}</title>
+ <description>{{ description | xml_escape }}</description>
+ <pubDate>{{ eip.created | date_to_rfc822 }}</pubDate>
+ <link>{{ site.url }}/{{ eip.url }}</link>
+ <guid isPermaLink="true">{{ site.url }}/{{ eip.url }}</guid>
+ </item>
+ {% endif %}
+ {% endunless %}
+ {% endfor %}
+ </channel>
+</rss>
+
+
+ http://localhost:4000/rss/nonerc.xml
+ http://localhost:4000/rss/nonerc.xml
+
+
+
+ Precompile for secp256r1 Curve Support
+ Standards Track/Core
+
+ https://ethereum-magicians.org/t/eip-7212-precompiled-for-secp256r1-curve-support/14789
+
+ ## Abstract
+
+This proposal creates a precompiled contract that performs signature verifications in the “secp256r1” elliptic curve by given parameters of message hash, `r` and `s` components of the signature, `x` and `y` coordinates of the public key. So that, any EVM chain - principally Ethereum rollups - will be able to integrate this precompiled contract easily.
+
+## Motivation
+
+“secp256r1” elliptic curve is a standardized curve by NIST which has the same calculations by different input parameters with “secp256k1” elliptic curve used by the “ecrecover” precompiled contract. The cost of combined attacks and the security conditions are almost the same for both curves. Adding a precompiled contract which is similar to "ecrecover" can provide signature verifications using the “secp256r1” elliptic curve in the smart contracts and multi-faceted benefits can occur. One important factor is that this curve is widely used and supported in many modern devices such as Apple’s Secure Enclave, Webauthn, Android Keychain which proves the user adoption. Additionally, the introduction of this precompiled contract could enable valuable features in the account abstraction which allows more efficient and flexible management of accounts by transaction signs in mobile devices.
+Most of the modern devices and applications rely on the “secp256r1” elliptic curve. The addition of this precompiled contract enables the verification of device native transaction signing mechanisms. For example:
+
+1. **Apple's Secure Enclave:** There is a separate “Trusted Execution Environment” in Apple hardware which can sign arbitrary messages and can only be accessed by biometric identification.
+2. **Webauthn:** Web Authentication (WebAuthn) is a web standard published by the World Wide Web Consortium (W3C). WebAuthn aims to standardize an interface for authenticating users to web-based applications and services using public-key cryptography. It is being used by almost all of the modern web browsers.
+3. **Android Keystore:** Android Keystore is an API that manages the private keys and signing methods. The private keys are not processed while using Keystore as the applications’ signing method. Also, it can be done in the “Trusted Execution Environment” in the microchip.
+4. **Passkeys:** Passkeys is utilizing FIDO Alliance and W3C standards. It replaces passwords with cryptographic key-pairs which is also can be used for the elliptic curve cryptography.
+
+Modern devices have these signing mechanisms that are designed to be more secure and they are able to sign transaction data, but none of the current wallets are utilizing these signing mechanisms. So, these secure signing methods can be enabled by the proposed precompiled contract to initiate the transactions natively from the devices and also, can be used for the key management. This proposal aims to reach maximum security and convenience for the key management.
+
+## Specification
+
+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.
+
+As of `FORK_TIMESTAMP` in the integrated EVM chain, add precompiled contract `P256VERIFY` for signature verifications in the “secp256r1” elliptic curve at address `PRECOMPILED_ADDRESS` in `0x100` (indicates 0x0000000000000000000000000000000000000100).
+
+### Elliptic Curve Information
+
+“secp256r1” is a specific elliptic curve, also known as “P-256” and “prime256v1” curves. The curve is defined with the following equation and domain parameters:
+
+```
+# curve: short weierstrass form
+y^2 ≡ x^3 + ax + b
+
+# p: curve prime field modulus
+0xffffffff00000001000000000000000000000000ffffffffffffffffffffffff
+
+# a: elliptic curve short weierstrass first coefficient
+0xffffffff00000001000000000000000000000000fffffffffffffffffffffffc
+
+# b: elliptic curve short weierstrass second coefficient
+0x5ac635d8aa3a93e7b3ebbd55769886bc651d06b0cc53b0f63bce3c3e27d2604b
+
+# G: base point of the subgroup
+(0x6b17d1f2e12c4247f8bce6e563a440f277037d812deb33a0f4a13945d898c296,
+ 0x4fe342e2fe1a7f9b8ee7eb4a7c0f9e162bce33576b315ececbb6406837bf51f5)
+
+# n: subgroup order (number of points)
+0xffffffff00000000ffffffffffffffffbce6faada7179e84f3b9cac2fc632551
+
+# h: cofactor of the subgroup
+0x1
+
+```
+
+### Elliptic Curve Signature Verification Steps
+
+The signature verifying algorithm takes the signed message hash, the signature components provided by the “secp256r1” curve algorithm, and the public key derived from the signer private key. The verification can be done with the following steps:
+
+```
+# h (message hash)
+# pubKey = (public key of the signer private key)
+
+# Calculate the modular inverse of the signature proof:
+s1 = s^(−1) (mod n)
+
+# Recover the random point used during the signing:
+R' = (h * s1) * G + (r * s1) * pubKey
+
+# Take from R' its x-coordinate:
+r' = R'.x
+
+# Calculate the signature validation result by comparing whether:
+r' == r
+
+```
+
+### Required Checks in Verification
+
+The following requirements **MUST** be checked by the precompiled contract to verify signature components are valid:
+
+- Verify that the `r` and `s` values are in `(0, n)` (exclusive) where `n` is the order of the subgroup.
+- Verify that the point formed by `(x, y)` is on the curve and that both `x` and `y` are in `[0, p)` (inclusive 0, exclusive p) where `p` is the prime field modulus. Note that many implementations use `(0, 0)` as the reference point at infinity, which is not on the curve and should therefore be rejected.
+
+### Precompiled Contract Specification
+
+The `P256VERIFY` precompiled contract is proposed with the following input and outputs, which are big-endian values:
+
+- **Input data:** 160 bytes of data including:
+ - 32 bytes of the signed data `hash`
+ - 32 bytes of the `r` component of the signature
+ - 32 bytes of the `s` component of the signature
+ - 32 bytes of the `x` coordinate of the public key
+ - 32 bytes of the `y` coordinate of the public key
+- **Output data:** 32 bytes of result data and error
+ - If the signature verification process succeeds, it returns 1 in 32 bytes format.
+
+### Precompiled Contract Gas Usage
+
+The use of signature verification cost by `P256VERIFY` is `3450` gas. Following reasons and calculations are provided in the [Rationale](#rationale) and [Test Cases](#test-cases) sections.
+
+## Rationale
+
+“secp256r1” ECDSA signatures consist of `v`, `r`, and `s` components. While the `v` value makes it possible to recover the public key of the signer, most signers do not generate the `v` component of the signature since `r` and `s` are sufficient for verification. In order to provide an exact and more compatible implementation, verification is preferred over recovery for the precompile.
+
+Existing P256 implementations verify `(x, y, r, s)` directly. We've chosen to match this style here, encoding each argument for the EVM as a `uint256`.
+
+This is different from the `ecrecover` precompiled address specification. The advantage is that it 1. follows the NIST specification (as defined in NIST FIPS 186-5 Digital Signature Standard (DSS)), 2. matches the rest of the (large) P256 ecosystem, and most importantly 3. allows execution clients to use existing well-vetted verifier implementations and test vectors.
+
+Another important difference is that the NIST FIPS 186-5 specification does not include a malleability check. We've matched that here in order to maximize compatibility with the large existing NIST P-256 ecosystem.
+
+Wrapper libraries **SHOULD** add a malleability check by default, with functions wrapping the raw precompile call (exact NIST FIPS 186-5 spec, without malleability check) clearly identified. For example, `P256.verifySignature` and `P256.verifySignatureWithoutMalleabilityCheck`. Adding the malleability check is straightforward and costs minimal gas.
+
+The `PRECOMPILED_ADDRESS` is chosen as `0x100` as `P256VERIFY` is the first precompiled contract presented as an RIP, and the address is the first available address in the precompiled address set that is reserved for the RIP precompiles.
+
+The gas cost is proposed by comparing the performance of the `P256VERIFY` and the `ECRECOVER` precompiled contract which is implemented in the EVM at `0x01` address. It is seen that “secp256r1” signature verification is ~15% slower (elaborated in [test cases](#test-cases)) than “secp256k1” signature recovery, so `3450` gas is proposed by comparison which causes similar “mgas/op” values in both precompiled contracts.
+
+## Backwards Compatibility
+
+No backward compatibility issues found as the precompiled contract will be added to `PRECOMPILED_ADDRESS` at the next available address in the precompiled address set.
+
+## Test Cases
+
+Functional tests are applied for multiple cases in the [reference implementation](#reference-implementation) of `P256VERIFY` precompiled contract and they succeed. Benchmark tests are also applied for both `P256VERIFY` and `ECRECOVER` with some pre-calculated data and signatures in the “go-ethereum”s precompile testing structure to propose a meaningful gas cost for the “secp256r1” signature verifications by the precompiled contract implemented in the [reference implementation](#reference-implementation). The benchmark test results by example data in the assets can be checked:
+
+- [P256Verify Benchmark Test Results](/assets/rip-7212/p256Verify_benchmark_test)
+- [Ecrecover Benchmark Test Results](/assets/rip-7212/ecrecover_benchmark_test)
+
+```
+# results of geth benchmark tests of
+# ECRECOVER and P256VERIFY (reference implementation)
+# by benchstat tool
+
+goos: darwin
+goarch: arm64
+pkg: github.com/ethereum/go-ethereum/core/vm
+ │ compare_p256Verify │ compare_ecrecover │
+ │ sec/op │ sec/op │
+PrecompiledP256Verify/p256Verify-Gas=3450-8 57.75µ ± 1%
+PrecompiledEcrecover/-Gas=3000-8 50.48µ ± 1%
+geomean 57.75µ 50.48µ
+
+ │ compare_p256Verify │ compare_ecrecover │
+ │ gas/op │ gas/op │
+PrecompiledP256Verify/p256Verify-Gas=3450-8 3.450k ± 0%
+PrecompiledEcrecover/-Gas=3000-8 3.000k ± 0%
+geomean 3.450k 3.000k
+
+ │ compare_p256Verify │ compare_ecrecover │
+ │ mgas/s │ mgas/s │
+PrecompiledP256Verify/p256Verify-Gas=3450-8 59.73 ± 1%
+PrecompiledEcrecover/-Gas=3000-8 59.42 ± 1%
+geomean 59.73 59.42
+
+ │ compare_p256Verify │ compare_ecrecover │
+ │ B/op │ B/op │
+PrecompiledP256Verify/p256Verify-Gas=3450-8 1.523Ki ± 0%
+PrecompiledEcrecover/-Gas=3000-8 800.0 ± 0%
+geomean 1.523Ki 800.0
+
+ │ compare_p256Verify │ compare_ecrecover │
+ │ allocs/op │ allocs/op │
+PrecompiledP256Verify/p256Verify-Gas=3450-8 33.00 ± 0%
+PrecompiledEcrecover/-Gas=3000-8 7.000 ± 0%
+geomean 33.00 7.000
+
+```
+
+## Reference Implementation
+
+Implementation of the `P256VERIFY` precompiled contract is applied to go-ethereum client to create a reference. Also, a “secp256r1” package has already been included in the Besu Native library which is used by Besu client. Other client implementations are in the future roadmap.
+
+## Security Considerations
+
+The changes are not directly affecting the protocol security, it is related with the applications using `P256VERIFY` for the signature verifications. The “secp256r1” curve has been using in many other protocols and services and there is not any security issues in the past.
+
+
+## Copyright
+
+Copyright and related rights waived via [CC0](/LICENSE).
+
+ Thu, 22 Jun 2023 00:00:00 +0530
+ http://localhost:4000/RIPS/rip-7212
+ http://localhost:4000/RIPS/rip-7212
+
+
+
+ Native Account Abstraction
+ Standards Track/Core
+
+ https://ethereum-magicians.org/t/rip-7560-native-account-abstraction/16664
+
+ ## Abstract
+
+Combining the [EIP-2938](./eip-2938)
+and [ERC-4337](./eip-4337)
+into a comprehensive Native Account Abstraction proposal.
+
+We propose splitting the Ethereum transaction scope into multiple steps: validations, execution,
+and post-transaction logic.
+Transaction validity is determined by the result of the validation steps of a transaction.
+
+We further separate transaction validation for the purposes of authorization and the gas fee payment,
+allowing contract B to pay gas for a transaction that will be executed from account contract A.
+
+The benefits are in backward compatibility with the emerging ERC-4337 ecosystem while achieving the
+long-term goal of Native Account Abstraction.
+
+## Motivation
+
+ERC-4337 can do a lot as a purely voluntary ERC. However, any of the out-of-protocol ways of achieving
+Account Abstraction faces several drawbacks compared to native support. There are a few key areas where
+it is weaker than a truly in-protocol solution:
+
+* Existing users cannot benefit from it or upgrade to use it without moving all their assets and activity
+ to a new account.
+
+* Extra gas overhead of ~42k for a basic `UserOperation` compared to ~21k for a basic transaction.
+
+* Less benefit from in-protocol censorship resistance techniques such as crLists, which target transactions
+ and would miss `UserOperations`.
+
+* Relying on a significantly smaller set of participating nodes and non-standard RPC methods like
+ `eth_sendRawTransactionConditional`.
+
+* Inability to use `tx.origin` or contracts that rely on it as it returns the meaningless address of a bundler.
+
+EIP-2938 defines a very mature alternative approach to Account Abstraction. However, it does not translate
+well to the architecture of ERC-4337 that is being used in production without any protocol changes.
+Therefore, the implementation of EIP-2938 will not benefit as much from the production experience gained by using
+ERC-4337 and from maintaining backward compatibility with it.
+
+There is also a possibility that at some point in the future, the EOAs on Ethereum will be replaced with pre-deployed
+smart contracts. This, however, is impossible without an addition of Native Account Abstraction to the protocol.
+
+## Specification
+
+### Constants
+
+| Name | Value |
+|-----------------------|---------------------------------------------------------------------------------|
+| FORK_BLOCK | TBD |
+| AA_TX_TYPE | 4 |
+| AA_ENTRY_POINT | `address(7560)` |
+| AA_SENDER_CREATOR | `address(ffff7560)` |
+| AA_NONCE_MANAGER | TODO |
+| AA_BASE_GAS_COST | 15000 |
+| AA_ECRECOVER_COST | 6000 |
+| VERSION | 1 |
+| MAGIC_VALUE_SENDER | 0xbf45c166 // bytes4(keccak256("validateTransaction(uint256,bytes32,bytes)")) |
+| MAGIC_VALUE_PAYMASTER | 0xe0e6183a // bytes4(keccak256("validatePaymasterTransaction(uint256,bytes32,bytes)")) |
+| MAX_CONTEXT_SIZE | 65536 |
+| UNUSED_GAS_PENALTY | 10 |
+
+### New Transaction Type
+
+A new [EIP-2718](./eip-2718) transaction with type AA_TX_TYPE is introduced. Transactions of this type are referred to as
+“AA transactions”. Their payload should be interpreted as:
+
+```
+
+0x04 || 0x00 || rlp([
+ chainId, sender, nonce, builderFee,
+ callData, paymasterData, deployerData,
+ maxPriorityFeePerGas, maxFeePerGas,
+ validationGasLimit, paymasterGasLimit, callGasLimit,
+ accessList, signature
+])
+
+```
+
+The base gas cost of this transaction is set to AA_BASE_GAS_COST instead of 21000 to reflect the lack of “intrinsic”
+ECDSA signature verification.
+
+If `paymasterData` is specified, its first 20 bytes contain the address of a `paymaster` contract.
+
+If `deployerData` is specified, its first 20 bytes contain the address of a `deployer` contract.
+
+### Optional "transaction counter header"
+
+In some cases the block builders may want to split up an array of type `AA_TX_TYPE` transactions into individual
+batches of transactions that perform validations and executions separately.
+
+Without a header transaction type this would only be possible by creating an artificial legacy type transaction.
+Instead, we propose to introduce an explicit "counter" transaction subtype.
+
+Their payload should be interpreted as:
+
+```
+0x04 || 0x01 || rlp([chainId, transactionCount])
+```
+
+Header transactions have a unique hash calculated as follows:
+
+```
+keccak256(AA_TX_TYPE || 0x01 || rlp(chainId, transactionCount, blockNumber, txIndex))
+```
+
+The `blockNumber` and `txIndex` parameters are added to the hash to achieve unique header transaction IDs.
+
+The header transactions are only used to help execution clients determine how many of the `AA_TX_TYPE` transactions
+belong to each individual batch.
+The block is not valid if a header transaction is located anywhere except before an `AA_TX_TYPE` transactions.\
+If a header transaction is included all `AA_TX_TYPE` transactions in the block must be covered by one.
+
+Header transactions do not affect blockchain state and do not cost any gas.
+
+### Non-sequential nonce support
+
+Before RIP-7560, for accounts with associated code (smart contracts), the account nonce is only used and incremented
+when the account executes the `CREATE` (`0xf0`) opcode.
+
+However, with Smart Contract Accounts this creates a bottleneck for some use-cases.
+For example, an account that is operated by multiple participants simultaneously will require these participants
+to coordinate their transactions to avoid invalidating each other.
+
+Another example when this can also be a limitation is a case where there are separate execution flows.
+A configuration change may require multiple participants to co-sign a transaction but a regular operation does not.
+With sequential nonces, all operations will have to be halted until the configuration change is executed.
+
+To address it we propose an introduction of a separate 2-dimensional nonce used when contracts initiate a transaction.
+
+The `nonce` parameter of the transaction is to be interpreted as `uint192 key || uint64 seq` value.
+The contract account nonce is then defined as a mapping `address account => uint192 key => uint64 seq`.
+This approach guarantees unique transaction nonce and hash but removes the requirement of nonce being sequential
+numbers.
+
+This `nonce` is exposed to the EVM in a `NonceManager` pre-deployed contract located at the AA_NONCE_MANAGER address.
+
+The `nonce` is [validated and incremented](#nonce-validation-frame) on-chain before the rest of the validation code.
+
+The old `nonce` account parameter remains in use for transactions initiated by EOAs and for the `CREATE` opcode.
+
+#### NonceManager Pseudocode
+
+```
+
+if evm.caller == AA_ENTRY_POINT:
+ validate_increment()
+else:
+ get()
+
+def get():
+ if len(evm.calldata) != 44:
+ evm.revert()
+
+ // address sender, uint192 key
+ address = to_uint160_be(evm.calldata[0:20])
+ key = to_uint192_be(evm.calldata[20:44])
+
+ nonce = storage.get(keccak(address, key))
+
+ evm.return((key << 64) + nonce)
+
+def validate_increment():
+
+ address = to_uint160_be(evm.calldata[0:20])
+ key = to_uint192_be(evm.calldata[20:44])
+ nonce = to_uint64_be(evm.calldata[44:52])
+
+ current_nonce = storage.get(keccak(address, key))
+
+ if (nonce != current_nonce):
+ evm.revert()
+
+ storage.set(kecca
+ k(address, key), current_nonce + 1)
+
+```
+
+#### NonceManager Bytecode and deployment
+
+TODO.
+
+### Gas fees are charged directly from the contract balance
+
+The maximum gas cost of the AA_TX_TYPE transaction is defined as:
+
+```
+
+maxPossibleGasCost = AA_BASE_GAS_COST +
+ callGasLimit +
+ paymasterGasLimit +
+ validationGasLimit
+
+```
+
+If `paymaster` is not specified, the `maxPossibleGasCost` is charged up-front, before any computation is done in any
+execution frame, from the balance of the `sender` address.
+If `paymaster` is specified, the gas cost is charged from its balance.
+The transaction is invalid if the balance of the account that is being pre-charged,
+whether it is a `sender` or a `paymaster`, is insufficient.
+After the transaction finishes its execution, the address that was pre-charged may receive a gas refund.
+
+### Gas fees charged for transaction input
+
+For all the existing transaction types, G_txdatazero (4 gas) and G_txdatanonzero (16 gas) per byte is
+charged for the `data` parameter.
+
+Transaction Type AA_TX_TYPE introduces the following dynamic length inputs: `callData`, `paymasterData`,
+`deployerData`, `signature`. Each of these parameters' gas cost is counted towards transaction data cost.
+This transaction data gas cost is referred to as `calldataCost` and is subtracted from the `validationGasLimit`
+before execution of the transaction.
+The transaction is considered INVALID if `validationGasLimit` is smaller than `calldataCost`.
+
+### Builder Fee
+
+As we need to account for an additional off-chain work that block builders have to perform to
+include `AA_TX_TYPE` transactions in their blocks, as well as a potential L1 gas cost for builders
+operating on L2 rollups, and given that this work does not correspond to the amount of gas spent on
+validation and is not linked to the gas price, the `sender` may decide
+to pay an extra `builderFee` as a "tip" to the block builder.
+
+This value is denominated in wei and is passed from the `sender`, or the `paymaster` if it is specified,
+to the `coinbase` of the current block as part of the gas pre-charge.
+
+### Unused gas penalty charge
+
+Transactions of type `AA_TX_TYPE` that reserve a lot of gas for themselves using `validationGasLimit`,
+`paymasterGasLimit` and `callGasLimit` fields but do not use the reserved gas present a challenge for
+block builders. This is especially demanding in case a gas used by a transaction can be significantly different
+based on its position within a block, as such transactions may cause the block builder to iterate its algorithm
+many times until a fully utilized block is discovered.
+
+A penalty of `UNUSED_GAS_PENALTY` percent of the entire unused gas limit is charged from the
+transaction `sender` or `paymaster`.
+
+The total gas limit is calculated as `totalLimit = validationGasLimit + paymasterGasLimit + callGasLimit`.\
+The `totalGasUsed` is calculated as a sum of all gas used during the transaction.\
+The unused gas is calculated as `unusedGas = totalLimit - totalGasUsed`.
+
+### Multiple execution frames for a single transaction
+
+All existing transaction types only have an implicit validation phase where balance, nonce, and signature are checked,
+and a single top-level execution frame with
+`tx.origin == msg.sender` which is the address that is determined by a transaction ECDSA signature.
+
+When processing a transaction of type `AA_TX_TYPE`, however, multiple execution frames will be created.
+The full list of possible frames tries to replicate the ERC-4337 flow:
+
+1. Validation Phase
+ * `nonce` validation and increment frame (required)
+ * `sender` deployment frame (once per account)
+ * `sender` validation frame (required)
+ * `paymaster` validation frame (optional)
+2. Execution Phase
+ * `sender` execution frame (required)
+ * `paymaster` post-transaction frame (optional)
+
+All execution frames in the "Validation Phase" must be completed successfully without reverting, and the return value
+for `sender` and `paymaster` validation frames must include `MAGIC_VALUE_SENDER` and `MAGIC_VALUE_PAYMASTER` accrodingly
+in order for the transaction to be considered valid for a given position in a block.
+
+In terms of block validity, all validation and execution frames may read and write any state when included in the block.
+However, the AA transactions in the mempool SHOULD be bound by storage access rules to avoid DoS on block builders.
+These rules are defined in [ERC-7562](./eips/eip-7562).
+
+In all top-level frames, the global variables have the following meaning:
+
+| Opcode Name | Solidity Equivalent | Value |
+|-------------|---------------------|-------------------------------------------------------------------------------|
+| `CALLER` | `msg.sender` | The `AA_ENTRY_POINT` address. `AA_SENDER_CREATOR` for the "deployment frame". |
+| `ORIGIN` | `tx.origin` | The transaction `sender` address |
+| `CALLDATA*` | `msg.data` | The transaction data is set to inputs of the corresponding frame |
+
+#### Nonce validation frame
+
+The `NonceManager` is invoked with the following data:
+
+```solidity
+abi.encodePacked(sender, nonce)
+```
+
+#### Sender deployment frame
+
+The `deployer` address is invoked with the `deployerData[20:]` as call data input.
+It is important that the `deployer` is **not** invoked from the `AA_ENTRY_POINT` but from the `AA_SENDER_CREATOR`.
+This is necessary to guarantee that `AA_ENTRY_POINT` may never initiate a call to a `sender` execution function
+without first completing a successful validation.
+
+The gas limit of this frame is set to `validationGasLimit`.
+The amount of gas used by this frame is referred to as `senderCreationGasUsed`.
+
+The sender deployment frame MUST result in the `sender` address becoming
+initialized with contract code.
+
+#### Sender validation frame
+
+We define the following Solidity struct to represent the AA transaction on-chain:
+
+```solidity
+
+struct TransactionType4 {
+ address sender;
+ uint256 nonce;
+ uint256 validationGasLimit;
+ uint256 paymasterGasLimit;
+ uint256 callGasLimit;
+ uint256 maxFeePerGas;
+ uint256 maxPriorityFeePerGas;
+ uint256 builderFee;
+ bytes paymasterData;
+ bytes deployerData;
+ bytes callData;
+ bytes signature;
+}
+
+```
+
+We then define the following Solidity method and the `sender` of the transaction is invoked with the corresponding data:
+
+```solidity
+
+function validateTransaction(uint256 version, bytes32 txHash, bytes transaction) external returns (uint256 validationData);
+
+```
+
+The gas limit of this frame is set to `validationGasLimit - senderCreationGasUsed - calldataCost`.\
+The `transaction` parameter is interpreted as an ABI encoding of `TransactionType4`.\
+The `txHash` parameter represents the hash of the AA_TX_TYPE transaction with empty signature, as defined in section
+[Calculation of Transaction Type AA_TX_TYPE hash](#calculation-of-transaction-type-aatxtype-hash).\
+The `version` parameter is added in order to maintain the Solidity method ID in case of changes to this struct
+in future revisions of this EIP.
+
+The amount of gas used by this frame is referred to as `senderValidationGasUsed`.
+
+The frame must return 32 bytes `validationData` that is interpreted as:
+
+```solidity
+
+abi.encodePacked(MAGIC_VALUE_SENDER, validUntil, validAfter)
+
+```
+
+In order to allow a gas estimation to determine the amount of gas that this frame
+requires to complete successfully while not having the actual `signature` value, this function
+should avoid reverting on invalid signature, and should return a value different from `MAGIC_VALUE_SENDER`.
+
+Type of the `validUntil` is 6-byte timestamp value, or zero for "infinite". The transaction is valid only up to this time.
+Type of the `validAfter` is 6-byte timestamp. The transaction is valid only after this time.
+
+The `validateTransaction` function can choose to revert on any condition that can be satisfied during gas estimation.
+
+#### Paymaster validation frame
+
+The `paymaster` of the transaction, if specified, is invoked with the following data:
+
+```solidity
+
+function validatePaymasterTransaction(uint256 version, bytes32 txHash, bytes transaction) external returns (bytes context, uint256 validationData);
+
+```
+
+The gas limit of this frame is set to `paymasterGasLimit`.
+
+The amount of gas used by this frame is referred to as `paymasterValidationGasUsed`.
+
+The `transaction` parameter is interpreted as an ABI encoding of `TransactionType4`.\
+The `txHash` parameter represents the hash of the AA_TX_TYPE transaction with empty signature, as defined in section
+[Calculation of Transaction Type AA_TX_TYPE hash](#calculation-of-transaction-type-aatxtype-hash).
+
+The frame must return a bytes array that is interpreted as:
+
+```solidity
+
+abi.encode(context, MAGIC_VALUE_PAYMASTER, validUntil, validAfter)
+
+```
+
+Same as in the [`sender` validation frame](#sender-validation-frame), in order to support gas estimation this
+frame should return a value different from `MAGIC_VALUE_PAYMASTER` for conditions that cannot be satisfied
+before signing.
+
+The size of the `context` byte array may not exceed `MAX_CONTEXT_SIZE` for a transaction to be considered valid.
+
+#### Sender execution frame
+
+The `sender` address is invoked with `callData` input.
+
+The gas limit of this frame is set to `callGasLimit`.\
+Calculation of the `calldataCost` value is defined in the
+[Gas fees charged for transaction input](#gas-fees-charged-for-transaction-input) section.\
+The amount of gas used by this frame is referred to as `gasUsedByExecution`.
+
+The validation frames do not revert if the execution frame reverts.
+The `postPaymasterTransaction` may still be called with a `success: false` flag.
+
+#### Paymaster post-transaction frame
+
+After the sender execution frame is over the `paymaster` may need to perform some post-transaction logic,
+for instance to perform some kind of cleanup or bookkeeping.
+If the gas payment validation returned a non-zero `context`, the `paymaster` is invoked again
+with the following inputs:
+
+```solidity
+
+function postPaymasterTransaction(bool success, uint256 actualGasCost, bytes context) external;
+
+```
+
+The `actualGasCost` parameter is the actual amount paid by the paymaster for this transaction,
+and `success` indicates whether this transaction's execution frame completed without revert.
+
+The gas limit of this frame is set to `paymasterGasLimit - paymasterValidationGasUsed`.
+
+Revert in the `postPaymasterTransaction` frame reverts the transaction's execution frame as well.
+The validation frames do not revert if the `postPaymasterTransaction` frame reverts.
+The gas fees charged from the `paymaster` will still include the gas cost of the reverted execution frame.
+
+### Execution flow diagram
+
+The execution flow determined by an Account Abstraction Transaction is visualised by the following flow diagram:
+
+
+*Execution flow for the Native Account Abstraction Transactions*
+
+### Execution layer transaction validation
+
+On the execution layer, the transaction validity conditions for a block are extended as follows:
+
+```
+
+func validateAccountAbstractionTransaction(tx *Transaction) {
+ assert !(sender.code.length > 0 && deployerData.length > 0)
+
+ if (sender.code.length == 0 && deployerData.length == 0) {
+ validUntil = (nonce >> 112) & 0xffffffffffff
+ validAfter = (nonce >> 160) & 0xffffffffffff
+ assert Date.now() <= validUntil
+ assert Date.now() >= validAfter
+ }
+
+ if (sender.code.length == 0 && deployerData.length > 0) {
+ assert deployerData.length >= 20
+ deployer := deployerData[0:20]
+ calldataCost := calculateCalldataCost(tx)
+ retDeployer, error := evm.Call(
+ from: AA_SENDER_CREATOR,
+ to: deployer,
+ input: deployerData[20:],
+ gas: validationGasLimit - calldataCost)
+ assert error == nil
+ assert sender.code.length > 0
+ }
+
+ if (paymasterData.length > 0) {
+ assert paymasterData.length >= 20
+ paymaster := paymasterData[0:20]
+ paymasterInput := ABI.encodeWithSelector('validatePaymasterTransaction', tx, tx.hash)
+ retPaymaster, error := evm.Call(
+ from: AA_ENTRY_POINT,
+ to: paymaster,
+ input: paymasterInput,
+ gas: paymasterGasLimit)
+ assert error == nil
+ assert Date.now() <= retPaymaster.validUntil
+ assert Date.now() >= retPaymaster.validAfter
+ assert retPaymaster.isValid
+ }
+
+ if (sender.code.length == 0) {
+ signer := ecrecover(tx.hash, tx.signature)
+ assert signer == sender.address
+ } else {
+ senderInput := ABI.encodeWithSelector('validateTransaction', tx, tx.hash);
+ retSender, error := evm.Call(
+ from: AA_ENTRY_POINT,
+ to: sender,
+ input: senderInput,
+ gas: validationGasLimit - retDeployer.gasUsed)
+ assert error == nil
+ assert Date.now() <= retSender.validUntil
+ assert Date.now() >= retSender.validAfter
+ assert retSender.isValid
+ }
+}
+
+```
+
+In order to defend from DoS attack vectors, the block builders performing mempool transaction validation SHOULD consider
+the opcode banning and storage access rules described in ERC-7562.
+
+[Block validation](#execution-layer-block-validation) takes roughly the same amount of work as without AA transactions.
+In any case, validation must execute the entire block in order to verify the state change.
+During this execution, it currently verifies signatures, nonces, and gas payment.
+With Account Abstraction, it will also verify that all the validation frames were successful.
+There is a slight increase in required memory mostly used to store the `context` value that is passed from
+the `paymaster` validation frame to its post-transaction frame.
+
+As long as all transaction validation steps return correct values the block is considered valid.
+Block builders who are willing to relax the rules applied to the validation frames MAY do so.
+
+Such transactions MUST NOT be propagated through the default transaction mempool as they will be rejected by the nodes
+and the sending node will be blocked as a spammer.
+They may be propagated in the alternative mempool that allows them explicitly as defined in ERC-7562.
+
+### All validation state changes apply before all execution ones
+
+Filling a block with AA transactions must not be a challenge for the block builder.
+However, if each transaction during its execution can alter any state that affects the validity of another transaction
+in the mempool, the block builder will be forced to revalidate all transactions in the mempool after each inclusion.
+
+We mitigate that by applying all changes in all the validation frames of a sequence of AA transactions first
+and all execution frames apply immediately after that.
+
+In theory, the validation frames can also invalidate each other, but we define ways to prevent that by applying
+certain rules for the mempool transactions in ERC-7562.
+
+A builder that chooses not to enforce the rules from ERC-7562 **must** take care to re-validate each transaction
+against the mid-block state at the position where it is being included into a block.
+Otherwise, the resulting block is likely to end up being invalid.
+
+### Block structure diagram
+
+Here is a visual representation of a block that contains multiple Account Abstraction Transactions.
+The validation parts of AA transactions are executed as separate transactions,
+but are not represented as separate transactions in the block data.
+
+
+*The structure of a block containing multiple Native Account Abstraction Transactions*
+
+Zooming into a single transaction, the validation part of an AA transaction may include multiple exectution frames:
+
+
+*Frames within a single Native Account Abstraction Transaction within a block*
+
+### Validation state change virtual transactions
+
+The validation frames of the AA_TX_TYPE transaction are represented as individual virtual transactions by the clients.
+They are assigned their own sequential `transactionIndex`, and their `transactionHash` is defined as
+(`AA_TX_TYPE transaction hash + 1`).
+
+All block-related RPC methods, like `eth_getBlockByHash` and `eth_getBlockByNumber`, must include these virtual
+transactions as part of the `transactions` field and include validation in the block transaction count.
+
+All transaction-related RPC methods, like `eth_getTransactionByHash` and `eth_getTransactionReceipt`, must
+accept the virtual transaction hash as input and return the details calculated as if the validation was a
+separate transaction.
+
+There is a number of behaviours that define transaction-wide effects in Ethereum.
+This list includes, but is not limited to:
+
+* Tracking `accessed_addresses`
+* [EIP-1283](./eip-1283) Gas metering for SSTORE
+* [EIP-1153](./eip-1153) Transient storage opcodes
+
+Any such behaviour has separate effects in the "Validation Virtual Transaction" and "Execution Transaction".
+
+Gas refunds are issued at the end of the entire transaction only.
+
+### Transaction validity time range parameters
+
+The `Paymaster validation frame` and the `Sender validation frame` each return values `validUntil` and `validAfter`.
+If the transaction is initiated by an EOA, these fields may be encoded into unused bits of the `nonce`.
+
+These values allow the `sender` and `paymaster` contracts to specify
+a time range for the blocks the transaction will be valid for.
+
+Transaction cannot be included in a block outside of this time range.
+If included, such a block is considered invalid.
+
+Passing `validUntil = 0` and `validAfter = 0` disables the check.
+
+### Calculation of Transaction Type AA_TX_TYPE hash
+
+```
+
+keccak256(AA_TX_TYPE || 0x00 || rlp(transaction_payload)
+
+```
+
+Note that the `chainId` and `accessList` parameters are included in the transaction hash calculation but are not
+available on-chain as part of the `TransactionType4` struct.
+
+In order to calculate the transaction hash that will be used during the signing of the transaction and validation of
+the transaction signature by the `sender`, the value of the `signature` parameter is considered to be an empty
+byte array.
+
+### Accepting EOA account as `sender` to achieve native gas abstraction
+
+In case the `sender` address does not have any code deployed and the `deployerData` length is zero,
+interpret the `signature` parameter as `(y_parity, r, s)` and the `nonce` parameter
+as `(validUntil, validAfter, nonce)`.
+Replace the sender validation frame with default ECDSA signature validation.
+Also check the block timestamp is within the `[validUntil, validAfter]` range.
+
+The base transaction gas cost, in this case, is increased by `AA_ECRECOVER_COST`.
+
+The `callData` parameter in this case is interpreted as following:
+
+```
+
+target || value || data
+
+```
+
+### Execution layer block validation
+
+When validating a block, the validity conditions for a block are extended as follows:
+
+```
+
+for txIndex := 0; txIndex < range block.Transactions.Len(); txIndex++ {
+
+ // 1. Save the current transaction
+ txCurr = block.Transactions[txIndex]
+
+ if (txCurr.Type() == AccountAbstractionTransaction) {
+
+ // 2. Start running validations for AA transactions
+ for j := txIndex; j < range block.Transactions().Len(); j++ {
+ tx = block.Transactions[j]
+
+ // 3. Stop after encountering a non-AA transaction (or reaching the end of the block)
+ if (tx.Type() != AccountAbstractionTransaction) {
+ break
+ }
+ context[j], paymasterValidationGasUsed[j], error := validateAccountAbstractionTransaction(tx)
+ assert error == nil
+ }
+
+ // 4. If all validations are successful, go back to the saved tx index and run all executions
+ for j := txIndex; j < range block.Transactions().Len(); j++ {
+ tx = block.Transactions[j]
+ if (tx.Type() != AccountAbstractionTransaction) {
+ break
+ }
+
+ retCall, error := evm.Call(
+ from: AA_ENTRY_POINT,
+ to: sender,
+ input: callData,
+ gas: callGasLimit)
+
+ txIndex := j // transaction executed - no need to revisit in the outer loop
+
+
+ // 5. Run paymaster's post-transaction logic if necessary
+ if (context[j].Len() == 0){
+ continue
+ }
+
+ paymasterPostTransactionInput := ABI.encodeWithSelector('postPaymasterTransaction', success, actualGasCost, context[j])
+ retPostTransaction, error := evm.Call(
+ from: AA_ENTRY_POINT,
+ to: paymaster,
+ input: paymasterPostTransactionInput,
+ gas: paymasterGasLimit - paymasterValidationGasUsed[j])
+ }
+ }
+ else {
+ // handle other types of transactions
+ evm.Apply(txCurr)
+ }
+}
+
+```
+
+### RPC methods (eth namespace)
+
+#### `eth_sendTransaction` and `eth_sendRawTransaction`
+
+Accepts Transaction Type `AA_TX_TYPE`.
+
+Return values unchanged for a successful call.
+
+In case of failure, MUST return an error result object, with code and message.
+The error code and message SHOULD be set as follows:
+
+* code: -32500 - transaction validation failed by `sender`.
+ The message field SHOULD be set to the revert message from the `sender`.
+
+* code: -32501 - transaction validation failed by `paymaster`.
+ The message field SHOULD be set to the revert message from the `paymaster`.
+
+* code: -32502 - transaction rejected because of storage or opcode rules violation in a validation frame.
+ The message field SHOULD be set to the location and description of the violated rule.
+
+* code: -32503 - Transaction out of time range.
+
+* code: -32504 - transaction rejected because `paymaster` is throttled or banned, as defined by ERC-7562.
+
+* code: -32505 - transaction rejected because `factory` is throttled or banned.
+
+* code: -32506 - transaction rejected because `sender` is throttled or banned.
+
+#### `eth_signTransaction`
+
+Accepts Transaction Type `AA_TX_TYPE`.
+
+Returns the RLP-encoded transaction object with value for the `signature` field that makes the `AA_TX_TYPE`
+transaction valid.
+
+Returns error object if this operation cannot be performed by the RPC endpoint.
+
+#### `eth_getTransactionReceipt`
+
+Accepts the hash of a virtual transaction that encapsulates the validation frames of the `AA_TX_TYPE` transaction.
+This transaction's ID is defined as (`AA_TX_TYPE transaction hash + 1`).
+
+If an AA transaction is included in a block, returns the following values in addition to the existing fields:
+
+| Name | Value |
+|----------------------------|------------------------------------------------------------------------------|
+| sender | Address of the sender of this transaction |
+| nonce | The transaction nonce value |
+| paymaster | Address of the Paymaster if it is paying for the transaction, null otherwise |
+| deployer | Address of the Deployer if it is included in the transaction, null otherwise |
+| senderCreationGasUsed | The amount of gas actually used by the sender deployment frame |
+| senderValidationGasUsed | The amount of gas actually used by the sender validation frame |
+| paymasterValidationGasUsed | The amount of gas actually used by the paymaster validation frame |
+
+Accepts hash of Transaction Type `AA_TX_TYPE`.
+
+If an AA transaction is included in a block, returns the following values in addition to the existing fields:
+
+| Name | Value |
+|---------------------------------|------------------------------------------------------------------------------------------------|
+| status | Either 1 (success) or 0 (failure) status of the execution frame |
+| executionGasUsed | The amount of gas actually used by the execution frame |
+| postPaymasterTransactionStatus | Either 1 (success), 0 (failure), or `null` (did not run) status of the `postPaymasterTransaction` frame |
+| postPaymasterTransactionGasUsed | The amount of gas actually used by the paymaster `postPaymasterTransaction` frame |
+
+Note that the field `to` is not included as there is no clear `target` in an `AA_TX_TYPE` transaction.
+
+#### `eth_call`
+
+Accepts Transaction Type `AA_TX_TYPE` with all fields except `from` and `callData` optional.
+
+Returns the return value of [the `sender` execution frame](#sender-execution-frame).
+
+If provided with `paymasterData` and `deployerData` also executes the corresponding frame.
+
+If any of the frames reverts the call returns the revert data of each reverted frame.
+
+#### `eth_estimateGasAccountAbstraction`
+
+Accepts Transaction Type `AA_TX_TYPE` with fields `validationGasLimit`, `paymasterGasLimit`, `callGasLimit` optional.
+
+Optionally accepts the State Override Set to allow users to modify the state during the gas estimation.
+This field as well as its behavior is equivalent to the ones defined for `eth_call` RPC method.
+
+Returns `{validationGasLimit, paymasterGasLimit, callGasLimit, builderFee}` object.
+
+Note that the `deployerData` and `paymasterData` fields are required for a consistent result.
+
+As mentioned earlier, the `sender` and `paymaster` contracts should not revert on the validation failure
+and should return a value different from `MAGIC_VALUE_SENDER` or `MAGIC_VALUE_PAYMASTER` accordingly
+in order to enable gas estimation.
+
+One acceptable way to achieve this behavior for Smart Contract Accounts is to compare the `signature` parameter to
+a predetermined "dummy signature" and to return without reverting in case the values match.
+This will not result in transaction being authorized as long as returned value does not include `MAGIC_VALUE_SENDER`.
+
+## Rationale
+
+### Using Solidity method selectors in a Core EIP
+
+The contracts that have a role in this Account Abstraction proposal, such as `sender` or `paymaster`,
+MUST know which code to execute and understand the calldata provided to them in order to validate the transaction.
+
+We argue that the most straightforward implementation is to rely on Solidity 4-byte method selectors as it is an
+established de-facto standard.
+
+### Accepting `AA_TX_TYPE` transactions from EOAs
+
+While it may seem like allowing EOAs to initiate `AA_TX_TYPE` transactions contradicts the purpose of Account Abstraction, we argue that this
+may actually be important for the adoption of Smart Contract Accounts.
+
+It will enable all existing EOAs to benefit from the improved UX features like gas abstraction and validity ranges.
+
+In the future, this can be used to pay gas for transactions that add code to the EOA addresses,
+once Ethereum implements changes like the ones proposed in
+[EIP-5003: Insert Code into EOAs with AUTHUSURP](./eip-5003),
+[EIP-6913: SETCODE instruction](./eip-6913) and
+[EIP-7377: Migration Transaction](./eip-7377).
+
+## Backwards Compatibility
+
+This EIP preserves most of the design elements established by the ERC-4337. This allows the same client code and smart
+contracts to be used in both systems with minimal to no modifications, while providing significant UX improvements.
+
+Existing contracts are not significantly affected by the change.
+The assumption that `tx.origin` is guaranteed to be an EOA is no longer valid.
+The assumption that `tx.origin` is the address that pays for the current transaction is no longer valid as well.
+
+Any code that expects a single top-level execution frame for an Ethereum transaction will have to accommodate
+the new transaction type.
+
+[EIP-3607](./eip-3607) introduces a ban on transactions from senders with deployed code.
+This limitation does not apply to AA_TX_TYPE transactions.
+
+### Migration path for existing ERC-4337 projects and further roadmap
+
+#### Existing bundlers can co-exist on the network
+
+The ERC-4337 is not a protocol change and may remain operational in parallel to this EIP indefinitely.
+Given the similarity to ERC-4337, the same block builders may easily support both ERC-4337 and `AA_TX_TYPE` transactions.
+
+#### Accounts need to upgrade their `EntryPoint` to an adapter contract
+
+The team behind ERC-4337 will provide a reference implementation of a contract converting
+the ABI of the `paymaster` and `sender` contracts. This adapter can be set as a trusted
+`EntryPoint` address by the ERC-4337 contracts.
+
+#### Supporting ERC-4337 RPC calls as a compatibility layer
+
+The `sender` contracts MAY support both ERC-4337 and `AA_TX_TYPE` transactions during a transition period,
+as long as this EIP may be adopted by some chains and not by others.
+
+## Security Considerations
+
+This EIP creates a complex and sophisticated mechanism and aims to expand the usage of Smart Contract Accounts.
+All of it creates a lot of new risk vectors and attack surfaces.
+
+The following is a non-exhaustive list of known security considerations regarding Native Account Abstraction.
+
+### Attacks on validation-execution separation
+
+The state that exists at the end of the validation frame may be observed or modified by unrelated contracts before
+the execution frame begins.
+`Sender` contracts must take great care in making sure their code does not make any false assumptions.
+
+### DoS attacks on block builders
+
+The amount of computation and available memory that is necessary to maintain a mempool and produce valid blocks is
+increased significantly.
+
+### Directly charging the balance of a contract
+
+This EIP adds a new way for a smart contract to have its balance charged simply by returning a valid value from a
+function with method ID that corresponds to `validateTransaction`, `validatePaymasterTransaction`.
+
+This creates a new kind of risk for contracts that accidentally or maliciously contain such methods but are not public
+about the fact that these contracts can be used as a `sender` or a `paymaster` in an `AA_TX_TYPE` transaction.
+
+This is somewhat mitigated by requiring these contracts to return `MAGIC_VALUE_SENDER` or `MAGIC_VALUE_PAYMASTER`,
+however code reviewers should still be aware of this.
+
+### Observing revert reasons in a validation frame
+
+Existing transaction types get included in a block even if reverted and provide a revert reason for debugging purposes.
+There is a very short list of things that can cause a transaction not to be included on-chain:
+
+* low gas fee
+* insufficient balance
+* invalid nonce
+* censorship
+
+This is not the case for reverts that occur in the validation phase of an `AA_TX_TYPE` transaction.
+In order to address this developers should track the validity of these transactions being signed and are encouraged
+to rely on the `validUntil` time range parameter to guarantee a transaction that has not been included in the intended time
+will not become valid again unexpectedly for the user who had sent it.
+
+## Copyright
+
+Copyright and related rights waived via [CC0](/LICENSE).
+
+ Fri, 01 Sep 2023 00:00:00 +0530
+ http://localhost:4000/RIPS/rip-7560
+ http://localhost:4000/RIPS/rip-7560
+
+
+
+
+ /
+
+ @import "minima";
+
+
+ http://localhost:4000/assets/main.css
+ http://localhost:4000/assets/main.css
+
+
+
+
+ /
+
+ Creative Commons Legal Code
+
+CC0 1.0 Universal
+
+ CREATIVE COMMONS CORPORATION IS NOT A LAW FIRM AND DOES NOT PROVIDE
+ LEGAL SERVICES. DISTRIBUTION OF THIS DOCUMENT DOES NOT CREATE AN
+ ATTORNEY-CLIENT RELATIONSHIP. CREATIVE COMMONS PROVIDES THIS
+ INFORMATION ON AN "AS-IS" BASIS. CREATIVE COMMONS MAKES NO WARRANTIES
+ REGARDING THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS
+ PROVIDED HEREUNDER, AND DISCLAIMS LIABILITY FOR DAMAGES RESULTING FROM
+ THE USE OF THIS DOCUMENT OR THE INFORMATION OR WORKS PROVIDED
+ HEREUNDER.
+
+Statement of Purpose
+
+The laws of most jurisdictions throughout the world automatically confer
+exclusive Copyright and Related Rights (defined below) upon the creator
+and subsequent owner(s) (each and all, an "owner") of an original work of
+authorship and/or a database (each, a "Work").
+
+Certain owners wish to permanently relinquish those rights to a Work for
+the purpose of contributing to a commons of creative, cultural and
+scientific works ("Commons") that the public can reliably and without fear
+of later claims of infringement build upon, modify, incorporate in other
+works, reuse and redistribute as freely as possible in any form whatsoever
+and for any purposes, including without limitation commercial purposes.
+These owners may contribute to the Commons to promote the ideal of a free
+culture and the further production of creative, cultural and scientific
+works, or to gain reputation or greater distribution for their Work in
+part through the use and efforts of others.
+
+For these and/or other purposes and motivations, and without any
+expectation of additional consideration or compensation, the person
+associating CC0 with a Work (the "Affirmer"), to the extent that he or she
+is an owner of Copyright and Related Rights in the Work, voluntarily
+elects to apply CC0 to the Work and publicly distribute the Work under its
+terms, with knowledge of his or her Copyright and Related Rights in the
+Work and the meaning and intended legal effect of CC0 on those rights.
+
+1. Copyright and Related Rights. A Work made available under CC0 may be
+protected by copyright and related or neighboring rights ("Copyright and
+Related Rights"). Copyright and Related Rights include, but are not
+limited to, the following:
+
+ i. the right to reproduce, adapt, distribute, perform, display,
+ communicate, and translate a Work;
+ ii. moral rights retained by the original author(s) and/or performer(s);
+iii. publicity and privacy rights pertaining to a person's image or
+ likeness depicted in a Work;
+ iv. rights protecting against unfair competition in regards to a Work,
+ subject to the limitations in paragraph 4(a), below;
+ v. rights protecting the extraction, dissemination, use and reuse of data
+ in a Work;
+ vi. database rights (such as those arising under Directive 96/9/EC of the
+ European Parliament and of the Council of 11 March 1996 on the legal
+ protection of databases, and under any national implementation
+ thereof, including any amended or successor version of such
+ directive); and
+vii. other similar, equivalent or corresponding rights throughout the
+ world based on applicable law or treaty, and any national
+ implementations thereof.
+
+2. Waiver. To the greatest extent permitted by, but not in contravention
+of, applicable law, Affirmer hereby overtly, fully, permanently,
+irrevocably and unconditionally waives, abandons, and surrenders all of
+Affirmer's Copyright and Related Rights and associated claims and causes
+of action, whether now known or unknown (including existing as well as
+future claims and causes of action), in the Work (i) in all territories
+worldwide, (ii) for the maximum duration provided by applicable law or
+treaty (including future time extensions), (iii) in any current or future
+medium and for any number of copies, and (iv) for any purpose whatsoever,
+including without limitation commercial, advertising or promotional
+purposes (the "Waiver"). Affirmer makes the Waiver for the benefit of each
+member of the public at large and to the detriment of Affirmer's heirs and
+successors, fully intending that such Waiver shall not be subject to
+revocation, rescission, cancellation, termination, or any other legal or
+equitable action to disrupt the quiet enjoyment of the Work by the public
+as contemplated by Affirmer's express Statement of Purpose.
+
+3. Public License Fallback. Should any part of the Waiver for any reason
+be judged legally invalid or ineffective under applicable law, then the
+Waiver shall be preserved to the maximum extent permitted taking into
+account Affirmer's express Statement of Purpose. In addition, to the
+extent the Waiver is so judged Affirmer hereby grants to each affected
+person a royalty-free, non transferable, non sublicensable, non exclusive,
+irrevocable and unconditional license to exercise Affirmer's Copyright and
+Related Rights in the Work (i) in all territories worldwide, (ii) for the
+maximum duration provided by applicable law or treaty (including future
+time extensions), (iii) in any current or future medium and for any number
+of copies, and (iv) for any purpose whatsoever, including without
+limitation commercial, advertising or promotional purposes (the
+"License"). The License shall be deemed effective as of the date CC0 was
+applied by Affirmer to the Work. Should any part of the License for any
+reason be judged legally invalid or ineffective under applicable law, such
+partial invalidity or ineffectiveness shall not invalidate the remainder
+of the License, and in such case Affirmer hereby affirms that he or she
+will not (i) exercise any of his or her remaining Copyright and Related
+Rights in the Work or (ii) assert any associated claims and causes of
+action with respect to the Work, in either case contrary to Affirmer's
+express Statement of Purpose.
+
+4. Limitations and Disclaimers.
+
+ a. No trademark or patent rights held by Affirmer are waived, abandoned,
+ surrendered, licensed or otherwise affected by this document.
+ b. Affirmer offers the Work as-is and makes no representations or
+ warranties of any kind concerning the Work, express, implied,
+ statutory or otherwise, including without limitation warranties of
+ title, merchantability, fitness for a particular purpose, non
+ infringement, or the absence of latent or other defects, accuracy, or
+ the present or absence of errors, whether or not discoverable, all to
+ the greatest extent permissible under applicable law.
+ c. Affirmer disclaims responsibility for clearing rights of other persons
+ that may apply to the Work or any use thereof, including without
+ limitation any person's Copyright and Related Rights in the Work.
+ Further, Affirmer disclaims responsibility for obtaining any necessary
+ consents, permissions or other rights required for any use of the
+ Work.
+ d. Affirmer understands and acknowledges that Creative Commons is not a
+ party to this document and has no duty or obligation with respect to
+ this CC0 or use of the Work.
+
+
+ http://localhost:4000/LICENSE
+ http://localhost:4000/LICENSE
+
+
+
+
+ /
+
+ <?xml version="1.0" encoding="utf-8"?>{% if page.xsl %}<?xml-stylesheet type="text/xml" href="{{ '/feed.xslt.xml' | absolute_url }}"?>{% endif %}<feed xmlns="http://www.w3.org/2005/Atom" {% if site.lang %}xml:lang="{{ site.lang }}"{% endif %}><generator uri="https://jekyllrb.com/" version="{{ jekyll.version }}">Jekyll</generator><link href="{{ page.url | absolute_url }}" rel="self" type="application/atom+xml" /><link href="{{ '/' | absolute_url }}" rel="alternate" type="text/html" {% if site.lang %}hreflang="{{ site.lang }}" {% endif %}/><updated>{{ site.time | date_to_xmlschema }}</updated><id>{{ page.url | absolute_url | xml_escape }}</id>{% assign title = site.title | default: site.name %}{% if page.collection != "posts" %}{% assign collection = page.collection | capitalize %}{% assign title = title | append: " | " | append: collection %}{% endif %}{% if page.category %}{% assign category = page.category | capitalize %}{% assign title = title | append: " | " | append: category %}{% endif %}{% if title %}<title type="html">{{ title | smartify | xml_escape }}</title>{% endif %}{% if site.description %}<subtitle>{{ site.description | xml_escape }}</subtitle>{% endif %}{% if site.author %}<author><name>{{ site.author.name | default: site.author | xml_escape }}</name>{% if site.author.email %}<email>{{ site.author.email | xml_escape }}</email>{% endif %}{% if site.author.uri %}<uri>{{ site.author.uri | xml_escape }}</uri>{% endif %}</author>{% endif %}{% if page.tags %}{% assign posts = site.tags[page.tags] %}{% else %}{% assign posts = site[page.collection] %}{% endif %}{% if page.category %}{% assign posts = posts | where: "category", page.category %}{% endif %}{% unless site.show_drafts %}{% assign posts = posts | where_exp: "post", "post.draft != true" %}{% endunless %}{% assign posts = posts | sort: "date" | reverse %}{% assign posts_limit = site.feed.posts_limit | default: 10 %}{% for post in posts limit: posts_limit %}<entry{% if post.lang %}{{" "}}xml:lang="{{ post.lang }}"{% endif %}>{% assign post_title = post.title | smartify | strip_html | normalize_whitespace | xml_escape %}<title type="html">{{ post_title }}</title><link href="{{ post.url | absolute_url }}" rel="alternate" type="text/html" title="{{ post_title }}" /><published>{{ post.date | date_to_xmlschema }}</published><updated>{{ post.last_modified_at | default: post.date | date_to_xmlschema }}</updated><id>{{ post.id | absolute_url | xml_escape }}</id>{% assign excerpt_only = post.feed.excerpt_only | default: site.feed.excerpt_only %}{% unless excerpt_only %}<content type="html" xml:base="{{ post.url | absolute_url | xml_escape }}">{{ post.content | strip | xml_escape }}</content>{% endunless %}{% assign post_author = post.author | default: post.authors[0] | default: site.author %}{% assign post_author = site.data.authors[post_author] | default: post_author %}{% assign post_author_email = post_author.email | default: nil %}{% assign post_author_uri = post_author.uri | default: nil %}{% assign post_author_name = post_author.name | default: post_author %}<author><name>{{ post_author_name | default: "" | xml_escape }}</name>{% if post_author_email %}<email>{{ post_author_email | xml_escape }}</email>{% endif %}{% if post_author_uri %}<uri>{{ post_author_uri | xml_escape }}</uri>{% endif %}</author>{% if post.category %}<category term="{{ post.category | xml_escape }}" />{% elsif post.categories %}{% for category in post.categories %}<category term="{{ category | xml_escape }}" />{% endfor %}{% endif %}{% for tag in post.tags %}<category term="{{ tag | xml_escape }}" />{% endfor %}{% if post.excerpt and post.excerpt != empty %}<summary type="html">{{ post.excerpt | strip_html | normalize_whitespace | xml_escape }}</summary>{% endif %}{% assign post_image = post.image.path | default: post.image %}{% if post_image %}{% unless post_image contains "://" %}{% assign post_image = post_image | absolute_url %}{% endunless %}<media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="{{ post_image | xml_escape }}" /><media:content medium="image" url="{{ post_image | xml_escape }}" xmlns:media="http://search.yahoo.com/mrss/" />{% endif %}</entry>{% endfor %}</feed>
+
+ http://localhost:4000/feed.xml
+ http://localhost:4000/feed.xml
+
+
+
+
diff --git a/_site/rss/erc-last-call.xml b/_site/rss/erc-last-call.xml
new file mode 100644
index 0000000..05828bb
--- /dev/null
+++ b/_site/rss/erc-last-call.xml
@@ -0,0 +1,42 @@
+
+
+
+ Ethereum EIPs - Last Call Review
+ All EIPs which are in the "last call" status, please help review these and provide your feedback!
+ http://localhost:4000
+
+ Sat, 03 Feb 2024 00:10:05 +0530
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/_site/rss/erc.xml b/_site/rss/erc.xml
new file mode 100644
index 0000000..5822234
--- /dev/null
+++ b/_site/rss/erc.xml
@@ -0,0 +1,42 @@
+
+
+
+ Ethereum ERCs
+ All updates for ERCs
+ http://localhost:4000
+
+ Sat, 03 Feb 2024 00:10:05 +0530
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/_site/rss/last-call.xml b/_site/rss/last-call.xml
new file mode 100644
index 0000000..5ca2626
--- /dev/null
+++ b/_site/rss/last-call.xml
@@ -0,0 +1,42 @@
+
+
+
+ Ethereum EIPs - Last Call Review
+ All EIPs which are in the two-week "last call" status, please help review these and provide your feedback!
+ http://localhost:4000
+
+ Sat, 03 Feb 2024 00:10:05 +0530
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/_site/rss/nonerc-last-call.xml b/_site/rss/nonerc-last-call.xml
new file mode 100644
index 0000000..b898586
--- /dev/null
+++ b/_site/rss/nonerc-last-call.xml
@@ -0,0 +1,72 @@
+
+
+
+ Ethereum EIPs - Last Call Review
+ All EIPs which are in the two-week "last call" status, please help review these and provide your feedback!
+ http://localhost:4000
+
+ Sat, 03 Feb 2024 00:10:05 +0530
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/_site/rss/nonerc.xml b/_site/rss/nonerc.xml
new file mode 100644
index 0000000..3a7bd18
--- /dev/null
+++ b/_site/rss/nonerc.xml
@@ -0,0 +1,72 @@
+
+
+
+ Ethereum EIPs
+ All EIPs that are not ERCs
+ http://localhost:4000
+
+ Sat, 03 Feb 2024 00:10:05 +0530
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/all.html b/all.html
new file mode 100644
index 0000000..d57a5a9
--- /dev/null
+++ b/all.html
@@ -0,0 +1,6 @@
+---
+layout: page
+title: All
+---
+
+{% include eiptable.html eips=site.pages %}
diff --git a/config/.codespell-whitelist b/config/.codespell-whitelist
new file mode 100644
index 0000000..9d2323c
--- /dev/null
+++ b/config/.codespell-whitelist
@@ -0,0 +1,16 @@
+uint
+ith
+nd
+mitre
+readded
+crate
+developper
+ist
+iam
+espace
+acn
+ende
+sting
+complies
+shiping
+furter
diff --git a/config/.jekyll-labels.yml b/config/.jekyll-labels.yml
new file mode 100644
index 0000000..56f96e9
--- /dev/null
+++ b/config/.jekyll-labels.yml
@@ -0,0 +1,28 @@
+#### EIP Type / Category ####
+
+# Type
+t-informational: this?.new?.type == "Informational" && this?.old?.status != "Living"
+t-meta: this?.new?.type == "Meta" && this?.old?.status != "Living"
+
+# Categories
+t-core: this?.new?.category == "Core" && this?.old?.status != "Living"
+t-networking: this?.new?.category == "Networking" && this?.old?.status != "Living"
+t-interface: this?.new?.category == "Interface" && this?.old?.status != "Living"
+t-erc: this?.new?.category == "ERC" && this?.old?.status != "Living"
+
+# Living EIPs & EIP Template
+t-process: this?.old?.status == "Living" || this?.old?.title == ""
+
+# Status
+s-draft: this?.new?.status == "Draft"
+s-final: this?.new?.status == "Final"
+s-lastcall: this?.new?.status == "Lastcall"
+s-review: this?.new?.status == "Review"
+s-stagnant: this?.new?.status == "Stagnant"
+s-withdrawn: this?.new?.status == "Withdrawn"
+
+#### PR Classification ####
+
+c-new: this?.new?.status && !this?.old?.status
+c-update: this?.new?.status && this?.old?.status && this?.new?.status == this?.old?.status
+c-status: this?.new?.status && this?.old?.status && this?.new?.status != this?.old?.status
diff --git a/config/.markdownlint.yaml b/config/.markdownlint.yaml
new file mode 100644
index 0000000..46c59a4
--- /dev/null
+++ b/config/.markdownlint.yaml
@@ -0,0 +1,192 @@
+# Rule details can be found at https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md
+
+default: false
+
+# MD001/heading-increment/header-increment - Heading levels should only increment by one level at a time
+MD001: true
+# MD002/first-heading-h1/first-header-h1 - First heading should be a top-level heading (deprecated)
+MD002: false
+
+# MD003/heading-style/header-style - Heading style
+MD003:
+ # Heading style
+ style: "atx"
+
+# MD004/ul-style - Unordered list style
+MD004:
+ # List style
+ style: "consistent"
+
+# MD005/list-indent - Inconsistent indentation for list items at the same level
+MD005: true
+
+# MD006/ul-start-left - Consider starting bulleted lists at the beginning of the line (deprecated)
+MD006: false
+# MD007/ul-indent - Unordered list indentation
+MD007: false
+# MD009/no-trailing-spaces - Trailing spaces
+MD009: false
+
+# MD010/no-hard-tabs - Hard tabs
+MD010: false
+
+# MD011/no-reversed-links - Reversed link syntax
+MD011: true
+
+# MD012/no-multiple-blanks - Multiple consecutive blank lines
+MD012: false
+
+# MD013/line-length - Line length
+# Changed from default so we can allow the paragraphs to be a single line
+MD013: false
+
+# MD014/commands-show-output - Dollar signs used before commands without showing output
+MD014: false
+
+# MD018/no-missing-space-atx - No space after hash on atx style heading
+MD018: true
+
+# MD019/no-multiple-space-atx - Multiple spaces after hash on atx style heading
+MD019: true
+
+# MD020/no-missing-space-closed-atx - No space inside hashes on closed atx style heading
+MD020: true
+
+# MD021/no-multiple-space-closed-atx - Multiple spaces inside hashes on closed atx style heading
+MD021: true
+
+# MD022/blanks-around-headings/blanks-around-headers - Headings should be surrounded by blank lines
+MD022: true
+
+# MD023/heading-start-left/header-start-left - Headings must start at the beginning of the line
+MD023: true
+
+# MD024/no-duplicate-heading/no-duplicate-header - Multiple headings with the same content
+MD024:
+ # Only check sibling headings
+ siblings_only: true
+
+# MD025/single-title/single-h1 - Multiple top-level headings in the same document
+MD025:
+ # Heading level
+ level: 1
+ # RegExp for matching title in front matter
+ front_matter_title: "^\\s*title\\s*[:=]"
+
+# MD026/no-trailing-punctuation - Trailing punctuation in heading
+MD026: false
+
+# MD027/no-multiple-space-blockquote - Multiple spaces after blockquote symbol
+MD027: false
+
+# MD028/no-blanks-blockquote - Blank line inside blockquote
+MD028: true
+
+# MD029/ol-prefix - Ordered list item prefix
+MD029: false
+
+# MD030/list-marker-space - Spaces after list markers
+MD030:
+ # Spaces for single-line unordered list items
+ ul_single: 1
+ # Spaces for single-line ordered list items
+ ol_single: 1
+ # Spaces for multi-line unordered list items
+ ul_multi: 1
+ # Spaces for multi-line ordered list items
+ ol_multi: 1
+
+# MD031/blanks-around-fences - Fenced code blocks should be surrounded by blank lines
+MD031:
+ # Include list items
+ list_items: true
+
+# MD032/blanks-around-lists - Lists should be surrounded by blank lines
+MD032: true
+
+# MD033/no-inline-html - Inline HTML
+MD033:
+ # Allowed elements
+ allowed_elements: []
+
+# MD034/no-bare-urls - Bare URL used
+MD034: false
+
+# MD035/hr-style - Horizontal rule style
+MD035:
+ # Horizontal rule style
+ style: "consistent"
+
+# MD036/no-emphasis-as-heading/no-emphasis-as-header - Emphasis used instead of a heading
+MD036: false
+
+# MD037/no-space-in-emphasis - Spaces inside emphasis markers
+MD037: false
+
+# MD038/no-space-in-code - Spaces inside code span elements
+MD038: true
+
+# MD039/no-space-in-links - Spaces inside link text
+MD039: false
+
+# MD040/fenced-code-language - Fenced code blocks should have a language specified
+MD040: false
+
+# MD041/first-line-heading/first-line-h1 - First line in a file should be a top-level heading
+# NOTE: Since this uses Jekyll, this setting only applies to freestanding markdown files, such as those in the assets folder
+MD041:
+ # Heading level
+ level: 1
+ # RegExp for matching title in front matter
+ front_matter_title: "^\\s*title\\s*[:=]"
+
+# MD042/no-empty-links - No empty links
+MD042: true
+
+# MD043/required-headings/required-headers - Required heading structure
+# Handled by EIP Walidator
+MD043: false
+
+# MD044/proper-names - Proper names should have the correct capitalization
+MD044:
+ # List of proper names
+ names: []
+ # Include code blocks
+ code_blocks: true
+ # Include HTML elements
+ html_elements: true
+
+# MD045/no-alt-text - Images should have alternate text (alt text)
+MD045: false
+
+# MD046/code-block-style - Code block style
+MD046:
+ # Block style
+ style: "consistent"
+
+# MD047/single-trailing-newline - Files should end with a single newline character
+MD047: true
+
+# MD048/code-fence-style - Code fence style
+MD048:
+ # Code fence style
+ style: "consistent"
+
+# MD049/emphasis-style - Emphasis style should be consistent
+MD049:
+ # Emphasis style should be consistent
+ style: "consistent"
+
+# MD050/strong-style - Strong style should be consistent
+MD050:
+ # Strong style should be consistent
+ style: "consistent"
+
+# MD051/link-fragments - Link fragments should be valid
+MD051: true
+
+# MD052/reference-links-images - Reference links and images should use a label that is defined
+MD052: true
+
+# MD053/link-image-reference-definitions - Link and image reference definitions should be needed
+MD053: true
diff --git a/config/eip-editors.yml b/config/eip-editors.yml
new file mode 100644
index 0000000..8eb7e2f
--- /dev/null
+++ b/config/eip-editors.yml
@@ -0,0 +1,42 @@
+governance:
+ - lightclient
+ - axic
+ - gcolvin
+ - SamWilsn
+ - Pandapip1
+core:
+ - lightclient
+ - axic
+ - gcolvin
+ - SamWilsn
+ - Pandapip1
+ - g11tech
+erc:
+ - axic
+ - SamWilsn
+ - Pandapip1
+ - xinbenlv
+ - g11tech
+networking:
+ - lightclient
+ - axic
+ - SamWilsn
+interface:
+ - lightclient
+ - axic
+ - SamWilsn
+ - Pandapip1
+meta:
+ - lightclient
+ - axic
+ - gcolvin
+ - SamWilsn
+ - Pandapip1
+ - xinbenlv
+informational:
+ - lightclient
+ - axic
+ - gcolvin
+ - SamWilsn
+ - Pandapip1
+ - xinbenlv
diff --git a/config/eipw.toml b/config/eipw.toml
new file mode 100644
index 0000000..e19bb68
--- /dev/null
+++ b/config/eipw.toml
@@ -0,0 +1,920 @@
+[[modifiers]]
+kind = "set-default-annotation"
+name = "status"
+value = "Stagnant"
+annotation_type = "warning"
+
+[[modifiers]]
+kind = "set-default-annotation"
+name = "status"
+value = "Withdrawn"
+annotation_type = "warning"
+
+[lints.markdown-re-eip-dash]
+kind = "markdown-regex"
+mode = "excludes"
+pattern = '(?i)eip[\s]*[0-9]+'
+message = "proposals must be referenced with the form `EIP-N` (not `EIPN` or `EIP N`)"
+
+[lints.preamble-date-created]
+kind = "preamble-date"
+name = "created"
+
+[lints.preamble-re-description-eip-dash]
+kind = "preamble-regex"
+name = "description"
+mode = "excludes"
+pattern = '(?i)eip[\s]*[0-9]+'
+message = "proposals must be referenced with the form `EIP-N` (not `EIPN` or `EIP N`)"
+
+[lints.preamble-re-description-colon]
+kind = "preamble-regex"
+name = "description"
+mode = "excludes"
+pattern = ":"
+message = "preamble header `description` should not contain `:`"
+
+[lints.preamble-refs-description]
+kind = "preamble-proposal-ref"
+name = "description"
+prefix = "erc-"
+suffix = ".md"
+
+[lints.preamble-enum-category]
+kind = "preamble-one-of"
+name = "category"
+values = [
+ "ERC",
+]
+
+[lints.preamble-re-description]
+kind = "preamble-regex"
+name = "description"
+mode = "excludes"
+pattern = '(?i)standar\w*\b'
+message = "preamble header `description` should not contain `standard` (or similar words.)"
+
+[lints.preamble-re-title-erc-dash]
+kind = "preamble-regex"
+name = "title"
+mode = "excludes"
+pattern = '(?i)erc[\s]*[0-9]+'
+message = "proposals must be referenced with the form `ERC-N` (not `ERCN` or `ERC N`)"
+
+[lints.preamble-re-description-erc-dash]
+kind = "preamble-regex"
+name = "description"
+mode = "excludes"
+pattern = '(?i)erc[\s]*[0-9]+'
+message = "proposals must be referenced with the form `ERC-N` (not `ERCN` or `ERC N`)"
+
+## TODO: Disabled because half the files are in another repository.
+# [lints.markdown-refs]
+# kind = "markdown-proposal-ref"
+# prefix = "erc-"
+# suffix = ".md"
+
+[lints.preamble-req-withdrawal-reason]
+kind = "preamble-required-if-eq"
+when = "status"
+equals = "Withdrawn"
+then = "withdrawal-reason"
+
+[lints.preamble-order]
+kind = "preamble-order"
+names = [
+ "eip",
+ "title",
+ "description",
+ "author",
+ "discussions-to",
+ "status",
+ "last-call-deadline",
+ "type",
+ "category",
+ "created",
+ "requires",
+ "withdrawal-reason",
+]
+
+## TODO: Disabled because half the files are in another repository.
+# [lints.preamble-requires-status]
+# prefix = "erc-"
+# suffix = ".md"
+# kind = "preamble-requires-status"
+# requires = "requires"
+# status = "status"
+# flow = [
+# [
+# "Draft",
+# "Stagnant",
+# ],
+# ["Review"],
+# ["Last Call"],
+# [
+# "Final",
+# "Withdrawn",
+# "Living",
+# ],
+# ]
+
+[lints.markdown-order-section]
+kind = "markdown-section-order"
+sections = [
+ "Abstract",
+ "Motivation",
+ "Specification",
+ "Rationale",
+ "Backwards Compatibility",
+ "Test Cases",
+ "Reference Implementation",
+ "Security Considerations",
+ "Copyright",
+]
+
+[lints.markdown-rel-links]
+kind = "markdown-relative-links"
+exceptions = [
+ '^https://(www\.)?github\.com/ethereum/consensus-specs/blob/[a-f0-9]{40}/.+$',
+ '^https://(www\.)?github\.com/ethereum/consensus-specs/commit/[a-f0-9]{40}$',
+ '^https://(www\.)?github\.com/ethereum/devp2p/blob/[0-9a-f]{40}/.+$',
+ '^https://(www\.)?github\.com/ethereum/devp2p/commit/[0-9a-f]{40}$',
+ '^https://(www\.)?github\.com/bitcoin/bips/blob/[0-9a-f]{40}/bip-[0-9]+\.mediawiki$',
+ '^https://www\.w3\.org/TR/[0-9][0-9][0-9][0-9]/.*$',
+ '^https://[a-z]*\.spec\.whatwg\.org/commit-snapshots/[0-9a-f]{40}/$',
+ '^https://www\.rfc-editor\.org/rfc/.*$',
+]
+
+[lints.preamble-req-category]
+kind = "preamble-required-if-eq"
+when = "type"
+equals = "Standards Track"
+then = "category"
+
+[lints.preamble-eip]
+kind = "preamble-uint"
+name = "eip"
+
+[lints.markdown-json-cite]
+kind = "markdown-json-schema"
+language = "csl-json"
+additional_schemas = [[
+ "https://resource.citationstyles.org/schema/v1.0/input/json/csl-data.json",
+ """
+{
+ \"description\": \"JSON schema for CSL input data\",
+ \"$schema\": \"http://json-schema.org/draft-07/schema#\",
+ \"$id\": \"https://resource.citationstyles.org/schema/v1.0/input/json/csl-data.json\",
+ \"type\": \"array\",
+ \"items\": {
+ \"type\": \"object\",
+ \"properties\": {
+ \"type\": {
+ \"type\": \"string\",
+ \"enum\": [
+ \"article\",
+ \"article-journal\",
+ \"article-magazine\",
+ \"article-newspaper\",
+ \"bill\",
+ \"book\",
+ \"broadcast\",
+ \"chapter\",
+ \"classic\",
+ \"collection\",
+ \"dataset\",
+ \"document\",
+ \"entry\",
+ \"entry-dictionary\",
+ \"entry-encyclopedia\",
+ \"event\",
+ \"figure\",
+ \"graphic\",
+ \"hearing\",
+ \"interview\",
+ \"legal_case\",
+ \"legislation\",
+ \"manuscript\",
+ \"map\",
+ \"motion_picture\",
+ \"musical_score\",
+ \"pamphlet\",
+ \"paper-conference\",
+ \"patent\",
+ \"performance\",
+ \"periodical\",
+ \"personal_communication\",
+ \"post\",
+ \"post-weblog\",
+ \"regulation\",
+ \"report\",
+ \"review\",
+ \"review-book\",
+ \"software\",
+ \"song\",
+ \"speech\",
+ \"standard\",
+ \"thesis\",
+ \"treaty\",
+ \"webpage\"
+ ]
+ },
+ \"id\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"citation-key\": {
+ \"type\": \"string\"
+ },
+ \"categories\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"type\": \"string\"
+ }
+ },
+ \"language\": {
+ \"type\": \"string\"
+ },
+ \"journalAbbreviation\": {
+ \"type\": \"string\"
+ },
+ \"shortTitle\": {
+ \"type\": \"string\"
+ },
+ \"author\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"chair\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"collection-editor\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"compiler\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"composer\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"container-author\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"contributor\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"curator\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"director\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"editor\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"editorial-director\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"executive-producer\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"guest\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"host\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"interviewer\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"illustrator\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"narrator\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"organizer\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"original-author\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"performer\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"producer\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"recipient\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"reviewed-author\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"script-writer\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"series-creator\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"translator\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"$ref\": \"#/definitions/name-variable\"
+ }
+ },
+ \"accessed\": {
+ \"$ref\": \"#/definitions/date-variable\"
+ },
+ \"available-date\": {
+ \"$ref\": \"#/definitions/date-variable\"
+ },
+ \"event-date\": {
+ \"$ref\": \"#/definitions/date-variable\"
+ },
+ \"issued\": {
+ \"$ref\": \"#/definitions/date-variable\"
+ },
+ \"original-date\": {
+ \"$ref\": \"#/definitions/date-variable\"
+ },
+ \"submitted\": {
+ \"$ref\": \"#/definitions/date-variable\"
+ },
+ \"abstract\": {
+ \"type\": \"string\"
+ },
+ \"annote\": {
+ \"type\": \"string\"
+ },
+ \"archive\": {
+ \"type\": \"string\"
+ },
+ \"archive_collection\": {
+ \"type\": \"string\"
+ },
+ \"archive_location\": {
+ \"type\": \"string\"
+ },
+ \"archive-place\": {
+ \"type\": \"string\"
+ },
+ \"authority\": {
+ \"type\": \"string\"
+ },
+ \"call-number\": {
+ \"type\": \"string\"
+ },
+ \"chapter-number\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"citation-number\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"citation-label\": {
+ \"type\": \"string\"
+ },
+ \"collection-number\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"collection-title\": {
+ \"type\": \"string\"
+ },
+ \"container-title\": {
+ \"type\": \"string\"
+ },
+ \"container-title-short\": {
+ \"type\": \"string\"
+ },
+ \"dimensions\": {
+ \"type\": \"string\"
+ },
+ \"division\": {
+ \"type\": \"string\"
+ },
+ \"DOI\": {
+ \"type\": \"string\"
+ },
+ \"edition\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"event\": {
+ \"description\": \"[Deprecated - use 'event-title' instead. Will be removed in 1.1]\",
+ \"type\": \"string\"
+ },
+ \"event-title\": {
+ \"type\": \"string\"
+ },
+ \"event-place\": {
+ \"type\": \"string\"
+ },
+ \"first-reference-note-number\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"genre\": {
+ \"type\": \"string\"
+ },
+ \"ISBN\": {
+ \"type\": \"string\"
+ },
+ \"ISSN\": {
+ \"type\": \"string\"
+ },
+ \"issue\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"jurisdiction\": {
+ \"type\": \"string\"
+ },
+ \"keyword\": {
+ \"type\": \"string\"
+ },
+ \"locator\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"medium\": {
+ \"type\": \"string\"
+ },
+ \"note\": {
+ \"type\": \"string\"
+ },
+ \"number\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"number-of-pages\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"number-of-volumes\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"original-publisher\": {
+ \"type\": \"string\"
+ },
+ \"original-publisher-place\": {
+ \"type\": \"string\"
+ },
+ \"original-title\": {
+ \"type\": \"string\"
+ },
+ \"page\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"page-first\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"part\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"part-title\": {
+ \"type\": \"string\"
+ },
+ \"PMCID\": {
+ \"type\": \"string\"
+ },
+ \"PMID\": {
+ \"type\": \"string\"
+ },
+ \"printing\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"publisher\": {
+ \"type\": \"string\"
+ },
+ \"publisher-place\": {
+ \"type\": \"string\"
+ },
+ \"references\": {
+ \"type\": \"string\"
+ },
+ \"reviewed-genre\": {
+ \"type\": \"string\"
+ },
+ \"reviewed-title\": {
+ \"type\": \"string\"
+ },
+ \"scale\": {
+ \"type\": \"string\"
+ },
+ \"section\": {
+ \"type\": \"string\"
+ },
+ \"source\": {
+ \"type\": \"string\"
+ },
+ \"status\": {
+ \"type\": \"string\"
+ },
+ \"supplement\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"title\": {
+ \"type\": \"string\"
+ },
+ \"title-short\": {
+ \"type\": \"string\"
+ },
+ \"URL\": {
+ \"type\": \"string\"
+ },
+ \"version\": {
+ \"type\": \"string\"
+ },
+ \"volume\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"volume-title\": {
+ \"type\": \"string\"
+ },
+ \"volume-title-short\": {
+ \"type\": \"string\"
+ },
+ \"year-suffix\": {
+ \"type\": \"string\"
+ },
+ \"custom\": {
+ \"title\": \"Custom key-value pairs.\",
+ \"type\": \"object\",
+ \"description\": \"Used to store additional information that does not have a designated CSL JSON field. The custom field is preferred over the note field for storing custom data, particularly for storing key-value pairs, as the note field is used for user annotations in annotated bibliography styles.\",
+ \"examples\": [
+ {
+ \"short_id\": \"xyz\",
+ \"other-ids\": [\"alternative-id\"]
+ },
+ {
+ \"metadata-double-checked\": true
+ }
+ ]
+ }
+ },
+ \"required\": [\"type\", \"id\"],
+ \"additionalProperties\": false
+ },
+ \"definitions\": {
+ \"name-variable\": {
+ \"anyOf\": [
+ {
+ \"properties\": {
+ \"family\": {
+ \"type\": \"string\"
+ },
+ \"given\": {
+ \"type\": \"string\"
+ },
+ \"dropping-particle\": {
+ \"type\": \"string\"
+ },
+ \"non-dropping-particle\": {
+ \"type\": \"string\"
+ },
+ \"suffix\": {
+ \"type\": \"string\"
+ },
+ \"comma-suffix\": {
+ \"type\": [\"string\", \"number\", \"boolean\"]
+ },
+ \"static-ordering\": {
+ \"type\": [\"string\", \"number\", \"boolean\"]
+ },
+ \"literal\": {
+ \"type\": \"string\"
+ },
+ \"parse-names\": {
+ \"type\": [\"string\", \"number\", \"boolean\"]
+ }
+ },
+ \"additionalProperties\": false
+ }
+ ]
+ },
+ \"date-variable\": {
+ \"title\": \"Date content model.\",
+ \"description\": \"The CSL input model supports two different date representations: an EDTF string (preferred), and a more structured alternative.\",
+ \"anyOf\": [
+ {
+ \"properties\": {
+ \"date-parts\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"minItems\": 1,
+ \"maxItems\": 3
+ },
+ \"minItems\": 1,
+ \"maxItems\": 2
+ },
+ \"season\": {
+ \"type\": [\"string\", \"number\"]
+ },
+ \"circa\": {
+ \"type\": [\"string\", \"number\", \"boolean\"]
+ },
+ \"literal\": {
+ \"type\": \"string\"
+ },
+ \"raw\": {
+ \"type\": \"string\"
+ }
+ },
+ \"additionalProperties\": false
+ }
+ ]
+ }
+ }
+}
+""",
+]]
+schema = """
+{
+ \"$id\": \"https://eips.ethereum.org/assets/eip-1/schema/json/citation.json\",
+ \"description\": \"Citation format for EIPs\",
+ \"$schema\": \"http://json-schema.org/draft-07/schema#\",
+ \"allOf\": [
+ {
+ \"$ref\": \"https://resource.citationstyles.org/schema/v1.0/input/json/csl-data.json#/items\"
+ },
+ {
+ \"required\": [
+ \"DOI\",
+ \"URL\"
+ ],
+ \"properties\": {
+ \"URL\": {
+ \"format\": \"uri\"
+ },
+ \"custom\": {
+ \"properties\": {
+ \"additional-urls\": {
+ \"type\": \"array\",
+ \"items\": {
+ \"format\": \"uri\"
+ }
+ }
+ }
+ }
+ }
+ }
+ ]
+}
+"""
+help = "see https://github.com/ethereum/eipw/blob/master/eipw-lint/src/lints/markdown/json_schema/citation.json"
+
+[lints.preamble-no-dup]
+kind = "preamble-no-duplicates"
+
+[lints.preamble-requires-ref-description]
+kind = "preamble-require-referenced"
+name = "description"
+requires = "requires"
+
+[lints.preamble-re-title]
+kind = "preamble-regex"
+name = "title"
+mode = "excludes"
+pattern = '(?i)standar\w*\b'
+message = "preamble header `title` should not contain `standard` (or similar words.)"
+
+[lints.preamble-re-title-eip-dash]
+kind = "preamble-regex"
+name = "title"
+mode = "excludes"
+pattern = '(?i)eip[\s]*[0-9]+'
+message = "proposals must be referenced with the form `EIP-N` (not `EIPN` or `EIP N`)"
+
+[lints.preamble-date-last-call-deadline]
+kind = "preamble-date"
+name = "last-call-deadline"
+
+[lints.markdown-req-section]
+kind = "markdown-section-required"
+sections = [
+ "Abstract",
+ "Specification",
+ "Rationale",
+ "Security Considerations",
+ "Copyright",
+]
+
+[lints.markdown-link-status]
+prefix = "erc-"
+suffix = ".md"
+kind = "markdown-link-status"
+status = "status"
+flow = [
+ [
+ "Draft",
+ "Stagnant",
+],
+ ["Review"],
+ ["Last Call"],
+ [
+ "Final",
+ "Withdrawn",
+ "Living",
+],
+]
+
+[lints.preamble-re-title-colon]
+kind = "preamble-regex"
+name = "title"
+mode = "excludes"
+pattern = ":"
+message = "preamble header `title` should not contain `:`"
+
+[lints.preamble-list-requires]
+kind = "preamble-list"
+name = "requires"
+
+[lints.preamble-len-description]
+kind = "preamble-length"
+name = "description"
+min = 2
+max = 140
+
+[lints.preamble-requires-ref-title]
+kind = "preamble-require-referenced"
+name = "title"
+requires = "requires"
+
+[lints.markdown-html-comments]
+kind = "markdown-html-comments"
+name = "status"
+warn_for = [
+ "Draft",
+ "Withdrawn",
+]
+
+[lints.preamble-author]
+kind = "preamble-author"
+name = "author"
+
+[lints.preamble-uint-requires]
+kind = "preamble-uint-list"
+name = "requires"
+
+[lints.preamble-len-requires]
+kind = "preamble-length"
+name = "requires"
+min = 1
+
+[lints.markdown-link-first]
+kind = "markdown-link-first"
+pattern = "(?i)(?:eip|erc)-[0-9]+"
+
+[lints.markdown-re-erc-dash]
+kind = "markdown-regex"
+mode = "excludes"
+pattern = '(?i)erc[\s]*[0-9]+'
+message = "proposals must be referenced with the form `ERC-N` (not `ERCN` or `ERC N`)"
+
+[lints.preamble-list-author]
+kind = "preamble-list"
+name = "author"
+
+[lints.preamble-enum-type]
+kind = "preamble-one-of"
+name = "type"
+values = [
+ "Standards Track",
+]
+
+[lints.preamble-len-title]
+kind = "preamble-length"
+name = "title"
+min = 2
+max = 44
+
+[lints.preamble-discussions-to]
+kind = "preamble-url"
+name = "discussions-to"
+
+[lints.preamble-req]
+kind = "preamble-required"
+names = [
+ "eip",
+ "title",
+ "description",
+ "author",
+ "discussions-to",
+ "status",
+ "type",
+ "created",
+]
+
+[lints.preamble-re-discussions-to]
+kind = "preamble-regex"
+name = "discussions-to"
+mode = "includes"
+pattern = "^https://ethereum-magicians.org/t/[^/]+/[0-9]+$"
+message = "preamble header `discussions-to` should point to a thread on ethereum-magicians.org"
+
+[lints.preamble-refs-title]
+kind = "preamble-proposal-ref"
+name = "title"
+prefix = "erc-"
+suffix = ".md"
+
+[lints.preamble-enum-status]
+kind = "preamble-one-of"
+name = "status"
+values = [
+ "Draft",
+ "Review",
+ "Last Call",
+ "Final",
+ "Stagnant",
+ "Withdrawn",
+ "Living",
+]
+
+[lints.preamble-trim]
+kind = "preamble-trim"
+
+[lints.preamble-req-last-call-deadline]
+kind = "preamble-required-if-eq"
+when = "status"
+equals = "Last Call"
+then = "last-call-deadline"
+
+[lints.preamble-file-name]
+kind = "preamble-file-name"
+name = "eip"
+prefix = "erc-"
+suffix = ".md"
+
+
diff --git a/config/mlc_config.json b/config/mlc_config.json
new file mode 100644
index 0000000..ed1f966
--- /dev/null
+++ b/config/mlc_config.json
@@ -0,0 +1,15 @@
+{
+ "ignorePatterns": [
+ "[`]*csl-json"
+ ],
+ "replacementPatterns": [
+ {
+ "pattern": "^/",
+ "replacement": "/github/workspace/"
+ }
+ ],
+ "aliveStatusCodes": [
+ 200,
+ 429
+ ]
+}
diff --git a/core.html b/core.html
new file mode 100644
index 0000000..29cceb2
--- /dev/null
+++ b/core.html
@@ -0,0 +1,7 @@
+---
+layout: page
+title: Core
+---
+
+{% assign eips=site.pages|where:"type","Standards Track"|where:"category","Core" %}
+{% include eiptable.html eips=eips %}
diff --git a/index.html b/index.html
new file mode 100644
index 0000000..eef163f
--- /dev/null
+++ b/index.html
@@ -0,0 +1,52 @@
+---
+layout: default
+title: Home
+---
+
+
EIPs
+
+
+
+
+
+
+
+
+
Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards. Network upgrades are discussed separately in the Ethereum Project Management repository.
+
+
Contributing
+
First review EIP-1. Then clone the repository and add your EIP to it. There is a template EIP here. Then submit a Pull Request to Ethereum's EIPs repository.
+
+
EIP status terms
+
+
Idea - An idea that is pre-draft. This is not tracked within the EIP Repository.
+
Draft - The first formally tracked stage of an EIP in development. An EIP is merged by an EIP Editor into the EIP repository when properly formatted.
+
Review - An EIP Author marks an EIP as ready for and requesting Peer Review.
+
Last Call - This is the final review window for an EIP before moving to FINAL. An EIP editor will assign Last Call status and set a review end date (`last-call-deadline`), typically 14 days later. If this period results in necessary normative changes it will revert the EIP to Review.
+
Final - This EIP represents the final standard. A Final EIP exists in a state of finality and should only be updated to correct errata and add non-normative clarifications.
+
Stagnant - Any EIP in Draft or Review if inactive for a period of 6 months or greater is moved to Stagnant. An EIP may be resurrected from this state by Authors or EIP Editors through moving it back to Draft.
+
Withdrawn - The EIP Author(s) have withdrawn the proposed EIP. This state has finality and can no longer be resurrected using this EIP number. If the idea is pursued at later date it is considered a new proposal.
+
Living - A special status for EIPs that are designed to be continually updated and not reach a state of finality. This includes most notably EIP-1.
+
+
+
EIP Types
+
+
EIPs are separated into a number of types, and each has its own list of EIPs.
+
+
Standard Track ({{site.pages|where:"type","Standards Track"|size}})
+
Describes any change that affects most or all Ethereum implementations, such as a change to the network protocol, a change in block or transaction validity rules, proposed application standards/conventions, or any change or addition that affects the interoperability of applications using Ethereum. Furthermore Standard EIPs can be broken down into the following categories.
Improvements requiring a consensus fork (e.g. EIP-5, EIP-211), as well as changes that are not necessarily consensus critical but may be relevant to “core dev” discussions (for example, the PoA algorithm for testnets described in EIP-225).
Includes improvements around devp2p (EIP-8) and Light Ethereum Subprotocol, as well as proposed improvements to network protocol specifications of whisper and swarm.
Includes improvements around client API/RPC specifications and standards, and also certain language-level standards like method names (EIP-6) and contract ABIs. The label “interface” aligns with the interfaces repo and discussion should primarily occur in that repository before an EIP is submitted to the EIPs repository.
Application-level standards and conventions, including contract standards such as token standards (EIP-20), name registries (EIP-137), URI schemes (EIP-681), library/package formats (EIP-190), and account abstraction (EIP-4337).
Describes a process surrounding Ethereum or proposes a change to (or an event in) a process. Process EIPs are like Standards Track EIPs but apply to areas other than the Ethereum protocol itself. They may propose an implementation, but not to Ethereum's codebase; they often require community consensus; unlike Informational EIPs, they are more than recommendations, and users are typically not free to ignore them. Examples include procedures, guidelines, changes to the decision-making process, and changes to the tools or environment used in Ethereum development. Any meta-EIP is also considered a Process EIP.
diff --git a/rss/all.xml b/rss/all.xml
new file mode 100644
index 0000000..b5be0a9
--- /dev/null
+++ b/rss/all.xml
@@ -0,0 +1,27 @@
+---
+layout: null
+---
+
+
+
+ Ethereum EIPs
+ A feed of all EIPs
+ {{ site.url }}
+
+ {{ site.time | date_to_rfc822 }}
+ {% assign eips = site.pages | sort: 'eip' %}
+ {% for eip in eips %}
+
+ {{ eip.title | xml_escape }}
+ {{ eip.type | xml_escape }}/{{ eip.category | xml_escape }}
+ {% if eip.discussions-to %}
+ {{ eip.discussions-to | xml_escape }}
+ {% endif %}
+ {{ eip.content | xml_escape }}
+ {{ eip.created | date_to_rfc822 }}
+ {{ site.url }}{{ eip.url }}
+ {{ site.url }}{{ eip.url }}
+
+ {% endfor %}
+
+
diff --git a/rss/erc-last-call.xml b/rss/erc-last-call.xml
new file mode 100644
index 0000000..5ba15cf
--- /dev/null
+++ b/rss/erc-last-call.xml
@@ -0,0 +1,35 @@
+---
+layout: null
+---
+
+
+
+ Ethereum EIPs - Last Call Review
+ All EIPs which are in the "last call" status, please help review these and provide your feedback!
+ {{ site.url }}
+
+ {{ site.time | date_to_rfc822 }}
+ {% assign eips = site.pages | sort: 'eip' %}
+ {% for eip in eips %}
+ {% if eip.category == "ERC" %}
+ {% if eip.status == "Last Call" %}
+ {% capture description %}
+
EIP #{{ eip.eip }} - {{eip.title }} is in Last Call status. It is authored by {{ eip.author }} and was originally created {{ eip.created }}. It is in the {{ eip.category }} category of type {{ eip.type }}. Please review and note any changes that should block acceptance.
+ {% endif %}
+
+ {{ eip.content }}
+ {% endcapture %}
+
+ {{ eip.title | xml_escape }}
+ {{ description | xml_escape }}
+ {{ eip.created | date_to_rfc822 }}
+ {{ site.url }}/{{ eip.url }}
+ {{ site.url }}/{{ eip.url }}
+
+ {% endif %}
+ {% endfor %}
+
+
diff --git a/rss/last-call.xml b/rss/last-call.xml
new file mode 100644
index 0000000..da06188
--- /dev/null
+++ b/rss/last-call.xml
@@ -0,0 +1,33 @@
+---
+layout: null
+---
+
+
+
+ Ethereum EIPs - Last Call Review
+ All EIPs which are in the two-week "last call" status, please help review these and provide your feedback!
+ {{ site.url }}
+
+ {{ site.time | date_to_rfc822 }}
+ {% assign eips = site.pages | sort: 'eip' %}
+ {% for eip in eips %}
+ {% if eip.status == "Last Call" %}
+ {% capture description %}
+
EIP #{{ eip.eip }} - {{eip.title }} is in Last Call status. It is authored by {{ eip.author }} and was originally created {{ eip.created }}. It is in the {{ eip.category }} category of type {{ eip.type }}. Please review and note any changes that should block acceptance.
+ {% endif %}
+
+ {{ eip.content }}
+ {% endcapture %}
+
+ {{ eip.title | xml_escape }}
+ {{ description | xml_escape }}
+ {{ eip.created | date_to_rfc822 }}
+ {{ site.url }}/{{ eip.url }}
+ {{ site.url }}/{{ eip.url }}
+
+ {% endif %}
+ {% endfor %}
+
+
diff --git a/rss/nonerc-last-call.xml b/rss/nonerc-last-call.xml
new file mode 100644
index 0000000..17f0939
--- /dev/null
+++ b/rss/nonerc-last-call.xml
@@ -0,0 +1,35 @@
+---
+layout: null
+---
+
+
+
+ Ethereum EIPs - Last Call Review
+ All EIPs which are in the two-week "last call" status, please help review these and provide your feedback!
+ {{ site.url }}
+
+ {{ site.time | date_to_rfc822 }}
+ {% assign eips = site.pages | sort: 'eip' %}
+ {% for eip in eips %}
+ {% unless eip.category == "ERC" %}
+ {% if eip.status == "Last Call" %}
+ {% capture description %}
+
EIP #{{ eip.eip }} - {{eip.title }} is in Last Call status. It is authored by {{ eip.author }} and was originally created {{ eip.created }}. It is in the {{ eip.category }} category of type {{ eip.type }}. Please review and note any changes that should block acceptance.
EIP #{{ eip.eip }} - {{eip.title }} is in Last Call status. It is authored by {{ eip.author }} and was originally created {{ eip.created }}. It is in the {{ eip.category }} category of type {{ eip.type }}. Please review and note any changes that should block acceptance.
+Execution flow for the Native Account Abstraction Transactions
+The structure of a block containing multiple Native Account Abstraction Transactions
+Frames within a single Native Account Abstraction Transaction within a block
