The following article is a guest post and opinion of Prabal Banerjee (Co-founder of Avail) and Shailey Singh (Marketing Manager and Researcher at Avail)

Imagine a world where you walk into a bank and apply for a $1 million loan. Instead of handing over your full income history and credit report, you generate a cryptographic proof confirming you meet every loan criterion without exposing actual numbers or documents. The bank verifies the proof instantly. No raw data changes hands. No paper trail for hackers to follow.

Today, for a financial institution to verify a fact—whether it’s a customer’s loan eligibility or proof of compliance—it must reveal every underlying piece of data, including sensitive personal information. That data lives in centralized systems, secured by or shared with third parties, creating an ever-expanding attack surface.

This is the paradox at the heart of modern finance: compliance demands disclosure, but disclosure erodes privacy and security. Zero-knowledge technology flips that script.

In a world of mounting cyber threats, regulatory scrutiny, and customer fatigue, zero-knowledge proofs (ZKPs) offer a better model for trust: verifiable, privacy-preserving, and future-ready. ZKPs let one party (the prover) convince another (the verifier) that a statement is true, without revealing why or exposing the underlying data.

Integrating ZK technology into traditional finance may seem futuristic, but the truth is, we need it now.

A Surge in Cyber Risk

Data privacy and security go hand in hand. The financial sector is under siege. In 2024, the average cost of a data breach for banks and insurers skyrocketed to $6.08 million—about 22% higher than the $4.88 million cross-industry average. Companies take an average of 168 days to detect and 51 more to contain these breaches, prolonging operational chaos and reputational damage.

In 2023, the financial industry accounted for 27% of all data breaches handled by Kroll—more than any other sector. These aren’t outliers; they’re bleeding-edge trends that cut into profits and erode public trust. Consider Equifax, which lost over $5 billion in market cap and 13% stock value after its 2017 breach; or Bank of America’s vendor-related breach that exposed the records of 7.6 million customers, prompting forensic investigations and intensified regulatory scrutiny.

Compliance Overload

Regulatory demands have outpaced legacy infrastructure. In the United States, Dodd‑Frank and SOX require firms to disclose detailed or near-real-time compliance data.

Europe’s MiCA adds granular reporting for crypto companies. Firms face nonstop exposure, rising complexity, and compliance fatigue. The result: bloated tech stacks, siloed data, and mounting vulnerability under constant internal and external scrutiny.

Banks Demand More Personal Data

Banks and fintechs are asking users to surrender increasing amounts of personal data: documents, income history, even biometric data, just to get started. Customer acquisition has become a leak-prone liability.

A 2023 Fenergo study found 67% of banks have lost potential clients due to clunky KYC and onboarding. Banks contact new customers an average of 10 times during onboarding, requesting countless documents, costing around $128 per customer and seeing an average 18% abandonment rate, per a 2024 report. These data-hungry paths are alienating users while making institutions data-rich and danger-rich.

Zero-Knowledge Tech: Proof Without Exposure

Zero-knowledge proofs change this calculus. ZKPs are built on decades of cryptographic research. Foundational work by researchers like Shafi Goldwasser, Silvio Micali, Oded Goldreich, Amit Sahai, and others laid the groundwork for modern zero-knowledge systems, defining both their theoretical limits and practical designs. Today, ZKPs have moved from mathematical concepts to real-world tools.

Under the hood, zero-knowledge systems rely on advanced cryptography to generate compact, verifiable proofs. No raw data ever needs to be revealed. Rules and inputs are programmatically smart-contract encoded, the proof is generated without exposing the underlying data, and the verifier receives a tamper-proof cryptographic assurance that all conditions were satisfied.

Recent breakthroughs have made these proofs fast enough for real-time use and efficient enough to scale across high-volume financial systems.

After the collapse of crypto giants like FTX, proving reserves became a top priority for crypto firms, especially exchanges. Centralized exchanges like Kraken, Gate.io, and OKX have already proven reserves without exposing sensitive details.

