Ethereum can process roughly 15 transactions per second. That is less than a single Starbucks checkout line. Rollups are the technology that lets Ethereum handle thousands of transactions per second without sacrificing the security that makes it valuable in the first place. They work by executing transactions off chain and posting compressed proofs back to Ethereum, turning the base layer into a settlement court rather than a transaction processor.

The standard narrative says that rollups make Ethereum faster. This is technically true but misleading. Ethereum itself does not get faster. It still produces a block every 12 seconds. It still processes roughly 15 transactions per second on the base layer. Nothing about Ethereum’s consensus or execution changes when a rollup deploys.

What changes is where the work happens. Rollups move transaction execution off the Ethereum mainnet and onto a separate chain that can process transactions much faster because it does not need thousands of validators to agree on every state change. The rollup then compresses the results and posts them back to Ethereum, where they are verified and made permanent.

The analogy that most explanations use is a court system: the rollup handles the day to day transactions (the cases), and Ethereum serves as the court of final appeal (the judge). This analogy is useful but incomplete. The more precise framing is that rollups convert Ethereum from a transaction processor into a data availability and verification layer. The base chain stops doing the work and starts checking the work.

Understanding why this matters requires understanding what makes Ethereum slow in the first place, and why the obvious solutions do not work.

Why Ethereum cannot simply increase its throughput

Ethereum processes approximately 15 transactions per second. The intuitive fix is to increase the block size or reduce the block time, allowing more transactions per block or more blocks per unit of time. Every first generation blockchain project that tried this approach discovered the same problem: larger blocks require more powerful hardware to validate, which prices out smaller node operators, which concentrates validation among fewer entities, which undermines decentralization.

This is the blockchain trilemma. You can optimize for any two of three properties (security, decentralization, throughput) but improving the third requires sacrificing one of the others. Increasing Ethereum’s block size would improve throughput at the cost of decentralization. Reducing the validator count would improve throughput at the cost of security.

Rollups sidestep the trilemma by separating execution from verification. The rollup chain handles execution with a small number of operators, achieving high throughput. Ethereum handles verification and data availability with its full validator set, maintaining security and decentralization. Neither chain compromises, because each is optimized for a different function.

This is not a theoretical argument. Solana, which chose to optimize for throughput over accessibility, requires validators to run hardware costing thousands of dollars and processes blocks that are hundreds of megabytes. Ethereum validators can run on a consumer laptop. The rollup architecture lets Ethereum achieve Solana’s throughput without Solana’s hardware requirements by moving execution to a separate layer.

How optimistic rollups work

Optimistic rollups are named for their core assumption: transactions are assumed to be valid unless proven otherwise.

The process starts with a sequencer, a node operated by the rollup team that collects user transactions, orders them, and executes them in batches. The sequencer produces a new rollup state after each batch, just as Ethereum produces a new state after each block.

Instead of requiring every validator to re-execute every transaction, the optimistic rollup posts the batch data to Ethereum and publishes a state root (a cryptographic hash of the rollup’s state after executing the batch). This state root is accepted as correct unless someone challenges it.

The challenge mechanism is the fraud proof system. During a challenge window, typically seven days, anyone can examine the batch data posted to Ethereum, re-execute the transactions locally, and compare their result to the published state root. If the results differ, the challenger submits a fraud proof to a smart contract on Ethereum, which re-executes the disputed transaction on chain and determines who is correct.

If the fraud proof shows that the sequencer published an incorrect state root, the sequencer’s staked collateral is slashed, the incorrect state root is reverted, and the challenger receives a reward. If no one challenges the state root within the challenge window, it is finalized on Ethereum and becomes the canonical state of the rollup.

This design is elegant because it moves the expensive work (re-execution and verification) off the critical path. In the normal case, where the sequencer is honest, no on chain re-execution happens at all. The cost of operating the rollup reduces to posting compressed batch data to Ethereum, which is dramatically cheaper than executing every transaction on the base layer.

Arbitrum and Optimism are the two largest optimistic rollups. Arbitrum uses an interactive dispute resolution protocol that narrows the disputed computation down to a single instruction before re-executing it on chain, minimizing the on chain gas cost of fraud proofs. Optimism uses a non-interactive fraud proof system where the entire disputed transaction is re-executed in a single on chain step.

Base, built by Coinbase using the OP Stack (Optimism’s open source framework), has become the fastest growing rollup by transaction volume, driven by consumer applications and the integration with Coinbase’s user base.

How ZK rollups work

ZK rollups take the opposite approach: they prove correctness up front rather than assuming it.

After the sequencer executes a batch of transactions, a prover generates a cryptographic validity proof (typically a zk-SNARK or zk-STARK) that mathematically demonstrates the batch was executed correctly. This proof, along with the batch data, is posted to a verifier contract on Ethereum. The verifier checks the proof, which is computationally cheap and takes constant time regardless of how many transactions the batch contains.

The advantage is finality. There is no seven day challenge window. As soon as the proof is verified on Ethereum, the batch is finalized. Users can withdraw assets from a ZK rollup to Ethereum in minutes rather than waiting a week.

The disadvantage is cost. Generating a validity proof for a complex batch of transactions requires significant computational resources. ZK proof generation is a mathematically intensive process that can take minutes for large batches and requires specialized hardware. This cost is amortized across all transactions in the batch, but it adds a per-batch overhead that optimistic rollups avoid.

ZK rollups are also more difficult to build. Optimistic rollups can support the same virtual machine as Ethereum (the EVM) with relatively minor modifications, which means existing Solidity smart contracts work with little or no changes. ZK rollups historically required developers to write contracts in specialized languages like Cairo (used by StarkNet) because the EVM’s instruction set was not designed for efficient zero-knowledge proof generation.

This gap is closing. zkSync Era and Polygon zkEVM have implemented EVM-compatible ZK rollups that can execute standard Solidity contracts, though with varying degrees of compatibility. Scroll, another ZK rollup, aims for full EVM equivalence, meaning contracts deployed on Ethereum can be deployed on Scroll without any modification.

Blobs and the Dencun upgrade: the economics shift

Before March 2024, rollups posted their batch data as calldata in Ethereum transactions. Calldata is stored permanently by every Ethereum node, which makes it expensive. A typical rollup batch cost $500 to $2,000 in calldata fees during periods of high Ethereum congestion.

The Dencun upgrade introduced EIP-4844, which created a new data type called blobs. Blobs are large chunks of data (approximately 128 KB each) that are attached to Ethereum transactions but are only stored temporarily, for approximately 18 days, rather than permanently. This makes them dramatically cheaper than calldata.

The impact was immediate and measurable. Transaction fees on Arbitrum dropped from an average of $0.25 to under $0.01. Fees on Base dropped to fractions of a cent. The cost of posting a rollup batch to Ethereum fell by more than 90%.

This matters because it changes the economic equation for rollup adoption. When layer 2 transactions cost $0.25, only users with transactions above a certain value threshold would choose the rollup over a competing chain with lower base fees. When layer 2 transactions cost $0.001, the cost advantage of competing chains largely disappears, and the security advantage of Ethereum settlement becomes the deciding factor.

Blobs are the first step toward full danksharding, a future upgrade that will increase the number of blobs per block from the current target of three to 64 or more. Each step in this progression further reduces rollup costs and increases the data throughput available for layer 2 settlement on Ethereum.

The sequencer centralization problem

Almost every major rollup today runs a single sequencer operated by the rollup team. Arbitrum’s sequencer is run by Offchain Labs. Optimism’s sequencer is run by OP Labs. Base’s sequencer is run by Coinbase.

This centralization creates several risks. If the sequencer goes down, the rollup halts. If the sequencer censors certain transactions, users cannot interact with the rollup normally. If the sequencer reorders transactions to extract MEV, users pay a hidden tax.

Rollup teams defend this centralization as a temporary measure. Decentralizing the sequencer, by introducing a rotating set of sequencers or using a shared sequencing layer, is on every major rollup’s roadmap. But roadmaps are not deployments.

The mitigation is forced inclusion. Most rollups include a mechanism that allows users to submit transactions directly to the Ethereum base layer, bypassing the sequencer entirely. If the sequencer censors your transaction, you can force it through the rollup’s on chain contract. This process is slower and more expensive than going through the sequencer, but it prevents permanent censorship.

The degree to which forced inclusion actually works in practice, under the time constraints and gas costs of real world usage, is a meaningful differentiator between rollups. L2BEAT, the primary independent tracker of rollup security properties, rates each rollup on the maturity of its forced inclusion mechanism along with several other security criteria.

The fragmentation problem

