Thierry Design Portfolio - Apollo, BTC Cross-chain Protocol

Apollo is a cross-chain protocol bringing Bitcoin liquidity to Solana. I redesigned the deposit flow, turning technical features like Deposit Address creation into a familiar, exchange-like experience. Reducing friction and building trust for BTC holders entering Solana DeFi.

UI Design

UX Design

Product Strategy

2024/10 - 2025/09

CLIENT OVERVIEW

CLIENT

DATE

ROLE

Optimizing the

BTC-to-Solana Wrapped Asset Experience

The Story

Apollo by Zeus Network is a cross-chain gateway for wrapped Bitcoin. Users can lock their native Bitcoin (BTC) on the Bitcoin mainnet and mint equivalent zBTC on Solana, enabling the “digital gold” traditionally idle in wallets to participate in Solana’s fast, low-fee DeFi ecosystem. While Bitcoin remains the most trusted digital asset, its mainnet limitations keep most BTC liquidity idle. Apollo was designed to unlock this liquidity by enabling users to mint zBTC on Solana and participate in fast, low-fee DeFi applications.

However, by 2025, the wrapped BTC landscape has become far more competitive, not weaker, but more mature. zBTC struggled to scale because its minting flow relied solely on native BTC deposits, creating a higher entry barrier. The cross-chain waiting period introduced psychological friction during onboarding, and the Solana-native design made it difficult to attract DeFi users whose capital was primarily in USDC or USDT rather than idle BTC.
As a result, Apollo’s initial supply growth fell short of expectations. Institutional partnerships progressed more slowly than planned, and overall adoption plateaued.  The challenge shifted to reducing cross-chain friction, rethinking user motivations, and attracting new sources of capital beyond the existing pool of Bitcoin holders, in order to break through the cold-start problem.

the Challenge

Cross-Chain Experience on Mobile

Apollo’s minting and redemption processes involve both Bitcoin and Solana, making the flow complex and information-heavy. As a decentralized application (dApp), users must operate through the In-App Browser within their crypto wallets.

However, Apollo’s early design required users to connect both Bitcoin and Solana wallets simultaneously within the same wallet app, a setup supported only by a few wallets such as Phantom or certain exchange wallets. This limitation made it difficult for most users to complete the minting process on mobile, as key interactions like wallet connection, transaction confirmation, and progress feedback became less intuitive.

How might we redesign the cross-chain experience within limited technical conditions and screen space, enabling users to complete the process smoothly?

How to turn additional technical steps into potential design opportunities?

In the early smart contract architecture, users had to first deposit BTC into a temporary vault (Hot Reserve), after which the system parsed their Solana address to complete the zBTC minting.
Because each Bitcoin transaction requires around 10 minutes for confirmation, the overall process could take up to an hour, resulting in a poor waiting experience.
To improve this, the engineering team upgraded the underlying architecture so that users could create a dedicated deposit address linked to their Solana wallet during their first use. This allowed BTC to be sent directly into cold storage (Cold Reserve) and reduced the waiting time to about thirty minutes.  

However, this improvement also introduced new design challenges.
Users now need to pay an additional setup fee to generate this deposit address, a step uncommon in most DeFi products. The key question for the product designer became:

How might we reframe this setup step into a clear value exchange where users see the address creation fee not as friction, but as the foundation of a secure and seamless cross-chain experience?

Market & User Analysis

After launch, Apollo’s zBTC minting volume remained low, indicating that the product had yet to achieve market adoption. Unexpectedly, on July 1st, a large redemption of 18 cbBTC → BTC occurred — nearly 10% of Apollo’s total BTC reserve.  Because Apollo promotes a permissionless mechanism, allowing any on-chain wrapped BTC with verified reserves to redeem native BTC without KYC, the system worked exactly as designed — yet it also exposed a deeper risk: Decentralization fosters trust, but it also weakens active control over reserves.
This incident led the team to impose a daily withdrawal cap — and it made me step back to think more deeply:

Who are our users?