Traditional banks can adopt similar mechanisms to prove Basel III compliance or liquidity thresholds without ever leaking proprietary risk models.

Some already have. In 2023, Société Générale Forge explored zero-knowledge technology to enhance confidentiality in digital bond issuance (fully subscribed by AXA Investments and Generali Investments) on Ethereum L1. In March 2024, the European Banking Authority began exploring ZKPs as part of its digital compliance toolkit. Singapore’s MAS has also funded ZK-based pilots for cross-border data privacy.

The other important aspect is scale. Interbank markets process trillions daily, but most require full disclosure for settlement—from counterparties to trade details. ZK-rollups can batch thousands of trades into a single proof, offering near-instant finality without revealing anything other than what needs to be proved.

Why Now? Tech + Timing

Zero-knowledge proofs aren’t new. But what is new is that they’re finally fast, scalable, and accessible.

Proof generation speed has improved dramatically in the past two years alone. With zk-SNARKs and zk-STARKs, proofs can now be generated in seconds and verified in milliseconds—even for complex financial computations. Developers are advancing ZK tech in the context of rollup architecture acceleration, with Ethereum’s rollup-centric vision.

Tooling has matured as well. Today, developers can plug into open-source libraries like Halo2, PLONK, or zkVMs with real-world use cases. Platforms like Polygon, zkSync, StarkWare, and Scroll are already deploying ZK-powered financial apps.

Legacy institutions may face challenges in upgrading entrenched infrastructure, aligning with regulatory frameworks, building internal cryptography domain expertise, and educating teams. But these limitations are shrinking fast.

Today, the pieces are in place. The time to act is now.

Those who move early will set new standards. The new model of trust is “verify, never reveal.” Early adopters will set the standard and win the clients.

Mentioned in this article

A note about the Stateless Ethereum initiative:
Research activity has (understandably) slowed in the second half of 2020 as all contributors have adjusted to life on the weird timeline. But as the ecosystem moves incrementally closer to Serenity and the Eth1/Eth2 merge, Stateless Ethereum work will become increasingly relevant and impactful. Expect a more substantial year-end Stateless Ethereum retrospective in the coming weeks.

Let’s roll through the re-cap one more time: The ultimate goal of Stateless Ethereum is to remove the requirement of an Ethereum node to keep a full copy of the updated state trie at all times, and to instead allow for changes of state to rely on a (much smaller) piece of data that proves a particular transaction is making a valid change. Doing this solves a major problem for Ethereum; a problem that has so far only been pushed further out by improved client software: State growth.

The Merkle proof needed for Stateless Ethereum is called a ‘witness’, and it attests to a state change by providing all of the unchanged intermediate hashes required to arrive at a new valid state root. Witnesses are theoretically a lot smaller than the full Ethereum state (which takes 6 hours at best to sync), but they are still a lot larger than a block (which needs to propagate to the whole network in just a few seconds). Leaning out the size of witnesses is therefore paramount to getting Stateless Ethereum to minimum-viable-utility.

Just like the Ethereum state itself, a lot of the extra (digital) weight in witnesses comes from smart contract code. If a transaction makes a call to a particular contract, the witness will by default need to include the contract bytecode in its entirety with the witness. Code Merkelization is a general technique to reduce burden of smart contract code in witnesses, so that contract calls only need to include the bits of code that they ‘touch’ in order to prove their validity. With this technique alone we might see a substantial reduction in witness, but there are a lot of details to consider when breaking up smart contract code into byte-sized chunks.

What is Bytecode?

There are some trade-offs to consider when splitting up contract bytecode. The question we will eventually need to ask is “how big will the code chunks be?” – but for now, let’s look at some real bytecode in a very simple smart contract, just to understand what it is:

pragma solidity >=0.4.22 <0.7.0;