Ethereum’s rollup strategy has succeeded in creating scalable execution environments. It has also created a fragmentation problem that did not exist before rollups.

A user with assets on Arbitrum cannot directly use them on Base. A DeFi protocol on Optimism has separate liquidity from the same protocol on zkSync. An NFT minted on StarkNet cannot be sold on a marketplace running on Scroll.

Each rollup is its own chain with its own state, its own bridge to Ethereum, and its own ecosystem of applications. Moving assets between rollups requires bridging, which introduces delay (seven days for optimistic rollup withdrawals to Ethereum), cost (gas fees on both the source and destination chains), and risk (bridge smart contract vulnerabilities).

This is not merely an inconvenience. It is a structural problem that undermines the network effects that make Ethereum valuable. If liquidity is split across 30 rollups, no single rollup has the depth of liquidity that Ethereum mainnet had when it was the primary execution environment.

Solutions are being developed. Shared sequencing layers like Espresso aim to coordinate transaction ordering across multiple rollups, enabling atomic cross-rollup transactions. Interoperability protocols like Chainlink CCIP and LayerZero provide messaging layers that let rollups communicate. ERC-7683, a cross-chain intent standard, aims to standardize how users express cross-rollup transfers.

None of these solutions are mature enough to eliminate fragmentation today. Whether the rollup ecosystem converges on a small number of dominant chains or remains fragmented across dozens is an open question with significant implications for where users, developers, and liquidity settle.

The security model differs in more subtle ways as well. In an optimistic rollup, security depends on at least one honest verifier watching the chain and submitting fraud proofs when needed. If every verifier is offline or colluding, invalid state transitions could be finalized after the challenge window closes. In practice, multiple independent verifiers monitor every major optimistic rollup, and the economic incentive to catch fraud (the challenger receives slashed collateral) makes this attack expensive to sustain. But the theoretical requirement is weaker than a ZK rollup, where the mathematical proof itself guarantees correctness regardless of who is watching.

The user experience implications of rollup choice extend beyond fees and finality. Wallet support, token availability, and application deployment all vary across rollups. A user who bridges assets to a rollup with limited DeFi protocol deployment may find their capital stranded in an ecosystem with few productive uses. The interoperability problem compounds this: moving assets back to Ethereum or to a different rollup incurs additional bridging fees and time delays that can negate the cost savings that attracted the user to the rollup in the first place.

What this does not cover

This article does not cover the internal architecture of specific rollup virtual machines. The differences between Arbitrum Nitro, the OP Stack, and StarkNet’s Cairo VM are significant and affect developer experience, performance, and security properties. Each deserves dedicated analysis.

This article does not cover validiums and volitions, which are rollup variants that post data to a separate data availability layer rather than to Ethereum. These systems trade some of Ethereum’s security guarantee for lower costs, and the tradeoffs are nuanced.

This article does not address the token economics of rollup governance. ARB, OP, STRK, and ZK tokens each have different governance, staking, and incentive structures. Whether rollup tokens accrue value to holders or function primarily as governance instruments is an active debate with implications for investment decisions.

Practical checks before choosing a rollup

Check the rollup’s security stage on L2BEAT. L2BEAT classifies rollups into three stages based on the maturity of their proof systems, upgrade mechanisms, and governance. Stage 0 rollups rely heavily on trust in the rollup team. Stage 1 rollups have functional proof systems but retain upgrade keys. Stage 2 rollups have fully trustless proof systems with minimal centralized control. Most major rollups are still at Stage 0 or Stage 1 as of mid 2026.

Understand the withdrawal time. Optimistic rollup withdrawals to Ethereum take approximately seven days due to the fraud proof challenge window. Fast bridge services can accelerate this by fronting the funds, but they charge a fee and introduce counterparty risk. ZK rollup withdrawals can complete in minutes once the validity proof is verified. This difference matters if you need rapid access to your assets on Ethereum mainnet.

Verify the forced inclusion mechanism. If the sequencer goes down or censors your transaction, can you force your transaction through the on chain contract? Check whether the rollup has a functioning forced inclusion mechanism and how long the delay is. A rollup without forced inclusion is a centralized chain with Ethereum branding.

Compare actual transaction costs. Rollup fees vary based on the rollup’s compression efficiency, batch frequency, and the current price of Ethereum blob space. Use a rollup fee tracker to compare the actual cost of common operations (token transfer, swap, contract deployment) across rollups at the time you plan to use them, rather than relying on historical averages.

Check the ecosystem. The cheapest rollup is not useful if the application you need is on a different rollup. Verify that the DeFi protocols, NFT marketplaces, or wallet infrastructure you plan to use are deployed and liquid on the rollup you choose.

Disclaimer: This article is for informational and educational purposes only. It does not constitute financial, investment, or legal advice. Cryptocurrency markets are volatile and carry significant risk. Always conduct your own research before making investment decisions.

You can prove you are over 18 without revealing your birthday. You can prove you have enough money for a transaction without revealing your balance. You can prove a computation was performed correctly without revealing the inputs. Zero-knowledge proofs make all of this possible, and they are quietly becoming the most important cryptographic primitive in blockchain since the hash function.

Most introductions to zero-knowledge proofs start with the Ali Baba cave analogy, where someone proves they know the secret word to open a door by consistently exiting from the side a verifier requests, without ever revealing the word. The analogy is charming and completely useless for understanding why ZK proofs matter in practice. It tells you that such a proof is possible. It does not tell you why anyone would need one on a blockchain.

The practical starting point is simpler. Every blockchain faces the same tension: transparency enables trust, but transparency also destroys privacy. Bitcoin’s ledger is public. Every transaction, every balance, every address is visible to anyone. Ethereum is the same. This transparency is what makes the system auditable and trustworthy, but it also means that anyone who learns which address belongs to you can see every transaction you have ever made, every token you hold, and every protocol you have interacted with.

Zero-knowledge proofs resolve this tension. They let you prove facts about your data without revealing the data itself. You can prove your account balance exceeds a threshold without revealing the exact balance. You can prove a transaction is valid without revealing the sender, recipient, or amount. You can prove you are not on a sanctions list without revealing your identity.

The mathematics behind this are deep. The applications are immediate.

The three properties every ZK proof must have

Every zero-knowledge proof system must satisfy three properties, and understanding them is essential for evaluating any ZK-based protocol.

Completeness. If the statement is true and both the prover and verifier follow the protocol, the verifier will always be convinced. A valid proof never fails to verify. If you genuinely know the secret, the proof will always work.

Soundness. If the statement is false, no cheating prover can convince the verifier that it is true, except with negligible probability. A dishonest prover cannot fabricate a valid proof. The probability of a false proof passing verification is so small (typically less than one in 2^128) that it is effectively impossible.

Zero-knowledge. The verifier learns nothing beyond the fact that the statement is true. The proof does not leak any information about the secret itself, any intermediate computation, or any data used to generate the proof. The verifier’s knowledge after seeing the proof is identical to what it would be if someone simply told them the statement was true.

The third property is what makes ZK proofs useful rather than merely correct. Standard digital signatures prove that a message was signed by a specific key, but they reveal the message content. Standard hash commitments prove that a value was committed, but they reveal the value when opened. ZK proofs prove that a relationship holds between secret values without revealing those values at any point.

How zk-SNARKs and zk-STARKs differ

The two dominant ZK proof systems in blockchain are zk-SNARKs and zk-STARKs. They solve the same problem with different tradeoffs.

zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Arguments of Knowledge) produce small proofs that are fast to verify. A typical zk-SNARK proof is around 200 to 300 bytes and can be verified on chain for approximately 200,000 to 300,000 gas on Ethereum. The verification time is constant regardless of how complex the computation being proved is. A proof that verifies a single transaction takes the same time to check as a proof that verifies ten thousand transactions.

The cost of this succinctness is a trusted setup. Most zk-SNARK systems require a one time ceremony where random parameters are generated and the randomness is destroyed afterward. If the randomness from this ceremony is not properly destroyed, an attacker could forge proofs. Zcash conducted one of the most elaborate trusted setup ceremonies in cryptographic history (the “Powers of Tau” ceremony) involving hundreds of participants worldwide, where the security assumption is that at least one participant honestly destroyed their randomness.

Newer SNARK systems like PLONK and Halo 2 have reduced or eliminated the trusted setup requirement, but the perception persists. Some projects avoid SNARKs specifically because of the trusted setup concern, even when the implementations they would use do not require one.

