If you are finding it difficult to comprehend either storage, memory, or calldata, you are not alone.If you are finding it difficult to comprehend either storage, memory, or calldata, you are not alone.

Memory, Calldata, and Storage in Solidity: Understanding the Differences

:::warning DISCLAIMER:

  • The code in this article is for educational purposes only.

:::

If you are finding it difficult to comprehend either storage, memory, or calldata, you are not alone. This is an area most beginner developers struggle to grasp, and even some experienced Solidity developers still don’t fully understand.

What are these ‘special words’? They are words that specify the main data locations in a Solidity smart contract. Data locations in Solidity describe where data can be stored and how it can be accessed on the Ethereum blockchain. Other data locations include the following:

  • Stack
  • Code
  • Logs

In this article, you will learn the differences between each main data location option and where to use each.

Firstly, what is storage?

Storage

Storage is the data location that holds a smart contract’s state variables. A state variable is data that lives permanently on the blockchain. Each smart contract has its own storage space (an array of 2^256 32-byte slots), and state variables are automatically assigned to storage.

The code snippet below shows a simple implementation of a state variable stored in storage, as well as its getter and setter functions: \n

// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Storage {     /////////////////////////////     // STATE VARIABLES //////////     /////////////////////////////     uint256 public s_storedData; // s_storedData is a storage variable, s_ denotes a storage variable     /////////////////////////////     // SETTER FUNCTION //////////     /////////////////////////////     function set(uint256 x) public {         s_storedData = x; // This value is saved permanently on-chain     }     /////////////////////////////     // GETTER FUNCTION //////////     /////////////////////////////     function getStoredData() public view returns(uint256) {         return s_storedData;     } } 

In the code above, the  s_storedData remains on the blockchain after the set() function runs.

More importantly, storage is one of the major data location options that isn’t explicitly specified. Any variable declared outside any function is implicitly converted to a storage variable.

Use-case

The Bank contract above acts as a simple bank, as the name implies. The balancesmapping is stored in storage, which means it remembers values across function calls.

For instance, if Alice calls deposit(100), her balance is saved in storage in the balances mapping. Conversely, if she calls withdraw(60), she receives 60 and the mapping updates to 40.

Memory

Unlike Storage, Memory is a temporary, function-scope data location. Function-scope means, variables exist only during a function call, not at the contract-level, and clears afterwards. Additionally, memory allows for read-write access; this means variables are modified within a function. Solidity allocates memory to variables defined inside a function(local variables) or parameters marked memory.

To demonstrate:

// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Memory {     function multiply(uint256 a, uint256 b) public pure returns (uint256) {         uint256 result = a * b; // 'result' is stored in memory         return result; // 'result' does NOT persist after the function ends     } } 

In the code above, Solidity implicitly stores result in memory, which does not persist after the function execution.

Use-case

The code below concatenates two string inputs, string memory first, string memory second exist while the function combineStrings runs.

A note on function parameters

// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Memory {     function multiply(uint256 memory a, uint256 memory b) public pure returns (uint256) {         uint256 result = a * b;         return result;      } } 

For function parameters, you can’t specify the memorykeyword for uint, bool, addressand enum variables as they are directly stored on the contract’s stack, no explicit keyword.

Whereas for reference types like strings, bytes, arrays, structs, and mapping, you will have to specify or defaults to memory for internal and private functions and calldata for external and public functions(more on this below👇).

Calldata

Lightly touched on in the previous section, calldata is another temporary data location, but it’s reserved for external function parameters.  Also, unlike memory, calldata cannot be modified. To explain what this means, let’s take a look at the code below:

\

// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Example {     function tryChangeCalldata(uint[] calldata nums) external pure returns (uint[] calldata) {         nums[0] = 999; // ❌ ERROR — "calldata is read-only"         return nums;     } } 

The error message above shows that calldata is read-only. To modify calldata variables, they must first be loaded into memory.

Take the adjusted code below now modified .The code below works because the it loads nums variable to memory before modifying it in the if block.

\

// SPDX-License-Identifier: MIT pragma solidity ^0.8.26; contract Example { &nbsp; &nbsp; function tryChangeCalldata(uint[] calldata nums)&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; external&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; pure&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; returns (uint[] memory)&nbsp; &nbsp; &nbsp; { &nbsp; &nbsp; &nbsp; &nbsp; // Copy from calldata to memory &nbsp; &nbsp; &nbsp; &nbsp; uint[] memory numsCopy = new uint[](nums.length); &nbsp; &nbsp; &nbsp; &nbsp; for (uint i = 0; i < nums.length; i++) { &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; numsCopy[i] = nums[i]; &nbsp; &nbsp; &nbsp; &nbsp; } &nbsp; &nbsp; &nbsp; &nbsp; // Now modify the copy &nbsp; &nbsp; &nbsp; &nbsp; if (numsCopy.length > 0) { &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; numsCopy[0] = 999; &nbsp; &nbsp; &nbsp; &nbsp; } &nbsp; &nbsp; &nbsp; &nbsp; return numsCopy; &nbsp; &nbsp; } } 