contract Storage {

    uint256 number;

    function store(uint256 num) public {
        number = num;
    }

    function retrieve() public view returns (uint256){
        return number;
    }
}

When this simple storage contract is compiled, it turns into the machine code meant to run ‘inside’ the EVM. Here, you can see the same simple storage contract shown above, but complied into individual EVM instructions (opcodes):

PUSH1 0x80 PUSH1 0x40 MSTORE CALLVALUE DUP1 ISZERO PUSH1 0xF JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST POP PUSH1 0x4 CALLDATASIZE LT PUSH1 0x32 JUMPI PUSH1 0x0 CALLDATALOAD PUSH1 0xE0 SHR DUP1 PUSH4 0x2E64CEC1 EQ PUSH1 0x37 JUMPI DUP1 PUSH4 0x6057361D EQ PUSH1 0x53 JUMPI JUMPDEST PUSH1 0x0 DUP1 REVERT JUMPDEST PUSH1 0x3D PUSH1 0x7E JUMP JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN JUMPDEST PUSH1 0x7C PUSH1 0x4 DUP1 CALLDATASIZE SUB PUSH1 0x20 DUP2 LT ISZERO PUSH1 0x67 JUMPI PUSH1 0x0 DUP1 REVERT JUMPDEST DUP2 ADD SWAP1 DUP1 DUP1 CALLDATALOAD SWAP1 PUSH1 0x20 ADD SWAP1 SWAP3 SWAP2 SWAP1 POP POP POP PUSH1 0x87 JUMP JUMPDEST STOP JUMPDEST PUSH1 0x0 DUP1 SLOAD SWAP1 POP SWAP1 JUMP JUMPDEST DUP1 PUSH1 0x0 DUP2 SWAP1 SSTORE POP POP JUMP INVALID LOG2 PUSH5 0x6970667358 0x22 SLT KECCAK256 DUP13 PUSH7 0x1368BFFE1FF61A 0x29 0x4C CALLER 0x1F 0x5C DUP8 PUSH18 0xA3F10C9539C716CF2DF6E04FC192E3906473 PUSH16 0x6C634300060600330000000000000000

As explained in a previous post, these opcode instructions are the basic operations of the EVM’s stack architecture. They define the simple storage contract, and all of the functions it contains. You can find this contract as one of the example solidity contracts in the Remix IDE (Note that the machine code above is an example of the storage.sol after it’s already been deployed, and not the output of the Solidity compiler, which will have some extra ‘bootstrapping’ opcodes). If you un-focus your eyes and imagine a physical stack machine chugging along with step-by-step computation on opcode cards, in the blur of the moving stack you can almost see the outlines of functions laid out in the Solidity contract.

Whenever the contract receives a message call, this code runs inside every Ethereum node validating new blocks on the network. In order to submit a valid transaction on Ethereum today, one needs a full copy of the contract’s bytecode, because running that code from beginning to end is the only way to obtain the (deterministic) output state and associated hash.

Stateless Ethereum, remember, aims to change this requirement. Let’s say that all you want to do is call the function retrieve() and nothing more. The logic describing that function is only a subset of the whole contract, and in this case the EVM only really needs two of the basic blocks of opcode instructions in order to return the desired value:

PUSH1 0x0 DUP1 SLOAD SWAP1 POP SWAP1 JUMP,

JUMPDEST PUSH1 0x40 MLOAD DUP1 DUP3 DUP2 MSTORE PUSH1 0x20 ADD SWAP2 POP POP PUSH1 0x40 MLOAD DUP1 SWAP2 SUB SWAP1 RETURN

In the Stateless paradigm, just as a witness provides the missing hashes of un-touched state, a witness should also provide the missing hashes for un-executed pieces of machine code, so that a stateless client only requires the portion of the contract it’s executing.

The Code’s Witness