zk-STARKs (Zero-Knowledge Scalable Transparent Arguments of Knowledge) eliminate the trusted setup entirely. They derive their security from hash functions rather than elliptic curve assumptions, which makes them transparent (no secret parameters) and theoretically quantum resistant (hash based cryptography is believed to be secure against quantum computers, while elliptic curve cryptography is not).

The tradeoff is size. STARK proofs are significantly larger than SNARK proofs, typically tens to hundreds of kilobytes compared to hundreds of bytes. On a blockchain where data storage costs gas, larger proofs mean higher verification costs. StarkWare, the primary developer of STARK technology, addresses this by using recursive proof composition: proving that a proof is valid, then proving that the proof of the proof is valid, compressing the final on chain footprint.

In practice, the distinction matters less than it did five years ago. Modern proof systems increasingly blend techniques from both families, and the engineering focus has shifted from which proof system to use to how fast the prover can generate proofs and how cheaply the verifier can check them.

ZK proofs for blockchain scaling

The scaling application of ZK proofs is conceptually straightforward. A rollup executes a batch of transactions off chain, generates a proof that the batch was executed correctly, and posts the proof to Ethereum. The Ethereum verifier contract checks the proof in a single operation and accepts the new state.

What makes this powerful is the asymmetry between proving and verifying. Generating the proof for a batch of 10,000 transactions might take a powerful machine several minutes. Verifying the proof takes a fraction of a second and costs a fixed amount of gas regardless of how many transactions are in the batch. This asymmetry is what allows ZK rollups to compress thousands of transactions into a single Ethereum verification.

The major ZK rollups each take a different approach to this architecture.

zkSync Era uses a custom virtual machine (zkEVM) that is compatible with Solidity at the language level but compiles to a different instruction set optimized for ZK proof generation. Existing Ethereum contracts can be recompiled for zkSync with minimal changes.

StarkNet uses the Cairo programming language and STARK proofs. Cairo is a purpose-built language designed specifically for provable computation, which gives it performance advantages but requires developers to learn a new language and paradigm.

Polygon zkEVM aims for EVM equivalence, meaning it can execute the same bytecode as Ethereum without recompilation. This maximizes compatibility but introduces engineering complexity in making every EVM opcode provable.

Scroll also targets full EVM equivalence and uses a community-driven approach to its zkEVM implementation, with the goal of being the most Ethereum-compatible ZK rollup.

The competition between these approaches is ultimately a competition between compatibility and performance. The more compatible a ZK rollup is with existing Ethereum tooling, the easier it is for developers to migrate. The more the rollup optimizes its instruction set for provability, the faster and cheaper its proofs become.

ZK proofs for privacy

The privacy application is where ZK proofs become most consequential and most controversial.

A standard Ethereum transaction reveals the sender address, the recipient address, the amount transferred, and the smart contract called. This information is permanently public. Chain analysis firms like Chainalysis and Elliptic have built entire businesses on tracing transaction flows across the transparent ledger, linking addresses to real world identities through exchange KYC data, known entity labels, and behavioral patterns.

ZK privacy protocols break this chain of visibility. In a ZK-based private transaction, the user generates a proof that their transaction is valid (the sender has sufficient funds, no double spending occurs, the amounts balance) without revealing who sent it, who received it, or how much was transferred. The proof is posted on chain and verified by the network, but the underlying transaction details remain encrypted.

Zcash was the first major implementation of this concept, launching in 2016 with shielded transactions using zk-SNARKs. A Zcash user can choose between transparent transactions (identical to Bitcoin’s public ledger) and shielded transactions (where the sender, recipient, and amount are hidden behind a ZK proof). In practice, shielded transaction adoption on Zcash has been lower than proponents hoped, with the majority of ZCash transactions still using the transparent pool.

Newer protocols are building programmable privacy, where not just token transfers but arbitrary smart contract logic can execute privately. Aztec Network is building a privacy-first layer 2 on Ethereum where all transactions are private by default. Aleo is building a layer 1 blockchain with native ZK support for private smart contracts. Both use ZK proofs to verify state transitions without revealing the computation or data involved.

The potential for privacy extends beyond individual transactions. ZK proofs can enable private voting (prove you voted without revealing your choice), private identity verification (prove you are a citizen of a specific country without revealing your passport number), and private DeFi (provide liquidity to a pool without revealing your address or position size).

The regulatory collision

Privacy in crypto occupies a contested legal space that is still being defined.

In August 2022, the U.S. Treasury’s Office of Foreign Assets Control (OFAC) sanctioned Tornado Cash, an Ethereum-based mixer that used ZK proofs to break the link between deposit and withdrawal addresses. The sanctioning of open source smart contract code, rather than a person or company, was unprecedented and sent shockwaves through the crypto privacy community.

In May 2024, Alexey Pertsev, one of Tornado Cash’s developers, was convicted by a Dutch court of money laundering facilitation. The conviction established a legal precedent that writing privacy-preserving code can carry criminal liability if the tool is used for illicit purposes, regardless of whether the developer personally facilitated the illegal activity.

These actions have shaped the direction of ZK privacy development. The current generation of privacy protocols is building around regulatory constraints rather than ignoring them.

Selective disclosure allows a user to prove specific facts about their identity or transaction history without revealing everything. A user could prove they passed KYC with a licensed exchange, prove they are not on the OFAC sanctions list, or prove their funds did not originate from a sanctioned address, all using ZK proofs that reveal nothing beyond the specific claim being verified.

Privacy pools, a concept formalized by Vitalik Buterin and others, allow users to prove that their withdrawal from a privacy set belongs to a clean subset of deposits. Instead of mixing all deposits together indiscriminately, the protocol maintains association sets that exclude known illicit addresses. Users prove membership in the clean set without revealing which specific deposit they are withdrawing.

Whether these compromises satisfy regulators remains to be seen. The fundamental tension, that privacy and surveillance are architecturally incompatible, will not be resolved by technology alone. ZK proofs give policymakers a tool they have never had before: the ability to verify compliance without requiring disclosure. Whether they choose to use it is a political question, not a cryptographic one.

The proving cost has concrete implications for which applications adopt ZK technology first. High value financial transactions, where the cost of generating a proof is negligible relative to the transaction size, have been the earliest adopters. Institutional cross-chain transfers, large DeFi positions, and enterprise settlement systems can absorb a proving cost of several dollars per transaction without affecting their economics. Consumer applications, where individual transactions may be worth only a few dollars, need proving costs to fall by another order of magnitude before ZK privacy becomes practical for everyday use. The hardware acceleration efforts by companies building ZK-specific ASICs are directly targeting this cost barrier.

The convergence of scaling and privacy applications is perhaps the most underappreciated aspect of ZK technology. A ZK rollup that processes transactions privately would combine the throughput benefits of off chain execution with the confidentiality benefits of encrypted state transitions. Users would get fast, cheap transactions that are also invisible to chain analysis. Several projects, including Aztec and Polygon Miden, are building exactly this combination, though the engineering complexity of merging both capabilities into a production system remains substantial.

What this does not cover

This article does not cover the mathematics of polynomial commitments, elliptic curve pairings, or Fiat-Shamir transformations that underpin ZK proof systems. Understanding these requires graduate level abstract algebra and is not necessary for evaluating ZK-based protocols as a user or investor.

This article does not cover ZK machine learning (zkML), an emerging field that uses ZK proofs to verify that a machine learning model produced a specific output without revealing the model’s weights or training data. This application is experimental and its practical implications are still being studied.

This article does not address the hardware acceleration race for ZK proof generation. Companies like Cysic, Ingonyama, and Fabric Cryptography are building custom ASICs and FPGAs specifically for ZK proving, which could reduce proving costs by orders of magnitude. The hardware landscape is moving too quickly for static analysis.

Practical checks before using a ZK-based protocol

Verify the proof system’s audit status. ZK proof systems are mathematically complex and implementation errors can be catastrophic. A bug in the circuit (the mathematical representation of the computation being proved) could allow an attacker to forge proofs and mint tokens or steal funds. Check whether the proof system and its circuits have been audited by firms specializing in ZK cryptography, not just general smart contract auditors.

Understand what is actually private. Not all ZK-based protocols provide the same level of privacy. Some hide transaction amounts but reveal addresses. Some hide addresses but reveal amounts. Some hide everything. Read the protocol’s documentation to understand exactly what information is concealed and what remains visible. Metadata such as transaction timing, gas patterns, and interaction frequency can often deanonymize users even when the core transaction data is hidden.

Check the trusted setup status. If the protocol uses zk-SNARKs, determine whether it required a trusted setup and how that setup was conducted. Multi-party computation ceremonies with hundreds of participants are more trustworthy than small ceremonies with a handful of known entities. Protocols using STARKs, PLONK with universal setup, or Halo 2 do not require trusted setups at all.

