01
Overview
Bungee was designed to help users move assets across chains, either to their own wallet or to a different recipient address. However, recipient-based transactions introduced a privacy challenge.
When a user sends funds to another wallet, the sender address, recipient address, transaction value, and surrounding wallet activity can become publicly visible and traceable on-chain.
For many users, this transparency is expected. For others, particularly those sending funds to clients, employees, partners, merchants, or personal contacts, it can expose more information than they intended to share.
We needed to design a privacy-preserving transaction experience that users could discover, understand, and trust without making Bungee’s existing swap flow significantly more complex.
02
The business outcome
Private Swap could help Bungee serve users hesitant to complete recipient-based transactions due to public on-chain visibility. However, simply making a private route available would not create value if users could not find it, did not understand what it protected, or were uncertain whether it was active.
The desired business outcome was to increase the number of privacy-conscious users who could confidently complete recipient-based transactions through Bungee. For that outcome to improve, users needed to be able to:
- 1Recognize when a transaction could expose sensitive information.
- 2Discover that a privacy-preserving option was available.
- 3Understand what Private Swap protects.
- 4Deliberately enable privacy for the transaction.
- 5Trust that privacy would not compromise the safety or reliability of transactions.
- 6Complete the transaction without learning an entirely new workflow.
The critical behavioral change was not simply getting users to activate a privacy control. It was helping users proceed with transactions they might otherwise abandon, delay, or complete elsewhere.
03
The initial hypothesis
My initial hypothesis was that some users hesitated to send funds to another wallet because they were uncertain about what information would become publicly visible. These users might understand how to complete the transaction but still be concerned about exposing:
- The relationship between the sender and recipient wallets
- The amount being transferred
- The recipient’s wallet activity
- The sender’s broader transaction history
- Personal or commercial relationships represented by the transfer
I believed that introducing privacy within Bungee’s existing swap experience could reduce this hesitation. However, privacy could not be treated like an ordinary routing preference. If it were hidden inside settings, users might never discover it. If it appeared as another route beside options such as Fastest or Max Output, it could increase decision load. If it were represented only by a toggle, users might enable it without understanding what protection they were receiving.
If Bungee introduces privacy at the point where users express an intent to send funds to another wallet, more privacy-conscious users will complete recipient-based transactions without experiencing significant additional cognitive load.
04
Assumptions we needed to validate
Several assumptions sat underneath this direction. First, we assumed users understood that blockchain transactions are publicly visible.
Second, we assumed privacy concerns were strong enough to affect transaction behavior. A user might say privacy matters while still completing a standard transaction. We needed to understand whether these concerns caused measurable hesitation, abandonment, or changes in how users transferred funds.
Third, we assumed users would trust Bungee to execute a privacy-preserving transaction; privacy could not come at the expense of confidence in the transaction itself.
We also needed to validate that Bungee could support Private Swap without compromising:
These were not questions the interface alone could answer. They represented product, business, user, and technical risks that needed testing.
05
Reframing the problem
The obvious question
How should users select a private route?
The more useful question
How might we help users deliberately enter a privacy-preserving transaction while keeping the rest of the swap experience familiar?
The obvious framing treated privacy as another route-selection problem. But from the user’s perspective, choosing a route was not the primary goal — the user wanted to send assets to another wallet without exposing sensitive information.
This shifted the design away from presenting privacy as another execution option and towards helping users express privacy intent before the route became relevant. The distinction was important. It allowed Incognito Swap to remain part of Bungee’s existing transaction model while creating sufficient separation to make it clear that users had entered a different mode.
06
Users & the job to be done
The experience needed to support several behavioral segments:
- Users sending funds to another person or business
- Users completing sensitive or high-value transfers
- Users who cared about privacy but were not privacy experts
When I want to swap tokens to a recipient wallet, I want to complete the transfer without publicly exposing sensitive recipient details, so I can send funds confidently without creating unwanted visibility.
This job became the basis for evaluating each solution. A strong direction needed to make privacy visible and understandable without forcing every Bungee user to navigate additional complexity.
07
Defining success
Before selecting a solution, I defined the behaviors and metrics that would indicate whether the experience was working.
Primary metric: Incognito Swap adoption rate. The percentage of eligible recipient-based transactions completed using Incognito Swap. This would help us understand whether users discovered the feature, understood its value, and considered privacy important enough to use with real funds — evaluated alongside the percentage of eligible users who enabled Incognito Swap but returned to the standard flow or abandoned the transaction.
Repeat usage. The percentage of Incognito Swap users who completed another private transaction within a defined period. A single private transaction could be driven by curiosity or a one-time need; repeat usage would provide a stronger signal that users trusted the experience and found it valuable.
Feature-understanding score. Whether users could accurately explain what Incognito Swap protected. Successful task completion did not necessarily mean users understood the scope of the privacy protection — this measure needed to assess comprehension rather than general satisfaction.
Support-ticket volume. The number and themes of support requests relating to Incognito Swap, identifying confusion around what was private, whether privacy was enabled, delays or failures, fees and expected output, recipient visibility, route availability, and transaction history.
Guardrail metrics. The primary metrics needed to be monitored alongside Incognito Swap abandonment rate, transaction failure rate, and time to completion — to avoid increasing adoption at the cost of reliability, comprehension, or transaction confidence.
08
Exploring the solution space
I explored three main directions.
Option 1
A dedicated private route
Image placeholder — Route selector exploration
Incognito Swap would appear as a route option alongside choices such as Fastest, Best, or Max Output.
What it offered
Let users weigh privacy against other priorities such as output and expected time during route selection.
What it risked
Bungee’s route selection already required comparing multiple variables; another route type meant more scrolling, more cognitive load, and poor scalability as route types grew.
Option 2
A privacy toggle within the swap flow
Image placeholder — Inline toggle exploration
Users would enable privacy using a toggle while completing their normal swap, keeping the transaction structure familiar while the control changed how the transaction was executed behind the scenes.
What it offered
Fit naturally into the existing swap experience and created less navigation complexity than adding another route.
What it risked
A toggle could communicate whether privacy was active, but not what privacy meant — easy to operate while still creating an inaccurate mental model.
Option 3
A persistent privacy preference in settings
Image placeholder — Settings preference exploration
Privacy would become an account-level preference in settings, automatically applied to future eligible transactions. It reduced repeated interaction but weakened awareness at the moment of execution.
What it offered
Reduced repetitive actions for frequent privacy users and created a more personalized experience.
What it risked
A low-discoverability entry point; users might forget privacy was enabled — especially problematic if it affected fees, route availability, completion time, or expected output.
09
The decision
I chose to combine the strongest elements of the route and toggle models through progressive disclosure. Users can manually enable Incognito Swap on the home screen, making the private route available and transitioning the interface into a distinct privacy state.
This decision considered more than just interaction efficiency. A dedicated route made privacy visible but added complexity, while a persistent setting simplified actions but risked being overlooked. A standalone toggle fit the flow but could confuse users.
Progressive disclosure keeps privacy visible before route selection and reveals more details only after users express privacy intent. This trade-off enhances mode awareness, making it clear when users enter a private transaction and how it differs from a standard swap.
10
The proposed experience
A user begins the existing Bungee swap flow by selecting the source asset, destination token, destination chain, and transaction amount. When the user enters a recipient address that is different from their connected wallet, Incognito Swap becomes relevant. A visible control allows the user to enable privacy before selecting a route.
Image placeholder — Privacy state transition — standard vs incognito mode
Once enabled, the interface transitions into a distinct privacy state. The experience then communicates:
- That Incognito Swap is active
- That the transaction will use a privacy-preserving route
- What recipient or transaction information is protected
- What information may remain visible
- Whether privacy affects cost, output, or completion time
- How to return to the standard swap experience
The private route then becomes available within the existing route-selection flow. This preserves the overall Bungee experience while ensuring privacy is only introduced after the user has deliberately requested it. The user can then review the quote, expected output, estimated completion time, and relevant privacy information before proceeding.
Throughout the experience, the user should be able to answer: Is Incognito Swap currently active? What does it protect? What remains publicly visible? Will the recipient still receive the funds normally? Does privacy affect the transaction cost or completion time? Can I return to a standard swap before confirming?
11
Reducing risk through testing
The usability test focused on two separate questions.
Interactional
Can users find, enable, and complete an Incognito Swap without assistance?
Conceptual
Do users understand what Incognito Swap actually protects?
This distinction mattered because users could successfully complete the task while holding an inaccurate understanding of the feature. I tested the prototype with 10 participants who were familiar with on-chain swaps and recipient-based transfers. The sessions evaluated whether users could:
- 1Identify when Incognito Swap was relevant.
- 2Locate the privacy control.
- 3Enable Incognito Swap without assistance.
- 4Recognize that the interface had entered a different mode.
- 5Complete the transaction flow.
- 6Explain what information was being protected.
- 7Identify what information could remain visible.
- 8Return to the standard swap flow.
The goal was not simply to ask whether users liked the feature. We needed to observe whether the interaction was clear enough for users to make an informed privacy decision.
12
What we learned from usability testing
Task completion
100%
All 10 participants completed the flow without help — the core mechanics were clear.
Discoverability & ease of use
8.5/10
Placement, naming, onboarding cues, and visual state worked together effectively.
Comprehension accuracy
83%
Most understood the core value, but some formed incomplete assumptions about scope.
Average task time
38s
Low interaction friction — but speed could not be treated as evidence of understanding.
The additional action introduced by the progressive-disclosure model did not appear to create significant interaction friction. But comprehension was the most important finding: some participants formed incomplete assumptions about whether the feature protected the sender address, the recipient address, the transferred amount, the relationship between both wallets, or the entire transaction history.
The mechanics were working better than the explanation.
13
How the findings changed the next iteration
The test showed that the selected interaction model was viable. Users could find the feature, enter the privacy state, and complete the transaction. The remaining design opportunity was education. The next iteration needed to make the privacy promise more concrete by explaining:
- What Incognito Swap protected
- What it did not protect
- How it differed from a standard swap
- Whether privacy affected cost, timing, or expected output
- When the feature was available
- What the recipient would see
- What Bungee could and could not guarantee
Image placeholder — Iteration — in-context privacy explainer within the activated state
This information could not depend entirely on a hover tooltip. Hover interactions were easy to miss and did not translate reliably to mobile devices. A concise explanation needed to appear directly within the activated privacy state, with additional technical information available for users who wanted to understand the execution model in more detail.
14
Launch and monitoring
After the comprehension issues were addressed and the transaction infrastructure was reliable, the experience could be released gradually. Post-launch monitoring in Mixpanel and PostHog should connect each step of the funnel:
- Recipient address entered
- Incognito Swap viewed
- Incognito Swap enabled
- Privacy information expanded
- Private route viewed
- Private route selected
- Quote accepted
- Transaction initiated
- Transaction completed
- Incognito Swap disabled
- Private transaction abandoned
- Second Incognito Swap completed
This would make it possible to identify whether users were abandoning because they could not discover the feature, did not understand the privacy promise, were dissatisfied with the quote, or encountered an operational failure. The final assessment should compare Incognito Swap adoption, repeat usage, comprehension, support volume, and transaction guardrails against the baseline established before launch.
15
What this decision taught me
The most important insight was that privacy is not only an infrastructure problem. A technically private transaction can still fail as a product experience if users do not understand what is being protected.
The usability test demonstrated this clearly. Users could find the feature, enable it, and complete the transaction, but some still held an incomplete mental model of the privacy guarantee. This meant success could not be measured only through task completion — users also needed to understand the decision they were making.
The broader lesson was that reducing friction does not always mean removing actions. In this case, one deliberate action helped users recognize that they were entering a different transaction mode.
Users did not only need privacy. They needed confidence that privacy was active and clarity about what it protected.