What motivates them?

And how are we really different from other wrapped BTC products?

Question 1.

Who are Apollo’s users?

Identifying Apollo’s users proved to be more complex than expected.
Based on on-chain data from the Growth Team, I found that most zBTC holders came from swaps rather than minting, indicating that many users were trading zBTC as a liquid asset rather than minting it with BTC.

For withdrawals, the data showed that frequent arbitrage traders often converted their assets back into zBTC after completing trading cycles, then used Apollo’s permissionless withdrawal feature to redeem native BTC. These users were experienced DeFi players who valued Apollo’s KYC-free redemption as a flexible exit route.

However, the deposit side remained more ambiguous.
Without direct user surveys — and considering how strongly BTC holders value anonymity, I could only infer behaviors from community discussions. Some users joined out of curiosity, while others were drawn by short-term incentives and reward campaigns from the “zBTC DeFi Vault.”

Ultimately, the research suggested that Apollo’s user base was fragmented: sophisticated DeFi traders using Apollo as a liquidity tool, and casual users testing the platform for incentives.

This reinforced a key realization:

Apollo lacked a clearly defined core audience, making product focus and long-term strategy difficult to establish.

Question 2.

What motivates Wrapped User to participate?

zBTC

Zeus

cbBTC

Coinbase

xBTC

OKX

Due to limited access to on-chain analytics resources, I combined market feedback from the Growth Team with Perplexity and Grok AI to better understand the positioning and user landscape of wrapped BTC.

Using Grok’s task automation, I tracked daily discussions and news around zBTC, cbBTC, and xBTC. The results revealed a clear narrative contrast — while cbBTC and xBTC focused on multi-chain expansion and ecosystem integration, zBTC’s messaging centered on its “permissionless” and “KYC-free” nature.
This led me to question:

Is “permissionless” truly a value that wrapped BTC users care about?

Further analysis suggested that wrapped BTC users are quite different from long-term BTC holders.
They are primarily DeFi players operating with USDC/USDT as their main assets, experienced in lending, leverage, and staking — with most profits settled in stablecoins.
For them, wrapped BTC is a liquid instrument for trading and yield, not a long-term store of value.

This insight revealed a critical challenge for Apollo: its “decentralized” and “KYC-free” advantages may not resonate with its real user base.
When the target audience hardly overlaps with BTC holders, Apollo must redefine the value and positioning of zBTC within the DeFi ecosystem.

Question 3.

Wrapped BTC as a Financial Product & Competitive Landscape

cbBTC

xBTC

zBTC

Cross-chain Cost & Transferability

DeFi Liquidity & Yield

Mint Capacity / Circulating Supply

Overall Fit & Market Positioning

Very low
Internal bridge

High
TVL $1B above
low slippage

High
4.6B USD BTC
backed

Strongest

High liquidity
multi-chain support

Medium
LayerZero bridge

Medium
TVL $300–400M

Medium
$200–400M

Good

Strong expansion potential, but lower market share

Medium-low
no multi-chain support

Low-medium
TVL only tens of millions

Low

less thant

1,000 BTC

General
Strong decentralization narrative but lacks scale

Wrapped BTC behaves like a financial product, similar to blue-chip assets, driven by long-term value preservation and yield opportunities.
Within Zeus, however, zBTC was often positioned as a marketing partnership rather than a product to be managed strategically.  This led to a lack of long-term planning and user insight, weakening its market presence.

While wBTC, cbBTC, and xBTC built trust through custodianship, liquidity, and exchange credibility,  zBTC’s “permissionless” advantage struggled to translate into adoption, especially among DeFi users who prioritize yield and liquidity over decentralization.

How might we turn zBTC’s permissionless nature into a true differentiator — a value proposition rather than an adoption barrier?

Design iterations

previous design

MVP Version

In Apollo’s early design, users were required to first connect their Solana wallet and then bind a Bitcoin wallet to create a receiving account. Each Bitcoin–Solana wallet pair would generate a dedicated deposit and withdrawal account, ensuring on-chain security and address accuracy.

