I. Introduction

As lawmakers consider digital asset market structure this year, there has been a growing conversation around how best to combat illicit finance and protect consumers that engage with open, permissionless blockchain systems and decentralized finance (DeFi). These are worthy goals that deserve all of the attention they get – and they present hard problems involving complex technology. In an effort to get to a quick solution in time to include within a market structure bill, there have been various proposals to create “certification regimes” for blockchain and smart contract protocols. However, as explained in this post, certification regimes would actually prove ineffective in an open-source, decentralized ecosystem, and would not strengthen cybersecurity, but instead, cede U.S. leadership in DeFi’s development. The solution is instead a standards development organization (SDO) that develops cybersecurity standards for blockchain and DeFi with input from industry experts and government agencies.

Cybersecurity standards must be developed in an open, collaborative system to be effective at combatting threats. The effort to create such standards must be technology-first and science-based, and should depend on expertise from the existing ecosystem of technologists. An ecosystem much like the Scientific Revolution, in which the pursuit of knowledge was no longer in the hands of the few, but of the many, and never settled, but continuously challenged and improved upon. The Scientific Revolution led to a plethora of advancements in almost all scientific disciplines and schools of thought, and was the precursor to what we know as modern science, because it allowed for open collaboration founded on the scientific method of “observation and reasoning” and on the open exchange of information.¹ 

Rather than creating a certification regime where cybersecurity standards are decided upon by lawmakers without input by industry experts, developing cybersecurity standards for DeFi in an open, collaborative system would be better done through voluntary standards developed by a fully-open, independent standards development organization. Just like with open-source software, anyone can choose to participate and contribute to standards development—including, but not limited to, independent developers, industry, users, federal agencies, and academia. And through a rigorous development process and broad adoption—based on merit and not mandate—these standards can help strengthen cybersecurity and protect DeFi users.

Most importantly, cybersecurity standards should serve as guidance and demonstrate best practices for DeFi developers to implement into their systems to make them more secure. By no means should they be mandated on developers to dictate how they should develop software, lest they stifle innovation and quickly become outdated. The ethos and core strength of DeFi is the ability for anyone to build what they believe will serve the greater good, based on the ideas they hold dearly, and cybersecurity standards should reflect that through open collaboration and by remaining voluntary.

II. Importance of Cybersecurity Standards

Cybersecurity standards provide guidance to a vast array of developers on best practices for securing the networks, devices, and data in which they build and utilize; subsequently, protecting the users who use them. For example, the Internet Engineering Task Force (IETF)—which develops voluntary standards for the Internet (more on this later)—developed the Internet Key Exchange Protocol Version 2 (IKEv2), which defines how two systems securely exchange and authenticate cryptographic keys and parameters to establish protected communication over networks on the Internet Protocol (IP). Today, developers can implement IKEv2 within their systems to establish more secure transmission of data.²

As an evolving technology still in its infancy, it is to no surprise that DeFi has experienced numerous cyberattacks. Much of this is because of bugs and vulnerabilities in smart contracts, as well as lack of standardization and fragmented technology stacks.³ For this reason, the DeFi industry has already taken substantial measures to strengthen its cybersecurity and broaden cooperation, even without a government mandate to do so.⁴

Even though many projects have come up with their own project-specific standards,  the DeFi industry has not yet coalesced around uniform cybersecurity standards. Creating industry-led uniform standards would have numerous benefits: 

• Standards are developed by interested parties across various disciplines and backgrounds that provide guidance to developers that vary across skill-set and knowledge.
• Standards create a metric against which developers can check as they build, raising issues they might not have thought of and encouraging more consumer protections that they might not have otherwise had. 
• Standards establish shared practices that enable greater interoperability between various technologies. 
• Standards can help to enhance an industry’s reputation through transparency and a greater sense of security.

Therefore, it is important for the DeFi industry to establish entirely voluntary standards, and do so in an open and collaborative manner. The industry cannot, and should not, depend on regulation to steer it towards greater cybersecurity, as doing so has significant costs with little benefit.

III. The Problem: Why A Certification Regime Is Not The Optimal Solution

First, mandating a certification regime—through either legislation or agency rulemaking—would prove ineffective for both blockchains and smart contracts. A blockchain’s open-source software can be deployed on the internet for anyone to run on their own computer from anywhere in the world. The same holds true for smart contracts: anyone in the world can write the code for a smart contract and deploy it on a blockchain, and the blockchain network will accept the code so long as the deployment transaction is valid. Taking this into account, forcing a certification regime on developers actively building in this space would incentivize those developers to seek easier or more innovation-friendly places to build, sending developers offshores and leaving the U.S. behind on this critical innovation.