Smart contracts in Ethereum live in the same place that externally-owned accounts do: as leaf nodes in the enormous single-rooted state trie. Contracts are in many ways no different than the externally-owned accounts humans use. They have an address, can submit transactions, and hold a balance of Ether and any other token. But contract accounts are special because they must contain their own program logic (code), or a hash thereof. Another associated Merkle-Patricia Trie, called the storageTrie keeps any variables or persistent state that an active contract uses to go about its business during execution.

This witness visualization provides a good sense of how important code merklization could be in reducing the size of witnesses. See that giant chunk of colored squares and how much bigger it is than all the other elements in the trie? That’s a single full serving of smart contract bytecode.

Next to it and slightly below are the pieces of persistent state in the storageTrie, such as ERC20 balance mappings or ERC721 digital item ownership manifests. Since this is example is of a witness and not a full state snapshot, those too are made mostly of intermediate hashes, and only include the changes a stateless client would require to prove the next block.

Code merkleization aims to split up that giant chunk of code, and to replace the field codeHash in an Ethereum account with the root of another Merkle Trie, aptly named the codeTrie.

Worth its Weight in Hashes

Let’s look at an example from this Ethereum Engineering Group video, which analyzes some methods of code chunking using an ERC20 token contract. Since many of the tokens you’ve heard of are made to the ERC-20 standard, this is a good real-world context to understand code merkleization.

Because bytecode is long and unruly, let’s use a simple shorthand of replacing four bytes of code (8 hexidecimal characters) with either an . or X character, with the latter representing bytecode required for the execution of a specific function (in the example, the ERC20.transfer() function is used throughout).

In the ERC20 example, calling the transfer() function uses a little less than half of the whole smart contract:

XXX.XXXXXXXXXXXXXXXXXX..........................................
.....................XXXXXX.....................................
............XXXXXXXXXXXX........................................
........................XXX.................................XX..
......................................................XXXXXXXXXX
XXXXXXXXXXXXXXXXXX...............XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX..................................
.......................................................XXXXXXXXX
XXXXXXXXXXXXXXXXXXXXXXXXXXXXX..................................X
XXXXXXXX........................................................
....

If we wanted to split up that code into chunks of 64 bytes, only 19 out of the 41 chunks would be required to execute a stateless transfer() transaction, with the rest of the required data coming from a witness.

|XXX.XXXXXXXXXXXX|XXXXXX..........|................|................
|................|.....XXXXXX.....|................|................
|............XXXX|XXXXXXXX........|................|................
|................|........XXX.....|................|............XX..
|................|................|................|......XXXXXXXXXX
|XXXXXXXXXXXXXXXX|XX..............|.XXXXXXXXXXXXXXX|XXXXXXXXXXXXXXXX
|XXXXXXXXXXXXXXXX|XXXXXXXXXXXXXX..|................|................
|................|................|................|.......XXXXXXXXX
|XXXXXXXXXXXXXXXX|XXXXXXXXXXXXX...|................|...............X
|XXXXXXXX........|................|................|................
|....

Compare that to 31 out of 81 chunks in a 32 byte chunking scheme:

|XXX.XXXX|XXXXXXXX|XXXXXX..|........|........|........|........|........
|........|........|.....XXX|XXX.....|........|........|........|........
|........|....XXXX|XXXXXXXX|........|........|........|........|........
|........|........|........|XXX.....|........|........|........|....XX..
|........|........|........|........|........|........|......XX|XXXXXXXX
|XXXXXXXX|XXXXXXXX|XX......|........|.XXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXXXX
|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXXX..|........|........|........|........
|........|........|........|........|........|........|.......X|XXXXXXXX
|XXXXXXXX|XXXXXXXX|XXXXXXXX|XXXXX...|........|........|........|.......X
|XXXXXXXX|........|........|........|........|........|........|........
|....