Assess the regulatory risk. Privacy protocols operate in a legally uncertain environment. Consider whether the protocol has a compliance mechanism (selective disclosure, privacy pools, opt-in compliance proofs) and whether that mechanism has been tested against actual regulatory scrutiny. Using a privacy protocol that is later sanctioned could complicate your ability to move or sell assets.

Test the proving time. Generating a ZK proof is computationally intensive. On a mobile device, proving a simple transaction might take 30 seconds to two minutes. On a desktop, it might take a few seconds. If the proving time is too long for your use case, the protocol may not be practical for frequent transactions. Some protocols offload proving to dedicated servers, which is faster but introduces a trust assumption that the server does not learn your private data.

Disclaimer: This article is for informational and educational purposes only. It does not constitute financial, investment, or legal advice. Cryptocurrency markets are volatile and carry significant risk. Always conduct your own research before making investment decisions.

Riot Platforms (RIOT) surged more than 20% before the start of U.S. equity trading on Tuesday after the bitcoin BTC$64,014.33 miner said it signed a $9.1 billion deal with “a leading frontier AI lab,” accelerating its transformation into a provider of infrastructure for the artificial intelligence industry.

The 20-agreement with the company, identified as Anthropic by Bloomberg, covers 191 megawatts of computing capacity at Riot’s Rockdale, Texas, campus.

Once focused almost entirely on bitcoin mining, Riot exemplifies an industry-wide pivot toward AI infrastructure, with long-term leases providing steadier revenue than the volatile flows from approving blocks on Bitcoin.

Miners control large sites with established grid connections, land and cooling systems, allowing them to serve power-hungry AI customers faster than developers starting from scratch. Anthropic recently signed a six-year, $10 billion contract with Volta Infra for computing capacity at a site in Norway operated by bitcoin miner Bitdeer.

Deployment at the Riot sites starts in December 2027, with the full buildout expected by June 2028. Two five-year extension options could increase total contract revenue to $16.1 billion. Riot projects the base term will generate between $7.3 billion and $8.2 billion in cumulative net operating income.

Several U.S. states have also pursued age-verification requirements, restrictions on addictive features, and other regulations related to children and social media. At least 20 states have enacted laws addressing young users’ social media usage, although many face legal challenges. In July, Illinois enacted a law prohibiting platforms from using minors’ viewing histories or data on their devices to curate feeds. The law, which will take effect in 2028, also restricts notifications between 10 p.m. and 7 a.m. and requires stronger privacy settings for minors. At least 40 states and Puerto Rico considered more than 300 measures related to children and social media during the 2026 legislative session, with 10 states enacting new laws or adopting resolutions.

Measures around the world have faced significant pushback from the tech industry. NetChoice, a trade association representing major tech companies including Meta and TikTok, has challenged state laws on grounds of free speech and privacy. Courts in several states, including Arkansas, California, Colorado, Georgia, Nebraska and Virginia, have temporarily or permanently blocked all or parts of laws around online safety. Most of those cases are ongoing. Other states, including Florida, Mississippi, Tennessee and South Carolina, also face ongoing litigation over their measures.

South Korea is preparing to expand its crypto “Travel Rule” so that it applies to virtually all on-chain transfers between registered virtual asset service providers (VASPs), rather than only transactions above a set value. The change removes the current 1 million won threshold (about $700), a step aimed at closing an obvious loophole: users splitting transfers into smaller chunks to stay under reporting and information-sharing requirements.

According to a cabinet decision approving amendments to the Enforcement Decree of South Korea’s Act on Reporting and Using Specified Financial Transaction Information, the updated rules will also add tighter anti-money laundering (AML) obligations around transfers that involve foreign exchanges and personal wallets, where authorities have said existing controls have been exploited.

Key takeaways

• South Korea’s Travel Rule will apply to all transfers between registered crypto VASPs, removing the 1 million won transaction cutoff.
• Receiving platforms must obtain sender and recipient information and can request missing data or reject transfers if required information is unavailable.
• New AML requirements extend to transfers involving overseas crypto exchanges and personal wallets, including risk-based acceptance rules.
• Platforms will need suspicious transaction monitoring for transfers of at least 10 million won involving foreign exchanges or personal wallets.
• The expanded framework starts at staggered timelines: some VASP registration updates take effect Aug. 20, while other transfer-related requirements begin six months after promulgation.

Travel Rule expanded with threshold removed

South Korea’s Financial Intelligence Unit (FIU) said the main driver behind the amendment is the risk that users can circumvent the Travel Rule by breaking up activity into smaller transfers that fall below the prior reporting threshold. The cabinet-approved changes remove the value limit entirely, making information-sharing obligations standard across the board for covered transfers.

The FIU cited an example intended to illustrate how the threshold can be gamed. It described a case where a user purchased Tether USDt (USDT) after depositing roughly 200 million won into a crypto exchange, then executed 216 withdrawals, each valued below 1 million won. By keeping each withdrawal under the cutoff, the user aimed to reduce exposure to the Travel Rule’s information-sharing requirements.

Under the revised framework, the Travel Rule will cover all transfers between registered crypto service providers, regardless of amount. This matters for compliance teams and operational workflows: firms can no longer assume that smaller transfers are “out of scope,” and they will need to ensure their transaction processing can consistently handle sender/recipient information requirements at higher volumes and smaller denominations.

What receiving platforms must do

The amendments specify operational responsibilities for counterparties receiving transfers. Receiving VASPs will be required to obtain sender and recipient information. If required data is incomplete or missing, receiving platforms may request the missing information—or reject the transaction when necessary details cannot be obtained.

For users, this raises the prospect of more frequent transfer friction, particularly around transactions where counterparties fail to provide the expected information. For exchanges and wallet providers, it emphasizes the importance of internal controls and technical readiness—especially where transfers cross different service providers that may vary in how they capture and transmit required details.

The rule change is also designed to standardize accountability across the ecosystem. Instead of relying on a threshold that can be optimized around, the updated approach pushes toward comprehensive compliance for covered counterparties.

Overseas exchanges and personal wallets face new AML controls

Beyond expanding the Travel Rule, the decree introduces new AML requirements for transfers that involve overseas crypto exchanges and personal wallets. Registered local VASPs will need to apply a risk-based approach to decide which transfers they allow based on the risk posed by the counterparty.

In practice, the amendments indicate that transfers to low-risk overseas exchanges will be permitted. However, transfers involving other foreign exchanges and personal wallets are generally allowed only when the sender and recipient are the same person—an effort to reduce anonymity and inter-personal laundering risks.

Where counterparties are assessed as high risk, transactions will be prohibited. This creates a compliance obligation that goes beyond simple eligibility checks: firms will have to maintain and update risk assessments tied to specific counterparties, and ensure those assessments are reflected in transaction controls.

The decree also requires crypto platforms to establish their own suspicious transaction monitoring systems for transfers worth at least 10 million won that involve foreign exchanges or personal wallets. Authorities said suspected money laundering involving overseas exchanges and personal wallets has risen because gaps in existing AML rules for such transfers have been exploited.

Even though the new Travel Rule applies to transfers between registered local providers, the AML changes broaden the compliance perimeter. They are aimed at the points where value can flow into or out of Korea’s regulated rails through foreign venues or self-custody arrangements.

Stronger registration standards and phased implementation

In addition to transaction-specific requirements, the decree strengthens the registration framework for crypto service providers. The amendments include requirements related to financial health, internal controls, staffing, and infrastructure standards, while also expanding scrutiny of major shareholders. This signals an intent to raise baseline operational quality and governance across the sector, not only to improve transaction monitoring.

The VASP registration provisions will take effect Aug. 20. However, existing providers will receive an additional year to comply with some of the financial, staffing, infrastructure, and internal control requirements—suggesting a transition period intended to reduce abrupt compliance shocks for incumbents.

Meanwhile, the expanded Travel Rule and the other transfer-related AML requirements will take effect six months after the decree is promulgated. That timing means exchanges and wallet providers will need to prepare their systems ahead of the compliance start date, including data capture and transfer handling logic required for sender/recipient information, as well as monitoring and risk assessment processes for cross-border and self-custody related activity.

For market participants, the key watch items are how risk assessments for overseas counterparties are implemented and how receiving platforms handle missing information in practice—because those operational details will determine whether the new rules mainly improve traceability or also introduce more frequent transaction rejections for edge cases.

Smart contracts are powerful, but they are also blind. They cannot see prices, read weather data, or verify that a payment arrived in a bank account. Oracles are the infrastructure that connects blockchains to the outside world, and the security of more than $200 billion in DeFi depends on them working correctly.