Second, a top-down certification regime would also fail to incorporate a diverse set of input that would otherwise exist with a broader view of the whole ecosystem. Even if the certification regime were developed through agency rulemaking with notice for public comment, the development would remain constrained by the agency’s discretion and fail to incorporate emerging developments or insights from newer industry participants.

Third, whether through legislation or rulemaking, certification regimes are not able to evolve at the same pace as emerging technologies – especially not technologies like blockchain and DeFi that operate through open-source code at a global scale. If such a regime were encoded in statute or through final agency rulemaking, it would be nearly impossible to update on a regular basis as the technology continues to develop. Innovation is continuous, whereas laws and regulation are static; such a regime would often find itself outdated in just a couple of years and in urgent need of an update that neither Congress nor a federal agency can accelerate to meet cybersecurity demands.

Fourth, by driving development offshores, a certification regime would hinder U.S. geopolitical influence. Because DeFi is global and open-source, its development will continue regardless of U.S. policy, and other nations will have the opportunity to influence its development and issue open cybersecurity standards for the world to participate and adopt, leaving the U.S. behind. The U.S. is currently facing a similar situation with RISC-V, where the federal government is skeptical of open development, while nations like China jump at the opportunity to take charge.

Case Study: RISC-V

RISC-V is “an open-source instruction set architecture (ISA),” defining the “interface between software and hardware” and “dictating how a [computer] processor executes instructions.”⁵ In layman’s terms, RISC-V is an open-source standard for computer chip architecture. RISC-V is managed by the Swiss foundation RISC-V International and consists of 4,600 member organizations from around the world—mostly from China and the U.S.⁶ Over the past few years, there has been rapid industry adoption of RISC-V in various technologies—including AI, automotives, and spaceflight—due to its technical flexibility and lower implementation costs.⁷ And while many U.S. firms use proprietary ISAs, they also develop RISC-V to maintain optionality and allow engineers to build their own implementations on top of the ISA. Of note, one such company that deploys this hybrid approach is a top U.S. company called Nvidia.⁸

However, U.S. leadership in RISC-V development is being threatened as the federal government has grown concerned with its open development and specifically, China’s adoption and involvement with the technology.⁹ This was raised in a bipartisan letter to the Department of Commerce from the House Select Committee on the Chinese Communist Party in 2023.¹⁰ Specifically, the Committee indicated that the People’s Republic of China (PRC) has taken initiative in RISC-V development as a means to “dominate” its production and become “self-reliant.”¹¹ The Committee noted the U.S. government’s authorities should require “U.S. persons engaging with the PRC on RISC-V technology, or other instruction set architecture, to first receive an export control license from the Department of Commerce” in order to “grant the U.S. government insight into U.S. interactions with the PRC on RISC-V technology and prevent U.S. companies from transferring technical expertise on RISC-V without U.S. government approval.”¹²

But, as the Center for Strategic and International Studies (CSIS) has explained, restricting U.S. firms from participating in the development of RISC-V “would likely not stop global development” and instead the U.S. would “cede innovation to Chinese firms” and “lose influence over its development,” while also still relying on the technology for innovation in the United States.¹³ CSIS argues that if the U.S. prioritizes firms’ proprietary standards over involvement in RISC-V development, it risks losing influence over the development and evolution of  a standards that are increasingly adopted by thousands of firms around the world:

China now recognizes the value of active participation in standards-setting in developing its long-term competitive advantage. As highlighted in the China Standards 2035 plan, China is prioritizing investment and engagement in standards-setting bodies with an eye to gaining a competitive advantage for Chinese companies in a broad range of emerging technologies. It would not be prudent to cede standards leadership. In this context, the United States should move toward exerting active leadership in international standards-setting opportunities—including that posed by RISC-V.

The same would hold true for DeFi: if the U.S. prioritizes a certification regime over encouraging open innovation in DeFi, it will cede its influence in its development to other nations, including adversarial nations. Instead, the U.S. should consider supporting voluntary standards that are developed through an open, collaborative process that would adhere to the ethos of DeFi, neither force developers offshore nor enable regulatory capture, and instead empower U.S. involvement and leadership.

IV. The Solution: A DeFi Standards Developing Organization

Voluntary cybersecurity standards for DeFi would be best developed by a standards developing organization – or SDO. SDOs are “any organization that develops and approves standards using various methods to establish consensus among its participants.”¹⁵ SDOs exist in almost all industries,especially technology-based fields like IETF, which is described in the next section. SDOs also exist in various forms: some are fully open for anyone to participate in (e.g.,  IETF),while others have membership tiers with annual dues to access different benefits.