However, this structure introduced significant friction: users had to reconnect the correct wallet pair every time before performing any action.

We soon identified that our initial account architecture was highly prohibitive for mobile users. Since Phantom was the only wallet at the time supporting both Bitcoin and Solana natively, we were forced to restrict mobile access entirely, a significant barrier given that the majority of Web3 users are mobile-first. Most of our potential audience, often attracted by high-yield DeFi opportunities discovered on X (Twitter), prefer managing dApps via mobile wallets. Forcing them to switch to a desktop to complete a cross-chain transaction severely stifled our growth potential.

This disconnect created a massive drop-off in our conversion funnel. Users discovered the value on mobile but were lost in the 'Desktop-only' friction.

Furthermore, the initial minting process suffered from a lack of immediacy. To properly identify depositor addresses, the legacy contract required a dual-deposit workflow and six Bitcoin confirmations, totaling nearly 60 minutes. Even after the minting was complete, zBTC was held in a relay address, requiring users to manually 'claim' their assets before they could be used in the Solana DeFi ecosystem. This cumbersome and time-consuming experience caused initial curiosity to evaporate quickly; following a brief hype cycle, our minting volume began to stagnate as the friction outweighed the incentives."

ACCOUNT CREATION

After the user connected to a new Bitcoin wallet, they need to bind with Solana wallet to create a deposit/withdrawal account.

NEED TO CONNECT BOTH WALLETS

To create a deposit account, users had to connect both Solana and Bitcoin wallets every time they used Apollo.

VISUAL HIERARCHY ISSUE

The “Pending Transaction” panel sits below the first fold, making it easy to miss.  Meanwhile, the top-right toast (Success!) draws more attention, misleading users into thinking the minting process is complete.

misleading status

The “Success” message indicates that the Solana-side transaction has been confirmed, but minting isn’t actually completed until both Bitcoin and Solana transactions are finalized.
This status often misleads users into thinking their minting process is done.

previous design

Version 2.

In Web3, the user experience is intrinsically tied to the underlying smart contract architecture. With our protocol upgrade, we introduced a 'Unique Deposit Address' mechanism. This system allows users to generate a dedicated Bitcoin address permanently bound to their connected Solana wallet. Once BTC is sent to this address, the minted zBTC is automatically distributed to the paired Solana wallet.

This architectural shift optimized our confirmation threshold from six blocks to three, cutting the waiting time by 50%. From a design perspective, I had to redefine the minting experience to support two distinct interaction scenarios:

UI-guided deposits for active sessions and direct-to-address transfers for users who prefer an 'exchange-like' deposit experience.

Benchmarking: Adopting an 'Exchange-like' Mental Model
To define the optimal workflow for our new architecture, we benckmarked against Lombard (LBTC), a prominent WBTC protocol on Ethereum. Lombard offers a versatile entry model: users can either connect a Bitcoin wallet directly or deposit via an external wallet to a designated address without a primary connection. This dual-path approach closely aligns with Apollo’s upgraded contract logic.

Specifically, I analyzed Lombard’s 'external deposit' workflow, which is categorized into four primary stages:"
① Enter deposit amount → ② Confirm service fee → ③ Verify the destination address → ④ Copy the address and manually complete the transfer.

Reference : Verify the Destination address

After the user enters the deposit amount, Lombard displays a clear minting summary showing the final delivery address and target blockchain network, helping reduce the risk of misoperation.

Reference : Copy the deposit address

The system then generates a dedicated Bitcoin deposit address. The deposited amount is automatically deducted for service fees and, once confirmed, is bridged into LBTC — making the entire minting process more transparent and traceable.

We tried to bring the same idea into Apollo, but the dual-option structure surfaced new usability challenges.

The Cost of Entry: A Non-standard Friction

To manage engineering resources and operational costs, we implemented a creation fee for the 'Deposit Address.' This requirement is non-standard in the DeFi landscape, where users expect zero-cost onboarding. I identified this as a critical friction point: users might abandon the process before minting and switch to fee-less WBTC competitors, directly impacting our conversion rates and market share.