Most explanations of blockchain oracles start with a definition and stop there. They tell you that an oracle is a bridge between a blockchain and the outside world, which is true but insufficient. It is like saying a power grid is a bridge between a generator and a light switch. Technically correct. Practically useless for understanding why the grid fails, who pays when it does, and why the design of the grid matters more than the design of the switch.

The more useful starting point is the constraint that oracles exist to solve. Smart contracts are deterministic. Every node on the network must execute the same code and arrive at the same result. If a smart contract could query a stock price API directly, different nodes would receive different responses at different times, and consensus would break. The blockchain would fork not because of a governance dispute but because of a rounding error in a price feed.

Oracles exist because blockchains chose determinism over connectivity, and that choice is not negotiable. Every oracle solution is an attempt to bring external data on chain without breaking the property that makes blockchains trustworthy in the first place.

How oracles actually work

The standard oracle architecture has three layers: data sourcing, aggregation, and on chain delivery.

At the sourcing layer, oracle nodes connect to external data providers. For a price feed, this might mean pulling the ETH/USD price from Coinbase, Kraken, Binance, and several other exchanges simultaneously. For a weather oracle, it might mean connecting to multiple meteorological APIs. The principle is the same: no single source is trusted.

At the aggregation layer, the oracle network combines these data points into a single value. The most common method is a weighted median, which discards outliers and produces a result that no single data provider can manipulate. If seven nodes report prices between $2,000 and $2,005 and one node reports $50,000, the median ignores the outlier.

At the delivery layer, the aggregated value is written to a smart contract on chain. This is the point where external data becomes blockchain data, immutable and available to any contract that references it. The on chain contract stores the latest value, and any DeFi protocol can read it.

This three layer model sounds clean in theory. In practice, each layer introduces attack surfaces, latency, and cost. Understanding where oracles fail requires examining each layer separately.

The oracle problem explained

The oracle problem is not a bug. It is a fundamental tension in blockchain design that cannot be fully resolved, only managed.

A blockchain derives its security from decentralization. No single entity controls the ledger. But if every smart contract on that blockchain reads price data from a single oracle controlled by a single company, the entire system security reduces to the security of that one company. The blockchain is decentralized. The data it depends on is not.

This is why the oracle problem is sometimes described as the last mile problem of blockchain security. You can build a perfectly audited smart contract, deploy it on a perfectly decentralized network, and still lose everything if the oracle feeding it data is compromised.

The solutions fall into two categories. Centralized oracles sacrifice decentralization for speed and simplicity. A single entity runs the oracle, and users trust that entity to deliver accurate data. This works for low stakes applications but is unsuitable for DeFi protocols holding billions of dollars.

Decentralized oracle networks address the trust problem by distributing data collection and aggregation across multiple independent nodes. Chainlink pioneered this model, requiring a configurable quorum of nodes to agree on a data point before it is published on chain. The economic incentive structure requires node operators to stake collateral that can be slashed for providing inaccurate data, aligning their financial interest with honest reporting.

Neither approach eliminates the oracle problem entirely. Decentralized oracle networks reduce the probability of manipulation but increase cost and latency. The tradeoff is a design decision, not a design flaw.

Why DeFi cannot exist without oracles

The dependency is arithmetic, not philosophical. Consider a lending protocol like Aave. A user deposits one ETH as collateral and borrows $1,500 in stablecoins. The protocol needs to know the price of ETH continuously to determine whether the collateral covers the loan.

If ETH drops from $2,000 to $1,400, the loan is undercollateralized and must be liquidated. Without an oracle providing the current price, the protocol has no way to trigger liquidation. The stablecoin borrowers would accumulate bad debt, and the protocol would become insolvent.

This is not a hypothetical scenario. Every lending protocol, every perpetual futures exchange, every options platform, and every synthetic asset on every blockchain depends on oracles for the prices that determine solvency. The total value locked in DeFi protocols that rely on oracle price feeds exceeds $200 billion across all chains.

The same dependency extends beyond price feeds. Prediction markets need oracles to report event outcomes. Insurance protocols need weather data. Real world asset platforms need proof that the underlying assets exist and are valued correctly. In each case, the oracle is the single component whose failure would make the entire application meaningless.

Oracle manipulation: how exploits happen

Oracle exploits follow a predictable pattern. The attacker identifies a DeFi protocol that derives its price from a single on chain source, typically a decentralized exchange liquidity pool, rather than from a decentralized oracle network.

The attack proceeds in three steps within a single transaction. First, the attacker takes a flash loan, borrowing millions of dollars with no collateral for the duration of one transaction. Second, the attacker uses the borrowed funds to manipulate the price on the DEX that the target protocol reads as its price source, executing a massive swap that moves the reported price by 50% or more. Third, the attacker interacts with the target protocol at the manipulated price, borrowing against artificially inflated collateral or liquidating positions at artificial prices.

The entire sequence happens atomically. If any step fails, the transaction reverts and the attacker loses nothing but gas fees. If it succeeds, the attacker repays the flash loan and keeps the profit.

This is not a theoretical attack vector. Flash loan oracle manipulations have drained hundreds of millions of dollars from DeFi protocols since 2020. The common thread in every case is a protocol that relied on a manipulable on chain price source instead of an external oracle network. Protocols that use Chainlink or equivalent decentralized oracle networks are not vulnerable to this specific attack because the price feed cannot be manipulated within a single transaction.

The lesson is counterintuitive. The most decentralized price source, an on chain DEX pool, is often the least secure for oracle purposes. The most secure price source for DeFi is an off chain oracle network that aggregates prices from centralized exchanges, precisely because those prices are harder to manipulate atomically.

The scale of these attacks has grown with DeFi itself. In October 2022, Mango Markets on Solana lost $114 million to an oracle manipulation exploit. The attacker used relatively modest capital to move the price of the MNGO token on thin DEX pools that Mango used as its price source, then borrowed against the inflated collateral value across every available asset on the platform. The entire operation took less than 20 minutes.

Euler Finance lost $197 million in March 2023 to a similar vector. BonqDAO, Harvest Finance, and dozens of smaller protocols have suffered the same pattern. In nearly every case, post mortem analysis identified the same root cause: the protocol used an on chain price source that could be moved by a single large transaction rather than an oracle network that aggregated prices from multiple independent external sources.

Types of oracles beyond price feeds

The industry focus on price feeds obscures the breadth of what oracles do in practice.

Verifiable randomness. On chain gaming, NFT minting, and lottery contracts need provably fair random numbers. Blockchains are deterministic by design, which means they cannot generate randomness natively. Oracle networks solve this by generating random numbers off chain using verifiable random functions, then publishing the result along with a cryptographic proof that the number was not tampered with.

Cross chain messaging. When a user bridges assets from Ethereum to Arbitrum, an oracle network verifies that the deposit transaction on the source chain was finalized before releasing assets on the destination chain. Chainlink Cross Chain Interoperability Protocol (CCIP) has become the default infrastructure for protocols like Aave handling cross chain operations, processing billions in transfers.

Proof of reserves. Stablecoins and wrapped tokens need to prove that their reserves match their circulating supply. Oracles that monitor custodian wallets and publish reserve balances on chain provide this assurance. Without proof of reserve oracles, users must trust the issuer self reported audits.

Computation oracles. Some operations are too expensive to perform on chain. Oracle networks can execute complex calculations off chain and deliver only the result on chain, along with a proof that the computation was performed correctly. This pattern is increasingly important for applications that need to process large datasets or run machine learning models while settling results on a blockchain.

The proliferation of oracle types reflects a broader shift in how blockchains interact with the real world. Early blockchain applications were self contained. Bitcoin transfers value between addresses on its own ledger. Ethereum executes logic using data stored in its own state. Neither required external information. The demand for oracles emerged only when builders began creating applications that referenced real world conditions: asset prices, event outcomes, identity claims, physical measurements. Each new category of real world reference creates a new category of oracle requirement, and each new oracle requirement creates a new surface area for the oracle problem to manifest.

The Chainlink dominance question

Chainlink position in the oracle market raises a question that the industry prefers not to examine too closely. If the entire point of decentralized finance is to eliminate single points of dependency, what does it mean that approximately 75% of DeFi total value secured relies on one oracle provider?

The defense is that Chainlink itself is decentralized. Its price feeds are generated by dozens of independent node operators, and no single operator can manipulate a feed. The network has processed trillions of dollars in transaction value without a major exploit of its core price feed infrastructure.