Important caveat, an SDO should not be conflated with a self-regulatory organization (SRO), as an SRO is authorized by the federal government to enforce rules and conduct within an industry, and requires membership. Such organizations would engender the same shortcomings as a certification regime—mainly, driving development offshores, developing high barriers to entry that result in regulatory capture, and ceding U.S. leadership in DeFi development and security to other nations.

For DeFi, an ideal SDO would be fully-open for participation without any membership requirements.. This is because DeFi development can vary from single developers to development teams with significant capital, and a membership-gated process could make it difficult or cost-prohibitive for smaller teams or individuals to participate in. A membership-gated SDO would not receive all substantial contributions to standards development and potentially bar thoughtful input that would have otherwise been included. A fully-open SDO would allow anyone from any sector to participate in thorough development of DeFi standards.

Additionally, these standards must be voluntary. By making standards voluntary, developers across the ecosystem are safe to innovate new ideas that can later be adopted by the SDO. In contrast, a certification regime would force developers to build within the constraints of the certification criteria and would chill innovation that could potentially improve the current system—assuming they remain in the U.S. And, unlike a certification regime conducted through legislation or rulemaking, voluntary standards through an SDO allow the industry to move faster to meet the demands of the technology and promote experimentation of new ideas and innovations.

Case Study: Internet Engineering Task Force (IETF)

IETF is an SDO that was founded in 1986 to develop voluntary standards for the development of the internet.¹⁶ There is no membership criteria for IETF, as “anyone can participate by signing up to a working group mailing list, or registering for an IETF meeting,” and sometimes accumulating over 7,000 active participants in a given year.¹⁷

 The Internet Engineering Steering Group (IESG) leads IETF and “administers the [standards] process according to the established rules and procedures.” It “[c]onsists of Area Directors, with backgrounds in Academia, private firms, NGOs, and even independent individuals.”¹⁸ These Directors are “[a]ppointed by the Nominations Committee, which consists of one chair, 10 voting volunteers, 4-5 liaisons, and an advisor. [The] Chair is appointed between the first and second meetings of the year, and the committee begins its work once the selected volunteers are seated following the volunteer solicitation, random selection, and community review time periods.”¹⁹

IETF’s Internet Standards Process—known as RFC 2026—outlines the various mechanisms whereby standards are developed and agreed upon. The process is generally conducted as such:

[A] specification undergoes a period of development and several iterations of review by the Internet community and revision based upon experience, is adopted as a Standard by the appropriate body (see below), and is published.

The process is deeply democratic, and as IETF notes: 

At each stage of the standardization process, a specification is repeatedly discussed and its merits debated in open meetings and/or public electronic mailing lists, and it is made available for review via world-wide on-line directories.

Each candidate specification is tested in order to meet certain requirements:

[A] candidate specification must be implemented and tested for correct operation and interoperability by multiple independent parties and utilized in increasingly demanding environments, before it can be adopted as an Internet Standard.

Importantly, IETF conducts its standards development process through working groups (WGs), which maintain their own mailing list that contains most interactions and official work.²³ These WGs draft the various internet standards that eventually become RFCs.²⁴

To date, IETF has developed over 100 internet standards, and has drafted and proposed hundreds more.²⁵ Various standards derived from IETF, including Internet Protocols (IPs), are globally adopted everyday.²⁶ For example, Cloudfare reports that roughly 40% of HTTP requests use Internet Protocol Version 6 (IPv6) and 60% still use its predecessor, IPv4,²⁷ and Google reports that 44-45% of its users access Google through IPv6.²⁸

V. The U.S. Government’s Role in a DeFi SDO

The U.S. government should both participate in and support a DeFi SDO in order to contribute its knowledge and strengthen cybersecurity standards, and as a geopolitical strategy by helping shape standards development. As previously mentioned, international standards are increasingly an area of strategic competition, and by proactively engaging in open, voluntary standards development, the U.S. can both enhance domestic cybersecurity for DeFi and shape its global development. 

However, for reasons previously mentioned, the U.S. should not try to overly control or gatekeep this process, but instead should participate in and help lead it. SDOs include and even welcome involvement from federal agencies, and the National Institute of Standards and Technology (NIST) is the most qualified to contribute and improve cybersecurity standards. 

