Allow users to send BRC20 tokens via the tokens send flow

[314159265359879]

It would require the wallet to inscribe a transfer inscription (ticker and amount) and then sending it off to where the user wants the tokens to go. (User clicks token, add amount, and receiving address and all they have to do is confirm, the rest is done in the background).

Some caviates:

1. inscription has to be on the address that holds the tokens and send from there (think: legacy regenerated addresses, and I also see users with BRC20 tokens on their native segwit address, what if 10 ordi tokens are on one taproot and 5 on another, it would require two transfer inscriptions to send 15 out).
2. You also want an option to check when not sending it out right away. That way the user can list the transfer inscription on a marketplace.

[markmhendrickson]

Here's some quick design guidance in lieu of proper Figma UI's from @mica000 for the time being:

Any BRC-20 tokens that the user has in their wallet should show up here similar to ALEX, applying the same row formatting as we have for BRC-20 on the home screen for balances:

The send screen should display the BRC-20 icon instead of the BTC one here while indicating the BRC-20 ticker instead of "Bitcoin (BTC"):

The value input field up top should also display the ticker in caps (e.g. "BIMB") instead of BTC, and the "Available balance" at the bottom should show the total amount of this BRC-20 token the user has in their wallet and not already transferring outbound via a previous (still pending) send transaction.

The recipient field will be, of course, where the user indicates whom to receive these BRC-20. Technically this will be the person who receives the transfer inscription (per below).

On the fees screen, we should likewise show the amount of BRC-20 to send and its ticker up top (e.g. "5 BIMB") instead of the amount to send in BTC.

We should show the total amount in BTC needed to both A) pay for the creation of the transfer inscription, and then B) actually send that inscription to the recipient of choice.

We can use OrdinalBot's API for creating transfer inscriptions (https://docs.ordinalsbot.com/).

Note that we can get fee estimates from this API via their "price" endpoint before submitting an order via their "textorder" endpoint, submitting BTC payment to the payment address returned by that endpoint, then polling their "order" endpoint for status on the inscription's completion and ID, which we can then use to trigger an inscription send to the recipient (all of this sequentially and in the background via a queuing system).

Since we don't have the actual transfer inscription upfront when viewing the fees selection screen, we may need to sample the fees needed by querying the fee estimator with a known, existing transfer inscription (owned by a team wallet?), assuming that the fees needed for it will be roughly the same (since transfer inscriptions don't vary much in their data size given they're simple JSON files).

The review screen can be the same but with showing a BRC-20 amount up top and no USD value. We may need to remove the estimated arrival as well since it could be tricky with two sequential transactions:

Similar changes to the submitted screen, where as should also remove the two buttons at the bottom (since we don't have a single transaction or its ID to use here upfront).

We can enhance this UX later by providing a status indicator on the submitted screen (and later accessible via the activity stream) for the two transactions, akin to what @mica000 is already designing for the swap flow's submitted state. The v1 implementation doesn't have to provide the user with such status details. Once they submit, we can simply lower their (available) balance as displayed on the home screen.

[markmhendrickson]

Per @314159265359879's caveats:

inscription has to be on the address that holds the tokens and send from there (think: legacy regenerated addresses, and I also see users with BRC20 tokens on their native segwit address, what if 10 ordi tokens are on one taproot and 5 on another, it would require two transfer inscriptions to send 15 out).

Let's support just the Taproot address to start. We can add Native SegWit, etc. support later alongside https://github.com/hirosystems/wallet/issues/3299

You also want an option to check when not sending it out right away. That way the user can list the transfer inscription on a marketplace.

Users who want to list these on marketplaces would presumably not use the send flow but rather inscribe the transfer operation separately then list?

[314159265359879]

A user commented being confused by the BRC-20 terminology. Instead of "inscribe" should we use the word "mint"... mint a transfer inscription? I think it reads better then inscribe a transfer inscription

You also want an option to check when not sending it out right away. That way the user can list the transfer inscription on a marketplace.

Users who want to list these on marketplaces would presumably not use the send flow but rather inscribe the transfer operation separately then list?

Yes they want to mint a transfer inscription to sell (in Naynay's suggested terminology).

Likewise BRC-20 inscriptions can be

• Unused (fresh transfer inscriptions)
• Used (anything else)

[markmhendrickson]

My sense is we want to avoid both "inscribe" and "mint" as terminology in general here and focus on "send tokens"? That's what the user wants to do, not the intermediate steps per se

[kyranjamie]

My reckoning here is that many BRC-20 users won't be first timers, and in guides and on youtube videos will hear the terms mint and inscribe. The counter risk of not confusing newbies is confusing more technical users with Hiro Wallet specific terminology. We should make clear in the UI that, in a lesser weight than Send, that under the hood a mint/inscribe is taking place.