Storage Cost Attacks on NEAR Easily Explained

Understanding storage cost attacks and storage staking on NEAR. This is part of an educational series covering the NEAR Protocol architecture and a security checklist for NEAR smart contracts.

Jul 08, 2026

Understanding storage cost attacks and storage staking on NEAR. This is part of an educational series covering the NEAR Protocol architecture and a security checklist for NEAR smart contracts.

In this article, we will take a deeper look into storage cost attacks and storage staking on NEAR smart contracts. The goal is to understand the concept of storage into the NEAR Protocol, the storage cost attack vector in smart contracts, and security good practices.

This article is useful for anyone who wants to increase their knowledge on NEAR:

NEAR enthusiasts
NEAR users
NEAR builders
blockchain developers
security researchers
smart contract auditors
bug bounty hunters

However, it’s important to note that this article aims to provide an easy explanation for a broader public. Developers and security researchers who want to dive deeper into the things discussed here may need to study NEAR docs and other sources as well.

Search for similar explanations under this series’ tag: NEAR Explained

NEAR Storage Staking Easily Explained

The blockchain is a shared and distributed database. NEAR is no different than that.

Computers run the node software (the protocol) and connect with other computers doing the same thing in a network to validate and store data (the state). Data can be financial amounts, usually represented as account balances. This is probably the most popular use for blockchains: cryptocurrencies. But it can be anything else.

One way or another, it is still data that needs to be stored by these computers—which consume physical storage space in a disk. Just like happens with our personal desktop computers or mobile smartphones for stored photos, videos, contacts, and messages.

One of the big questions for blockchain architects to answer is: who is paying for this data’s storage cost?

In our personal computer and mobile, we pay for it via the built-in disk that comes with the device or by buying extra hardware like USB flash drives or microSDs. In cloud or host services, we can pay for it via subscription plans with predefined, limited available storage.

“who is paying for this data’s storage cost?”

So, if you want to store more data, you buy more disk or upgrade your cloud/hosting plan. Blockchains work similarly, but the way to pay for it may vary.

Storage Costs on NEAR vs. Other Blockchains

Many legacy blockchains pass on the burden directly to validator nodes and their usual staking rewards (from fees and token emission). Validators are supposed to pay for storage with these rewards received from block production and that’s it.

NEAR addresses the problem differently.

On NEAR, validators are rewarded with token emission—currently at 2.5% per year over the total circulating supply, providing ~4.5% APY with ~45% of all NEAR in circulation being staked. Gas fees paid in transactions and contract calls are fully burned, creating potential deflationary economics.

Meanwhile, storage costs are paid via storage staking, also known as state staking.

For every 100kb of data stored in a smart contract, the contract needs to stake 1 NEAR in storage staking. This is a hard coded protocol setup that can change via governance votes. A change can be proposed and voted, for example, If physical storage costs or NEAR/USD exchange rate change significantly.

Right now, 1 NEAR = 100kb of storage, but it can change.

This cost is paid automatically every time a smart contract needs to store more data, staking the required amount directly from the contract’s account balance. The transaction will fail if there isn’t enough NEAR balance to cover these costs. On the bright side, the storage stake can be recovered if data is deleted—which frees space.

Smart contracts can absorb the storage cost alone or they can pass it on to the users. For that, they need to calculate and request users to add enough NEAR in the transaction to cover for the amount of data they will store.

Notably, the near-sdk-rs has environment variables to help with storage management.

env::storage_usage() // ← current storage used by this smart contract in bytes
env::storage_byte_cosy() // ← current storage cost per byte in yoctoNEAR
env::attached_deposit() // ← amount in yoctoNEAR attached to the call
env::account_balance() // ← balance of this smart contract, including attached deposit
env::account_locked_balance() // ← balance of this smart contract that is locked

Nevertheless, smart contract developers still need to be careful while managing its storage, as storage cost attacks are a known attack vector in NEAR.

Security Checklist: Storage Cost Attacks on NEAR Smart Contracts

The storage cost attack vector is an important item in the security docs for NEAR smart contracts development. It has an entire section for itself, and there are three brief checklist items related to storage in the security checklist.

In summary, the checklist warns developers to make sure the contract has enough balance to cover the storage cost as it grows organically, but also to make sure it’s protected against storage drain attacks, which may try to artificially inflate it and cause harm.

How to verify:

Calculate storage cost for each state change
Check contract balance before storing data
Require users to attach deposit for their storage
Monitor contract balance regularly.

As a critical rule: “If your contract doesn’t require users to cover their own storage costs, attackers can drain your contract’s balance by creating many small storage entries.”

The Attack Vector

Basically, if users are not paying for storage rent, there is an economic imbalance that attackers can exploit. A low-cost data spam can quickly become a high-cost storage for the contract owner.

Imagine an attacker who creates a script that sends thousands of transactions with storable arbitrary data. For each 100kb, 1 NEAR is locked from the contract’s balance. 100MB of data will cost the contract 1,000 NEAR in staked storage and this can be very easily achieved with a script and NEAR’s low gas fees.

The result is an unusable contract, huge amounts of NEAR locked. and a lot of wasted time managing this storage by depositing more stake or deleting data to free space.

Common attack patterns are:

Small Deposit Attack
Data Spam Attack
Collection Growth Attack

The Solution

The solution is simple: contracts must require users to cover storage cost.

Here’s an example:

pub fn add_message(&mut self, message: String) {
    let storage_cost = self.calculate_storage_cost(&message);
    assert!(env::attached_deposit() >= storage_cost, "Insufficient deposit for storage");
    
    // Store the message
    // Storage cost is covered by attached deposit
}

Calculate the storage cost for the data being stored
Require users to attach at least that amount as deposit
The attached deposit covers the storage cost automatically
Users who want to store data must pay for it
Implement data expiration or explicit deletion of old data to free storage
Test with attack scenarios, simulating many small storage operations

This safe-guard should, for example, be added to the near-examples/guest-book-examples/…/lib.rs, which is vulnerable to storage cost attacks as is.

This is it for today! Let me know if you liked this format and topic.

Join the discussion in the comments

Discussion about this post

Ready for more?