The Paradox of Choice in the Interface

Our UI was required to present both 'Connect Bitcoin Wallet' and 'Use Deposit Address' as high-priority options.

This dual-path approach risked creating cognitive overload. Without a clear hierarchy or a compelling value proposition for the new method, users might either stick to the friction-heavy traditional way out of habit or experience decision paralysis, ultimately failing to recognize the convenience of the deposit-based system.

To cater to different user preferences, the team requested a prominent toggle for switching deposit methods at the very top of the minting flow. While this added flexibility, it introduced unexpected complexity and diluted the intuitive nature of the original interface. Furthermore, a looming marketing deadline severely compressed the design exploration phase, leaving little room for extensive UX validation before launch.

The V2 release didn't just cause user uncertainty—it sparked intense internal debate. One of our Co-Founders felt that the dual-option approach was inherently unintuitive and even suggested scrapping the 'Deposit Address' feature entirely. This created a new, critical challenge:

How might we   

① help users make a clear choice between wallet connection and deposit address, while keeping the interface clean and intuitive?  

② better communicate the value of the deposit address to reduce drop-off during account creation?

Optimizations

optimization 1

Deposit Address Creation Process

Problems

Lack of Clear Action Expectations

Users were unsure what would happen after clicking Create Account, as this is not a common pattern in DeFi products. Many did not realize that the Deposit Address is the final outcome of creating an account, resulting in a disconnect between action and expected result.

Information Overload and Poor Scanability

Excessive explanatory text and overlapping information hierarchy made the screen difficult to scan. The lack of clear next-step guidance often caused users to pause or abandon the flow.

Emotional Curve: Confusion → Skepticism → Doubt

Based on internal discussions and simulated personas, we observed a likely emotional progression
during this flow:

Confusion – “What is this address for? Why do I need it?”

Skepticism – “Why do I need to pay before I even deposit anything?”

Doubt – “Why can’t I mint directly? What value does creating this address give me?”

Design Solution

After clarifying the core issues, I designed a three-step walkthrough to help users progressively understand the meaning and value of the Deposit Address during the account creation process. The flow is structured into three stages:

Wallet Linking

Explains that Apollo creates a dedicated Bitcoin Address for the user and automatically links it to their Solana wallet.

Cross-platform Deposits

Communicates that BTC from any source, centralized exchanges or single-chain wallets, can be deposited directly to mint zBTC.

One-time Setup, Lifetime Use

Highlights the long-term value behind the account creation fee: once the address is created, it can be used permanently.

Visual Cues to Clarify the Concept

Using visual illustrations paired with concise text to communicate the value of each step, ensuring that users can quickly grasp the purpose of the Bitcoin Account—even without reading the full copy.

Auto-played progress bar

Each steps will auto-played 4 seconds, users can easily rewind/forward or even skip the guidance through the control buttons.

Once the transaction is signed, the system immediately displays the user’s Deposit Address in QR code form. After discussing with the Growth Team, we identified that asking users to pay to “create an address” could feel off-putting. To align expectations, we renamed the Deposit Address to Bitcoin Account Address, reframing the step as an account-opening process rather than simply generating an address.

Ultimately, this redesigned flow answers a fundamental question:

How can BTC participate in Solana DeFi?
Users now only need to create an account and deposit into their Bitcoin Account to get started.

Mobile-First Deposit

For users operating on a single mobile device, the 'Download' feature is essential. It allows them to save the QR code image, then upload it directly to exchange deposit forms (e.g., Binance, Coinbase), bypassing the impossible self-scan and eliminating copy-paste errors.

Enhancing the Moment With Background Depth While Keeping the QR Code Central

This modal represents the user’s first successful account creation on Apollo. I used a subtle, visually rich background to elevate the experience, while ensuring the QR code remains the dominant visual focus.

reference