On the surface it seems like smaller chunks are more efficient than larger ones, because the mostly-empty chunks are less frequent. But here we need to remember that the unused code has a cost as well: each un-executed code chunk is replaced by a hash of fixed size. Smaller code chunks mean a greater number of hashes for the unused code, and those hashes could be as large as 32 bytes each (or as small as 8 bytes). You might at this point exclaim “Hol’ up! If the hash of code chunks is a standard size of 32 bytes, how would it help to replace 32 bytes of code with 32 bytes of hash!?”.

Recall that the contract code is merkleized, meaning that all hashes are linked together in the codeTrie — the root hash of which we need to validate a block. In that structure, any sequential un-executed chunks only require one hash, no matter how many there are. That is to say, one hash can stand in for a potentially large limb full of sequential chunk hashes on the merkleized code trie, so long as none of them are required for coded execution.

We Must Collect Additional Data

The conclusion we’ve been building to is a bit of an anticlimax: There is no theoretically ‘optimal’ scheme for code merkleization. Design choices like fixing the size of code chunks and hashes depend on data collected about the ‘real world’. Every smart contract will merkleize differently, so the burden is on researchers to choose the format that provides the largest efficiency gains to observed mainnet activity. What does that mean, exactly?

One thing that could indicate how efficient a code merkleization scheme is Merkleization overhead, which answers the question “how much extra information beyond executed code is getting included in this witness?”

Already we have some promising results, collected using a purpose-built tool developed by Horacio Mijail from Consensys’ TeamX research team, which shows overheads as small as 25% — not bad at all!

In short, the data shows that by-and-large smaller chunk sizes are more efficient than larger ones, especially if smaller hashes (8-bytes) are used. But these early numbers are by no means comprehensive, as they only represent about 100 recent blocks. If you’re reading this and interested in contributing to the Stateless Ethereum initiative by collecting more substantial code merkleization data, come introduce yourself on the ethresear.ch forums, or the #code-merkleization channel on the Eth1x/2 research discord!

And as always, if you have questions, feedback, or requests related to “The 1.X Files” and Stateless Ethereum, DM or @gichiba on twitter.

HodlX Guest Post  Submit Your Post

Blockchain technology has transformed the financial landscape – but as it continues to evolve, the need for enhanced privacy, scalability and security has become more apparent.

While blockchain networks like Ethereum (ETH) have made significant strides in their adoption, they still face challenges surrounding these core aspects.

Enter ZKPs (zero-knowledge proofs) – a cryptographic breakthrough that is quickly becoming a game-changer in the blockchain world.

In this article, we will explore how ZKPs are improving blockchain ecosystems by offering privacy-preserving features, enhancing scalability and enabling new use cases across industries.

Understanding ZKPs

At its core, a ZKP is a cryptographic protocol that allows one party to prove to another that a statement is true without revealing any additional information about the statement itself.

In the context of blockchain, ZKPs can be used to verify transactions or other data on a network while keeping sensitive information private.

For instance, a user could prove that they have enough funds to complete a transaction on a blockchain without disclosing the actual amount in their wallet or the details of the transaction.

This concept of privacy – coupled with the ability to verify data without exposing it – is what makes ZKPs such a powerful tool for blockchain scalability and security.

There are two primary types of ZKPs in the blockchain space.

• ZK-SNARKs (zero-knowledge succinct non-interactive argument of knowledge) – A powerful cryptographic technique that enables fast, non-interactive proofs. They are particularly useful for applications requiring scalability, such as Ethereum’s ZK-rollups.
• ZK-STARKs (zero-knowledge scalable transparent argument of knowledge) – These offer stronger security guarantees and are designed to be more scalable, as they don’t require a trusted setup, unlike ZK-SNARKs.

ZKPs in action – blockchain privacy and security

As blockchain adoption grows, privacy concerns have become one of the most pressing issues for users and regulators alike. ZKPs offer an elegant solution to this problem.

By allowing users to prove the validity of transactions without revealing any sensitive data, ZKPs help maintain privacy while still ensuring that the transaction is valid.

A good example of ZKPs in action is Zcash (ZEC), a privacy-focused cryptocurrency that leverages ZK-SNARKs to allow private transactions.