NIST functions as a non-regulatory agency within the Department of Commerce—a status reflected in its organic statute and confirmed in both legislative history and executive guidance.²⁹ NIST’s statutory mission is “to promote United States innovation and industrial competitiveness by advancing measurement science, standards, and technology in ways that enhance economic security and improve our quality of life.”³⁰ NIST also assists “private-sector initiatives to capitalize on advanced technology, “advance[s], through cooperative efforts among industries, universities, and government laboratories, promising research and development projects,” and “promote[s] shared risks, accelerated development, and pooling of skills … necessary to strengthen America’s manufacturing industries.”³¹ Its separate statutory authorization, sustained research focus, and scientific credibility have enabled NIST to maintain long-term technical leadership insulated from political change.³²

Through legislation, Congress should direct NIST to establish a joint task force on developing an SDO focused on DeFi cybersecurity. Membership could include: the Secretary of Commerce, Director of NIST, representatives from existing SDOs, and ten representatives from the DeFi industry (e.g., blockchain and smart contract developers, cryptographers, security researchers, trade associations and non-governmental organizations (NGOs), and academic researchers, among others). Legislation could then direct NIST, in consultation with the task force and expert input from an RFC, to develop the SDO with open processes and participation—much like IETF. Once established, the SDO would exist as an independent non-profit.

Congress could support this initiative by directing or encouraging annual government grants to the DeFi SDO or appropriations to government agencies working with the SDO, which would supplement donations from the private sector to maintain its independence. This would be functionally similar to the manner in which Congress appropriates funds to the U.S. Agency for Global Media to then administer grants to organizations like the Open Technology Fund.³³

Then, through an Executive Order (EO), the President should further these efforts by amending EO 14306—which focuses on strengthening the nation’s cybersecurity—to direct NIST to participate in standards development within the SDO thereafter.³⁴ The President might select NIST’s Computer Security Division (CSD) and the Applied Cybersecurity Division (ACD) within the Information Technology Laboratory (ITL) to be responsible for these tasks, given their expertise.³⁵ Of note, CSD is the core division for developing cybersecurity standards and guidance, and would make an ideal candidate for contributing to an SDO’s development of cybersecurity standards, particularly given their expertise. And, ACD houses the National Cybersecurity Center of Excellence (NCCOE), which “is a collaborative hub where industry, government agencies, and academic institutions work together to address businesses’ most pressing cybersecurity issue,” as well as the Cybersecurity and Privacy Applicants Group, which “address[es] critical cybersecurity and privacy needs through the development, integration, and promotion of standards and guidelines, tools, and technologies, methodologies, tests, and measurements.”³⁶

VI. Conclusion: Positioning the U.S. to Lead on Innovation and Cybersecurity

As DeFi continues to evolve and its adoption continues to increase, DeFi cybersecurity standards are crucial for the integrity of the technology and the safety of users. An SDO provides the appropriate balance between structure and flexibility, as well as government involvement and open participation – and would ultimately help the United States become well-positioned to lead on the next generation of innovation in DeFi and cybersecurity. 

This piece was authored by Lizandro (Laz) Pieper, DEF’s Research Director.

Notes

1.  The Scientific Revolution, Historic UK, https://www.historic-uk.com/HistoryUK/HistoryofBritain/The-Scientific-Revolution/#:~:text=William%20Harvey’s%20discovery%20explained%20how,%2C%20a%20ground%2Dbreaking%20discovery. (last visited Nov. 4, 2025). ↩︎
2. C. Kaufman et al. Internet Key Exchange Protocol Version 2 (IKEv2), RFC 7296 (Oct. 2014), https://www.rfc-editor.org/pdfrfc/rfc7296.txt.pdf. ↩︎
3. DeFi Education Fund, Solana Policy Institute, Paradigm, Response to Department of the Treasury’s Request for Comment on Innovative Methods to Detect Illicit Activity Involving Digital Assets, DeFi Education Fund (Oct. 17, 2025) (public comment submitted to the U.S. Dept. of the Treasury),  https://www.defieducationfund.org/_files/ugd/84ba66_c10e175b10a7465582a39f806887efab.pdf. ↩︎
4. Platforms like Immunefi and HackenProof both broker the relationship between DeFi protocols and security researchers by hosting a platform where security researchers register and opt in to different bug bounty programs to participate in. See Bug Bounty Program, Immunefi, https://immunefi.com/bug-bounty-program/ (last visited Nov. 4, 2025); Run Bug Bounty, HackenProof, https://hackenproof.com/run-bug-bounty (last visited Nov. 4, 2025). The Security Alliance (SEAL) was established in 2024 to remedy security risks, provide legal protection for white hat hacking in the digital asset ecosystem, and help with incident response, among other initiatives. See About, Security Alliance, https://www.securityalliance.org/ (last visited Nov. 4, 2025).
   ↩︎