When analyzing onboarding patterns in other financial products, I looked closely at Revolut’s approach. Revolut uses an auto-playing walkthrough, guiding users through a sequence of lightweight animations that quickly communicate the product’s core value and usage scenarios.
Each step focuses on a single concept, paired with clear visual cues and concise titles, allowing users to grasp the idea within seconds while reducing cognitive load throughout the onboarding experience.

Result

This redesign brings several meaningful improvements to Apollo’s product positioning and overall user experience:

Enhancing Post-Setup Feedback

In the previous flow, users were redirected back to Apollo’s main interface immediately after completing account creation. Without any clear feedback, they often couldn’t perceive the actual value of the fee they had just paid.

In this redesign, I focused on strengthening the post-setup experience. Once the account is created, the system now instantly displays the user’s unique Deposit Address, presented as a QR code. This visual element reinforces a sense of ownership—“I now have my own address”, and enhances the perceived value of the setup action.

Users can scan or save the QR code to deposit BTC directly, whether through a centralized exchange (CEX) or a single-chain wallet, allowing them to start minting zBTC immediately.

Expanding Reach to a Broader User Base

Many retail investors typically purchase BTC on centralized exchanges or accumulate it through DCA (dollar-cost averaging). This design allows Apollo to engage BTC holders who previously couldn’t participate in the zBTC ecosystem, effectively broadening its accessible user base.

Benchmarking the Minting Experience with Centralized Competitors

Previously, Apollo’s minting process required manual interaction through the interface, users had to input amounts, confirm transactions, and wait for completion. This flow was overly technical and less appealing to those new to DeFi.

In contrast, Coinbase’s cbBTC introduced a much simpler logic: users only need to send BTC to a designated address to automatically complete the minting. This “as simple as sending money” model lowers the entry barrier and aligns with traditional financial behaviors users already trust.

Inspired by this approach, I redefined the Deposit Address as a central interaction point rather than a technical setup. After account creation, users immediately receive their dedicated address; by sending BTC to it, the system automatically mints zBTC.

This change not only elevated the visibility and significance of the Deposit Address within Apollo’s product experience but also aligned the overall minting flow closer to leading centralized competitors.

optimization 2

Minting Process

Problems

Lack of Clear Action Expectations

The interface presented two deposit methods without explaining their differences. Users were unsure which option to choose, and the repeated simulation screen in the Deposit Address flow increased confusion.

Unclear Role of the Deposit Address (Bitcoin Account)

Users could not understand how the Deposit Address fits into the minting journey or why it was required, weakening their confidence to proceed.

Insufficient Guidance Through Irreversible Steps

Critical steps lacked visual cues and next-step expectations. Users were also unaware that the minting process could take up to 30 minutes, leading to premature abandonment.

Weak Trust Indicators

Key trust-building signals—such as TVL and ecosystem adoption for zBTC—were missing, making the product feel less credible compared to industry expectations.

Emotional Curve: Confusion → Hesitation → Misinterpretation

Through internal discussions and heuristic evaluation, we observed a typical emotional progression:

Confusion – “Why are there two ways to deposit? What’s the difference?”

Hesitation – “Should I connect my wallet or create an address first?”

Misinterpretation – “Why did the interface jump to an address? Did the flow break?”

Solution 1
Streamlining the Minting Interface

The core goal of this iteration was to reduce decision friction and clarify the hierarchy of actions. I focused the main user path on “Connect Bitcoin Wallet”, while intentionally lowering the prominence of the Deposit Address option. Instead of placing both actions side by side, Deposit Address is now presented as a secondary QR Code shortcut, allowing users who have already created an address to access it quickly without interrupting the main flow.

This decision was based on the updated onboarding flow: since users now learn the purpose and value of their Bitcoin Account during the creation process, the minting screen only needs to serve as a quick-access entry point.

Also, I refined the overall input field structure, simplifying visual lines and introducing clear cross-chain indicators (“Deposit from Bitcoin / Receive on Solana”). This visual distinction reinforces the concept of a cross-chain minting process, helping users differentiate it from a typical single-chain swap.

