How Portal to Bitcoin Stacks Up Against Wormhole, Axelar, and LayerZero
A comparison of Portal to Bitcoin with LayerZero, Wormhole, and Axelar—not just in terms of market share, but at the architectural level.
Interoperability has become one of the most critical layers of infrastructure in the multichain ecosystem. Protocols like LayerZero, Wormhole, and Axelar have emerged as dominant players, enabling seamless cross-chain messaging, asset transfers, and composability across dozens of blockchains.
This report takes a close look at how these leading interoperability protocols operate under the hood. We break down their architectural design, trust models, custody mechanics, and execution guarantees to better understand how value moves across chains—and where the risks lie.
Most importantly, we compare them directly to Portal to Bitcoin, a trust-minimised protocol currently in testnet that aims to bring native Bitcoin into the cross-chain economy through peer-to-peer atomic swaps, without validators, wrapping, or synthetic assets.
By examining these protocols side by side, we aim to clarify what makes Portal’s approach fundamentally different, and why it may unlock a market opportunity others have yet to reach.
Disclaimer: This research report is intended for informational purposes only and does not constitute financial advice. Readers are advised to conduct thorough research and seek professional advice before making investment decisions. Full disclaimer at the end of the report.
The Market Opportunity
Bitcoin is arguably the most sought-after crypto asset today, with its dominance nearing 60% (at the time of writing). Yet despite this commanding position, Bitcoin remains largely isolated from the broader crypto ecosystem.
Only around 0.8% of all BTC is currently utilised in DeFi, and the vast majority of that exists in the form of wrapped Bitcoin on Ethereum and other chains via custodial bridges.
This disconnect isn’t due to a lack of infrastructure. In recent years, cross-chain protocols like LayerZero, Wormhole, and Axelar have gained significant traction, enabling the seamless transfer of assets between blockchains.
LayerZero processed $5.099 billion in bridge volume over the past month, followed by Wormhole with $935.49 million and Axelar with $89.68 million.
These powerhouses have become deeply embedded in the interoperability stack, powering a substantial share of the cross-chain market. Overall, total bridge volume this month reached $18 billion.
Yet despite all this activity, Bitcoin remains largely on the sidelines.
The reasons are not technical but philosophical. Bitcoin holders tend to be security-conscious and sceptical of solutions that introduce additional trust layers.
Wrapped tokens, multi-sig custodians, and validator-based messaging systems all introduce clear risks: loss of custody, smart contract exploits, and centralised points of failure. For many BTC holders, these trade-offs are unacceptable. The yield simply isn't worth the trust they would need to give up.
This opens the door for a different kind of solution.
Portal to Bitcoin enters the picture with a model that doesn’t require users to wrap their assets, rely on external validators, or hand over control to a bridge contract. It is built around atomic swaps, a trust-minimised design, and native BTC support, offering a fundamentally different approach to interoperability that aligns with the values of the Bitcoin community.
But can it deliver? And how does it compare to the protocols that currently dominate the cross-chain landscape?
To answer that, we need to compare Portal to Bitcoin with LayerZero, Wormhole, and Axelar not just in terms of market share, but at the architectural level.
Understanding how these systems differ in trust assumptions, custody models, and execution logic will reveal whether Portal offers a safer and more compelling on-ramp for Bitcoin into DeFi.
LayerZero: Modular Messaging, Not Bitcoin-Ready
Let’s start our comparison with LayerZero, which at the time of writing is the largest cross-chain communication solution on the market. Multiple applications leverage its infrastructure to facilitate cross-chain messaging and asset transfers.
Architectural Design Philosophy
LayerZero is built as a general-purpose cross-chain messaging protocol. Unlike traditional bridges that mainly focus on moving tokens between blockchains, LayerZero lets applications send all kinds of messages—like function calls and data—between smart contracts on different chains.
This makes it possible to build more advanced use cases, such as cross-chain lending, governance, NFT minting across multiple chains, and complex DeFi apps. That’s why many projects choose to build on LayerZero.
The protocol architecture is modular and made up of four main components: Endpoints, Message Libraries (MessageLibs), Decentralised Verifier Networks (DVNs), and Executors. Each plays a specific role in enabling secure cross-chain messaging.
The Endpoint is a smart contract deployed on each chain that acts as the starting and ending point for messages — like a mailbox that sends and receives.
The MessageLib is the logic that encodes, verifies, and handles messages according to a chosen security model.
DVNs are independent entities (often off-chain) that observe the source chain and sign messages to confirm they were genuinely emitted.
The Executor is responsible for submitting the verified message to the destination chain and triggering whatever action the message specifies.
When a message is sent, it goes through this pipeline: emitted from the Endpoint, verified by one or more DVNs, and then submitted by an Executor to the destination chain, where it executes the intended function — such as a token transfer or smart contract call.
Because LayerZero doesn’t enforce a single trust model, each application can configure its own DVNs, MessageLibs, and Executors. This gives developers flexibility to optimise for security, cost, or performance, but also means the overall reliability depends on how these components are chosen and configured.
Trust Assumptions and Verifier Dependencies
The trust model in LayerZero is decentralised in theory but highly configurable in practice. Applications choose which DVNs are responsible for verifying their cross-chain messages.
These DVNs are external, off-chain entities that monitor for emitted messages and provide cryptographic attestations. Most commonly, applications configure a K-of-N threshold—for example, requiring 2 out of 3 DVNs to agree on a message’s validity before it can be accepted.
This approach offers flexibility and modularity but still relies on external verifiers. If the selected DVNs go offline, delay their signatures, or act maliciously, the messaging channel can become unreliable or insecure. There is no universally enforced verifier set. Instead, the responsibility falls on developers to select trustworthy DVNs and monitor their behaviour.
Beyond verifiers, LayerZero also depends on Executors to complete the final step of a message’s journey. Executors are off-chain actors responsible for submitting verified messages to the destination chain and triggering the corresponding smart contract logic.
Although applications can use multiple Executors and implement fallback mechanisms, message delivery still relies on someone taking action and paying the gas cost. This introduces additional latency and a dependency on active participation.
Custodianship and User Asset Control
LayerZero does not directly hold or transfer user assets. Instead, it acts as a communication layer that applications use to build more complex cross-chain systems, some of which may involve asset custody.
For example, if a lending app built on LayerZero sends collateral data or executes token operations across chains, the custody of user funds depends entirely on how that app is implemented.
This positions LayerZero more as infrastructure than a protocol with clear, user-facing custody guarantees. In practice, user assets may be managed by smart contracts that rely on DVNs to verify the origin of messages and Executors to trigger specific actions. This creates an indirect trust chain: users must trust that messages are signed correctly, delivered reliably, and executed as intended—even though LayerZero itself never holds the assets.
The decentralised nature of this architecture makes LayerZero highly flexible and powerful, but it also introduces opacity. Users rarely interact with LayerZero directly. Instead, they interact with applications built on top of it, where asset control is abstracted and shaped by the app’s specific security model.
Execution Guarantees and Failure Modes
Message delivery in LayerZero is not atomic; it occurs through a multi-step pipeline. First, a message is emitted from the source chain’s Endpoint. Next, DVNs must detect and verify it by providing cryptographic signatures. Once verification is complete, an Executor must submit the message to the destination chain and call the function that triggers the intended action.
Any part of this process can fail. If DVNs are offline or unresponsive, the message cannot be verified. If no Executor submits the message, it remains pending indefinitely. And if the receiving smart contract contains faulty logic or reverts, the message may ultimately fail. LayerZero does not include a native rollback or refund mechanism in these scenarios.
To improve reliability, the protocol supports “permissionless liveness,” allowing anyone to act as an Executor and deliver the message, as long as they cover the gas fees. While this adds resilience, it also assumes that someone is actively monitoring and willing to step in. If no one does, messages can be stuck in limbo, leading to indefinite delays or disrupted application behaviour.
To mitigate some of these risks, LayerZero offers Pre-Crime, an optional off-chain tool that simulates and evaluates the outcome of a message before execution. While helpful for preventing certain failures, Pre-Crime only provides guidance—it does not guarantee safety or recovery.
Wormhole: Bridging at Scale with Wrapped Assets
Now that we've explored the benefits and security trade-offs of LayerZero, it's time to look at another giant in the interoperability space: Wormhole. Currently sitting at number four in terms of bridge volume, Wormhole is especially dominant on high-throughput chains like Solana.
Let’s take a closer look at how Wormhole is architected, and how its approach to cross-chain communication differs from other major interoperability protocols in both design and trust assumptions.
Architectural Design Philosophy
Wormhole began as a token bridge but has since evolved into a general-purpose interoperability protocol, supporting both asset transfers and cross-chain messaging across more than 30 blockchains.
Its architecture centres around the Guardian Network, a federation of validator nodes operated by prominent infrastructure providers. These nodes are responsible for observing blockchain events and signing cryptographic attestations to confirm their validity.
When a user initiates a cross-chain action, such as bridging tokens, the assets are first locked in a Wormhole smart contract on the source chain. The Guardian nodes monitor this contract and, once they detect the event, collectively sign an attestation verifying that the lock has occurred. This signed message is then relayed to the destination chain, where a corresponding contract verifies the signature and mints a wrapped version of the asset. This is commonly referred to as a lock and mint model.
Wormhole’s design prioritises speed and composability across chains, but it introduces a significant shift away from native asset interoperability. Users no longer hold the original token, but instead hold a wrapped representation of it, with redemption dependent on the custody and coordination of the Guardian Network.
Trust Assumptions and Verifier Dependencies
Wormhole’s core trust model relies on the honesty and availability of its Guardian set. A message is considered valid if a quorum, currently 13 out of 19 Guardians, sign off on it. This design introduces trust in a fixed, permissioned group.
While these Guardians are professional infrastructure providers, they are off-chain actors with no slashing risk or direct economic penalties for misbehaviour.
This model came under intense scrutiny following the Wormhole exploit in February 2022. In that incident, attackers exploited a vulnerability in the Ethereum smart contract to mint 120,000 wrapped ETH on Solana without locking any ETH on Ethereum. The Guardian network failed to detect or prevent the attack. The lost funds were only restored after Jump Crypto, one of Wormhole’s main backers, stepped in to cover the loss.
The exploit underscored the fragility of relying on off-chain consensus from a static group of verifiers, especially in the absence of built-in economic or cryptographic guarantees for users.
Custodianship and User Asset Control
Wormhole’s bridging model is based on custodial smart contracts. When a user sends tokens across chains, those assets are deposited into a Wormhole vault on the source chain—a contract controlled by the protocol rather than the user. A wrapped version of the token is then minted on the destination chain. While this design supports composability within the DeFi ecosystem, it breaks the user’s direct ownership of the original asset.
In effect, custody is handed over to the smart contract and, by extension, to the security of the Guardian network. If the contract is exploited or the Guardians act maliciously or fail to respond, user funds may be lost or become inaccessible.
Wrapped tokens also introduce systemic risk, as their value depends entirely on the perceived ability to redeem the underlying asset. If the Wormhole network were to become compromised or inactive, these synthetic assets could become orphaned, with no guaranteed path to redemption.
Execution Guarantees and Failure Modes
Execution in Wormhole is not atomic. The process unfolds in several steps: first, a lock event must occur on the source chain. Then, the Guardians must observe and sign off on the event. Finally, the message must be submitted to the destination chain to mint the corresponding asset. At each stage, there is a risk of failure.
If the Guardian set fails to reach quorum due to downtime, network issues, or collusion, the message cannot be relayed. Likewise, if the relayer does not deliver the signed message, the transaction stalls. Because the system uses wrapped tokens, a partial failure can leave tokens locked on the source chain while the user receives nothing. In more serious cases, duplicated tokens may be created if validation fails.
Wormhole tries to reduce some of these risks by offering message replay features and monitoring tools. However, there is no built-in guarantee of atomicity or refunds. If a failure occurs, user funds may be stuck in limbo, and recovery often depends on manual intervention from the Wormhole team or its backers. This fallback is based on trust rather than enforced by the protocol.
Axelar: Cosmos-Native Messaging with External Trust
The last project we will look at before diving into Portal to Bitcoin is Axelar, which is often considered a smaller sibling of Wormhole and LayerZero. It processed around 89 million dollars in bridge volume over the past month and currently ranks ninth in terms of size.
Let’s take a look at how Axelar approaches cross-chain communication and what it is doing differently from the larger players in the space.
Architectural Design Philosophy
Axelar is an interoperability protocol designed to help blockchains communicate with each other. It uses a system called General Message Passing, which allows smart contracts and users to send tokens, data, or function calls across different chains in a secure and consistent way. Unlike some protocols that focus only on messaging or only on bridging assets, Axelar combines both in one unified system.
At the core of Axelar’s design is its validator set. This is a group of nodes that run a dedicated blockchain called the Axelar network, which serves as a middle layer between other blockchains.
When a user or application initiates a cross-chain action, Axelar validators watch the source chain, confirm the event, and then broadcast that information to the destination chain. On the receiving side, a gateway contract picks up the validated message and performs the required action, such as minting a wrapped token or calling a smart contract function.
This model takes much of the complexity out of cross-chain development. Developers do not need to build custom bridges or manage relayers. Instead, they can use Axelar’s SDKs or APIs while the validator network handles verification and delivery in the background. In this way, Axelar acts as a universal routing layer for cross-chain communication, with a strong focus on usability and scalability.
Trust Assumptions and Validator Dependencies
Axelar’s security relies on its Proof of Stake validator set, which currently consists of 75 validators. These validators are responsible for watching supported blockchains, agreeing on cross-chain events, and relaying verified messages to other chains. Each validator runs a full node and participates in Axelar’s consensus mechanism, which is built on the Cosmos SDK and Tendermint.
The system depends on a supermajority of these validators acting honestly. If more than one third go offline or act maliciously, the network can stop working. If two thirds collude, they could censor or forge messages. Validators can be penalised through slashing if they misbehave, which encourages good behaviour. However, like any Proof of Stake system, Axelar is still exposed to risks such as economic centralisation or validator influence over governance.
For developers, this validator layer is mostly invisible. They interact with Axelar through SDKs or APIs, while the network handles the technical coordination in the background. But for users, the system ultimately depends on Axelar’s validator set staying live, decentralised, and properly incentivised.
Unlike modular protocols where each application chooses its own verifier set, Axelar applies a single global trust model. Every message and bridge event is verified by the same group of validators. This makes development easier and adds consistency, but it limits flexibility when it comes to customising security or trust preferences.
Custodianship and User Asset Control
Axelar uses a lock and mint bridging model. When tokens are bridged, they are deposited into Axelar gateway contracts on the source chain. Once the deposit is confirmed by validators, a wrapped version of the token is minted on the destination chain.
This means that during a bridging event, users give up direct custody of their assets to the Axelar smart contract system, which is ultimately controlled by the validator set. The wrapped token acts as a claim on the original asset, but only as long as the network remains active and the validators behave honestly.
For many users, this process works smoothly, especially when used through wallets or DeFi applications. However, it introduces systemic risk. If the validator network fails, is compromised, or loses access to funds on the source chain, the wrapped assets may become impossible to redeem. There is no built-in fallback or refund system available to users.
Axelar also supports general message passing, so not every message involves user assets. But whenever tokens are part of the operation, whether transferred directly or handled through smart contracts, the safety of user funds depends on the performance and integrity of Axelar’s infrastructure and validators.
Execution Guarantees and Failure Modes
Axelar’s General message-passing framework is designed to make cross-chain execution feel as smooth and native as possible, but the process is not atomic. Operations happen in multiple steps. The gateway contract must detect and emit the event, validators must reach consensus, and the destination gateway must execute the approved message.
Failures can occur at any stage. If the validator set stalls due to downtime, consensus issues, or even validator bribery, the network may become unresponsive. If a specific chain is unreachable, messages involving that chain can be delayed or completely blocked. Although Axelar’s consensus mechanism ensures consistency, it also introduces a central coordination point. The validator set can become a bottleneck for both performance and availability.
Crucially, Axelar does not support atomic swaps or state rollback. If a cross-chain action fails after partial execution—such as a function succeeding on the source chain but failing on the destination—users may end up in an inconsistent or unrecoverable state. There is no built-in mechanism for automatic refunds or retries without manual intervention by developers.
The team is actively working on ways to improve these flows. However, the system still remains exposed to validator-level failures and does not offer the strict atomicity provided by simpler peer-to-peer swap models.
Portal to Bitcoin: Trust-Minimised, Native Interoperability
Now it is time to compare these three giants to the new player on the block: Portal to Bitcoin. While not fully live yet, Portal is already on testnet and positioning itself with a radically different approach to cross-chain communication.
Let’s take a closer look at how it stacks up, and what makes its design fundamentally different from the established models used by LayerZero, Wormhole, and Axelar.
Architectural Design Philosophy
Portal to Bitcoin is a cross-chain interoperability protocol that brings native Bitcoin into the broader multi-chain economy—without compromising on trust minimisation.
Unlike conventional bridges that rely on wrapped tokens, validators, or custodial smart contracts, Portal enables direct peer-to-peer atomic swaps backed entirely by cryptographic guarantees. Its mission is to make Bitcoin a first-class citizen in cross-chain applications—not just a wrapped derivative passing through intermediary infrastructure.
At the heart of Portal is BitScaler, a trustless swap framework built on Bitcoin-native technologies. It leverages Hashed Time-Locked Contracts (HTLCs) to allow users on different chains to engage in atomic swaps: both parties lock their funds under a shared cryptographic condition, and the trade only completes if both sides fulfill their obligations within a set timeframe. If either fails, the contracts automatically return the funds—ensuring binary atomicity, where a swap either fully succeeds or reverts without partial execution or risk.
To achieve scalability, BitScaler extends the concept of channel factories, originally developed for the Lightning Network. These off-chain constructions allow thousands of swaps to occur without incurring per-swap on-chain fees. A single on-chain hook transaction sets up a factory from which users can create and close multiple channels, making high-frequency trading fast, efficient, and fully non-custodial.
The end result is a system where cross-chain swaps happen directly between users—without wrapped assets, without reliance on validators or relayers, and without the need for permissioned liquidity pools. Trust is enforced entirely by Bitcoin’s scripting capabilities and cryptographic design. Portal doesn't bridge Bitcoin—it extends it.
Trust Assumptions and Verifier Dependencies
Portal’s architecture eliminates all reliance on third-party trust. There are no validators, relayers, or external verifiers involved in the swap process. Each trade occurs directly between users, enforced by cryptographic commitments and Bitcoin-native smart contracting primitives. This ensures that fairness and execution are guaranteed by protocol logic—not by intermediaries.
Trust is never delegated. Instead, it is replaced by enforcement. Both parties lock their funds under mirrored cryptographic conditions using HTLCs embedded in Taproot scripts. The moment one party broadcasts the preimage to claim funds, the other can deterministically claim theirs—or recover it via timeout if the counterpart fails to act. There is no reliance on arbitration, no dispute process, and no dependency on liveness beyond the blockchain itself.
This model diverges sharply from consensus-based bridges and interoperability layers that depend on validator sets, quorum decisions, or off-chain uptime guarantees. There is no committee to collude, no relayer network to run, and no middleware to monitor. As long as Bitcoin and the target chain (e.g., Ethereum) maintain liveness and finality, swaps either complete as intended or safely revert. The result is a sharply reduced trust surface and an uncompromising commitment to end-to-end self-custody.
Custodianship and User Asset Control
Portal ensures full self-custody from start to finish. At no point are user funds deposited into bridge vaults, proxy contracts, or custodial smart contracts. There is no wrapping of tokens, no intermediary custody, and no synthetic representations. User funds only exist in one of two states: either fully under their control or temporarily locked in an HTLC with a guaranteed refund path.
Even during a swap, the asset never leaves the user's control without conditions. Ownership transfers only when both parties complete their side of the trade according to the agreed cryptographic terms. If one party disappears, delays, or tries to cheat, the HTLC automatically returns the funds to the original owner. There is no risk of frozen assets, stuck messages, or custody failure caused by protocol bugs or validator misbehaviour.
BitScaler’s node network—comprised of liquidity providers and a validator federation—plays a critical role in routing and execution, but it never has access to user funds. Nodes coordinate swaps through a hub-and-spoke structure and maintain the integrity of off-chain state transitions using Taproot scripts and invalidation trees. Their role is limited to policy enforcement and coordination; they cannot intercept, freeze, or misappropriate assets at any stage.
This strict model of self-custody is especially important for Bitcoin users, who are often highly risk-averse and reluctant to trust custodial systems or complex bridging architectures.
Execution Guarantees and Failure Modes
Portal’s swap model is grounded in binary atomicity: a swap either fully executes or cleanly aborts. There are no partial settlements, intermediary states, or reliance on external consensus. Each step of the process is governed by deterministic, on-chain logic—primarily via HTLCs embedded within Taproot-based channel structures. This ensures that asset state transitions remain entirely local, transparent, and enforceable without coordination from third-party services.
If one participant fails to fulfil their obligations—whether due to going offline, attempting to cheat, or simply delaying—the swap automatically reverts. Funds are returned to their respective owners via pre-agreed refund paths, secured by timelocks and enforced cryptographically. This eliminates the risk of stuck assets, inconsistent channel states, or double-spend vectors.
By removing multi-step coordination, retry loops, and fallback mechanisms, Portal’s architecture simplifies execution and hardens fault tolerance. All edge cases are pre-resolved at the protocol level. There is no dependency on governance, validators, relayers, or off-chain sequencing to guarantee completion. The system functions autonomously, as long as the underlying chains remain final and secure.
Final Thoughts
Over the past two years, protocols like LayerZero, Wormhole, and Axelar have become foundational infrastructure in the multi-chain ecosystem. Their success is measurable. Together, they secure billions of dollars in bridged value, power hundreds of decentralised applications, and enable seamless connectivity between dozens of blockchains. By prioritising composability, developer tooling, and broad chain support, they have helped define what is now considered standard for cross-chain interaction.
But they have all achieved this by making a trade-off. They prioritise speed and flexibility at the cost of security, trust minimisation, and true asset sovereignty. Whether through relayers, validator sets, or guardian networks, each protocol introduces an external trust layer between the user and the blockchain. When it comes to Bitcoin, no other asset class in crypto is more resistant to that kind of trust assumption.
Bitcoin holders are historically conservative—not just in ideology, but in how they manage their assets. Wrapped BTC, whether issued by Wormhole, Axelar, or others, introduces risks related to custody, counterparties, and the potential for exploits, downtime, or depegging. While these risks may be acceptable to more agile, DeFi-native users, they represent a core problem for BTC holders who prioritise self-custody and finality.
This is where Portal to Bitcoin offers a compelling alternative. By enabling trust-minimised, native Bitcoin swaps through atomic execution—without wrapping, without validators, and without synthetic assets—Portal provides cryptographic guarantees that align with the security-first principles of the Bitcoin community.
Portal does not need to match existing protocols in volume today to be relevant tomorrow. It is uniquely positioned to unlock a market segment that has been structurally excluded from DeFi: Bitcoin holders who refuse to compromise.
To sum it up, here is a table with the full comparison.