5. What is RISC-V and why is it important?, RISC-V International, https://riscv.org/blog/what-is-risc-v-and-why-is-it-important/ (last visited Nov. 4, 2025). ↩︎
6. Members, RISC-V International, https://riscv.org/members/ (last visited Nov. 4, 2025). ↩︎
7. Ibid. ↩︎
8. Ibid. ↩︎
9. Ibid. ↩︎
10. Letter from Mike Gallagher, Chair, & Raja Krishnamoorthi, Ranking Member, House Select Committee on the CCP, et al., to U.S. Department of Commerce (Nov. 1, 2023) https://selectcommitteeontheccp.house.gov/sites/evo-subsites/selectcommitteeontheccp.house.gov/files/evo-media-document/11.1.23-riscv-letter.pdf. ↩︎
11. Ibid. ↩︎
12. Ibid. ↩︎
13. Sujai Shivakumar & Julie Heng, Sustaining Standards Leadership: The United States Cannot Disengage from RISC-V, CSIS (April 28, 2025), https://www.csis.org/analysis/sustaining-standards-leadership-united-states-cannot-disengage-risc-v. ↩︎
14. Ibid. ↩︎
15. Standards Developing Organization, Computer Security Resource Center, NIST, https://csrc.nist.gov/glossary/term/standards_developing_organization (last visited Nov. 4, 2025). ↩︎
16. Introduction to the IETF, IETF, https://www.ietf.org/about/introduction/ (last visited Nov. 4, 2025). ↩︎
17. Ibid. ↩︎
18. Internet Engineering Steering Group, IETF, https://www.ietf.org/about/groups/iesg/ (last visited Nov. 4, 2025); IESG Members, IETF, https://www.ietf.org/about/groups/iesg/members/ (last visited Nov. 4, 2025). ↩︎
19. Nominating Committee, IETF, https://www.ietf.org/about/groups/nomcom/ (last visited Nov. 4, 2025). ↩︎
20. Scott O. Bradner, Internet Standards Process – Revision 3, RFC 2026, sec. 1.2 (Oct. 1996), https://www.rfc-editor.org/rfc/rfc2026.html. ↩︎
21. Ibid. ↩︎
22. Ibid. ↩︎
23. IETF, supra note 16. ↩︎
24. Ibid. ↩︎
25. Official Internet Protocol Standards, RFC Editor, https://www.rfc-editor.org/standards (last visited Nov. 4, 2025). ↩︎
26. Ibid. ↩︎
27. IPv6 – Google, Google, https://www.google.com/intl/en/ipv6/statistics.html#tab=ipv6-adoption (last visited Nov. 4, 2025); Adoption and Usage, Cloudfare Radar, https://radar.cloudflare.com/explorer?dataSet=http&groupBy=tls_version&filters=botClass%253DLIKELY_HUMAN (last visited Nov. 4, 2025) (showing IPv4 vs. IPv6 adoption data). ↩︎
28. Google, supra note 27. ↩︎
29. 15 U.S.C. §§ 271–272 (2024) (authorizing research, measurement, and coordination activities but no regulatory powers); H.R. Rep. No. 100-576, at 548 (1988) (Conf. Rep.), reprinted in 1988 U.S.C.C.A.N. 1547, 1851 (“The Institute will remain a non-regulatory agency of the Department of Commerce.”); Office of Mgmt. & Budget, Circular A-119, § 6(a)(2) (2016) (describing NIST as “a non-regulatory agency of the Department of Commerce”). ↩︎
30. 15 U.S.C. § 271(a). ↩︎
31. 15 U.S.C. § 272(b)(1)–(2). ↩︎
32. 15 U.S.C. §§ 271–282a (2024) (authorizing appropriations for NIST programs). ↩︎
33. About Our Funding, Open Technology Fund, https://www.opentech.fund/about/about-our-funding/ (last visited Nov. 4, 2025). ↩︎
34. Executive Order No. 14306, Sustaining Select Efforts to Strengthen the Nation’s Cybersecurity and Amending Executive Order 13694 and Executive Order 14144, 90 Fed. Reg. 24723 (June 11, 2025). ↩︎
35. Computer Security Division, NIST, https://www.nist.gov/itl/csd (last visited Nov. 4, 2025). ↩︎
36. Id.; Cybersecurity and Privacy Applications, NIST, https://www.nist.gov/itl/applied-cybersecurity/cybersecurity-and-privacy-applications (last visited Nov. 4, 2025). ↩︎

---