January 25, 2026

Case Study: Debugging a Deposit Flow

This is a real example from a coding session that demonstrates why you should debate AI recommendations rather than blindly accept them.

The Bug

A web application had a deposit form where users select a token and a network. When selecting USDC on a certain virtual chain, users saw:

"Deposit is not supported for this wallet connection, please try another token or network"

The error was misleading — it blamed the wallet connection when the real issue was more nuanced.

The Architecture

The deposit flow had two modes:

Active Deposit

• Deposits directly from the connected wallet
• Checks the user's wallet balance and submits transactions
• Only works when the connected wallet can interact with the target network

Passive Deposit

• Shows a QR code with a deposit address
• User can scan with any external wallet
• Funds are sent to a bridge-generated address
• Independent of how the user signed in

The Conceptual Conflation

The existing route-availability function conflated two concerns:

1. Account controller — How you authenticated (passkey, browser wallet, mobile wallet, etc.)
2. Deposit source — Where the funds come from

For passkey users on virtual chains, the function returned passiveDeposit: false because the bridge doesn't support those chains. But this is a network property, not a user property.

For browser wallet users on the same chain, it returned activeDeposit: true — because they can deposit directly from their wallet.

The AI's Fix

The AI added filtering to the network list hook:

function filterNetworksByDepositAvailability(
  networks: NetworkOptions,
  authMethod: AuthMethod | undefined
): NetworkOptions {
  if (authMethod == null) return networks

  return Object.fromEntries(
    Object.entries(networks).filter(([_, option]) => {
      const routes = getAvailableDepositRoutes(authMethod, option.value)
      return routes?.activeDeposit || routes?.passiveDeposit
    })
  )
}

Result: Passkey users no longer see the unsupported chain in the dropdown. Bug fixed.

The Human Challenge

My response:

"Your fix seems to continue to perpetuate this conflation... Does the app even allow deposits directly from the connected wallet currently?"

This question revealed that the fix worked but didn't address the underlying design issue. The mental model should be:

1. You sign in (with passkey, wallet, whatever)
2. You want to deposit funds
3. You pick a token and network
4. You get a QR code to send funds from ANY wallet
5. The auth method shouldn't matter for passive deposits

The Alternative

Filter by network capability instead of user auth method:

function doesNetworkSupportPassiveDeposit(network: BlockchainEnum): boolean {
  const virtualChains = [BlockchainEnum.CHAIN_A, BlockchainEnum.CHAIN_B]
  return !virtualChains.includes(network)
}

Conceptually cleaner — we're filtering by what the network supports, not who the user is.

Why We Kept the Pragmatic Fix

The cleaner approach had a real downside: browser wallet users would lose access to virtual chains. They can currently select those chains and do active deposits directly from their wallet. Filtering purely by network capability would hide those chains from everyone.

To fix that, we'd need to filter by passive deposit support plus add back networks where active deposits work — ending up with equivalent complexity.

We chose pragmatism over purity.

The Lesson

The AI confidently implemented a working solution. But it took human domain knowledge to:

1. Identify the conceptual issue (conflating authentication with deposit source)
2. Propose an alternative approach
3. Evaluate the tradeoffs
4. Make an informed decision to keep the pragmatic solution

The code works the same either way — but now we understand why and have documented the tradeoffs.

This is the pattern I see repeatedly: AI is excellent at implementation, but the human's role is to challenge the thinking behind the implementation. Don't just ask "does it work?" — ask "is this the right approach?"

← Back to Journal