Performance Architecture in Cross-Chain Protocols: THORChain vs Portal to Bitcoin
Portal's vision is measured against the lived reality of THORChain, revealing where design choices diverge and what consequences they bring for end users.
Cross-chain protocols are judged not only by their ability to support diverse assets but also by their capacity to deliver those assets with speed, consistency, and finality. Performance in this context goes beyond raw throughput. It encompasses a system’s ability to settle transactions quickly, avoid delays and failures, scale under pressure, and offer a reliable user experience. In this report, we explore the performance characteristics of two distinct approaches to cross-chain settlement: THORChain and Portal to Bitcoin.
THORChain has been live for several years, enabling swaps between native Layer 1 assets without wrapping. It uses a Cosmos-based architecture with vaults and validator coordination to orchestrate outbound transfers. Portal, by contrast, is designed around a different philosophy. At its core is the use of HTLCs (Hash Time-Locked Contracts) supported by a coordination layer presenting an alternative design that prioritises determinism and atomicity.
This report presents a comparative analysis of their architectures with respect to performance. The aim is not to make speculative claims, but to assess how each protocol handles latency, transaction determinism, scalability, and user-facing responsiveness. Portal's vision is measured against the lived reality of THORChain, revealing where design choices diverge and what consequences they bring for end users.
1. Latency and Settlement: Streaming Swaps vs Atomic Finality
One of the central performance challenges in cross-chain systems is latency, especially in environments involving Bitcoin or Ethereum where block times are longer and finality is delayed.
THORChain addresses this by maintaining native vaults for each supported chain, governed by its validator set. When a user initiates a swap on THORChain, the process begins with an inbound transaction into a liquidity pool.
Depending on the size of the trade relative to the pool’s depth, the system may opt to stream the swap over several smaller transactions. This mechanism is intended to protect liquidity but often comes at the cost of speed. Streaming swaps, especially those involving large trades or illiquid pools, can take upwards of thirty minutes to an hour to fully settle.
Moreover, THORChain imposes an additional phase of delay after the swap completes. Outbound transactions must be signed by the active vault, and this signing process is limited by throughput constraints.
These constraints are set to improve, with THORChain planning to scale outbound throughput to approximately two transactions per second (instead of six) in the coming weeks. While this represents a significant upgrade, it still does not overcome the structural limitations imposed by the vault system and queue-based transaction handling.
Portal’s design avoids this problem altogether. Rather than relying on shared liquidity pools and outbound coordination, each swap is executed atomically using HTLCs. The logic of the swap is embedded directly in the transaction, with a simple binary outcome: the swap succeeds, or the user is refunded.
There is no streaming, no partial execution, and no requirement for post-settlement coordination. The only latency present is that of the underlying chain’s block confirmation. On Bitcoin, this typically means settlement within one to three blocks. However, with the integration of the Lightning Network, Portal is designed to support instant swaps for small payments, bringing finality down to sub-second latency in specific contexts.
In short : THORChain’s architecture introduces latency through vaults and streaming logic, while Portal simplifies execution by enabling direct, atomic swaps settled purely on-chain.
2. Execution Determinism and Failure Modes
In decentralised systems, determinism is essential to performance. Users must be able to predict whether their transaction will succeed or fail and understand the conditions under which funds will be returned.
THORChain has developed a robust architecture to manage this complexity, combining validator observation, vault-based custody, and queue coordination. This layered design allows the protocol to handle native assets across multiple chains without wrapping or trusted intermediaries, an achievement that very few live protocols have accomplished.
However, this complexity also introduces certain operational risks. Transactions begin with inbound observation by node operators. If this observation is delayed due to node downtime, inconsistent signatures, or software issues, the swap process may stall.
Once triggered, swaps enter an outbound queue where delays can occur due to network congestion, gas misconfiguration, or vault churn events. While these challenges are well understood by the community and the system includes recovery mechanisms to address stuck states, users can still face periods of uncertainty, especially during high activity or network upgrades.
Portal eliminates these risks with HTLCs. The use of HTLCs ensures that a trade is either executed successfully or refunded after a timeout. There is no need for third-party signing, queue handling, or vault approval. The outcome is governed strictly by whether both parties complete the swap within the required time frame and produce the necessary cryptographic proofs. If the other party fails to claim the funds, the sender automatically recovers them. This deterministic execution model ensures that no transaction can be delayed or frozen in an intermediate state.
It is important to note that determinism in Portal does not imply instant success in all cases. A swap can still fail due to a mismatch in fees, timeouts, or network congestion on the base chain. However, these failures result in direct refunds without the need to intervene. From a performance perspective, this clarity is critical. It means users always know the state of their funds and do not need to rely on protocol intervention to recover them.
In short : Portal replaces THORChain’s complex, validator-driven architecture with a deterministic HTLC model where swaps either complete or refund automatically, removing delays, stuck states, and uncertainty.
3. Scalability and Parallelism
Scalability is often interpreted as a function of throughput, but in decentralised systems, it also involves the ability to process transactions independently without bottlenecks.
THORChain’s scalability is constrained by its architecture. Vaults represent single points of coordination. All outbound transactions must pass through these vaults, and their signing must be coordinated by the validator set. This limits how many swaps can be processed in parallel. While multiple vaults may exist over time due to churn, each vault must still coordinate its activity with the broader network.
The forthcoming upgrade to 2 TPS is a meaningful improvement. It will help alleviate some of the outbound queue delays and provide a higher baseline for concurrent processing. However, this figure remains modest compared to what a parallelised system could achieve. Vault-based coordination is inherently centralised within the validator set, which acts as a bottleneck during periods of high activity.
Portal, by design, avoids centralised bottlenecks by allowing each HTLC-based swap to function as an independent transaction. There is no validator set required to approve or sign messages for individual trades. Instead, coordination is handled by the Portal Attestation Chain (PAC), a standalone chain optimised for high-throughput consensus. The PAC is responsible for orchestrating swap intent, tracking execution state, and ensuring synchronisation across participants, without introducing delays into the settlement process itself.
Scalability is achieved through this separation of duties: while the PAC handles coordination rapidly and efficiently, settlement takes place directly on the underlying blockchains. This structure allows many swaps to be initiated and coordinated in parallel, with overall throughput limited only by the base chain’s blockspace and mempool capacity, not by internal constraints within the Portal system
This architectural separation provides Portal with a clear scalability advantage. It allows the system to grow horizontally, processing as many swaps as the chains can handle, without being constrained by shared infrastructure.
In short, THORChain’s scalability is limited by its architecture, whereas Portal has no internal bottleneck and is only limited by the native blockchains themselves.
4. A Tale of Two Swaps: Performance in Practice
To illustrate how performance plays out in real-world usage, consider two users, Alice and Bob, each attempting the same type of cross-chain trade: swapping Bitcoin for Ether.
Alice uses THORChain, a protocol she trusts due to its years of operation and native asset support. She initiates her swap by sending BTC into a THORChain-controlled vault. The protocol observes her transaction and begins processing it. Because the trade is relatively large and the BTC-ETH pool lacks sufficient depth for an immediate full execution, the system opts to stream the swap (Alice is aware of it).
This means Alice's trade will be broken into smaller segments, each executed separately over time to protect pool integrity. As these segments are processed, they are queued for outbound delivery, where they await signing by the active vault. THORChain’s outbound queue operates at a rate that will soon reach two transactions per second, but during periods of high network activity, Alice’s transaction must still wait its turn. She finally receives the full amount of ETH around 45 minutes later, spread across several on-chain transfers, but deposited at once in her wallet.
Bob uses Portal. He initiates a swap by creating an HTLC on Bitcoin. The system locks his BTC in a contract that will release the funds only if a corresponding Ether transaction occurs on the other side. The conditions are clear and binary: either the swap completes, or Bob’s funds are automatically returned after the timeout expires. The order is matched and within one Bitcoin block, the corresponding ETH is delivered to Bob’s wallet. There is no streaming, no outbound queue, and no post-swap processing. The swap is complete and registered on the PAC. Had the transaction failed due to fee volatility or partner unresponsiveness, Bob would have received his BTC back after a fixed time period with no protocol intervention required.
Both Alice and Bob successfully exchanged BTC for ETH. However, their experiences could not have been more different. Alice endured a fragmented, delayed settlement process shaped by system-level constraints: liquidity management, validator coordination, and outbound throttling. Bob encountered a simple atomic transaction governed entirely by cryptographic rules on the underlying chains.
This example demonstrates how performance architecture shapes not just technical benchmarks, but the very nature of user experience. In time-sensitive environments, such as trading, settlement, or payments, these differences can become decisive.
6. Conclusion
THORChain and Portal represent two different architectures of cross-chain performance. THORChain, as a live and widely used protocol, has made significant progress in supporting native asset swaps without wrapping. Its move to increase transaction throughput and streamline vault operations shows a clear commitment to improving the user experience. However, its architecture, rooted in validator coordination, vault queues, and shared liquidity, imposes limitations that are difficult to fully overcome.
Portal presents an architecture built around atomic execution. By removing the need for consensus-based coordination, it offers faster settlement, greater determinism, and more scalable throughput. Validators do not interfere with the swaps; they just coordinate and register them on the PAC. These structural advantages position it as a promising model for the next generation of cross-chain infrastructure.
In comparing the two, one must weigh the maturity of THORChain against the theoretical clarity of Portal. Where THORChain offers proven utility, Portal offers a blueprint for higher performance. This blueprint could help unlock a new standard in cross-chain finance, one where performance is not an optimisation, but a guarantee.