Unbreak "Test TX" flow during account creation

[kcole16]

Overview

We've had many instances of users sending multiple TXs to the implicit account during account creation, even after pushing the recent changes to address this.

At this point, I think it's fairly clear we've broken the crypto "best practice" of first sending a test TX to an account, and then sending a larger one. I'm not sure we can address this with further copy and warnings, as we already have pretty substantial messaging around this.

Potential Solutions

1. Keep (don't delete) the implicit account after it is funded, and load both accounts into the Wallet

• Pros:
  • Quick fix
  • Closer to current user expectations of accounts always persisting
• Cons:
  • Users may not immediately understand they have two different accounts
  • Email/phone and seed phrase recovery aren't optimized for this

2. Move account name selection to the end of the flow, make it optional

• Pros:
  • Potentially makes it more clear what is happening
  • Allows users to choose to just keep the implicit account (for greater pseudonymity)
• Cons:
  • Higher lift

Thoughts on these and other potential solutions? @vgrichina @corwinharrell @mattlockyer @Patrick1904 @marcinbodnar @jimmy3dita

[vgrichina]

we've broken the crypto "best practice" of first sending a test TX to an account, and then sending a larger one.

I think this part of the problem will go away once we reduce minimum balance required. We need something like 0.35 N as actual minimum. We already had significantly less problems once UX changed, let's see what happens if we also change the balance.

Harder part of the problem is that exchange typically stores this account in history and so users would just repeat transaction and get surprised money didn't go through.

Allows users to choose to just keep the implicit account (for greater pseudonymity)

This is not a pro for us. Named accounts are out distinct feature, we want to encourage their usage. Also greater pseudonymity here is mostly an illusion.

Keep (don't delete) the implicit account after it is funded, and load both accounts into the Wallet

This is basically the similar situation as to what is current workaround for when you accidentally overfunded the account, except no tech support needed. Not sure whether this is top support problem though, on my watch seems like far more people were concerned with say 35 NEAR minimum balance.

I think it's important to consider other alternatives as well:

3. Keep everything as is (besides reducing minimum balance):
   Pros:

• no design/eng work required, which is good given that once payment on-ramp lands implicit account flow would be less important for noobs
  Cons:
• we would have to spend more time educating users until they understand that .near account is their actual account indeed. Note that this question pops even outside of creation flow – people keep searching for unreadable address to use on exchange when they have .near account.

4. Change account creation flow to avoid using implicit account anywhere in the process. Can work like this:

• we create account with minimum balance and limited access key (this needs faucet, but we can make it so that backend that created it can re-claim unfunded accounts)
• once account is funded – access key needs to be replaced with full access
  Pros:
• least confusing
• full attention on readable account names
• very useful patterns for app on-boarding where you first can get free account and then upgrade it
  Cons:
• might be a bit not trivial to avoid having backend which briefly has access to user funds

[kcole16]

This is basically the similar situation as to what is current workaround for when you accidentally overfunded the account, except no tech support needed. Not sure whether this is top support problem though, on my watch seems like far more people were concerned with say 35 NEAR minimum balance.

I have personally helped 8 users with this, and it takes quite a while to walk them through it. I would say it's both the most common and time consuming support issue right now