\

Why Data Locations Matter

Using appropriate data locations matters as they directly affect how your contracts store, access, and pay for data. The differences can have a large impact on cost, behaviour, and security of your smart contracts. Here’s how:

Gas Costs

  • Writing data to Storage is the most expensive.
  • The gas costs in Memory is more moderate than storage.
  • Calldata is the cheapest data location, i.e., writing to calldata costs the least amount of gas.

Persistence and Temporariness

  • Any data written to Storage lives onchain, meaning the data is permanent.
  • Memory only persists during the function’s lifecycle.
  • Calldata acts like memory in handling data, only it can’t be changed.

Mutability

  • Storage data can be modified.
  • Similar to Storage, Memory can be modified but only within the context of a function.
  • Calldata is read-only.

Safety

  • Storage can be a risky choice of location because mistakes or hacks can permanently change the blockchain’s state.
  • Memory is a safer option since changes are temporary.
  • Calldata is the safest for passing input for external functions.

Wrapping Up

That’s it for this piece, as previously stated, using the appropriate data locations is integral to the functionality of your contracts. I implore you to research further about the other types of data locations mentioned in the introduction of this article.

Happy Hacking!!

Market Opportunity
Notcoin Logo
Notcoin Price(NOT)
$0,0005036
$0,0005036$0,0005036
-3,63%
USD
Notcoin (NOT) Live Price Chart
Disclaimer: The articles reposted on this site are sourced from public platforms and are provided for informational purposes only. They do not necessarily reflect the views of MEXC. All rights remain with the original authors. If you believe any content infringes on third-party rights, please contact service@support.mexc.com for removal. MEXC makes no guarantees regarding the accuracy, completeness, or timeliness of the content and is not responsible for any actions taken based on the information provided. The content does not constitute financial, legal, or other professional advice, nor should it be considered a recommendation or endorsement by MEXC.

You May Also Like

MoneyGram launches stablecoin-powered app in Colombia

MoneyGram launches stablecoin-powered app in Colombia

The post MoneyGram launches stablecoin-powered app in Colombia appeared on BitcoinEthereumNews.com. MoneyGram has launched a new mobile application in Colombia that uses USD-pegged stablecoins to modernize cross-border remittances. According to an announcement on Wednesday, the app allows customers to receive money instantly into a US dollar balance backed by Circle’s USDC stablecoin, which can be stored, spent, or cashed out through MoneyGram’s global retail network. The rollout is designed to address the volatility of local currencies, particularly the Colombian peso. Built on the Stellar blockchain and supported by wallet infrastructure provider Crossmint, the app marks MoneyGram’s most significant move yet to integrate stablecoins into consumer-facing services. Colombia was selected as the first market due to its heavy reliance on inbound remittances—families in the country receive more than 22 times the amount they send abroad, according to Statista. The announcement said future expansions will target other remittance-heavy markets. MoneyGram, which has nearly 500,000 retail locations globally, has experimented with blockchain rails since partnering with the Stellar Development Foundation in 2021. It has since built cash on and off ramps for stablecoins, developed APIs for crypto integration, and incorporated stablecoins into its internal settlement processes. “This launch is the first step toward a world where every person, everywhere, has access to dollar stablecoins,” CEO Anthony Soohoo stated. The company emphasized compliance, citing decades of regulatory experience, though stablecoin oversight remains fluid. The US Congress passed the GENIUS Act earlier this year, establishing a framework for stablecoin regulation, which MoneyGram has pointed to as providing clearer guardrails. This is a developing story. This article was generated with the assistance of AI and reviewed by editor Jeffrey Albus before publication. Get the news in your inbox. Explore Blockworks newsletters: Source: https://blockworks.co/news/moneygram-stablecoin-app-colombia
Share
BitcoinEthereumNews2025/09/18 07:04
Optum Golf Channel Games Debut In Prime Time

Optum Golf Channel Games Debut In Prime Time

