XO Wallet
Overview
XO Wallet was the first non-custodial wallet built for Telegram inside the Kaspa ecosystem. Users could store KAS and its related tokens, manage their seed phrase, and secure their funds through a layered security model purpose-built for the risks of a third-party messaging platform.
I joined before anything existed. No brand, no screens, no flows. Over two phases I designed the full product: Telegram mini app first, then a native app, along with the promotional motion content used to launch both.
The product launched to a selected alpha group, received strong positive feedback, and moved to open beta, where it attracted over 1,000 signups in its first week from a community of 6,000.
Role | Senior Product / Visual Designer (sole designer) |
Team | CEO, product manager, dev team |
Engagement | Full-time at Xodex |
Timeline | Two phases, 8 weeks each (4 x 2-week sprints per phase) |
Surfaces | Telegram mini app, native app, promotional motion assets |
The Problem
Non-custodial wallets in crypto typically require users to manage a seed phrase and trust that the application storing access to their funds is secure. On Telegram, that trust problem is compounded: the platform is a third-party service outside your control, meaning a compromised Telegram account could mean compromised funds.
The Kaspa ecosystem had no dedicated wallet that addressed this. XO Wallet was built to be that product.
Understanding Who I Was Designing For
The Kaspa community skews toward technically engaged users who understand self-custody and care deeply about security. But the product also needed to be accessible to newer users who were coming into Kaspa from adjacent crypto communities. I designed for both.
Persona 1 |
|---|
The Self-Custody Believer |
Profile: 25-40 years old. Holds crypto across multiple wallets. Has strong opinions about seed phrase hygiene and would not use a custodial product. Already familiar with Kaspa. |
Goals: Store KAS securely. Understand the security model clearly. Have a recovery path that does not depend on any single service staying alive. |
Design implication: The two-shard security system needed to be explained clearly, not hidden. The private key export and shard removal features needed to be accessible but not buried. |
Persona 2 |
|---|
The Kaspa Community Member "I've been in the Kaspa ecosystem for a while and I just want a wallet that works properly." |
Profile: 20-35 years old. Active in the Kaspa community. Not necessarily a security expert but understands the basics of non-custodial wallets. Discovered XO Wallet through the community. |
Goals: A clean, fast wallet that feels native to the ecosystem. Easy deposit and withdrawal. Confidence that funds are safe without having to think about it constantly. |
Design implication: Onboarding needed to be fast with security handled quietly in the background, not as a series of friction points upfront. The security model should feel protective, not complicated. |
Persona 3 |
|---|
The Multi-Chain User (Phase 2) "I hold Kaspa but I also hold SOL and ETH. I don't want a different app for each chain." |
Profile: 25-40 years old. Manages assets across multiple blockchains. Technically comfortable with network switching, gas fees, and chain-specific quirks. |
Goals: Switch between networks without confusion. See the right balance for the right chain at all times. Trust that the app handles chain routing correctly. |
Design implication: Phase 2 introduced network selection and chain-switching states as a core UX problem. Every balance, transaction, and address display needed to be chain-aware. More screens, more edge states, more potential for confusion. |
Phase 1: Kaspa Wallet on Telegram
The security model
The most technically complex decision on this project came from the security lead: split the user's Telegram auth token into two shards. One shard stored on XO's encrypted cloud. One backed up manually by the user. Neither alone can grant access. If a Telegram account is breached, the funds remain inaccessible without both shards.
This was the right security call. As the designer, my job was to make sure it introduced zero felt friction for the user.
The solution was to handle shard creation silently during onboarding. The user receives one confirmation message that their secure shard has been created, and that is the full extent of their interaction with it. From there they move directly into PIN setup and seed phrase backup, presented as cards inside the app in a clear, sequential flow. The shard system protects them without them ever having to understand it.
If a user later wants to remove their shard from Telegram, for example to transfer the wallet to a different account, that option lives in app settings. It is findable without being prominent.
Onboarding flow
The first-time experience was designed to be fast. The goal was to get the user from zero to wallet setup in the minimum number of steps, then lead them through backup as a separate, guided flow rather than a blocker.
Onboarding sequence: account creation, shard creation (background, one confirmation), PIN setup, seed phrase backup prompt (card-based, skippable but persistent). Users who skipped the backup were reminded on their dashboard until it was complete.
The Telegram mini app constraints
Designing inside Telegram's mini app environment means working within WebView constraints: limited native gestures, no access to system-level biometrics at the time, and a viewport that can shift unexpectedly based on keyboard state. Navigation patterns had to be simple and predictable. Every interactive state had to be tested against keyboard-open scenarios.
The advantage of the mini app model was distribution. No App Store, no install barrier. Users could open the wallet directly from a Telegram link, which aligned with how the Kaspa community operated.
Phase 2: Multi-Chain Expansion
Adding Solana and Ethereum was not just a feature addition. It was an information architecture problem.
A single-chain wallet has one address, one balance, one transaction history. A multi-chain wallet has to answer: which chain are you on right now, what is your address on that chain, what is your balance on that chain, and what happens when you try to send to an address on a different chain.
Every screen that showed a balance, address, or transaction history had to become chain-aware. Network selection was added as a persistent context at the top of the app. Chain-switching introduced empty states, loading states, and error states that did not exist before. The number of screens and edge cases roughly doubled.
The native app launched alongside Phase 2. Without the Telegram platform risk, the two-shard system was not needed. The native app used the standard non-custodial model: seed phrase and PIN. This simplified the native onboarding significantly and allowed the team to move faster on the multi-chain work.
Promotional Work
Alongside the product design, I produced motion design assets and video content for the launch campaigns. This included promotional content for the open beta launch and assets for partnership campaigns run with the Kaspa Team and Tangem Wallet, which extended reach beyond the core XO community.
Outcome
The product launched to a curated alpha group drawn from the Kaspa community. Feedback was strongly positive, specifically around the UI quality and how approachable the wallet felt for a non-custodial product.
Open beta followed. 1,000+ signups in the first week from a community of 6,000. That is approximately 17% of the total addressable community converting in the first seven days, which by any measure is a strong launch signal.
Partnership campaigns with the Kaspa Team and Tangem Wallet further extended the product's reach after launch.
Reflections
The decision to build a native app in Phase 2 made sense at the time. But shortly after, Telegram introduced the ability to add mini apps to the home screen, making them behave like installed apps. At that point the native app was solving a problem that no longer existed.
The team reached the same conclusion and eventually discontinued the native app, continuing development on the Telegram mini app only.
If I were doing this again, I would have bet on Telegram from the start and invested the Phase 2 effort entirely into deepening the mini app experience rather than splitting it across two platforms. The mini app was always the product. The native version was an insurance policy that turned out to be unnecessary.
XO Wallet
Overview
XO Wallet was the first non-custodial wallet built for Telegram inside the Kaspa ecosystem. Users could store KAS and its related tokens, manage their seed phrase, and secure their funds through a layered security model purpose-built for the risks of a third-party messaging platform.
I joined before anything existed. No brand, no screens, no flows. Over two phases I designed the full product: Telegram mini app first, then a native app, along with the promotional motion content used to launch both.
The product launched to a selected alpha group, received strong positive feedback, and moved to open beta, where it attracted over 1,000 signups in its first week from a community of 6,000.
Role | Senior Product / Visual Designer (sole designer) |
Team | CEO, product manager, dev team |
Engagement | Full-time at Xodex |
Timeline | Two phases, 8 weeks each (4 x 2-week sprints per phase) |
Surfaces | Telegram mini app, native app, promotional motion assets |
The Problem
Non-custodial wallets in crypto typically require users to manage a seed phrase and trust that the application storing access to their funds is secure. On Telegram, that trust problem is compounded: the platform is a third-party service outside your control, meaning a compromised Telegram account could mean compromised funds.
The Kaspa ecosystem had no dedicated wallet that addressed this. XO Wallet was built to be that product.
Understanding Who I Was Designing For
The Kaspa community skews toward technically engaged users who understand self-custody and care deeply about security. But the product also needed to be accessible to newer users who were coming into Kaspa from adjacent crypto communities. I designed for both.
Persona 1 |
|---|
The Self-Custody Believer |
Profile: 25-40 years old. Holds crypto across multiple wallets. Has strong opinions about seed phrase hygiene and would not use a custodial product. Already familiar with Kaspa. |
Goals: Store KAS securely. Understand the security model clearly. Have a recovery path that does not depend on any single service staying alive. |
Design implication: The two-shard security system needed to be explained clearly, not hidden. The private key export and shard removal features needed to be accessible but not buried. |
Persona 2 |
|---|
The Kaspa Community Member "I've been in the Kaspa ecosystem for a while and I just want a wallet that works properly." |
Profile: 20-35 years old. Active in the Kaspa community. Not necessarily a security expert but understands the basics of non-custodial wallets. Discovered XO Wallet through the community. |
Goals: A clean, fast wallet that feels native to the ecosystem. Easy deposit and withdrawal. Confidence that funds are safe without having to think about it constantly. |
Design implication: Onboarding needed to be fast with security handled quietly in the background, not as a series of friction points upfront. The security model should feel protective, not complicated. |
Persona 3 |
|---|
The Multi-Chain User (Phase 2) "I hold Kaspa but I also hold SOL and ETH. I don't want a different app for each chain." |
Profile: 25-40 years old. Manages assets across multiple blockchains. Technically comfortable with network switching, gas fees, and chain-specific quirks. |
Goals: Switch between networks without confusion. See the right balance for the right chain at all times. Trust that the app handles chain routing correctly. |
Design implication: Phase 2 introduced network selection and chain-switching states as a core UX problem. Every balance, transaction, and address display needed to be chain-aware. More screens, more edge states, more potential for confusion. |
Phase 1: Kaspa Wallet on Telegram
The security model
The most technically complex decision on this project came from the security lead: split the user's Telegram auth token into two shards. One shard stored on XO's encrypted cloud. One backed up manually by the user. Neither alone can grant access. If a Telegram account is breached, the funds remain inaccessible without both shards.
This was the right security call. As the designer, my job was to make sure it introduced zero felt friction for the user.
The solution was to handle shard creation silently during onboarding. The user receives one confirmation message that their secure shard has been created, and that is the full extent of their interaction with it. From there they move directly into PIN setup and seed phrase backup, presented as cards inside the app in a clear, sequential flow. The shard system protects them without them ever having to understand it.
If a user later wants to remove their shard from Telegram, for example to transfer the wallet to a different account, that option lives in app settings. It is findable without being prominent.
Onboarding flow
The first-time experience was designed to be fast. The goal was to get the user from zero to wallet setup in the minimum number of steps, then lead them through backup as a separate, guided flow rather than a blocker.
Onboarding sequence: account creation, shard creation (background, one confirmation), PIN setup, seed phrase backup prompt (card-based, skippable but persistent). Users who skipped the backup were reminded on their dashboard until it was complete.
The Telegram mini app constraints
Designing inside Telegram's mini app environment means working within WebView constraints: limited native gestures, no access to system-level biometrics at the time, and a viewport that can shift unexpectedly based on keyboard state. Navigation patterns had to be simple and predictable. Every interactive state had to be tested against keyboard-open scenarios.
The advantage of the mini app model was distribution. No App Store, no install barrier. Users could open the wallet directly from a Telegram link, which aligned with how the Kaspa community operated.
Phase 2: Multi-Chain Expansion
Adding Solana and Ethereum was not just a feature addition. It was an information architecture problem.
A single-chain wallet has one address, one balance, one transaction history. A multi-chain wallet has to answer: which chain are you on right now, what is your address on that chain, what is your balance on that chain, and what happens when you try to send to an address on a different chain.
Every screen that showed a balance, address, or transaction history had to become chain-aware. Network selection was added as a persistent context at the top of the app. Chain-switching introduced empty states, loading states, and error states that did not exist before. The number of screens and edge cases roughly doubled.
The native app launched alongside Phase 2. Without the Telegram platform risk, the two-shard system was not needed. The native app used the standard non-custodial model: seed phrase and PIN. This simplified the native onboarding significantly and allowed the team to move faster on the multi-chain work.
Promotional Work
Alongside the product design, I produced motion design assets and video content for the launch campaigns. This included promotional content for the open beta launch and assets for partnership campaigns run with the Kaspa Team and Tangem Wallet, which extended reach beyond the core XO community.
Outcome
The product launched to a curated alpha group drawn from the Kaspa community. Feedback was strongly positive, specifically around the UI quality and how approachable the wallet felt for a non-custodial product.
Open beta followed. 1,000+ signups in the first week from a community of 6,000. That is approximately 17% of the total addressable community converting in the first seven days, which by any measure is a strong launch signal.
Partnership campaigns with the Kaspa Team and Tangem Wallet further extended the product's reach after launch.
Reflections
The decision to build a native app in Phase 2 made sense at the time. But shortly after, Telegram introduced the ability to add mini apps to the home screen, making them behave like installed apps. At that point the native app was solving a problem that no longer existed.
The team reached the same conclusion and eventually discontinued the native app, continuing development on the Telegram mini app only.
If I were doing this again, I would have bet on Telegram from the start and invested the Phase 2 effort entirely into deepening the mini app experience rather than splitting it across two platforms. The mini app was always the product. The native version was an insurance policy that turned out to be unnecessary.
XO Wallet
Overview
XO Wallet was the first non-custodial wallet built for Telegram inside the Kaspa ecosystem. Users could store KAS and its related tokens, manage their seed phrase, and secure their funds through a layered security model purpose-built for the risks of a third-party messaging platform.
I joined before anything existed. No brand, no screens, no flows. Over two phases I designed the full product: Telegram mini app first, then a native app, along with the promotional motion content used to launch both.
The product launched to a selected alpha group, received strong positive feedback, and moved to open beta, where it attracted over 1,000 signups in its first week from a community of 6,000.
Role | Senior Product / Visual Designer (sole designer) |
Team | CEO, product manager, dev team |
Engagement | Full-time at Xodex |
Timeline | Two phases, 8 weeks each (4 x 2-week sprints per phase) |
Surfaces | Telegram mini app, native app, promotional motion assets |
The Problem
Non-custodial wallets in crypto typically require users to manage a seed phrase and trust that the application storing access to their funds is secure. On Telegram, that trust problem is compounded: the platform is a third-party service outside your control, meaning a compromised Telegram account could mean compromised funds.
The Kaspa ecosystem had no dedicated wallet that addressed this. XO Wallet was built to be that product.
Understanding Who I Was Designing For
The Kaspa community skews toward technically engaged users who understand self-custody and care deeply about security. But the product also needed to be accessible to newer users who were coming into Kaspa from adjacent crypto communities. I designed for both.
Persona 1 |
|---|
The Self-Custody Believer |
Profile: 25-40 years old. Holds crypto across multiple wallets. Has strong opinions about seed phrase hygiene and would not use a custodial product. Already familiar with Kaspa. |
Goals: Store KAS securely. Understand the security model clearly. Have a recovery path that does not depend on any single service staying alive. |
Design implication: The two-shard security system needed to be explained clearly, not hidden. The private key export and shard removal features needed to be accessible but not buried. |
Persona 2 |
|---|
The Kaspa Community Member "I've been in the Kaspa ecosystem for a while and I just want a wallet that works properly." |
Profile: 20-35 years old. Active in the Kaspa community. Not necessarily a security expert but understands the basics of non-custodial wallets. Discovered XO Wallet through the community. |
Goals: A clean, fast wallet that feels native to the ecosystem. Easy deposit and withdrawal. Confidence that funds are safe without having to think about it constantly. |
Design implication: Onboarding needed to be fast with security handled quietly in the background, not as a series of friction points upfront. The security model should feel protective, not complicated. |
Persona 3 |
|---|
The Multi-Chain User (Phase 2) "I hold Kaspa but I also hold SOL and ETH. I don't want a different app for each chain." |
Profile: 25-40 years old. Manages assets across multiple blockchains. Technically comfortable with network switching, gas fees, and chain-specific quirks. |
Goals: Switch between networks without confusion. See the right balance for the right chain at all times. Trust that the app handles chain routing correctly. |
Design implication: Phase 2 introduced network selection and chain-switching states as a core UX problem. Every balance, transaction, and address display needed to be chain-aware. More screens, more edge states, more potential for confusion. |
Phase 1: Kaspa Wallet on Telegram
The security model
The most technically complex decision on this project came from the security lead: split the user's Telegram auth token into two shards. One shard stored on XO's encrypted cloud. One backed up manually by the user. Neither alone can grant access. If a Telegram account is breached, the funds remain inaccessible without both shards.
This was the right security call. As the designer, my job was to make sure it introduced zero felt friction for the user.
The solution was to handle shard creation silently during onboarding. The user receives one confirmation message that their secure shard has been created, and that is the full extent of their interaction with it. From there they move directly into PIN setup and seed phrase backup, presented as cards inside the app in a clear, sequential flow. The shard system protects them without them ever having to understand it.
If a user later wants to remove their shard from Telegram, for example to transfer the wallet to a different account, that option lives in app settings. It is findable without being prominent.
Onboarding flow
The first-time experience was designed to be fast. The goal was to get the user from zero to wallet setup in the minimum number of steps, then lead them through backup as a separate, guided flow rather than a blocker.
Onboarding sequence: account creation, shard creation (background, one confirmation), PIN setup, seed phrase backup prompt (card-based, skippable but persistent). Users who skipped the backup were reminded on their dashboard until it was complete.
The Telegram mini app constraints
Designing inside Telegram's mini app environment means working within WebView constraints: limited native gestures, no access to system-level biometrics at the time, and a viewport that can shift unexpectedly based on keyboard state. Navigation patterns had to be simple and predictable. Every interactive state had to be tested against keyboard-open scenarios.
The advantage of the mini app model was distribution. No App Store, no install barrier. Users could open the wallet directly from a Telegram link, which aligned with how the Kaspa community operated.
Phase 2: Multi-Chain Expansion
Adding Solana and Ethereum was not just a feature addition. It was an information architecture problem.
A single-chain wallet has one address, one balance, one transaction history. A multi-chain wallet has to answer: which chain are you on right now, what is your address on that chain, what is your balance on that chain, and what happens when you try to send to an address on a different chain.
Every screen that showed a balance, address, or transaction history had to become chain-aware. Network selection was added as a persistent context at the top of the app. Chain-switching introduced empty states, loading states, and error states that did not exist before. The number of screens and edge cases roughly doubled.
The native app launched alongside Phase 2. Without the Telegram platform risk, the two-shard system was not needed. The native app used the standard non-custodial model: seed phrase and PIN. This simplified the native onboarding significantly and allowed the team to move faster on the multi-chain work.
Promotional Work
Alongside the product design, I produced motion design assets and video content for the launch campaigns. This included promotional content for the open beta launch and assets for partnership campaigns run with the Kaspa Team and Tangem Wallet, which extended reach beyond the core XO community.
Outcome
The product launched to a curated alpha group drawn from the Kaspa community. Feedback was strongly positive, specifically around the UI quality and how approachable the wallet felt for a non-custodial product.
Open beta followed. 1,000+ signups in the first week from a community of 6,000. That is approximately 17% of the total addressable community converting in the first seven days, which by any measure is a strong launch signal.
Partnership campaigns with the Kaspa Team and Tangem Wallet further extended the product's reach after launch.
Reflections
The decision to build a native app in Phase 2 made sense at the time. But shortly after, Telegram introduced the ability to add mini apps to the home screen, making them behave like installed apps. At that point the native app was solving a problem that no longer existed.
The team reached the same conclusion and eventually discontinued the native app, continuing development on the Telegram mini app only.
If I were doing this again, I would have bet on Telegram from the start and invested the Phase 2 effort entirely into deepening the mini app experience rather than splitting it across two platforms. The mini app was always the product. The native version was an insurance policy that turned out to be unnecessary.