Technical Analysis of Chainway: How a Bitcoin Layer2 Project Capitalizes on Hype (Part 1)
TechFlow Selected TechFlow Selected
Technical Analysis of Chainway: How a Bitcoin Layer2 Project Capitalizes on Hype (Part 1)
Chainway is essentially a sovereign rollup/client-validated scheme that uses BTC as the DA layer.
Navigating Web3 tides with focused insightsAuthor: Shew & Faust, Geeker Web3
The current Bitcoin Layer2 landscape is flourishing, with a wide array of technical approaches converging within the BTC ecosystem as a vast melting pot. Due to the fast pace of iteration in the blockchain field, professional terminology and standards continuously evolve through research, innovation, and engineering implementation. In this context, many projects adopt the practice of "coining concepts" or "piggybacking on buzzwords" to differentiate themselves and gain attention, which has become an industry-wide unwritten rule.
For example, many modular blockchain projects originally active in the Ethereum/Celestia ecosystems have also jumped on the "Bitcoin Layer2" bandwagon amid the recent surge, branding themselves as "Rollups," even though their technical designs often do not meet standard Rollup criteria.
However, terms like "Rollup" carry high recognition value, making such labels more favorable for marketing purposes. Many project teams either forcibly claim the Rollup label or fork mainstream Rollup concepts by adding ambiguous qualifiers (e.g., sovereign Rollup).
Yet once we peel back the "XX Rollup" facade, we find that many projects still fundamentally operate on simple "client-side validation" or "sidechain" mechanisms, merely leveraging the "XX Rollup" slogan for convenience. Although this kind of marketing is widespread, it is often misleading, doing more harm than good for the general public seeking truth.
(Joseph Goebbels, Nazi Minister of Propaganda, summarized "deceptive propaganda"—a tactic frequently seen among many project teams)
So how can we identify such practices of "hijacking the Rollup concept"?
Perhaps, by returning to first principles and relying on definitions widely accepted in the West and across the industry, we can classify different Layer2 solutions based on their security levels and functional completeness, thus equipping ourselves with the "truth-seeing eyes" needed to cut through the fog. Put differently, the specific technical approach matters less than whether the project's mechanism design ensures genuine security and reliability for the Layer2 network and truly empowers the BTC mainnet.
Below, we will use Chainway—an overseas-developed Bitcoin Layer2—as a case study to dissect how certain projects hide a core mechanism of "client-side validation" behind their "Rollup" marketing claims. This analysis will clearly reveal the significant differences between so-called "sovereign Rollups" or "client-side validation" schemes versus mainstream industry Rollup implementations such as ZKRollup or OPRollup, which rely on smart contracts.
Of course, this is not to say that sovereign Rollups or client-side validation are inherently less secure or reliable than ZK Rollups—the actual security depends entirely on implementation details. While Chainway is a typical client-side validated Layer2, it proposes an anti-censorship transaction model based on "BTC-triggered + off-chain verification" and employs recursive ZK proofs similar to those used by the MINA blockchain, placing it ahead of most Bitcoin Layer2s.
We believe that a technical review of Chainway holds considerable value and offers important reference insights for observers of the broader Bitcoin Layer2 space.
(Chainway’s promotional image labeling itself as a ZK Rollup, but its actual architecture relies on client-side validation; currently, it has not implemented consensus among off-chain clients or reliable message exchange)
Main Text: Chainway is a relatively well-known Bitcoin Layer2 project in Western communities. Many KOLs directly refer to it as a "ZK Rollup," while in its technical documentation, Chainway self-identifies as a "sovereign Rollup." Recently, Chainway announced a new project called Citrea, claiming it to be a BitVM-based ZK Rollup. Since Citrea has not yet detailed how its BitVM-based ZK verification would work, this article focuses on interpreting Chainway’s existing technical solution.
We can summarize Chainway’s publicly disclosed technical design in one sentence: publishing DA data via the Ordinals protocol, using BTC as its DA layer, publishing state diffs (changes in account states) along with ZK proofs verifying the correctness of these state transitions on Layer1—effectively equivalent to publishing complete, verifiable transaction data.
(State diff refers to changes in account states)
However, since Layer1 does not directly verify ZK proofs—instead leaving verification to off-chain independent clients/nodes—and Chainway’s current codebase does not implement consensus among off-chain clients, nor has the team claimed to solve this issue on social media, Chainway’s published technical design essentially falls under the category of "client-side validation," and arguably resembles little more than an inscription indexing protocol with asset bridging support.
The following sections will introduce Chainway’s specific technical implementation and analyze its security model.
What Is a Sovereign Rollup: Data Published on DA Layer + Off-Chain Validation
In Chainway’s technical documentation, the term "sovereign rollup" from Celestia is adopted. However, sovereign Rollups differ drastically from the mainstream Rollup concept in the Ethereum community and wider industry (i.e., smart contract Rollups). So what exactly constitutes a sovereign Rollup?
In fact, a Bitcoin-based sovereign Rollup is somewhat analogous to—"an off-chain group of clients / sidechain publishing DA data on the BTC chain." Its key feature is not requiring Layer1 smart contracts to validate Layer2 state transitions or cross-chain operations. Instead, it simply uses BTC as a DA layer, resulting in a security model largely aligned with "client-side validation."
Certainly, some higher-security sovereign Rollup designs may rely on third-party settlement layers (akin to sidechains) outside the BTC chain to verify state transitions, and include consensus mechanisms or reliable messaging between independent clients/nodes to reach agreement on disputed actions. But other sovereign Rollup projects are outright "client-side validation," lacking any reliable communication between independent clients/nodes.
To better understand this unique concept of "sovereign Rollup," we can compare it directly with its counterpart: smart contract Rollups. Most Layer2s on Ethereum are smart contract Rollups, such as Arbitrum and StarkNet. The architecture of a smart contract Rollup is illustrated below:
In the diagram above, several terms from the modular blockchain narrative are explained as follows:
Execution Layer: Executes user transactions, updates blockchain state, and submits data to DA and settlement layers
Settlement Layer: Validates state transitions from the execution layer, resolves disputes (e.g., via fraud proofs), and provides bridge modules for L1-L2 asset transfers
DA Layer: A large public bulletin board that receives state transition data submitted by the execution layer and makes this data trustlessly available to anyone
Consensus Layer: Ensures finality of transaction ordering—its function overlaps significantly with the DA layer (note: the Ethereum community’s modular blockchain framework typically excludes a separate consensus layer)
From the smart contract Rollup architecture, we see that apart from the execution layer, all other functions are fulfilled by Ethereum. The diagram below illustrates Ethereum’s role in greater detail.
Rollup contracts on Ethereum receive validity proofs or fraud proofs to verify the validity of Layer2 state transitions. Notably, the Rollup smart contract effectively serves as the settlement layer entity in modular blockchains. These settlement layer contracts often include bridge modules for handling assets transferred from Ethereum to Layer2.
Regarding DA, the settlement layer contract can enforce requirements that the sequencer post latest transaction data / state diffs on-chain; failure to publish DA data prevents successful update of the L2 state recorded in the Rollup contract.
(ZK Rollups or OP Rollups can enforce DA data publication—failure to publish blocks updating the state in the settlement layer)
Reference: Dissecting Bitcoin/Ethereum Layer2 Security Models and Risk Indicators Using the Bucket Theory
It becomes evident that smart contract Rollups heavily depend on Layer1 smart contracts. For Layer1 chains like BTC, which struggle to support complex logic, constructing Layer2s that align with Ethereum-style Rollups is nearly impossible.
In contrast, sovereign Rollup designs eliminate the need for Layer1 contracts to perform state validation or bridge processing. Their architecture is shown below:
As shown, in sovereign Rollups, a group of nodes outside the DA layer serve as entities responsible for transaction execution and settlement, offering greater flexibility. The workflow proceeds as follows:
Execution layer nodes in sovereign Rollups send transaction data/state diffs to the DA layer, while settlement layer clients retrieve and verify this data. Importantly, because the settlement module is not located on Layer1, sovereign Rollups theoretically cannot achieve bridge security equivalent to Layer1, often relying instead on custodial bridges or third-party bridging solutions.
Currently, sovereign Rollup/client-side validation schemes are easier to deploy—requiring only data publication on the BTC chain using methods like the Ordinals protocol. The off-chain validation and consensus components offer broad room for customization. In fact, many sidechains can become "BTC-based sovereign Rollups" simply by publishing DA data on BTC, although their actual security remains questionable.
However, a critical issue is that Bitcoin’s data throughput is extremely low, with each block capped at 4MB and an average block time of 10 minutes—translating to roughly 6KB/s. Most projects claiming to be sovereign Rollups may not be able to publish all DA data directly on the BTC chain, forcing them to adopt compromises, such as publishing DA data off-chain and only storing the data hash on BTC as a "commitment," or employing highly compressed representations (like Chainway’s claimed State diff + ZK Proof).
Clearly, such models deviate from the formal definition of "sovereign Rollup" or legitimate Rollups—they are variants whose security remains debatable. We predict that most Layer2 projects branding themselves as "Rollups" in the future will ultimately fail to fully publish DA data on the BTC chain, meaning their real-world implementations will likely fall short of whitepaper claims like "ZK Rollup" or "OP Rollup."
Finally, let us briefly summarize the key differences between sovereign Rollups and smart contract Rollups:
First, upgradability. Upgrading a smart contract Rollup involves updating the smart contract, usually managed via upgradeable contracts controlled by multi-sig wallets held by the development team. In contrast, upgrades in sovereign Rollups follow traditional blockchain soft/hard fork rules—nodes can choose whether to upgrade, and different clients may accept or reject the change independently. In this regard, sovereign Rollups are superior to smart contract Rollups.
Second, bridging. Bridges in smart contract Rollups are ideally minimally trusted, though upgradeability introduces risks. In sovereign Rollup designs, developers must build bridge components off-chain on Layer1, and the resulting bridges are unlikely to achieve the same level of trustlessness as smart contract-based bridges.
BTC DA Construction
As mentioned earlier, implementing a BTC-based sovereign Rollup hinges on using the Ordinals protocol to treat BTC as a DA layer. Chainway adopts precisely this approach.
We can examine a DA data submission transaction from Chainway’s sequencer, with transaction hash:
24add7cdcbffcda8d43509c8e27c5a72f4d39df1731be84bdba727cd83ae0000, illustrated below:
This transaction’s script borrows from the Ordinals Protocol’s method of writing data using OP_0 OP_IF, embedding Rollup DA data onto the BTC chain (publishing state diffs + ZK Proofs, which is equivalent in security to publishing raw transaction data but allows massive data compression).
In addition to DA data, the sequencer also embeds authentication data within the transaction—the most important being the sequencer’s digital signature over the DA data using its private key, ensuring the authenticity of the data submission.
We should also note that every transaction involving DA data submission ends with 16 binary zeros (i.e., two consecutive zero bytes) in its transaction hash. This constraint appears in the code:
The random number b715 in the earlier example adjusts the transaction hash so its tail contains exactly 16 trailing zeros—similar in principle to the nonce used in Bitcoin mining to make the hash start with N leading zeros satisfying difficulty requirements.
This design simplifies DA data retrieval: when any Layer2 node needs to fetch DA data, it only needs to scan BTC blocks for transactions ending with 16 zeros, clearly distinguishing Chainway sequencer transactions from other BTC chain activity. Hereafter, transactions containing DA data and meeting the 16-zero suffix condition will be referred to as "Chainway-compliant transactions."
Now we arrive at the central question posed in this article’s title: How does Chainway achieve censorship resistance? Since Layer2 sequencers might deliberately reject certain user transactions, a special mechanism is required to enable users to submit censorship-resistant transactions.
To address this, Chainway allows users to initiate a "forced transaction." Once a user submits such a declaration within a BTC block, the Chainway sequencer must process the transaction request on Layer2; otherwise, it cannot produce valid blocks, or its blocks will be rejected by off-chain clients.
The forced transaction parameter structure is as follows:
This transaction is submitted to the Bitcoin chain as a "Chainway-compliant transaction," with a hash ending in 16 zeros. When generating an L2 block, the Chainway sequencer must include all "Layer2-compliant transactions" disclosed on the BTC chain but not yet included in the L2 ledger, aggregating them into a Merkle Tree and writing the Merkle root into the L2 block header.
Once a user initiates a forced transaction directly on the BTC chain, the sequencer must process it—or else it cannot generate the next valid block. Off-chain Chainway clients can first verify the ZK proof to confirm the validity of the proposed L2 block, then check the Merkle root in the block header to determine whether the sequencer has faithfully included all forced transaction requests.
The workflow is illustrated below. Note: due to space limitations, the diagram omits a conditional check in verify_relevant_tx_list:
In summary, Chainway clients/nodes synchronize BTC mainnet blocks and scan for DA data published by the Chainway sequencer, confirming both the authenticity of the data source and that all submitted "Chainway-compliant transactions" have been properly included.
It is clear that as long as a user can construct and submit a compliant "standard transaction" to the BTC chain, that transaction will eventually be incorporated into the local L2 ledger of Chainway clients; otherwise, blocks published by the Chainway sequencer will be rejected.
If combined with reliable off-chain consensus or alert messaging, Chainway’s censorship-resistant transaction scheme would closely resemble the ideal sovereign Rollup anti-censorship model. For instance, some sovereign Rollup designs explicitly state they will broadcast Alert messages among off-chain clients upon detecting invalid blocks, enhancing security—especially informing light clients unable to sync full DA data about network anomalies.
If a block fails to properly include a "forced transaction," it should trigger such an alert broadcast, but currently, Chainway has not implemented this functionality (at least not in publicly available documentation or code repositories).
Reference: Celestia Researcher Analyzes 6 Rollup Variants: Sequencer = Aggregator + Header Generator
Even if off-chain consensus among clients/nodes were implemented, Chainway’s censorship resistance via "forced transactions" would still fall short of smart contract Rollups like Arbitrum, where Arbitrum One ultimately relies on Layer1 contracts to ensure forced transactions are included in the L2 ledger, thereby fully inheriting Layer1’s censorship resistance. Sovereign Rollups clearly cannot match smart contract Rollups in this aspect—their censorship resistance ultimately depends on off-chain components.
This implies that the architectural思路 of "sovereign Rollups" and "client-side validation" fundamentally cannot fully inherit Layer1’s censorship resistance like Arbitrum One, Loopring, dydx, or Degate. Whether a forced transaction gets included in the L2 ledger depends on decisions made by off-chain Layer2 entities—not on Layer1 itself.
Clearly, Chainway’s approach—relying solely on discretionary off-chain client validation—only inherits Layer1’s DA reliability, not its full censorship resistance.
Recursive ZK Proofs Similar to MINA
In this section, we further explore other components of Chainway. Beyond using BTC as a DA layer, it implements recursive ZK proofs similar to those used by MINA. The overall structure is shown below:
After processing user transactions, Chainway’s sequencer generates a final ZK proof along with state diffs for individual accounts and publishes them on the BTC chain. Full nodes synchronize all historical Chainway data published on BTC. Each new ZK proof not only verifies the current block’s state transition but also confirms the validity of the previous block’s ZK proof.
With this design, each newly generated proof recursively confirms the prior one. As a result, the latest ZK proof can guarantee the validity of all previous proofs dating back to genesis—just like in MINA.
When a "light client" (i.e., a light node syncing only block headers) joins the network, it only needs to verify the validity of the latest ZK proof disclosed on BTC to confirm the integrity of the entire chain’s history and all state transitions.
If the sequencer acts maliciously—for example, refusing to accept a forced transaction or failing to perform recursive proof generation—the newly generated ZK proof will be rejected by clients (even if produced, it won’t be recognized), as illustrated below:
Conclusion
As summarized at the beginning of this article, Chainway is fundamentally a sovereign Rollup / client-side validation solution using BTC as its DA layer. To enhance censorship resistance, Chainway introduces the concept of forced transactions. Additionally, Chainway employs recursive ZK proofs, enabling new nodes to trust the sequencer’s output and instantly verify the correctness of the entire chain’s history.
Chainway’s current challenge lies in achieving trust-minimized cross-chain bridging. Because it adopts a sovereign Rollup model without detailing its bridge solution or technical specifics, its ultimate security remains uncertain.
Today, through an in-depth analysis of Chainway’s technical design, we found that the technology promoted by its community does not qualify as a mainstream Rollup. Given that there are already dozens of Bitcoin Layer2 projects (potentially hundreds within six months), to reduce confusion around technical terminology, we will continue conducting deep research into Layer2 classification frameworks, security benchmarks, and functional completeness evaluation standards—stay tuned!
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@godrealmx
