---
NEP: 448
Title: Zero-balance Accounts
Author: Bowen Wang <bowen@near.org>
DiscussionsTo: https://github.com/nearprotocol/neps/pull/448
Status: Final
Type: Protocol Track
Created: 10-Jan-2023
---

## Summary

A major blocker to a good new user onboarding experience is that users have to acquire NEAR tokens to pay for
their account. With the implementation of [NEP-366](https://github.com/near/NEPs/pull/366), users don't necessarily have
to first acquire NEAR tokens in order to pay transaction fees, but they still have to pay for the storage of their account.
To address this problem, we propose allowing each account to have free storage for the account itself and up to four keys
and account for the cost of storage in the gas cost of create account transaction.

## Motivation

Ideally a new user should be able to onboard onto NEAR through any applications built on top of NEAR and do not have to
understand that the application is running on top of blockchain. The ideal flow is as follows: a user hear about an interesting
application from their friends or some forum and they decide to give it a try. The user opens the application in their
browser and directly starts using it without worrying about registration. Under the hood, a keypair is generated for the
user and the application creates an account for the user and pays for transaction fees through meta transactions. Later on,
the user may find other applications that they are also interested in and give them a try as well. At some point, the user
graduates from the onboarding experience by acquiring NEAR tokens either through earning or because they like some experience
so much that they would like to pay for it explicitly. Overall we want to have two full access keys for recovery purposes
and two function call access keys so that users can use two apps before graduating from the onboarding experience.

## Rationale and alternatives

There are a few alternative ideas:

- Completely disregard storage staking and do not change the account creation cost. This makes the implementation even
  simpler. However, there may be a risk of spamming attack given that the cost of creating an account is around 0.2Tgas.
  In addition, with the current design, it is easy to further reduce the cost. Going the other way is more difficult.
- Do not change how storage staking is calculated when converting to gas cost. This means that account creation cost would
  be around 60Tgas, which is both high in gas (meaning that the throughput is limited and more likely for some contract to break)
  and more costly for users (around 0.006N per account creation).

## Specification

There are two main changes to the protocol:

- Account creation cost needs to be increased. For every account, at creation time, 770 bytes of storage are reserved
  for the account itself + four full access keys + two function call access keys. For function call access keys,
  the "free" ones cannot use `method_names` in order to minimize the storage requirement for an account.
  The number of bytes is calculated as follows:
  _ An account takes 100 bytes due to `storage_usage_config.num_bytes_account`
  _ A full access key takes 42 bytes and there is an additional 40 bytes required due to `storage_usage_config.num_extra_bytes_record`
  _ A function call access key takes 131 bytes and there is an additional 40 bytes required due to `storage_usage_config.num_extra_bytes_record`
  _ Therefore the total the number of bytes is `100 + (131 + 40) * 2 + (42 + 40) * 4 = 770`.

  The cost of these bytes is paid through transaction fee. Note that there is already [discussion](https://github.com/near/NEPs/issues/415)
  around the storage cost of NEAR and whether it is reasonable. While this proposal does not attempt to change the entire
  storage staking mechanism, the cost of storage is reduced in 10x when converting to gas. A [discussion](https://gov.near.org/t/storage-staking-price/399)
  from a while ago mentioned this idea, and the concerns there were proven to be not real concerns. No one is deleting
  data from storage in practice and the storage staking mechanism does not really serve its purpose. That conversion means
  we increase the account creation cost to 7.7Tgas from 0.2Tgas

- Storage staking check will not be applied if an account has <= 4 full access keys and <= 2 function call access keys
  and does not have a contract deployed. If an account accrues more than full access keys or function call access keys,
  however, it must pay for the storage of everything including those 6 keys. This makes the implementation simpler and less error-prone.

## Reference Implementation (Required for Protocol Working Group proposals, optional for other categories)

Details of the changes described in the section above:

- Change `create_account_cost` to

```json
"create_account_cost": {
  "send_sir": 3850000000000,
  "send_not_sir": 3850000000000,
  "execution": 3850000000000
},
```

- Change the implementation of `get_insufficient_storage_stake` to check whether an account is zero balance account.
  Note that even though the intent, as described in the section above, is to limit the number of full access keys to 4
  and the number of function call access keys to 2, for the ease of implementation, it makes sense to limit the size of
  `storage_usage` on an account to 770 bytes because `storage_usage` is already stored under `Account` and it does not
  require any additional storage reads. More specifically, the check looks roughly as follows:

```rust
/// Returns true if an account is a zero balance account
fn check_for_zero_balance_account(account: &Account) -> bool {
    account.storage_usage <= 770 // 4 full access keys and 2 function call access keys
}
```

## Drawbacks (Optional)

- Reduction of storage cost when converting the storage cost of zero balance accounts to gas cost may be a concern. But
  I argue that the current storage cost is too high. A calculation shows that the current storage cost is around 36,000 times
  higher than S3 storage cost. In addition, when a user accrues any contract data or has more than three keys on their account,
  they have to pay for the storage cost of everything combined. In that sense, a user would pay slightly more than what
  they pay today when their account is no longer a zero-balance account.

## Unresolved Issues (Optional)

## Future possibilities

- We may change the number of keys allowed for zero-balance accounts in the future.
- A more radical thought: we can separate out zero-balance accounts into its own trie and manage them separately. This
  may allow more customization on how we want zero-balance accounts to be treated.

## Decision Context

### 1.0.0 - Initial Version

The initial version of NEP-448 was approved by Protocol Working Group members on February 9, 2023 ([meeting recording](https://youtu.be/ktgWXjNTU_A)).

#### Benefits

- Users can now onboard with having to acquire NEAR tokens
- Together with [meta transactions](https://github.com/near/NEPs/pull/366), this allows a user to start interacting with an app on NEAR directly from their device without any additional steps
- Solves the problem of meta transaction for implicit accounts

#### Concerns

| #   | Concern                                                                                      | Resolution                                                                                                                                                       | Status   |
| --- | -------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------- | -------- |
| 1   | The number of full access keys allowed is too small                                          | Could be done in a future iteration.                                                                                                                             | Resolved |
| 2   | No incentive for people to remove zero balance account.                                      | Very few people actually delete their account anyways.                                                                                                           | Resolved |
| 3   | UX of requiring balance after a user graduate from zero balance account to a regular account | The experience of graduating from zero balance account should be handled on the product side                                                                     | Resolved |
| 4   | Increase of account creation cost may break some existing contracts                          | A thorough investigation has been done and it turns out that we only need to change the contract that is deployed on `near` slightly                             | Resolved |
| 5   | Account creation speed is slower due to increased cost                                       | Unlikely to be a concern, especially given that the number of shards is expected to grow in the future                                                           | Resolved |
| 6   | Cost of transfers to implicit account increases                                              | Unlikely to break anything at the moment, and could be addressed in the future in a different NEP (see https://github.com/near/NEPs/issues/462 for more details) | Resolved |

## Copyright

Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).