Zcash users can send funds without revealing the transaction amounts or addresses involved, making it one of the most secure and privacy-preserving blockchains in the crypto space.

In addition to privacy, ZKPs provide an extra layer of security. By ensuring that data is only validated through cryptographic proofs, they significantly reduce the risk of fraudulent or malicious activity on the network.

For enterprises and individuals looking to use blockchain technology for confidential applications, this is a huge advantage.

Scalability – how ZKPs are enhancing blockchain networks

While privacy and security are crucial, scalability remains a critical bottleneck for blockchain networks.

As DApps (decentralized applications) and transactions grow in volume, traditional blockchain networks – especially those using PoW (Proof-of-Work) – struggle to keep up with demand due to network congestion and high fees.

This is where ZK-rollups – a layer-two scaling solution based on ZKPs – come into play.

ZK-rollups aggregate large numbers of transactions into a single proof, allowing the main chain to process them more efficiently.

Since only a single proof needs to be posted on-chain, the scalability of the entire network improves dramatically, resulting in lower fees and faster transaction speeds.

Ethereum, for example, has integrated ZK-rollups as part of its broader scalability solutions through the Ethereum 2.0 upgrade.

Platforms like Loopring and zkSync have already begun utilizing ZK-rollups, significantly improving transaction throughput while maintaining the security of the Ethereum network.

The real-world adoption of ZKPs

The potential of ZKPs extends beyond just privacy and scalability. Several industry leaders and blockchain projects are already integrating ZKPs to solve real-world problems.

• Polygon – One of the most prominent layer-two solutions for Ethereum, Polygon is working on integrating ZK-rollups into its ecosystem to further improve scalability and reduce costs for DeFi users.
• StarkWare – By utilizing ZK-STARKs, StarkWare is enhancing scalability solutions for DApps and enterprise solutions.
• Optimism – While Optimism focuses on optimistic rollups, there is increasing exploration of how ZKPs can work in conjunction with optimistic rollups to improve overall system efficiency.

As these examples show, ZKPs are not just theoretical – they are actively being used to address blockchain’s most pressing challenges.

ZKPs – The future of blockchain privacy, scalability and innovation

The continued development and adoption of ZKPs will play a pivotal role in shaping the future of blockchain technology.

As more blockchain networks adopt ZKPs, we can expect to see increased privacy protections, reduced network congestion and greater scalability.

This will unlock new opportunities for DeFi (decentralized finance), gaming and enterprise applications.

Moreover, the ability to preserve privacy while maintaining full transparency will likely become a standard expectation in blockchain protocols.

ZKPs are not only advancing the usability of blockchain networks but also paving the way for a future where blockchain is used for a wide range of applications – from secure voting systems and confidential data sharing to scalable financial services.

Conclusion

ZKPs are fast becoming a cornerstone of blockchain innovation. With their ability to enhance privacy, security and scalability, ZKPs will enable the next wave of growth and adoption for blockchain technology.

As ZKPs continue to evolve, we are likely to see a transformation in the way blockchain networks operate – ushering in a more private, efficient and secure decentralized future.

For developers, investors and blockchain enthusiasts, understanding ZKPs and their applications will be key to staying ahead in the rapidly advancing world of crypto innovation.

Diksha Chawla is the founder of FinLecture, an insightful platform dedicated to making finance more accessible and understandable. With a strong academic background in business administration, Diksha is passionate about empowering individuals with the knowledge and tools they need to make informed financial decisions.

Check Latest Headlines on HodlX

Follow Us on Twitter Facebook Telegram

Check out the Latest Industry Announcements  

Disclaimer: Opinions expressed at The Daily Hodl are not investment advice. Investors should do their due diligence before making any high-risk investments in Bitcoin, cryptocurrency or digital assets. Please be advised that your transfers and trades are at your own risk, and any loses you may incur are your responsibility. The Daily Hodl does not recommend the buying or selling of any cryptocurrencies or digital assets, nor is The Daily Hodl an investment advisor. Please note that The Daily Hodl participates in affiliate marketing.

