NEAR unique account model opens up a pretty amazing opportunity to onboard users who don’t have $NEAR, don’t know what wallets are and still be able to provide them some of the benefits of the blockchain right away.
Here are 3 options in decreasing order of user ownership.
In all examples App runs a frontend, a centralized backend and a contract under
Access key account
User comes to the Apps website, and identifies they don’t have a NEAR wallet yet.
App sends them to create an implicit account (e.g. key pair), for which they need to store seed phrase or send that seed phrase to their email/sms.
Note, that Tor.us or Magic.link can replace need to setup a wallet and recovery explicitly and instead allow to login across apps with social logins.
This implicit account doesn’t get represented in any way on chain. It also doesn’t contain any assets at this point.
Coming back to App’s frontend, user requests backend to add this access key to the contract
app.near as function call access key. What this means is that user can actually send transactions calling functions on
app.near and this contract will pay for these transaction fees.
For example, App allows user to mint some NFTs or create proposals in Sputnik DAO. That NFT or proposal belongs to their account which is identified
hex(public_key) (this is special type of account name, called implicit account).
Now user will see these assets in the wallet, explorer can show this information and if user sells their NFT - the resulting money will go to their account.
You can see some different ways to implement this in @mattlockyer great videos:
- Live App Review 1 - App Access Keys - YouTube
- ETH Denver 2021 - WHERE ARE MY KEYS Onboarding the Masses with NEAR Protocol - YouTube
- Live App Review 6 - NFT Example - Part 2 App Demo and Tests - YouTube (this is the app walkthrough - part 1 covers contract, part 3 covers React frontend)
The benefits of this approach is that it’s fully non custodial on the app’s side. Backend just provides “meta transaction” functionality via the access keys, paying for user’s initial transactions until they get their own funds.
Not always you want to send user on a path to create non custodial account right away.
NEAR’s unique account model can provide a way around this.
App frontend/backend allow user to sign up with email/password or social login. This is done in a regular web2 way. While user signs up, they need provide some
username. For example
Going forward app proxies all the interaction with blockchain via backend, paying for all the transactions and enacting them from the “admin”'s perspective: minting NFTs, transferring assets, etc.
But instead of using “admin”'s account_id, a
illia.app.near is used (e.g. username + contract name). For example user
illia received 100 $APP tokens, the app.near contract would record that
illia.app.near has 100 tokens. Same with NFTs or anything else.
illia.app.near account doesn’t really exist on chain. But at the same time, because in NEAR only
app.near can create sub account - app can safely manage these accounts. Explorers and read only wallets can still show what account
illia.app.near owns as they would index inside the contract itself.
If user wants to move away from managed situation and claim ownership, the backend just allows them to create the account
illia.app.near. This would be done by user creating key pair and then asking backend to call a method on
This account automatically has access to all the assets that were stored under this name both in this contract and any other contracts (for example due to airdrop to all the users of this contract).
In this case user benefits from on chain visibility and activity (airdrops, composability, etc), while not needing the self custodial wallet on day 1. They trust the app to create the account when needed and then become self custodial going forward.
Third option is to store all the data on the backend until the user actually requests it on the blockchain.
E.g. it’s same as in option above but only minting NFTs / depositing assets to the user’s account when user requests to move to self custody.
This way it allows to save on storage and gas fees to the app building, but limits what value user gets out of it until they decide to self custody. E.g. they wouldn’t see their assets in other places or won’t be able to participate passively in other economy.
This covers 3 options of onboarding users who are don’t have assets or not ready for self custody.