Add STX deposit/withdrawal options for subnets

[markmhendrickson]

Subnets are an L2 for Stacks (...and "L3" if we treat Stacks itself as an L2 for Bitcoin) that provide scalability and functionality benefits.

The wallet handles them generally like any other Stacks network, in that the underlying API for subnets conforms to the same standards as the Stacks Blockchain for Stacks networks.

However, as a usability enhancement, users will likely need to move STX from Stacks into a subnet and then back out from within the wallet itself.

If the user has a subnet added within the networks area of the wallet, we can display an additional option for STX tokens depending on the currently viewed network.

• If on mainnet with positive STX balance, we can show a "Deposit to subnet" option that when selected, allows the user to indicate how much STX they want to deposit and select the subnet of choice (in case they have several subnets in their networks menu). When they submit this form, the wallet triggers the relevant contract on mainnet for depositing (which is available via the subnet's API)
• If on subnet with positive STX balance, we can show a "Withdraw to mainnet" option that when selected, allows the user to indicate how much STX they want to withdraw to mainnet. When they submit this form, the wallet triggers the relevant contract on the subnet (?) for withdrawing (which is available via the subnet's API)

cc @saralab @hugocaillard in case they want to provide any additional context on the above UX need

[hugocaillard]

Thanks Mark! I want to highlight the fact that STX withdrawal from subnet happens in 2 steps;

1. initiate the withdraw on the subnet
2. confirm withdraw on the mainnet

I'll have a detailed example of it pushed on GitHub soon and deployed on testnet as part of the Subnet demo app.

Happy to get in touch with @mica000 when needed

[markmhendrickson]

@hugocaillard @saralab After talking with @mica000 about this task, we're thinking that it may fit best into the UX if we place the deposit/withdraw capabilities into the "Send" form of the wallet:

If the user has added one or more subnets to their networks menu, they'd see "Subnet" as an option in the dropdown of recipient types:

And if selected, they'd have the option to select "Choose subnet" and pick from a drawer showing their subnet networks (while hiding the memo field which is presumably unnecessary in this scenario):

For withdrawing, the user would have a similar experience but with "Mainnet" listed under types and no need to choose a particular network:

Since the user has two send two transactions (one for subnet then mainnet respectively), we can include fees and balances for each in this scenario and automatically submit the mainnet transaction once the subnet one confirms. That way the user doesn't need to toggle between networks to complete the withdrawal or otherwise manually broadcast two transactions.

How does this approach sound?

[hugocaillard]

I don't have a strong opinion regarding handling deposits from the mainnet "Send" form. Although I think it might be worth exploring a dedicated page for subnet to manage STX funds (deposit and withdraw).

Regarding the two steps withdrawal process, here is the flow from a technical point of view:

• send withdraw transaction on subnet
• wait for the transaction to be confirmed (...)
• on mainnet, fetch pending withdrawal for a given address*
• send a withdraw transaction on mainnet to confirm the withdrawal

So it's not possible to send to two withdraw transactions at the same time. At some point, the Subnet team suggested that the second step of a withdraw could be handled by the teams running the Subnet (eg: a marketplace like gamma) instead of the end-users.

* there's no easy way to do it right now, but we might just have an API endpoint soon to do so * there can be multiple withdrawal transaction initiated on subnet but not confirmed on mainnet)

[markmhendrickson]

So it's not possible to send to two withdraw transactions at the same time.

Is it possible for the wallet to wait for the subnet transaction to confirm then fetch the withdrawal info via the new API endpoint and then broadcast the mainnet transaction automatically?

i.e. sequential transactions instead of parallel ones

[hugocaillard]

@markmhx The second transaction is built with data coming from the confirmation of the first one. So we have to wait for the first one to be confirmed to build and sign the second one. I think the 2nd transaction could be automated, but I don't think that would be the responsibility of the wallet team to handle it.

I have a meeting with the Subnet team later today, I'll bring it up

[markmhendrickson]

I guess I'm thinking if the wallet can save the user an extra step by auto-signing the 2nd transaction, it's a good responsibility for it to have? Whereas an app wouldn't have the power to do such automation or sequencing given its lack of key access.

[hugocaillard]

it's a good responsibility for it to have?

I totally agree, but have some concerns regarding the feasibility. It would have to run as a background task, ideally on a server I guess?

So let's say that a a marketplace like Gamma runs a marketplace on a subnet. They have their own subnet and miner for this subnet. Should they decide to take care of the second withdrawal step, we could provide guidelines to set up a service (on a server) that is responsible for listening to withdrawal transaction on their subnet, and automatically broadcast the 2nd step (and pay the fees for it). The principal sending the 2nd withdrawal transaction can be any transaction (it doesn't have to be the address of the user performing the withdrawal)

[markmhendrickson]

The wallet extension can essentially wait for the 1st transaction to confirm (in the background i.e. while not the UI isn't open necessarily) then construct and broadcast the 2nd one as needed (also while in the background).

If a server-side service wants to take this on for the user and pay its fees, then that could work too I suppose. Though we'd probably want to be confident that all subnets are paired with such a service?

[hugocaillard]

The wallet extension can essentially wait for the 1st transaction to confirm (in the background i.e. while not the UI isn't open necessarily) then construct and broadcast the 2nd one as needed (also while in the background).

Well if we can make it work it would be great. But it would fail if the users closes it's browser right?

Though we'd probably want to be confident that all subnets are paired with such a service?

Yes, I think we'll have to anticipate the both scenarios can co-exist. For some subnets, the withdraw fees will be paid by users and for some other subnets, fees will be taken in charge by the company running the subnet

[markmhendrickson]

But it would fail if the users closes it's browser right?

Yea or at least, wouldn't continue until they reopen their browser again

[hugocaillard]

Ok I see 👍 I think it would be nice to have feedback from the subnet team, I'll share it with them

[markmhendrickson]

@mica000 has started a Figma for these designs here.

Some notes from our call yesterday:

• We'll indeed want the wallet to handle both transactions for withdrawal (on subnet and mainnet)
• We intend to add the separate fees screen to the STX flow (akin to BTC flow) which will facilitate the display of total fees for both of those transactions for single selection (e.g. user selects high which applies to both transactions vs. choosing fees for each network separately). This also facilitates removing dual fee and balance lines from the send form per the mockups above in the comments
• Once the user initiates withdrawal, we'll to display its progress on the confirmation screen so the user can see the sequence of transaction confirmations (Nice to have: If they close the wallet and return before completion, they'll have a way to get back to that confirmation screen and its status by clicking on the withdrawals entry in the activity area)
• If for some reason the user closes the wallet and never returns after emitting the first withdrawal transaction but not the second, we'll handle recovery outside the wallet for now and see how often it happens. If the user closes and reopens the wallet, it should resume the process of waiting for the first transaction to confirm then emit the second.