After internal testing, the team aligned that the redesigned flow significantly improved clarity, efficiency, and decision confidence.

former design

More borders wrapped around the input fields, making the entire section appear visually heavy and block-like.

after simplified

Reduced the number of borders and lowered their opacity, allowing the visual focus to shift toward the numbers instead.

Solution 2
Addressing Mobile Wallet Limitations

To resolve the previous limitation where mobile users were unable to mint via Apollo, I adjusted the button hierarchy on the mobile interface.

On mobile, the primary action now displays “Display Bitcoin Account”, showing the user’s dedicated QR Code instead of prompting a wallet connection.

This change reflects real user behavior: most BTC holders prefer keeping their assets in native Bitcoin wallets or exchanges rather than multi-chain wallets like Phantom.

By prioritizing direct access to their Bitcoin Account, users can copy or scan the QR Code to deposit BTC from any exchange or wallet, completing the minting process without connecting wallets.

This enhancement opened up the mobile experience, allowing more BTC holders to participate seamlessly in zBTC minting while maintaining a consistent and intuitive cross-platform design language.

Solution 3
Strengthening the Role of the Bitcoin Account in Apollo

In the previous design, the Bitcoin Account, while essential for minting zBTC is lacked a clear and persistent presence within the overall product architecture. Users typically encountered the address only during setup, and had no intuitive way to retrieve it later. This not only introduced friction but also limited its potential as a primary interaction point for cross-chain activity.

In this iteration, I reframed the Bitcoin Account’s role from a technical configuration to a core element of the user’s account system. By positioning it alongside the user’s Solana wallet address, the Bitcoin Account becomes an always-available resource, easy to locate, reference, and reuse across sessions.

This repositioning helps users form a more accurate mental model: the Bitcoin Account is their persistent identity endpoint on Apollo, which they can use from any wallet or exchange to interact with the platform.

Solution 4
Enhancing Real-Time Feedback After Minting

Apollo’s original “Success” toast only reflected the Solana-side confirmation, not the full cross-chain minting process. This caused users to falsely assume the mint was complete, while the actual progress panel remained hidden below.

To fix this, I replaced the toast with a dedicated Notification System that:

Surfaces all active deposit and withdrawal transactions
Explains each processing stage (e.g., Verify = confirming BTC arrival on Bitcoin chain)
Provides direct links to ZeusScan for transparent cross-chain visibility

This redesign gives users a clear sense of progress: what’s happening, why it matters, and how long it takes, reducing confusion and reinforcing trust throughout the minting process.

Result & Takeaway

The optimization work did not directly translate into growth in zBTC minting volume. The primary reason lies in user behavior and the inherent constraints of the product itself.

Most BTC holders are long-term investors with low transactional activity, and they tend to be cautious toward new, non-custodial, and unproven decentralized products.

More importantly, wrapped BTC is fundamentally a financial product, and adoption is driven by clear utility and yield opportunities. Because zBTC was introduced from a technology-first perspective rather than a market-first strategy, its ecosystem lacked compelling incentives and liquidity depth. In this context, even a highly refined minting flow cannot independently create demand.

Market research also revealed a deeper structural limitation:

Apollo’s current design restricts the sources of capital entering the zBTC ecosystem.

Users can only mint zBTC using BTC. DeFi users, who mainly hold USDC/USDT to move between assets cannot directly mint; they can only swap for existing circulating zBTC. As a result, zBTC's growth becomes bottlenecked by the limited supply minted by BTC holders or institutions.

From a product strategy perspective, Apollo would benefit from creating multi-asset entry points into zBTC. For example, allowing users to “Deposit USDC → Auto-buy BTC → Auto-mint zBTC,” similar to DCA services or cross-chain aggregators.

This shifts the ecosystem from a passive, BTC-only inflow model into a more open financial product capable of attracting new capital across user segments, helping zBTC grow beyond the constraints of single-source liquidity.

english