From e440e5fd47c440425180a362e7e8ef54862ff0ab Mon Sep 17 00:00:00 2001
From: leopardracer <136604165+leopardracer@users.noreply.github.com>
Date: Thu, 3 Jul 2025 20:39:14 +0300
Subject: [PATCH] Update storage.md

---
 docs/learn/tutorials/storage/storage.md | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/docs/learn/tutorials/storage/storage.md b/docs/learn/tutorials/storage/storage.md
index dbe2b53..7bbc6b3 100644
--- a/docs/learn/tutorials/storage/storage.md
+++ b/docs/learn/tutorials/storage/storage.md
@@ -177,7 +177,7 @@ Storage data is always encoded with the `[SCALE](https://docs.substrate.io/refe
 
 ### Packed vs Non-Packed layout
 
-Types that can be stored entirely under a single storage cell are considered `[Packed](https://docs.rs/ink_storage_traits/4.0.0/ink_storage_traits/trait.Packed.html)`. By default, ink! tries to store all storage struct fields under a single storage cell. Consequentially, with a `Packed` storage layout, any message interacting with the contract storage will always need to operate on the entire contract storage structure.
+Types that can be stored entirely under a single storage cell are considered `[Packed](https://docs.rs/ink_storage_traits/4.0.0/ink_storage_traits/trait.Packed.html)`. By default, ink! tries to store all storage struct fields under a single storage cell. Consequently, with a `Packed` storage layout, any message interacting with the contract storage will always need to operate on the entire contract storage structure.
 
 If we have a few tiny fields in storage it’s not a problem to load all of them in every message, but if we have a large field with `Packed` type and if it’s not used in every message, it’s not rational to load this field every time.