Can ERC in Final state establish orthodox status?
TechFlow Selected TechFlow Selected
Can ERC in Final state establish orthodox status?
What does ERC represent on Ethereum? Is it the source of community legitimacy?
Navigating Web3 tides with focused insightsAuthor: Zhixiong Pan
Recently, discussions around ERC-6551 have been heating up—ranging from "enabling new use cases for ERC-721" to "NFTs leveraging ERC-6551 for speculation," and even the practical implementation after ERC integration. However, I believe the key is not the standard itself, but rather understanding what an ERC represents on Ethereum. Is it the source of community legitimacy?
Here, I won't go into detailed background on ERC-6551. In short, it's a smart contract standard that enables NFTs to hold other assets, thereby creating more user scenarios.
Hot Knowledge 1: ERCs are actually application-layer standards and do not directly involve the Ethereum protocol itself.
Ethereum Improvement Proposals (EIPs) are clearly categorized into three types in EIP-1: Standard Track EIPs, Meta EIPs, and Informational EIPs.
Among these, Standard Track EIPs are the most common, including Core improvements, Networking improvements, Interface improvements, and Application layer standards (ERC).
Specifically, the ERC-6551 standard defines a "registry" smart contract, an account implementation interface, and reference implementations for both. For example, the registry smart contract defined by ERC-6551 only needs to include two interfaces: creating an account and reading an account address. As for how exactly to implement them, ERC-6551 provides a reference.
For instance, the most widely used token standard on Ethereum is ERC-20, which defines a set of basic interfaces. Developers can either implement these interfaces according to their own needs or directly use open-source standard contracts like those from OpenZeppelin.
Hot Knowledge 2: There are specific formatting rules for EIP or ERC proposals (refer to EIP-1). It should be written as ERC-XXX, not ERC XXX or ERCXXX. The same applies to non-ERC EIPs, which should be formatted as EIP-XXX.
Examples include ERC-20, ERC-6551, and EIP-3540.
Since ERC-6551 is a standard achievable via smart contracts, developers could have implemented similar functionality even before its proposal. However, with this standard, we can potentially build a larger ecosystem—for example, how wallets and marketplaces support it.
Without ERC-4337, each wallet could still independently implement smart contract-based account abstraction, but they would lack composability across wallets and applications. Without ERC-20, every developer could also implement their own token issuance, but wallets would then need to integrate each token individually, resulting in unnecessary additional development overhead.
However, this does not mean that becoming an "ERC standard" is the only path to becoming an industry standard. In fact, "social consensus" and "de facto standards" matter more than achieving the "Final" status in an ERC.
Some may think that for a standard to become an industry norm, it must be reviewed by the Ethereum Foundation or the EIP editors and officially marked as Final. But in reality, some "industry standards" might receive little attention, while certain unstandardized practices can evolve into de facto standards through growing social consensus.
For example, NFTs are such a case—they emerged through applications first, and the ERC standard came later. ERC-721 was not submitted until January 2018 and did not reach Final status until June that year. Yet, CryptoKitties had already launched by the end of 2017 and is widely recognized as the first application using the ERC-721 standard.
Therefore, the logic should not be "because ERC-721 became a standard, ecosystems and legitimacy followed," but rather "because there was demand for non-fungible tokens, CryptoKitties solved this problem, and the subsequently formalized ERC-721 met this demand, leading the community to adopt it." This explains why later standards like ERC-1155 emerged—to meet increasingly diverse and personalized needs.
In summary, both of the following sequences are possible, but the latter likely reflects reality more accurately:
1. Propose standard → Ecosystem
2. Identify demand → Develop solution → Formalize standard → Ecosystem
Regardless of the path, the core lies in addressing user needs and ensuring the solution gains broad acceptance and adoption—that is the true purpose behind introducing any new standard.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@nake13
