Wallet onboarding - Foundation funded accounts

[stefanopepe]

This document outlines a short-term flow that will provide foundation-funded accounts for users signing up for NEAR accounts. Longer-term, we will want a more complicated system in place that allows us to loan tokens to users that are creating their NEAR account; that work is documented here: #1577. Unlike this proposal, the long-term plan in #1577 will 'borrow' tokens from a liquidity pool or DAO to reserve accounts for a short period of time, using a smart contract to control how accounts can be closed (funds will only be able to be sweeped back to the pool that they were loaned from), and when/if users do not claim accounts within X time (24h?) they will be automatically deleted and the loaned tokens reclaimed.

Foundation-funded Faucet backend and behavior

Avoid spamming/sybil attacks - @vgrichina @MaximusHaximus

1. New endpoint for creating an account that is foundation funded
2. This endpoint will be protected with recaptcha validation

Modify wallet UX

What needs to be done from a design pov? - @corwinharrell

• Create account with bare-minimum funds
• Invite user to add funds via:

1. Moonpay
2. Exchanges
3. ETH Faucet via Rainbow Bridge
4. (future) Specific actions
5. (future) Apps providing tokens after login/authorization

Faucet funds

Required to finance new account creation - @kcole16

1. Define the initial amount
2. from Foundation -- which account?

[MaximusHaximus]

reCaptcha details

We had looked into implementing reCaptcha last year, and even started a basic implementation on the frontend side before deciding not to use it. The original implementation intended to use both `v2` and `v3` reCaptcha. For clarification, `v3` reCaptcha does not _replace_ v2 reCaptcha; it is an entirely different protection type that is used for different purposes, and v2 is not being retired/deprecated or any other sort of thing.

In a nutshell:

• v3 reCaptcha happens in the background; reCaptcha v3 monitors user usage of the site and generates a token based on these patterns that is used to run an assessment that returns a value between 0 and 1, where 0 means the browser is almost certainly a bot, and 1 means the browser is almost certainly a user.
• v2 reCaptcha is an interactive verification that the browser is user piloted, by way of forcing the user to complete a task that would be extremely difficult for a bot to perform (e.g. select all the tiles where a mailbox is visible in the picture), and provides a mild deterrent effect on individual users spending their time repeating the action many many times in sequence, since the manual reCaptcha takes some effort to solve. This verification happens at the moment the user wants to perform a protected action, and isn't a 'fuzzy' score; it's either a pass or a failure. It is recommended as best practice for v2 (interactive) reCaptcha to be used for high-value actions even if you also use v3 reCaptcha to try to detect if the browser is a bot.

Google has recently renamed these two different versions of reCaptcha in reCaptcha Enterprise to reflect this reality - v2 was renamed Challenge based reCaptcha, and v3 was renamed Score based reCaptcha.

Since the v3 reCaptcha is an entirely different service, it requires its own resources independent from v2 reCaptcha. This means that a different client is loaded for v2 reCaptcha than for v3, from a different URL, and that client requires a dedicated API key. When verifying the reCaptcha, the backend would likewise needs to know which type of reCaptcha token it is receiving during the account creation step for it to know which backend API endpoint to send the request for reCaptcha verification (or 'assessment', as v3 is called) and how to handle the response - since scoring reCaptcha returns a fuzzy number between 0 and 1, but challenge reCaptcha returns a boolean success value.

I think that, at least for an initial release, we should include challenge based reCaptcha only, for 4 major reasons:

1. While it is possible to run both challenge and scoring based reCaptcha on the same page, doing both adds significant complexity to both the client side and server side implementation.

• Requires loading 2 independent reCaptcha clients at different times (we can lazy load challenge based reCaptcha, but due to its user-monitoring behavior, scoring based should be loaded at page load time...)
• Clients require different API keys
• Fallback logic to handle showing v2 reCaptcha only if v3 score is outside of a threshold we would need to decide on :)
• Frontend needs to track the source of its reCaptcha code in state and tell backend API which type of code it is when it passes it.
• Backend needs to know about both reCaptcha API endpoints and their API details/response shapes/failure modes

2. It is still recommended to use challenge based reCaptcha on highly sensitive actions, even if scoring recaptcha is enabled
3. reCaptcha v3 is far more likely to be blocked by users due to its user action monitoring behavior/eager loading behavior. We can ensure that users won't even download the reCaptcha challenge client during normal wallet use until they perform an action that requires a reCaptcha challenge, but for scoring based reCaptcha - per Google documentation:

• reCAPTCHA works best when it has the most context about interactions with your site, which comes from seeing both legitimate and abusive behavior. For this reason, we recommend including reCAPTCHA verification on forms or actions as well as in the background of pages for analytics.
  I think we also actually want a little bit of friction here in the form of a direct challenge to discourage single users from spamming new account creations.

4. Ideally, this entire chunk of logic will exist temporarily, and be replaced by our pledged 'mini temporary faucet' account flow (Account Creation: Improve Funding UX w/ Temporary Faucet #1577), which only temporarily loans funds to new accounts; this flow will likely be fine with our existing rate limiting middleware as protection as there is less possibility for abuse.

References:
reCaptcha FAQ
v3 docs
v2 docs

User flow

CURRENT FLOW

1. User clicks 'Create Account', enters their account name and agrees to our terms & conditions and privacy policy modal.
2. User is prompted to choose their recovery type for the new account
3. User selects recovery type for the new account, and is taken to the appropriate add recovery method page (ledger, phrase, or 2fa via phone or e-mail are currently the 3 choices)
4. User follows the recovery method setup prompts. When they have successfully completed the recovery setup steps, the final button displayed is actually responsible for creating a NEAR account, reading e.g. Verify and Complete, which they can click to create the account.
5. User clicks the button which:

• Testnet: Creates the named account and loads the main wallet for that account
• Mainnet: Creates an implicit account and displays the 'please send funds to your implicit account to complete the creation process'

NEW FLOW
5. The final confirm button that creates a new account will be reCaptcha protected; the user will need to solve the reCaptcha to be allowed to click the final confirmation button.
6. When the user solves the reCaptcha and clicks the final button (e.g. Verify and Complete).

• If the attempt fails due to reCaptcha service returning a 'success: false' response (code invalid), the user will see a toast indicating they should re-complete the reCaptcha and try again (this probably will happen if someone lets the reCaptcha time out and then clicks submit)
• If the attempt fails due to the foundation funded account having no funds available, the wallet UI will automatically fall back to creating the account using the existing implicit account funding screen
• If the attempt to create using the implicit account fails, we will fall back to current UI behavior (display a toast to the user)

[stefanopepe]

My thoughts:
+1 to the idea of using the V2 only. I don't like at all the UX, and it will be a strong incentive to totally remove it ASAP
+1 to check this decision against integrating the smart-contract+DAO combo, and essentially focus on it

-1 to the idea of asking the reCaptcha before we check if the funds are available. I'd rather invert the first two steps in the new flow, and check if there are enough funds. I would also let the user try again the reCaptcha and (after a number of failures) automatically fallback to the funding route.

@corwinharrell you have the last word on the UX side of this discussion