The post Optum Golf Channel Games Debut In Prime Time appeared on BitcoinEthereumNews.com. FARMINGDALE, NEW YORK – SEPTEMBER 28: (L-R) Scottie Scheffler of Team
Share
BitcoinEthereumNews2025/12/18 07:21
Google's AP2 protocol has been released. Does encrypted AI still have a chance?

Google's AP2 protocol has been released. Does encrypted AI still have a chance?

Following the MCP and A2A protocols, the AI Agent market has seen another blockbuster arrival: the Agent Payments Protocol (AP2), developed by Google. This will clearly further enhance AI Agents' autonomous multi-tasking capabilities, but the unfortunate reality is that it has little to do with web3AI. Let's take a closer look: What problem does AP2 solve? Simply put, the MCP protocol is like a universal hook, enabling AI agents to connect to various external tools and data sources; A2A is a team collaboration communication protocol that allows multiple AI agents to cooperate with each other to complete complex tasks; AP2 completes the last piece of the puzzle - payment capability. In other words, MCP opens up connectivity, A2A promotes collaboration efficiency, and AP2 achieves value exchange. The arrival of AP2 truly injects "soul" into the autonomous collaboration and task execution of Multi-Agents. Imagine AI Agents connecting Qunar, Meituan, and Didi to complete the booking of flights, hotels, and car rentals, but then getting stuck at the point of "self-payment." What's the point of all that multitasking? So, remember this: AP2 is an extension of MCP+A2A, solving the last mile problem of AI Agent automated execution. What are the technical highlights of AP2? The core innovation of AP2 is the Mandates mechanism, which is divided into real-time authorization mode and delegated authorization mode. Real-time authorization is easy to understand. The AI Agent finds the product and shows it to you. The operation can only be performed after the user signs. Delegated authorization requires the user to set rules in advance, such as only buying the iPhone 17 when the price drops to 5,000. The AI Agent monitors the trigger conditions and executes automatically. The implementation logic is cryptographically signed using Verifiable Credentials (VCs). Users can set complex commission conditions, including price ranges, time limits, and payment method priorities, forming a tamper-proof digital contract. Once signed, the AI Agent executes according to the conditions, with VCs ensuring auditability and security at every step. Of particular note is the "A2A x402" extension, a technical component developed by Google specifically for crypto payments, developed in collaboration with Coinbase and the Ethereum Foundation. This extension enables AI Agents to seamlessly process stablecoins, ETH, and other blockchain assets, supporting native payment scenarios within the Web3 ecosystem. What kind of imagination space can AP2 bring? After analyzing the technical principles, do you think that's it? Yes, in fact, the AP2 is boring when it is disassembled alone. Its real charm lies in connecting and opening up the "MCP+A2A+AP2" technology stack, completely opening up the complete link of AI Agent's autonomous analysis+execution+payment. From now on, AI Agents can open up many application scenarios. For example, AI Agents for stock investment and financial management can help us monitor the market 24/7 and conduct independent transactions. Enterprise procurement AI Agents can automatically replenish and renew without human intervention. AP2's complementary payment capabilities will further expand the penetration of the Agent-to-Agent economy into more scenarios. Google obviously understands that after the technical framework is established, the ecological implementation must be relied upon, so it has brought in more than 60 partners to develop it, almost covering the entire payment and business ecosystem. Interestingly, it also involves major Crypto players such as Ethereum, Coinbase, MetaMask, and Sui. Combined with the current trend of currency and stock integration, the imagination space has been doubled. Is web3 AI really dead? Not entirely. Google's AP2 looks complete, but it only achieves technical compatibility with Crypto payments. It can only be regarded as an extension of the traditional authorization framework and belongs to the category of automated execution. There is a "paradigm" difference between it and the autonomous asset management pursued by pure Crypto native solutions. The Crypto-native solutions under exploration are taking the "decentralized custody + on-chain verification" route, including AI Agent autonomous asset management, AI Agent autonomous transactions (DeFAI), AI Agent digital identity and on-chain reputation system (ERC-8004...), AI Agent on-chain governance DAO framework, AI Agent NPC and digital avatars, and many other interesting and fun directions. Ultimately, once users get used to AI Agent payments in traditional fields, their acceptance of AI Agents autonomously owning digital assets will also increase. And for those scenarios that AP2 cannot reach, such as anonymous transactions, censorship-resistant payments, and decentralized asset management, there will always be a time for crypto-native solutions to show their strength? The two are more likely to be complementary rather than competitive, but to be honest, the key technological advancements behind AI Agents currently all come from web2AI, and web3AI still needs to keep up the good work!
Share
PANews2025/09/18 07:00