Rujira vs Bitscaler, building the Future of Native Decentralised Finance.
Cross-chain protocols are evolving. While initial focus lay in bridging assets without wrapping or trust, attention is now shifting to building app layers that enable more complex financial logic.
Cross-chain protocols are evolving. While initial focus lay in bridging assets without wrapping or trust, attention is now shifting to building application layers that enable more complex financial logic, composability, and programmability.
THORChain and Portal to Bitcoin represent two distinct designs in this space. THORChain is a live protocol built on a Cosmos-based validator set and vault system, facilitating native asset swaps across chains. Meanwhile, Portal uses Hashed Time-Locked Contracts (HTLCs) and a coordination layer called the Portal Attestation Chain (PAC) to enforce atomic swaps without custody risk or bonded tokens.
Swapping native assets is a great achievement, but unlocking the full potential of DeFi requires more than basic exchange functionality. Yet no solution to date has delivered a truly compelling experience because of centralisation risks, reliance on bridged assets, or the introduction of systemic risks.
THORChain has recently phased out its THORFi stack and introduced Rujira, a dedicated App Layer designed to safely extend functionality. Portal, on the other hand, remains true to its HTLC-based architecture, leveraging Bitscaler to deliver DeFi capabilities without compromising on trust minimisation.
In this report, we explore how Rujira and Bitscaler approach native DeFi, highlighting their architectural choices and the distinct paths they chart toward next-generation cross-chain finance.
Rujira: The App Layer on THORChain
Rujira is THORChain's App Layer, designed to support a new generation of applications by cleanly separating execution logic from the vault infrastructure. Built with the Cosmos SDK, Rujira enables developers to create advanced DeFi applications without interfering with consensus mechanisms or validator operations on the Base Layer.
Specificities of the Design
At the heart of Rujira is the concept of Secured Assets, representations of native assets that are fully collateralised by THORChain vaults. They can be seen as wrapped assets but offer stronger guarantees thanks to THORChain’s decentralised design and multi-year operational resilience.
To obtain Secured Assets, users must deposit their native assets into THORChain’s vaults, receiving a corresponding representation on the App Layer.
Source : THORChain Documentation
By using Secured Assets, native assets held on the Base Layer are shielded from application-level risks. This architecture ensures that any issue on Rujira, such as a contract failure or exploit, cannot compromise THORChain’s core vaults. However, if THORChain itself experiences a failure related to Secured Assets, Rujira could be indirectly impacted. Nonetheless, the overarching objective remains clear: to safeguard native assets from the DeFi risks that have led to major collapses in the past, such as Luna or THORFi.
To reinforce this boundary, Rujira is built with strict limitations. Smart contracts are sandboxed within a secure environment and can only perform two actions: MsgSend and MsgDeposit. They have no privileged access to the Base Layer and cannot mint or burn Secured Assets under any circumstance.
Governance plays a key role in operational safety. THORChain’s Node Operators have access to emergency controls through certain parameters (Mimirs). They can pause specific applications or halt the minting and redemption of Secured Assets if needed. Before any app goes live on Mainnet, it must pass through a vetting process, including contract auditing and deployer address whitelisting.
In the event of a smart contract exploit on Rujira, only the users interacting with the affected application are at risk of losing their Secured Assets. THORChain’s Base Layer remains insulated. It continues to track all accounting and processes asset redemptions independently, ensuring that system-wide solvency is never compromised.
Limitations
While Rujira presents one of the most innovative and elegant models in the ecosystem, it also comes with notable limitations. Let’s explore them:
First, Secured Assets are not true native assets. They function as wrapped representations, issued only after users deposit their actual BTC, ETH, or other tokens into THORChain’s vaults. This creates a dependency on vault solvency and the integrity of THORChain’s infrastructure.
Second, users must give up custody of their assets to THORChain’s vaults, placing trust in the Node Operators to act reliably and securely.
Third, THORChain’s Node Operators have the authority to freeze activity on Rujira at any time. In addition to controlling the native assets, they can determine which operations are permitted and suspend activity if needed.
Fourth, there is an asymmetry in risk between the App Layer and the Base Layer. Rujira is designed to shield THORChain’s Base Layer from potential app-level failures, but not vice versa. Suppose the Base Layer experiences a protocol-level failure. In that case, Rujira applications may become insolvent, even if the applications themselves are securely built, since their underlying assets would no longer be backed.
Fifth, Rujira’s growth is heavily dependent on the Base Layer. Its capacity to expand, evolve, and scale is limited not only by the Base Layer’s security budget, the total value of Secured Assets that can be minted, but also by the code itself. Node operators maintain significant control over operations, and the system’s design imposes strict constraints. Together, these factors may restrict Rujira’s pace of development and limit the scope of its ambitions.
In sum, Rujira provides a secure, conservative framework for DeFi experimentation on top of THORChain. But it does so with trade-offs in custody, validator control, and dependency on the Base Layer infrastructure.
Bitscaler, DeFi on Portal
Bitscaler is Portal’s execution layer, designed to enable programmable cross-chain finance without compromising Bitcoin’s trust-minimised principles. Rather than relying on custodial bridging or validator-led vaults, Bitscaler uses advanced Bitcoin-native mechanisms such as channel factories, Taproot scripting, and HTLC logic to coordinate complex financial operations in a fully non-custodial environment.
But before diving into Bitscaler, some key definitions have to be presented:
Lightning is a Layer 2 protocol built on Bitcoin that enables fast, low-cost payments by moving transactions off-chain. It helps scale Bitcoin by reducing the need for every transaction to be recorded on the main blockchain.
A payment channel is a two-party setup where users lock funds in a smart contract and can then exchange unlimited payments off-chain, updating balances privately. Only the final state is settled on-chain, saving time and fees in all payments and transactions between the two parties.
A Channel Factory extends this idea by allowing a group of users to create multiple payment channels from a single on-chain transaction. It acts like a shared container, enabling participants to open, close, and update channels among themselves without interacting with the blockchain each time.
Source: Lightning Network
BitScaler Specificities
At its core, Bitscaler leverages a modified channel factory architecture to create a scalable network of off-chain, multi-party channels that can execute trades, automate market making, and settle contracts without touching L1 except during the settlement stage.
The channel factory model allows multiple subchannels to be opened and closed within a single on-chain commitment, enabling high-throughput financial applications with minimal base-layer footprint.
These subchannels work like a hub-and-spoke system: a central group of validators connects to multiple liquidity providers through simple two-party payment channels. Traders can then swap assets off-chain by using special time-locked contracts in these channels. This setup enables fast, low-cost trading directly on Bitcoin without wrapped Bitcoin.
Hub - Source : BitScaler Documentation
Importantly, Bitscaler uses non-custodial delegation mechanisms that allow LPs to delegate control over their subchannels under defined conditions, without relinquishing ownership of funds. This opens the door to agent-managed liquidity strategies while preserving full user custody.
But Bitscaler doesn't stop at Bitcoin. Its architecture is inherently cross-chain capable. By embedding HTLC logic and synchronising Merkle-tree-based state commitments across multiple chains, Bitscaler enables atomic, trust-minimised swaps between Bitcoin and ecosystems like Ethereum, Solana, or any chain that supports basic scripting primitives. This capability forms the foundation for a new class of cross-chain DeFi applications.
With Bitscaler, users can trade BTC against ETH, SOL or stablecoins without custodians, wrapped tokens, or external bridge infrastructure. More than just asset swaps, it enables complex interactions like cross-chain lending (for example, depositing BTC as collateral to borrow USDC on another chain), decentralised perpetuals settled in Bitcoin, and yield strategies that span multiple ecosystems. All coordination happens off-chain through Bitscaler’s execution network, and settlement is only finalised once every condition across chains is cryptographically met, ensuring atomicity and eliminating risks from MEV extraction, front-running, or bridge-based failures.
Limitations
Despite its elegant design, Bitscaler is not without constraints. The current implementation assumes a fixed participant set during the initial hook transaction, changing participants later requires an on-chain update, which reduces factory flexibility. This is especially limiting for applications like pooled liquidity, where dynamic membership is valuable.
In addition, the reliance on custom coordination logic and HTLC-based swaps introduces a steep technical learning curve for developers unfamiliar with Bitcoin’s advanced scripting paradigms but also the users. This could limit onboarding and adoption compared to ecosystems with more familiar smart contract tooling.
Finally, while Bitscaler avoids custodial risk, it also lacks the programmable generality of platforms like EVM. Logic must be explicitly encoded via policy templates and scripted coordination, which restricts complex interactions or composability between apps.
Nonetheless, Bitscaler represents a credible and innovative path forward for Bitcoin-native DeFi, one that embraces Bitcoin’s constraints while offering a composable, performant, and trust-minimised application layer for the future.
Outlook and Final Thoughts
Cross-chain finance is evolving. Early efforts focused on moving assets between chains without relying on custodians or wrapped tokens. Today, the challenge is bigger: how to build financial applications that are secure, scalable, and work seamlessly and natively across chains. Rujira and Bitscaler represent two distinct responses to that challenge.
Rujira, adds programmability to an already-proven vault system. It lets developers build DeFi applications using Secured Assets under control. Applications are restricted to a controlled environment, with THORChain’s Node Operators retaining oversight and intervention rights. This provides safety and predictability, but it comes with trade-offs. Users must give up custody of their assets, and the system depends on THORChain’s base layer to remain operational and solvent. If the base layer fails, applications on Rujira could be at risk.
Bitscaler, by contrast, removes these dependencies entirely. It doesn’t rely on vaults, validators, or tokenised representations. Users keep control of their assets at all times. Financial activity, whether it’s trading, lending, or cross-chain settlement, happens off-chain and only finalises if every condition across all parties and chains is met. This atomic structure removes the need for trust and prevents partial or failed execution. There is no central point of custody, no validator intervention except for coordination, and no systemic risk from the base layer.
The difference is clear: Rujira is secured through managed custody and layered governance, while 8Bitscaler is secured through user custody and strict atomicity.
As the next phase of DeFi takes shape, both models will play a role. Rujira extends THORChain’s features. Bitscaler turns Bitcoin into a base for non-custodial, cross-chain automation. Together, they signal a future where users will be able to interact seamlessly between chains.