The concern is that decentralization within Chainlink does not address the concentration of the oracle layer in a single protocol. If a vulnerability were discovered in Chainlink EntryPoint contracts, or if a regulatory action targeted Chainlink Labs, the impact would cascade across virtually every major DeFi protocol simultaneously.

Competitors exist. Pyth Network, backed by Jump Crypto, focuses on high frequency price feeds from institutional market makers. API3 takes a first party oracle approach, having data providers run their own oracle nodes rather than relying on third party intermediaries. Chronicle, originally built for MakerDAO, provides oracle infrastructure for the largest decentralized stablecoin.

The market has not converged on a multi oracle standard the way it has converged on multi chain deployment. Most protocols use one oracle provider. Whether this concentration is a systemic risk or simply the natural result of network effects and security track record is an open debate with significant implications for DeFi resilience.

What this does not cover

This article does not cover the token economics of oracle networks in detail. LINK, PYTH, and API3 tokens each have different staking, reward, and governance mechanisms that affect oracle security and incentive alignment. Those mechanisms deserve their own analysis.

This article does not address the emerging category of AI oracles, systems that use machine learning models to generate predictions rather than relay observed data. AI oracles introduce a fundamentally different trust model and are at too early a stage for definitive assessment.

This article does not examine the specific smart contract architecture of any oracle network on chain components. The security of an oracle depends partly on its off chain infrastructure and partly on the correctness of its on chain contracts, and auditing those contracts requires a level of technical depth beyond this article scope.

Practical checks before trusting an oracle

Verify the data source count. A price feed aggregating data from 21 independent sources is more robust than one aggregating from three. Most oracle dashboards publish this information. If the protocol you are using does not disclose its oracle data source count, that is a signal.

Check the update frequency. Some oracle feeds update on every block. Others update only when the price deviates by a threshold, typically 0.5% to 1%. A lending protocol using a feed that updates every hour is exposed to rapid price movements that occur between updates. The deviation threshold and heartbeat interval matter for any protocol where liquidation timing is critical.

Confirm the oracle is external, not on chain. If a DeFi protocol derives its prices from its own liquidity pool or from a single DEX, it is vulnerable to flash loan manipulation regardless of how decentralized the underlying blockchain is. External oracle networks that aggregate off chain data are more resistant to this attack vector.

Look for a fallback mechanism. Well designed protocols implement oracle fallbacks. If the primary oracle feed stops updating, the protocol should have a secondary feed or a circuit breaker that pauses operations rather than operating on stale data. Protocols without fallback mechanisms are one oracle outage away from cascading liquidations based on incorrect prices.

Read the oracle incident history. Every major oracle network has experienced outages, delayed updates, or edge case failures. A network that has never experienced an incident is either too new to have been tested or too small to have been targeted. What matters is how incidents were handled and what architectural changes followed.

Disclaimer: This article is for informational and educational purposes only. It does not constitute financial, investment, or legal advice. Cryptocurrency markets are volatile and carry significant risk. Always conduct your own research before making investment decisions. Published August 11, 2026.

The SEC Reg Crypto proposal is heading to an Aug. 14, 2026, open meeting, where the U.S. Securities and Exchange Commission will consider whether to issue proposed rules creating a tailored offering regime for certain investment contracts involving crypto assets. The meeting is scheduled for 10 a.m. ET. If approved, the proposed release would begin the formal public-comment process once published.

Sec Schedules Regulation Crypto Assets for Aug 14

The SEC’s Aug. 10 Sunshine Act notice confirms that the Commission will hold an open meeting on Friday, Aug. 14, at 10 a.m. ET. The meeting will take place at the SEC’s headquarters in Washington, D.C., and will also be available through the agency’s webcast.

The official agenda identifies the matter as “Regulation Crypto Assets.” The Commission will consider whether to issue a release proposing new rules to create a tailored offering regime for certain investment contracts involving crypto assets.

The initiative is commonly referred to as “Reg Crypto,” while the SEC’s official agenda uses the title “Regulation Crypto Assets.” The matter falls under the SEC’s Division of Corporation Finance. The agency lists Jim Moloney, Sebastian Gomez Abero, Valian Afshar, Patrick Faller, John Fieldsend and Irene Paik as staff members for the agenda item.

The SEC’s notice does not announce a final rule. It states that the Commission will consider whether to issue a proposal. If approved and issued, the proposal would move into the public-comment and rulemaking process.

The meeting notice was dated Aug. 10, with the open meeting scheduled four days later. The SEC currently has three sitting commissioners, all Republicans. Their votes will determine whether the SEC issues the proposal for public comment.

Reg Crypto Could Create a Pathway for Crypto Fundraising

The proposed framework could address how certain crypto projects raise capital under a tailored offering regime. The framework could give eligible crypto firms a pathway to raise capital for projects without immediately triggering the SEC’s full registration requirements.

That would potentially give qualifying projects a defined route for fundraising in the United States while operating within a framework established by the agency. For crypto founders and fundraising platforms, the potential change could address uncertainty around how certain digital-asset projects structure offerings in the U.S. market.

Regulatory uncertainty has also encouraged some crypto offerings to seek jurisdictions outside the United States. A tailored U.S. framework could provide qualifying projects with another option for raising capital domestically. The precise scope of the fundraising pathway remains unknown because the SEC’s Aug. 10 notice does not specify registration exemptions, eligibility requirements or other detailed conditions.

The framework would not necessarily create a blanket exemption for token issuers or crypto companies. Its impact would depend on the eligibility requirements, disclosures, investor protections and continuing obligations included in the proposed release.

A Potential Exit Mechanism Could Address Continuing SEC Oversight

The framework could also address what happens after a crypto project is no longer actively managed by its development team. A potential mechanism could allow certain projects to seek relief from continuing SEC oversight once their teams are no longer involved in hands-on management.

The precise legal effect and eligibility conditions remain unknown. That would not mean a project automatically leaves the SEC’s jurisdiction simply because its team stops managing it day to day.

Any relief would depend on the legal mechanism and conditions established in the proposed framework, if such a mechanism is included. The SEC’s official notice does not confirm an exit mechanism.

It only states that the Commission will consider proposed rules creating a tailored offering regime for certain investment contracts involving crypto assets. The proposed release will therefore be critical for determining whether an exit pathway is included, which projects could qualify and what conditions would apply.

Aug 14 Would Begin a Longer Rulemaking Process

The Aug. 14 meeting would be the start of a longer process rather than the completion of a new crypto rule. If the Commission approves the proposal and it is published, the public would have an opportunity to submit comments.

The comment period is expected to last roughly two to three months, after which the SEC could review the responses and revise the proposal before considering a final rule. A final rule would generally provide a more formal and durable framework than informal staff statements or speeches, although it could still be challenged, amended or replaced.

The proposed rule would not immediately create binding requirements for crypto businesses. Instead, the proposal would establish the SEC’s intended regulatory approach and give market participants an opportunity to respond before the agency considers whether to adopt a final rule.

The eligibility requirements, disclosure obligations, investor protections, continuing requirements and any potential exit mechanism would therefore need to be assessed from the proposed release itself.

Clarity Act Consideration Moves Into September

The SEC’s planned action comes as Senate consideration of the Digital Asset Market Clarity Act has moved into September after lawmakers did not complete the relevant procedural step before the August recess.

Senate leaders have scheduled a Sept. 15 cloture vote on the motion to proceed to the legislation. That vote would determine whether the Senate can advance to consideration of the bill; it would not constitute final passage.

The CLARITY Act is intended to provide a broader legal foundation for crypto market rules in the United States. The delay leaves the SEC able to pursue rules within its existing authority while Congress considers whether to establish a broader statutory framework.

SEC Chairman Paul Atkins has said the agency can address many crypto market-structure issues through its existing authority. He has also indicated that congressional legislation would provide clearer, longer-term direction than SEC rulemaking alone.

The two regulatory tracks therefore remain important for crypto businesses. A final SEC rule could establish requirements within the agency’s authority, while legislation could provide broader statutory rules governing the U.S. digital-asset market.

SEC’s Crypto Work Extends Beyond the Aug 14 Proposal

The Regulation Crypto Assets proposal is part of the SEC’s wider work on digital-asset regulation. The SEC has issued an interpretation clarifying the application of federal securities laws to certain crypto assets and transactions.

That interpretation includes a taxonomy covering categories such as digital commodities, digital collectibles, digital tools, stablecoins and digital securities. The proposed offering regime would address another part of the regulatory framework by establishing rules for certain investment contracts involving crypto assets.

