What is available when, and what depends on what

Two tracks, one passkey

The single most important separation in the product — and the one most people get wrong.

The dependency ladder

Read top to bottom. nuri_me returns exactly this, resolved against the real account, so an agent always knows which rung it is on.

1. No account yet Open to everyone

   needs: nothing

   unlocks: nuri_me nuri_swap (quotes) nuri_signup nuri_login

   Quotes, routes and rates need nothing at all. An agent can price a swap before a user exists.

2. Passkey created Both tracks

   needs: open

   unlocks: nuri_login nuri_wait

   RP ID is nuri.com. The private key is derived from PRF in the browser, used, and wiped — it never exists on a server.

3. Keys derived Both tracks

   needs: passkey

   unlocks: nuri_receive (EVM) nuri_send (crypto rails) nuri_topup nuri_multisig

   Automatic — the same passkey tap that creates the credential derives the keys.

4. Username claimed Both tracks

   needs: passkey

   unlocks: user@nuri.com Lightning address user.nuri.eth ENS name

   Both names resolve the moment the username exists. No registrar call, no transaction, no waiting.

5. Smart account registered on-chain Card & IBAN gate

   needs: keys + username

   unlocks: the ID-check link itself

   THE gate people miss: there is no KYC link until this settles. wirex_register_result submits it and only then returns kyc_url. Nuri sponsors the gas.

6. ID check started Card & IBAN

   needs: smart_account

   unlocks: nothing yet — waiting on the provider

   An email address is required here, and only here. The self-custody track never needs one.

7. Identity approved Card & IBAN gate

   needs: kyc_started

   unlocks: EUR IBAN virtual Visa card SEPA out 3DS approvals physical card

   IBAN and the first virtual card are provisioned automatically at this point.

8. Wallet funded Self-custody

   needs: keys

   unlocks: every outbound rail

   Independent of identity. A user can hold and move Bitcoin forever without ever doing a KYC.

Which tool needs which stage

flowchart LR
  classDef open fill:#0d2b21,stroke:#3ec9a0,color:#d6fff2
  classDef mid fill:#1a2230,stroke:#8b9dff,color:#e6ebff
  classDef gated fill:#2e1a10,stroke:#f7931a,color:#ffe8c6

  P["passkey"]:::open --> K["keys derived"]:::open
  P --> U["username"]:::open
  K --> SA["smart account on-chain"]:::mid
  U --> SA
  SA --> KY["ID check link"]:::mid
  KY --> V["identity approved"]:::mid
  K --> F["wallet funded"]:::open

  O["no account needed"]:::open --> T0["nuri_me · nuri_swap · nuri_signup · nuri_login · nuri_wait"]:::open
  K --> T1["nuri_receive · nuri_topup · nuri_multisig · nuri_history"]:::open
  F --> T2["nuri_send"]:::open
  V --> T3["nuri_card · nuri_iban"]:::gated
  

How nuri_send picks a rail

flowchart TD
  A["nuri_send(to, amount)"] --> B{"what is 'to'?"}
  B -->|"lnbc… lnurl…"| L["Lightning invoice"]
  B -->|"name@domain"| LA["Lightning address"]
  B -->|"+255 6xx/7xx"| TZ["Tanzanian mobile"]
  B -->|"DE89 3704…"| IB["IBAN"]
  B -->|"0x… name.eth"| EV["EVM"]
  B -->|"bc1…"| BQ["Bitcoin bech32"]
  B -->|"1… 3…"| CK{"base58check valid?"}
  CK -->|yes| BT["Bitcoin legacy"]
  CK -->|no| SO["Solana"]
  L --> SK1["swapkit → BTC_LN"]
  LA --> SK1
  TZ --> RM["remit: quote + BOLT11"]
  RM --> SK1
  IB --> WX["banking: lookup → estimate → signed SEPA"]
  EV --> DT["connect: signed ERC-20, gas sponsored"]
  BQ --> SK2["swapkit → BTC / SOL"]
  BT --> SK2
  SO --> SK2
  classDef rail fill:#0d2b21,stroke:#3ec9a0,color:#d6fff2
  classDef work fill:#141b23,stroke:#5b6c8f,color:#e8edf5
  class L,LA,TZ,IB,EV,BQ,BT,SO rail
  class SK1,SK2,WX,DT,RM work
  

Every function, under its tool, with its dependency

The complete map: which function sits under which tool, what that tool requires before it works, and which backend answers. 85 functions across 12 tools.

The same thing grouped by area

Each tool is tagged with its area and its required stage inside the MCP itself, so an agent sees the same separation you see here.

To reach parity, in this order

Ordered by what a user feels, not by effort.

1. One-tap combined login

   The only gap a user notices today. Have wirex_session_result return the wallet tuple, or wallet_link_result return a banking session. Either one fixes it.

2. Publish the on-chain Bitcoin host

   The nuri_btc_* server exists but bitcoin.nuri.com does not resolve. Publishing it closes BTC receive, BTC balance and native BTC send at once.

3. Add arkade_send_invoice to connect

   Pay Lightning straight from the Bitcoin balance instead of routing through a stablecoin.

4. Derive a Solana key in connect

   The last chain that is send-only.

5. Add daimo to the swap_onramp enum

   One line. swap_route.only already accepts it.

6. Wrap the amber rows

   Invoice settlement, swap tracking, dust sweep, card withdrawal, IBAN move. All facade-side, no upstream dependency.