Storage

NEAR uses storage staking which means that a contract account must have sufficient balance to cover all storage added over time. This standard provides a uniform way to pass storage costs onto users. It allows accounts and contracts to:

1. Check an account's storage balance.
2. Determine the minimum storage needed to add account information such that the account can interact as expected with a contract.
3. Add storage balance for an account; either one's own or another.
4. Withdraw some storage deposit by removing associated account data from the contract and then making a call to remove unused deposit.
5. Unregister an account to recover full storage balance.

Prior art:

• A previous fungible token standard (NEP-21) highlighting how storage was paid for when increasing the allowance of an escrow system.

Example scenarios

To show the flexibility and power of this standard, let's walk through two example contracts.

• A simple Fungible Token contract which uses Storage Management in "registration only" mode, where the contract only adds storage on a user's first interaction.

  1. Account registers self
  2. Account registers another
  3. Unnecessary attempt to re-register
  4. Force-closure of account
  5. Graceful closure of account

• A social media contract, where users can add more data to the contract over time.

  1. Account registers self with more than minimum required
  2. Unnecessary attempt to re-register using registration_only param
  3. Attempting to take action which exceeds paid-for storage; increasing storage deposit
  4. Removing storage and reclaiming excess deposit