Test address validation before an irreversible send

The contract this flow keeps

The three checks catch progressively subtler mistakes, and the second is the one most products leave out.

The wrong-network case is the important one. The address is genuinely valid, it passes any format check, and sending BTC to an ETH address destroys the funds with no error from the network itself.

The objective in plain English

The same address is used for both the wrong-network warning and the valid case, with only the asset changed. That isolates the network check as the thing under test.

---
mode: testing
url: https://my-testing-repo-main.vercel.app/coinbase-clone-app/send?reset=true
max_steps: 45
tags: [coinbase, fintech, crypto]
---

# Coinbaze 18.3: Send to address

Catalog objective: initiate a send and verify address validation and warning states.
Key assertion: an invalid address is blocked before confirming.

## Verify a malformed address is rejected
With "ETH" selected, type "not-an-address" into "Recipient address" and verify a red badge reads "Not a valid ETH address - 0x followed by 40 hex characters" and the send button is disabled.

## Verify the wrong-network warning
Select "BTC" in "Asset", type "0x8Ba1f109551bD432803012645Ac136ddd64DBA72" into "Recipient address", and verify a red banner titled "Wrong network" says that looks like an ETH address and sending BTC to it would lose the funds.

## Verify a valid address is accepted
Select "ETH" in "Asset", keep the address "0x8Ba1f109551bD432803012645Ac136ddd64DBA72", and verify a green badge reads "Valid ETH address" with the send button now enabled.

## Complete the send
Type "0.1" into "Amount in ETH", tick "I understand this transfer is irreversible", click "Send ETH", and verify a green banner titled "Send submitted" says "0.1 ETH" was sent.

The final step ticks an explicit acknowledgement before sending, so the test covers the consent mechanism as well as the transfer.

Assertion by assertion

Three validation states, then the send.

Changing only the asset between the second and third steps is what proves the warning is about the network pairing rather than about the address itself.

Putting it in CI

kane-cli testmd run tests/coinbase/send-to-address_test.md

Against a live environment, point this at a testnet. The final step submits a genuine transfer.

Guardrails are the code most likely to be weakened by a refactor nobody flags. Checking the UI before a pull request is where that should be caught, and assertions on a live page covers the disabled-state checks used here.