The distinction between an interpretation and a final rule is significant. The SEC’s interpretation explains how existing federal securities laws apply to specified crypto assets and transactions, while a final rule adopted through rulemaking would establish regulatory requirements within the agency’s authority.

The Aug. 14 meeting therefore represents the beginning of a proposed rulemaking process rather than the completion of the SEC’s crypto regulatory framework.

What Crypto Businesses Should Watch Next

The immediate question is whether the Commission votes to issue the proposed release. If it does, the document will provide the first detailed view of how the SEC intends to structure the tailored offering regime.

Crypto businesses will need to examine which investment contracts qualify, what conditions apply, what disclosures are required and what investor protections are included. The potential fundraising pathway will also require close attention.

Qualifying projects could potentially receive a route to raise capital without immediately triggering full SEC registration requirements, but the actual proposal will determine the scope and conditions of that route. The potential exit mechanism will require similar scrutiny.

For now, the confirmed development is that the SEC will meet on Aug. 14, 2026, to consider whether to issue proposed rules creating a tailored offering regime for certain investment contracts involving crypto assets.

If approved, the proposed release will determine how the fundraising pathway, eligibility requirements, investor protections, continuing obligations and any potential exit mechanism are structured. Until that document is issued, those details should not be treated as final SEC rules.

Node operators who miss the August 11 cutoff will be disconnected from Pi’s mainnet. With 421,000 nodes, a token trading at $0.08, and Binance still refusing to list, the upgrade is a stress test for a project that claims 60 million users but struggles to prove they matter.

Tomorrow morning, more than 421,000 Pi Network node operators face a choice that sounds routine but carries real consequences. Protocol 26, the ninth mandatory upgrade in recent months, must be installed by August 11 or the node loses its connection to Pi’s mainnet. The update itself takes less than five minutes. The question it raises takes longer to answer: what exactly are these nodes securing, and does it matter?

Pi Network occupies a unique position in crypto. It claims more than 60 million registered users, more than 18 million of whom have completed KYC verification. It has more active nodes than most proof of stake networks. It has been running an open mainnet since February 2025. And yet the token trades at eight cents, the largest exchanges will not list it, and the project’s first year on open mainnet produced more questions than answers.

Protocol 26 is worth examining not because the upgrade itself is dramatic, but because it forces a reckoning with the gap between Pi’s infrastructure ambitions and its market reality.

What Protocol 26 actually changes

The upgrade introduces improvements to contract security, state management, and cryptographic capabilities within Pi’s blockchain. The Core Team has described it as part of a sequential upgrade path, with Protocol 27 designated as the final major protocol change before what the team calls full network maturity.

In practical terms, Protocol 26 tightens the rules for how smart contracts interact with the network’s state layer and adds cryptographic primitives that will be required for Protocol 27’s feature set. The internal data migration involved is modest. Most node operators report less than five minutes of downtime during the process.

The mandatory nature of the upgrade is standard for Pi’s governance model. Unlike Bitcoin, where soft forks are backward compatible and nodes can choose whether to adopt new rules, Pi’s upgrade path is centrally coordinated. The Core Team sets deadlines, and nodes that miss them are disconnected. This is closer to how Solana or Aptos manage protocol upgrades than how Bitcoin or Ethereum operate.

This distinction matters. Pi’s consensus mechanism is derived from the Stellar Consensus Protocol, which relies on trust relationships between validators rather than proof of work or economic staking. The network’s 421,000 nodes participate in transaction validation through a trust graph managed by the Core Team’s selection of supernodes. The question of how decentralized this architecture actually is has been a persistent source of scrutiny from external observers.

The exchange listing problem

The most visible failure of Pi’s first 18 months on open mainnet is its absence from the two largest crypto exchanges in the world.

Binance held a community vote in February 2025 in which 86.8% of participants voted in favor of listing PI. The exchange did not act on the result. No public explanation was offered at the time, but reporting from multiple outlets has since identified three concerns: code transparency, the absence of a comprehensive third party security audit, and questions about the degree of centralization in Pi’s validator infrastructure.

Coinbase has been silent. No public statement regarding a PI listing has been made. The exchange’s general listing standards require projects to meet criteria around security, regulatory compliance, and technical architecture that Pi has not publicly shown it satisfies.

The listings that have materialized tell their own story. Kraken listed PI for spot trading in March 2026, making it the first US regulated exchange to do so. OKX opened US access in May. Bitget, MEXC, and several smaller venues also trade PI. But these exchanges collectively represent a fraction of the liquidity that Binance and Coinbase provide. Without the two largest venues, PI’s trading volume remains thin enough that relatively small sell orders can move the price by several percentage points.

The tokenomics pressure

Pi’s price trajectory since open mainnet launch has been a study in supply overwhelming demand. The token reached an all time high of $2.98 on February 26, 2025, the day it became freely tradeable. It now trades at approximately $0.08, a decline of more than 95%.

The supply schedule is the primary driver. Pi has a maximum supply of 100 billion tokens, of which roughly 9% is currently circulating. The remaining tokens unlock over time as users complete KYC verification, claim mining rewards, and exit lock up periods. Approximately 775 million additional PI are expected to unlock by December 2026 as three year lock up periods expire.

This creates a structural problem. Even if demand for PI increases, the incoming supply acts as a persistent headwind. Every month, tens of millions of new tokens enter circulation from users who mined them for free on their phones and have no cost basis. The rational behavior for these holders is to sell at any price above zero, because every token sold is pure profit.

The comparison to traditional token launches is instructive. Most crypto projects that distribute tokens through airdrops or mining programs experience significant sell pressure in the first year. Pi’s distinction is the scale. With 60 million registered users and a supply schedule that stretches over years, the sell pressure is not a spike that clears. It is a constant flow.

The RoboPay question

On August 4, 2026, the Fabric Foundation announced that Pi Network had joined RoboPay as a payment partner. RoboPay is a payment layer designed to let AI agents discover, hire, and pay robots for physical services through on chain transactions. The announcement described Pi’s PiRC2 smart contracts enabling recurring and automated settlements for robotic services.

The announcement deserves careful scrutiny on two fronts.

First, Pi’s Core Team has not confirmed the partnership. The claim comes from Fabric Foundation, not from Pi Network. Community reaction has been mixed, with some members treating it as a significant utility milestone and others noting the absence of official verification. Until the Core Team confirms, the partnership should be treated as unverified.

Second, even if confirmed, the services described are not live. RoboPay is infrastructure for a future in which autonomous robots provide services and receive payment through blockchain transactions. That future may arrive, but it has not arrived yet. A payment integration with a platform that has no live commercial users does not generate demand for PI tokens in the present.

This pattern, announcements of future utility that do not translate into current demand, has characterized much of Pi’s ecosystem development. The project has announced partnerships and integrations at a steady pace, but the gap between announcement and measurable economic activity remains wide.

The 421,000 node question

Pi’s node count is impressive in isolation. More than 421,000 active nodes place it among the largest validator networks in crypto by raw count. The network has processed more than 526 million verification tasks. Node operators run Pi Node software on desktop computers, contributing computational resources to the network’s consensus process.

The question is what these nodes are actually doing. Pi’s consensus mechanism, derived from the Stellar Consensus Protocol, does not require the computational intensity of proof of work or the economic staking of proof of stake. Nodes participate in a trust graph where supernodes, selected by the Core Team, anchor the consensus process. Regular nodes validate transactions within the trust relationships defined by these supernodes.

Critics argue this architecture is closer to a permissioned network than a truly decentralized one. BeInCrypto reported in early 2026 that concerns over supernode selection transparency had grown within the community, with node operators questioning how supernodes are chosen and whether the process concentrates too much authority in the Core Team.

Defenders counter that 421,000 nodes represent genuine geographic distribution and that the trust graph model is a deliberate design choice, not a centralization compromise. The Stellar Consensus Protocol, they note, was designed specifically to avoid the energy costs of proof of work while maintaining Byzantine fault tolerance.

Both arguments have merit. The relevant question for Protocol 26 is whether the upgrade deadline will reveal how many of those 421,000 nodes are actively maintained versus abandoned. If a significant fraction miss the deadline and are disconnected, the effective validator set shrinks, and the network’s claim to broad decentralization weakens.

What Protocol 27 needs to deliver

The Core Team has positioned Protocol 27 as the final major upgrade. It is expected to include expanded smart contract capabilities, DeFi infrastructure, DEX liquidity mechanisms, and the technical foundations for real world merchant payments.

The stakes for Protocol 27 are existential. Pi’s value proposition has always been future oriented: mine now, use later. The network launched with a mobile mining app that required no hardware investment, no electricity cost, and no technical knowledge. Tens of millions of people participated because the implied promise was that PI would eventually become valuable once the network matured and real use cases emerged.

