Connecting Qubic to Solana: The Qubic-Solana Bridge Explained

Qubic is getting its first direct connection to Solana. The bridge will allow QUBIC tokens to move between both networks, opening access to Solana's large DeFi ecosystem and bringing new liquidity opportunities to the Qubic community.

Here's what you need to know about how it works, who's building it, and when you can expect to use it.

Why Solana?

Solana is one of the most active liquidity and user hubs in crypto. It powers some of the largest DeFi platforms in the space, and attracts a constant flow of users searching for new primitives, yields, and infrastructure to build on.

Until now, Qubic’s compute-first architecture has evolved largely outside of that high-velocity environment.

The bridge changes the direction of flow.

Rather than pulling value away from Qubic, the Solana bridge acts as an access layer; bringing Solana’s users, capital, and attention into the Qubic ecosystem. Qubic holders gain a seamless path to interact with Solana-based liquidity while remaining anchored to Qubic’s underlying compute network. At the same time, Solana users are introduced to Qubic as a new class of infrastructure: a network where computation itself is the product.

In short, Solana provides reach.

Qubic provides substance.

Who's Building It?

Avicenne Studio won the competitive Request for Proposal process with a score of 89.33 out of 100. The Paris-based Web3 development studio has built a strong reputation in cross-chain infrastructure over the past five years, expanding operations to Dubai and delivering more than 25 blockchain products.

Bridge security is not theoretical, it’s one of the most exploited vectors in crypto. Avicenne stands out because their infrastructure has already been tested under real-world conditions: nine-figure TVL, millions of active users, zero major outages, and no known security breaches.

That experience matters when building a bridge meant to move real value at scale.

How the Bridge Works

The Qubic-Solana Bridge uses a lock-and-mint model inspired by Circle's CCTP v2 protocol, a well-tested standard in cross-chain transfers. The design prioritizes simplicity. There are no complex reversal mechanisms or state machines that could introduce vulnerabilities. Once a transfer starts, it completes.

Moving QUBIC to Solana: When you send QUBIC from Qubic to Solana, your tokens get locked in a smart contract on the Qubic side. The bridge then mints an equivalent amount of wrapped QUBIC (wQUBIC) on Solana. Your original tokens stay secured and backed one-to-one.

Moving wQUBIC back to Qubic: Going the other direction, your wQUBIC gets burned on Solana. The bridge then unlocks your original QUBIC tokens from the smart contract. You receive native QUBIC in your wallet.

The process involves three steps:

Step 1 – Lock or Burn: You initiate the transfer by specifying where you want the tokens to go, how much you're sending, and the fee you're willing to pay for the transaction to be processed.

Step 2 – Verification: A network of independent oracles watches for your transfer request. Each oracle independently verifies the details and produces a digital signature. The transfer can only proceed when roughly 75% of oracles agree that everything checks out. No single oracle can approve a transfer on its own.

Step 3 – Release: Once enough oracles have signed off, a relayer submits the verification to the destination chain. The smart contract confirms the signatures are valid, checks that the transfer hasn't already been processed, and releases your tokens.

The entire design ensures that tokens are always backed one-to-one. Nothing gets created out of thin air.

The Oracle Network

Oracles are the bridge's verification layer. The system uses six to eight independent oracles, each holding signing keys for both the Qubic and Solana chains.

These oracles constantly monitor both networks. When they detect a lock event, they independently verify the transfer details and produce signatures. A transfer requires about 75% of oracles to agree before it can proceed. This threshold prevents any single oracle, or even a small group, from approving fraudulent transfers.

Oracles can also act as relayers if configured to do so. Relayers compete to process transactions and earn fees, which creates an efficient market for transaction execution.

Fees

The bridge uses two fee types:

Relayer Fee: This covers the transaction cost on the destination chain. You set this fee yourself when creating the transfer. Higher fees attract relayers faster. If you're technically inclined, you can set this to zero and submit the final transaction yourself.

BPS Fee: A small percentage-based fee applied to the transfer amount. This fee gets split between the protocol treasury and the oracle operators who secure the network. Larger transfers may have different fee tiers, and the exact structure is being finalized.

Both fees come out of the transfer amount, so you know exactly what you'll receive on the other side.

Security Design

The bridge architecture prioritizes security through simplicity rather than complexity.

A multi-signature wallet controls all critical administrative functions. This wallet is operated jointly by Avicenne team members and trusted Qubic community members, requiring multiple parties to agree before any changes take effect. No single person can modify oracle thresholds, upgrade contracts, or adjust fees.

The protocol includes a pause function for emergencies. If unusual activity is detected, authorized parties can instantly freeze new transfers while preserving all existing orders. This can be triggered by human operators or automated monitoring systems.

All oracle signatures are verified against a fixed message structure. This prevents replay attacks and ensures that transfer details cannot be modified after signing. The deterministic verification approach simplifies security audits and reduces potential attack vectors.

Notably, the bridge handles operator misconduct off-chain rather than through automated slashing mechanisms. This design choice reduces smart contract complexity and eliminates an entire category of potential vulnerabilities.

Development Roadmap

The project follows a six-month timeline with clear milestones:

November 2025 – January 2026: Planning Phase The team finalizes the architecture, technical specifications, and development plans for both the Solana and Qubic sides. This phase concludes with a formal specifications review.

January 2026 – February 2026: Core Development

Active building begins. The Solana contracts, Qubic contracts, and oracle/backend systems are developed in parallel. Each track has dedicated developers working simultaneously.

February 2026 – March 2026: Integration

The separate components come together. Integration tests verify that the Solana side, Qubic side, and oracle network communicate correctly.

March 2026 – April 2026: Advanced Testing

End-to-end testing runs the complete user flow from start to finish. The frontend interface gets built during this phase, along with operator contracts.

April 2026 – May 2026: Security Audit

External auditors review all code for vulnerabilities. This is a critical checkpoint before any real assets flow through the system.

May 2026 – June 2026: Launch

Post-audit fixes get implemented and tested. The Qubic core team gives final approval. Mainnet deployment follows, making the bridge available to the community.

Total development time is approximately 80 days. The full project timeline, including testing and audits, spans 180 days.

Future Compatibility

The architecture is designed with multi-chain expansion in mind. While Solana is the first deployment, the core logic can be adapted for other networks. The data structures are built to be compatible with different virtual machines, meaning future connections to Ethereum and other EVM-compatible chains could reuse much of the existing system.

On the Qubic side, the bridge infrastructure remains the same regardless of which external chain connects to it. Adding new chains primarily requires building out the destination-side components and expanding the oracle network's capabilities.

What Does This Means for You?

For $QUBIC holders, the bridge opens doors to Solana's trading venues, liquidity pools, and DeFi protocols. You'll be able to use your tokens across both ecosystems without converting through centralized exchanges.

For Solana users, it provides access to Qubic's unique compute-focused network. The bridge creates a pathway for developers and users interested in Qubic's AI and distributed computing capabilities.

The code will be open source, the governance is decentralized, and the security approach prioritizes proven patterns over experimental complexity. Avicenne's track record with Wormhole and their performance on previous projects provides confidence that the technical execution will meet professional standards.

Development is already underway. The first version is targeted for May 2026.