Generated Image: Midjourney

The following is a guest post by Rob Viglione, CEO of Horizen Labs.

Standards are the unsung heroes of technological innovation. They pave the way for true interoperability and establish a solid foundation for businesses to operate. A solid foundation of standards and guidelines makes it possible for builders to take a longer view and design more reliable technology.  

From HTTP for web browsing to SMTP for email, standards have catalyzed paradigm shifts that shaped the modern world. As privacy technology matures, the emergence of standards for zero-knowledge proofs (ZKPs) promises to usher in a new era for web3 and beyond.

An effort to standardize ZK is underway

The National Institute of Standards and Technology (NIST) is a U.S. government agency that focuses on developing and maintaining standards across a variety of industries, including cybersecurity, AI, healthcare, and cryptography. Operating under the Department of Commerce, NIST sets benchmarks for technical standards and measurements within the country. 

Now, as part of its Privacy-Enhancing Cryptography (PEC) initiative, NIST has set an anticipated 2025 deadline to standardize zero-knowledge proofs (ZKPs), which could be impactful for the blockchain world and beyond. 

To do this, they’ve opened a “Threshold Call” — which is an ongoing open call for researchers to submit their proposals for advanced cryptographic techniques. By doing this, the agency gathers a comprehensive set of reference material that they can use to base their analysis and standardization efforts. Essentially, it’s a way for the research community to weigh in on how these specifications and standards should be crafted, and why. 

For this open call, experts have been asked to submit and refine ZKP schemes to ensure consistency, security, and usability across applications. Without these standards, ZKPs risk becoming a fragmented patchwork of solutions as adoption skyrockets. 

Standards unlock new eras of technological growth

With formal standards in place, we can build trust and interoperability in fields like blockchain, finance, and identity verification, much like HTTP did for web browsing. 

HTTP established the internet as we know it, by creating a standardized way for computers to communicate and transfer data and multimedia. With HTTP, users could now visit different websites using any browser, operating system, or device. It also unlocked the ability to use hyperlinks, making the internet interactive and easy for anyone to navigate. 

Before HTTP, the internet was largely text-based and centered around a command-line interface. Used by academics and researchers, users could navigate to files and information by entering commands, but there wasn’t a graphical interface or hyperlinks to jump between pages. It was basically just a limited network of computers sharing information between each other. Once we had standards in place to make the internet accessible for all, the entire world started to wrap their minds around the World Wide Web, kicking off the dotcom era that fostered Amazon and Google.

This is the level of standardization that we need for ZK cryptography, as we move fully into the web3 era. 

NIST has collaborated with the ZKProof initiative since 2019, as a way of supporting the development of open reference material on zero-knowledge proofs. The agency’s research team is also setting guidelines around what ZKPs can and cannot be used for. For instance, ZKPs are ideal for proving the identity of a person without revealing anything else about them, but they aren’t suitable for opinions. They can only be used for verifiable statements. 

The team is also maintaining a community reference with relevant terms, examples, and recommendations, to help bring ZK down to earth for anyone who wants to study this transformative technology. 

Looking forward to 2025 and beyond

Formal standards will accelerate enterprise adoption of ZK technology by reducing risk and fostering interoperability. Early adopters like Horizen Labs are laying the groundwork for this transition, creating a foundation for larger companies to build on.

With standards paving the way, zero-knowledge proofs could become the backbone of a more private, secure, and interoperable digital future. By participating in NIST’s standardization efforts, the cryptographic community can ensure ZKP technology is ready to meet the demands of a rapidly evolving, AI-driven world. This is our chance to define not just the future of web3, but the future of trust itself.

If you have a ZKP scheme or research to contribute, or you’d like to support NIST’s public analysis, you can participate in the standardization effort here.