Protocol 26 is the penultimate step. If Protocol 27 ships and the promised capabilities fail to generate meaningful transaction volume, exchange listings, or developer activity, the project will have exhausted its technical roadmap without resolving the fundamental question of whether anyone needs to use the Pi blockchain for anything that existing networks do not already provide.

The case for Pi

Dismissing Pi Network entirely requires ignoring several facts that competitors cannot replicate. No other crypto project has onboarded 60 million users. No other project has 18 million KYC verified participants. No other project has 421,000 nodes running validation software. These are real numbers representing real human participation, even if the economic value generated by that participation remains close to zero.

The bull case rests on a conversion thesis: if even a small fraction of Pi’s user base begins transacting on chain in meaningful ways, the network effects could be significant. A 60 million user network that achieves 1% active daily usage would have 600,000 daily active users, more than most DeFi protocols.

The question is whether Protocol 26 and Protocol 27 can provide the infrastructure necessary for that conversion. The current ecosystem has not produced a breakout application. The token’s price decline has eroded confidence among early adopters. And the exchange listing gap means that new capital cannot easily enter the PI market.

What would change this analysis

A confirmed Binance listing would transform Pi’s outlook overnight. The liquidity, visibility, and credibility that Binance provides would address the most common objection institutional and retail investors cite. Watch for any change in Binance’s public posture or new listing evaluation announcements.

A sharp reduction in token unlock volume, either through extended lock up incentives or a protocol level change to the emission schedule, would reduce sell pressure and allow demand to influence price. The current unlock schedule makes sustained price appreciation arithmetically difficult.

A breakout dApp that generates real transaction volume on the Pi blockchain would validate the network’s technical capabilities and provide a concrete answer to the question of what Pi is for. No such application exists today.

What to watch

Node connectivity after August 11. The number of nodes that successfully upgrade versus those that are disconnected will reveal the health of Pi’s validator community. A drop below 350,000 active nodes would signal significant operator attrition.

Protocol 27 timeline. The Core Team has not announced a firm date. Any delay beyond Q4 2026 extends the period of technical uncertainty and weakens the “final upgrade” narrative.

Binance listing signals. Monitor Binance’s listing evaluation page, community vote results, and any public statements from Binance leadership regarding PI. The absence of signals is itself informative.

Monthly token unlock volumes. Track the pace of new PI entering circulation against trading volume. If unlocks consistently exceed daily volume, sell pressure will continue to suppress price regardless of other developments.

DApp transaction counts. The Pi browser includes access to Pi ecosystem applications. Weekly active user counts and on chain transaction volumes for these applications are the most direct measure of whether the network is generating real utility.

Disclaimer: This article is for informational and educational purposes only. It does not constitute financial, investment, or legal advice. Cryptocurrency markets are volatile and carry significant risk. Always conduct your own research before making investment decisions. Published August 10, 2026.

BTCPay Server supporters have backed a recovery bounty equal to 10% of funds retrieved from a recent Lightning wallet exploit, with the reward capped at 3 BTC if all stolen assets are recovered.

The BTCPay Server project said on Monday that the bounty is part of its response to a critical security flaw that exposed LND administrator credentials on vulnerable installations, days after users were told to immediately upgrade to version 2.4.2.

The open-source Bitcoin payment processor has not disclosed how much cryptocurrency was stolen or how many servers were compromised. However, several affected users, including Foundation and Citadel21, have reported that funds held in their Lightning nodes were drained.

BTCPay said the vulnerability affected all releases before version 2.4.2, including release candidate versions of 2.4.2. The flaw allowed an attacker to obtain LND admin macaroon credentials from exposed BTCPay instances and then access wallets connected to the affected Lightning nodes.

A macaroon works as an authentication credential for a Lightning node, with an administrator macaroon providing extensive permissions over the associated wallet. Access to those credentials can therefore allow an unauthorized party to control funds held through the affected LND setup.

BTCPay Server exploit was fixed in version 2.4.2

Following the discovery, BTCPay released the final version of 2.4.2 with a fix for the vulnerability and urged operators running older versions to update their servers.

The project said the security issue was specific to LND credentials and did not expose users running other Lightning implementations through the same attack route. Operators who do not use Lightning were also not affected by the LND credential issue, although BTCPay recommended that all users install the latest release.

BTCPay’s onchain wallets were not compromised through the vulnerability, including onchain hot wallets maintained by users of the software, according to the project.

The distinction limits the known attack path to connected LND wallets rather than the full range of Bitcoin funds that can be managed through a BTCPay installation.

Although BTCPay has yet to release figures for the losses, reports from individual users have confirmed that the exploit resulted in stolen funds. The project is preparing a full postmortem that is expected to provide more information about the vulnerability and the response.

BTCPay has also started introducing stronger code-scanning and review procedures with assistance from several external organizations.

The response follows a difficult year for crypto security. In April,crypto.news reported that CertiK had recorded more than $600 million in crypto losses during 2026 at the time, while the security firm warned that AI-assisted attacks and weaknesses in infrastructure were becoming important risks for projects.

Researchers receive 0.42 BTC for finding the flaw

Alongside the recovery bounty, the BTCPay Server Foundation is paying rewards to the researchers who identified the vulnerability before it was publicly disclosed.

The foundation is donating 0.21 BTC each to Sparrow Wallet developer Craig Raw and the Bitcoin Red Team fund. Raw discovered the security issue and privately reported it to BTCPay, allowing developers to prepare a fix before details of the flaw became public.

Raw later said he had also been affected by the exploit.

Bitcoin Red Team operates as a volunteer security research group whose members include Rob Hamilton, Calle and Evan Kaloudis. The group works on finding and reporting vulnerabilities affecting Bitcoin-related software.

BTCPay’s decision to fund both researchers comes alongside the separate recovery bounty backed by project supporters. Under the proposed terms, 10% of successfully recovered funds can be paid as a bounty, while a complete recovery would carry a maximum reward of 3 BTC.

Recovery incentives have also surfaced after other crypto exploits this year. In July, crypto.news examined efforts to recover roughly 16 million ADA taken from 374 Cardano wallets in a late-June exploit. EMURGO outlined a process to return affected assets while an independent forensic team conducted a separate investigation into the incident.

AI may have helped uncover the BTCPay Server exploit

As part of its initial assessment, BTCPay raised the possibility that artificial intelligence tools could have played a role in finding the vulnerable code.

The project said improving AI models have reduced the time and cost required to inspect large software repositories for weaknesses, changing the capabilities available to both attackers and security researchers.

Bitcoin software presents an attractive target because exploitable weaknesses can provide direct access to assets, BTCPay said, adding that other areas of the software industry could eventually face similar problems as AI-based code analysis becomes more capable.

Concerns over AI-assisted attacks had already surfaced elsewhere in the crypto sector. CertiK reported in June that crypto hacks and exploits caused $68.3 million in losses during May, down nearly 90% from roughly $650 million in April, but the firm also recorded an increase in AI-assisted malware targeting code repositories and coding tools, as previously covered by crypto.news.

A July analysis of AI security also examined how increasingly capable models can identify and exploit software vulnerabilities, with the technology arriving during a year already dominated by large crypto security incidents.

The BTCPay incident differs from attacks based primarily on social engineering or compromised signing devices because the entry point was a software vulnerability that exposed sensitive LND authentication credentials.

Coldcard exploit raised similar AI concerns

The BTCPay attack has followed another major Bitcoin security incident involving Coldcard hardware wallets, where the suspected use of AI to inspect older code was also raised after funds were stolen.

At least $116 million in losses have been confirmed from the Coldcard exploit so far. Coinkite, the company behind Coldcard, said it considered it likely that someone had used AI to examine older publicly available firmware and identify the weakness.

The two incidents have put code review under increased attention at a time when attackers have already moved beyond conventional smart contract vulnerabilities.

In April, crypto.news reported on more than $17 billion lost across 518 documented crypto hacks and exploits over the previous decade, citing DefiLlama data. The report found that private key leaks, credential theft, phishing and attacks against wallets and infrastructure had become major sources of losses alongside flaws in smart contracts.

Chainalysis has separately estimated that attackers stole $36.7 million from unverified, closed-source smart contracts during the first six months of 2026 by decompiling contract bytecode. The blockchain analytics firm assessed that AI was very likely involved in this activity.

For BTCPay users, the immediate remediation remains the official 2.4.2 release. The project has said it will publish a more detailed postmortem on the exploit while its new code-scanning and review procedures are being developed with external organizations.