Quick rundown: When storage collisions happen in upgradeable proxies, they can cause some sneaky failures that really screw up your data. These issues might bypass access controls and throw a wrench in your audits. This playbook is designed to help you identify and avoid potential issues while smoothly migrating with tools like EIP-1967, UUPS, and ERC-7201 namespaced storage. You’ll find everything you need to tackle these challenges safely! We’ll take all that complicated engineering stuff and simplify it into SOC2-ready processes that actually provide solid returns on your investment.

Auditing Your Upgradable Proxy Pattern for Storage Collisions

P A I N -- the specific headache you’re likely facing

So, you've really committed to using Transparent/UUPS proxies to keep everything running smoothly, right? But now you're noticing that your upgrade diffs are getting messy with all these “unrelated” changes popping up. It can be a bit frustrating, can't it? It’s possible that you added a new modifier, upgraded to a newer version of a library, or maybe you switched up the order of inheritance. After the upgrade, I've noticed that some states seem to randomly flip or an initializer just decides to kick in again for no apparent reason. It's kind of puzzling!

Your internal audit team wants to see some reassurance that the upcoming upgrade won’t mess with those important privileged spots like admin and implementation. They also want to make sure it won’t interfere with anything from the past. On the flip side, your vendors are just saying, “We ran a test suite,” but honestly, that doesn’t give you the definite, reliable proof you really need when it comes to storage layouts.

So, you've got this migration to OpenZeppelin v5 on the horizon, but it looks like your setup is a bit of a jumble. You've got some old v4 storage layouts hanging around mixed in with those sleek new v5 namespaced contracts. Hey there! I’ve noticed that your tools are constantly bringing up that “layout incompatibility” issue, and it seems like your release window is getting tighter.

Why This Matters Now:

Hey there! Just wanted to share that EIP-6780 has totally revamped the SELFDESTRUCT semantics. Big shoutout to Dencun for making that happen on March 13, 2024! So, basically, those “metamorphic” upgrade tricks are starting to fade away. If you’re diving into the world of proxies, you’re definitely in it for the long run. Now, storage safety is really taking the spotlight--it’s not just something we can overlook anymore. Feel free to take a closer look at it here: (eips.ethereum.org).

Let's talk about something that happened in the real world--like the Audius governance takeover on July 23, 2022. It's a great example to consider. So, here’s what went down: there was a bit of a storage showdown between a custom proxy admin slot and OpenZeppelin’s Initializable flags. It was one of those technical hiccups that happens sometimes! So, this minor glitch gave an attacker the chance to rerun the initialize function and snag some governance rights. The result? They ended up draining 18. 56M AUDIO. This isn’t just some made-up story; it actually went down! Check it out for yourself over at blog.audius.co.

A G I T A T I O N -- What’s at risk if you ignore it

• Missed deadlines and stalled releases: When your upgrade validation hits a snag late in the process because the storage layouts aren’t lining up across inheritance chains, it really puts you in a bind. If you don’t have a solid list of slots to rely on, your only fallback is a canary deployment. But honestly, that’s not going to be enough when you’re dealing with tight change-management rules.
• Compliance exposure: Auditors really focus on having clear controls in place to prevent any unauthorized privilege escalation from happening. If you run into a storage collision that ends up flipping an “initialized” flag or messing with an admin slot, you’re going to find it pretty challenging to get through those SOC2 checks for “change control” and “logical access.” It's like trying to navigate a maze blindfolded--definitely not an easy task! This really doesn’t help your governance story; it actually just makes it weaker.
• Reputational and financial risk: Just a heads up, if your storage gets corrupted, that's not something you can just fix on a whim--it’s a lasting issue. You can't just hit "undo" on EVM storage like it never happened, you know? Sure, you might get through a "successful" hotfix, but you'll still find yourself facing some audit gaps. Plus, it'll create a bit of extra hustle for the Procurement, Legal, and InfoSec teams. They'll have to step in and sort things out. They will definitely notice!.

S O L U T I O N

7Block Labs Methodology to Close the Gap

Here at 7Block Labs, we totally get that closing the gap in technology and innovation takes some serious thought and care. So, here’s how we’re going to handle this challenge:

1. Getting a Handle on Needs: First things first, it's super important to really understand what our clients and the market are all about.

2. Collaborative Development: We really value teamwork and are all about partnering with our clients throughout the entire process. Teamwork is super important when it comes to making sure the final product matches what they had in mind.

3. Agile Methodology: When we adopt an agile approach, it really helps us stay flexible and respond to changes on the fly. It's all about being quick and efficient, which makes a huge difference in how we work! This helps us stay on course, even when surprises come our way.

4. Continuous Feedback: We believe in getting feedback at every step of the way. It's super important to us! This really helps us tweak our strategy and make any needed changes as we go.

5. Cutting-Edge Technology: We’re constantly hunting for the newest tools and tech out there to improve our services and solutions. It’s all about finding those game-changers that can make a real difference!

6. Training & Support: We believe that delivering a product is just the beginning. That’s why we offer thorough training and continuous support to help our clients really thrive. We want to make sure you're well-equipped for success!

7. Measuring Impact: At the end of the day, we take a good look at the results to see how we're doing. This helps us understand our impact and figure out how we can step up our game for future projects.

At 7Block Labs, we’re all about bridging the tech gap and pushing innovation to new heights. That’s our mission, and we’re totally dedicated to making it happen!

We combine high-quality engineering with smart enterprise change management. This isn't just your average audit, you know? This program is super organized and really helps your security team and procurement get everything they need to approve things quickly.

1) List Your Proxy Estate and Baseline Standards

First off, you'll want to sort all the upgradeable instances by their type. Check to see if they fall into one of these categories: Transparent Proxy, UUPS (which is based on ERC-1822), or Beacon. Hey, just a quick reminder to grab the admin and implementation slots based on EIP-1967, alright? Make sure to double-check that the slots are aligned with: To get the implementation address, you can use this formula: bytes32(uint256(keccak256("eip1967.proxy.implementation")) - 1). It’s a neat little trick to pull it off! So, you've got this piece of code here: bytes32(uint256(keccak256("eip1967.proxy.admin")) - 1). Essentially, it’s a way to generate a unique identifier by using the keccak256 hashing function on the string "eip1967.proxy.admin." By converting that hash to a uint256 and then subtracting 1, you're essentially tweaking the output a bit. It’s pretty clever! So, for the beacon, you can use this code: bytes32(uint256(keccak256("eip1967.proxy.beacon")) - 1). It’s a bit of a mouthful, but basically, it’s just a way to create a unique identifier using a hash. Just remember to keep that syntax in mind when you're working with it! If something seems a bit off, that's definitely a red flag! Let's make sure we keep track of the slot reads and jot down any Upgraded/AdminChanged/BeaconUpgraded events that pop up. It’ll be helpful to connect those to the right change tickets too. Take a look at this: eips.ethereum.org. You might find it interesting!

When you're working with UUPS, make sure that the proxiableUUID and the update process are woven into your logic--they shouldn't just be sitting around in the proxy. Make sure to check that the slot usage matches up with EIP-1967, even though the original example in EIP-1822 talks about "PROXIABLE" storage. We're all about aligning the design vision with what's really going on in the code. If you want to dive deeper into that topic, check it out here: (eips.ethereum.org).

2) Generate and Diff Storage Layouts at Build Time

To keep everything organized, we pull the storage layouts for each contract straight from Solidity’s compiler output. This covers everything you need to know about packing, offsets, and slots. Merges are only approved if the layout differences look good for the implementations that are hanging out behind proxies. If you want to explore this topic further, check it out here. You’ll find some really useful info!

• So, here’s the set of tools we’re going to roll with:
• OpenZeppelin Upgrades plugins (for both Hardhat and Foundry) help keep your upgrades secure and ensure that your storage compatibility is spot on, even when it comes to those tricky reserved gaps.
  In our CI pipeline, we make sure to run validate/upgradeProxy dry-runs. Plus, we keep all our manifests neatly organized in one place. openzeppelin for each network. If you’re looking for more details, check this out here. It’s a great resource!
• Slither’s slither-check-upgradeability is our reliable tool for catching things like variable reorders, function-ID conflicts, and any changes in the layout of proxies or implementations. We keep the JSON outputs stored away as reliable proof for our records. Take a look at it on GitHub!

3) Namespaced Storage Rollout Plan (ERC-7201) for Forward Compatibility

Hey there! So, OpenZeppelin Contracts v5 is launching some cool new stuff, including this thing called ERC-7201 namespaced storage. What’s that all about? Well, it’s designed to tackle those annoying "reorder" issues that have been bothering us for a while now. Pretty neat, right? It handles storage by using a specific root slot for each namespace--sort of like diamond storage but made more user-friendly with a standardized approach. We're excited to help you get your codebase set up with some v5-friendly patterns! We'll also guide you on how to tag your namespaces using @custom:storage-location erc7201:. Let’s dive in and make this happen together! If you want to dive deeper into it, feel free to check it out here. Happy reading!

• Migration Guardrails: Hey, quick tip for you: steer clear of trying to do a “drop-in” swap with v5 setups when you're using a v4 proxy that relies on linear storage. Trust me, it can lead to some headaches! Using namespaces can really complicate how we access different paths. We'll either handle the upgrades separately for you or provide some shims and data migration scripts to help you keep everything running smoothly.
  If you're curious and want to dive deeper, you can find all the details here. Happy reading!
• No problem if you can't switch to v5 right away! We’ll still keep the good old v4-style inherited storage with __gap buffers, plus we'll stick with OpenZeppelin plugin validation. It's all good! We're gearing up to launch ERC-7201 adoption during a significant upgrade period. If you want to dive deeper, you can check out more details here. It's a great resource!

4) Collision Threat Modeling and Tests That Actually Fail When It Matters

We come up with some pretty smart upgrades that focus on:

• Switch up or retype the variables as needed.
• Bring in some new base contracts that will sit above the ones we already have.
• Shadow proxy-specific storage

We need our test suite to catch any issues before anything gets added to the chain, not after the fact. Using the OZ plugins along with Slither is an awesome way to make sure we’re catching those situations with predictable failures. Take a look at this: docs.openzeppelin.com. You'll find some great info there!

Plus, we also include property tests to ensure things are set up just once and that the admin side stays nice and unchangeable. We even run a simulation of the Audius failure mode, where things can go haywire if the initializer gets confused by storage flags clashing with admin bytes. This way, we can make sure your setup stops any accidental re-initializations from happening. Looking to dive deeper? Check out this link: (blog.audius.co). Happy reading!

5) Governance and Change Control for SOC2 Compliance

• Introduce “Transparent proxy” semantics to prevent any mix-ups with function selectors. It’s super important that admin accounts can only tap into those proxy admin functions, so users don’t unintentionally activate any proxy admin code paths. We always keep tabs on how things are playing out on-chain to make sure it matches this clear pattern we're looking for. If you want to dive deeper into this topic, feel free to check it out here.

If you’re planning on making any upgrades, it’s a smart idea to use multi-signature wallets, like Gnosis Safe, and throw in a timelock for good measure. This way, you’re adding an extra layer of security to your assets while keeping control in a safe, collective way. Oh, and make sure you connect the OpenZeppelin plugin manifests to your ticketing system! That way, every upgrade event is linked to an approved change, which is super helpful. OpenZeppelin's setup for their network files really makes it a breeze to keep track of everything and manage different versions. It's like they thought of everything to simplify the process! For more info on that, check it out here.

Sure thing! Let's whip up an auditor-ready packet that covers everything you need. We’ll include the differences in storage layouts, outputs from our tools, slot proofs, and the runbooks. Just let me know if you want to dive into any specific sections or if you have any other details you’d like to add! This is going to be a crucial piece of your SOC2 evidence library, so keep that in mind!

6) Performance and “Gas optimization” without compromising safety

So, we're diving into the nitty-gritty of how different EVM opcodes, like SLOAD and DELEGATECALL, affect overhead. We're pinpointing those key areas where UUPS can significantly reduce call overhead when stacked up against Transparent proxies, and the best part? We’re doing all this while making sure that upgrade safety stays rock solid. We’ve outlined these trade-offs in your ROI story. If you want to learn more about it, head over to evm.codes. There’s a ton of great info waiting for you!

Hey there! So, if you're working with operations that happen within a transaction, like dealing with locks and caches, it could be a good idea to check out some optimizations like transient storage (that's EIP-1153) and MCOPY (which is EIP-5656), especially if you're using compilers version 0. Just a little tip that might make your life easier! 8. 28 and up. You can definitely mix these with proxies in a safe way! Just remember, though, that any temporary storage you use won’t stick around after your transactions are done. So, it won’t really help you hide any possible collision issues. If you're looking for the most up-to-date info, check out this link: soliditylang.org. It's got everything you need!

7) Optional: Modular Architectures Using ERC-7201/8042

When we're working on creating intricate and modular systems, like facets or plugins, we really try to simplify things by standardizing where we store everything. It just makes life a lot easier! Thanks to ERC-7201 and ERC-8042 diamond storage conventions, we can easily keep our modules organized by using namespaces. It’s a pretty handy way to separate everything! Using this method also makes it easier to handle upgrade checks for your tools. On top of that, we ensure that your tools really get the annotations. For more info, take a look at this link: eips.ethereum.org. It’s got all the details you need!

Detecting a Collision Before It Ships

• Symptom: Alright, so you've rolled out a new version that throws in a boolean flag to a base contract, and it's sitting right above the original storage. So, you’ve run all your local tests and everything seems to be working perfectly. But then, once you go live, you try to read something and it pulls up the wrong address. Ugh, how frustrating is that? Yikes!.
• Action:

1. Hey there! Just a quick reminder to run the Slither and OZ validation, okay? Alright, to kick things off, just go ahead and run this command: bash slither-check-upgradeability . ContractV2 --proxy-name TransparentUpgradeableProxy
Alright, let’s go ahead and validate it using Hardhat! bash npx hardhat compile && npx hardhat upgrades:validate
2. Inspect compiler storage:

• If you’re using Foundry, take a moment to check out your storage with: bash forge inspect ContractV2 storage --pretty

3. To fix the issue, you’ve got a couple of options. You can either rearrange the new variables so they come after the ones that are already there, or you can switch to a namespaced storage struct in v5. Both should do the trick! If you want to dive deeper into the details, just click here. Happy exploring!

Safe Slot Math and Assertions for EIP-1967

Hey there! Before you dive into deploying your custom proxy, just a quick heads-up: double-check that the slot constants are in line with EIP-1967 right from the get-go. It’ll save you some headaches later on!

bytes32 internal constant _IMPLEMENTATION_SLOT =
  0x360894a13ba1a3210667c828492db98dca3e2076cc3735a920a3ca505d382bbc;
bytes32 internal constant _ADMIN_SLOT =
  0xb53127684a568b3173ae13b9f8a6016e243e63b6e8ee1178d6a717850b5d6103;

constructor(address logic, bytes memory data) payable {
  assert(_IMPLEMENTATION_SLOT == bytes32(uint256(keccak256("eip1967.proxy.implementation")) - 1));
  _upgradeToAndCall(logic, data, false);
}

This is great because it prevents any accidental changes that might mess with the standard slots, keeping everything consistent across different scanners and tools. (eips.ethereum.org).

Namespaced Storage in OZ v5 Style (ERC-7201)

When you're dealing with data in smart contracts, namespaced storage really makes a huge difference. Hey there! With the new ERC-7201 rolling out in OpenZeppelin v5, we've got a pretty awesome tool for tidying up our storage. Plus, it helps us maintain everything securely and efficiently. How cool is that? Alright, let’s take a closer look at what this means for your contracts!

What is Namespaced Storage?

Basically, namespaced storage is a way to keep your contract's storage neat and tidy by using unique namespaces to organize everything. So, this basically helps you steer clear of any collisions and keep your data organized and neat! The goal is to come up with a naming system that organizes your storage variables. This way, it’ll be a lot easier to keep track of everything!

How Does It Work?

ERC-7201 gives you a handy framework to set up specific namespaces. Let’s take a quick peek at how you could go about doing this:

Setting Up Namespaces

To kick things off, you'll want to set up your namespaces. Imagine you're working on a token contract that comes with some cool features--like voting and staking. Pretty exciting, right? You can create namespaces this way:

contract MyToken {
    using Namespace for Namespace.Storage;

    Namespace.Storage private _voting;
    Namespace.Storage private _staking;

    // Your other contract code goes here...
}

Accessing Data

Whenever you need to save or pull up some data, just refer to your specific namespace. Let me show you a quick example of how to set a value in the voting namespace.

_voting.set("proposalCount", 5);

To grab that value again, you’d go ahead and do something like this:

uint256 proposalCount = _voting.get("proposalCount");

Benefits of Namespaced Storage

Wondering why you should even think about namespaced storage? Well, let me break down some of the main perks for you:

• Organization: It’s a great idea to keep your storage variables grouped in a way that makes sense. This way, your code will be easier to read and manage down the line!
• Collision Avoidance: It's super important to steer clear of any name clashes, especially when you're working with a bunch of people on big projects or when you're merging with other contracts. Trust me, it saves a lot of headaches down the line!
• Efficiency: Save on gas costs by organizing your data smartly. When you lay it out in a way that cuts down on storage access, you’ll find that every little bit helps!

Conclusion

With the rollout of namespaced storage in ERC-7201 as part of OpenZeppelin v5, keeping your smart contracts organized is now a breeze! By using this approach, you'll end up with a tidier codebase, steer clear of those annoying variable name clashes, and boost your overall efficiency. It's a win all around! If you haven’t done it yet, now's the perfect time to dive in and see how you can bring this into your own projects! Trust me, you’ll be glad you did!

If you want to dive deeper into this topic, be sure to take a look at the OpenZeppelin documentation. It’s super helpful!

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

/// @custom:storage-location erc7201:mycorp.payments.v1
library PaymentsStorage {
  struct Layout {
    address treasury;
    mapping(address => uint256) balances;
    // later additions won’t collide across upgrades
  }
  bytes32 internal constant SLOT = keccak256(abi.encode(uint256(keccak256("mycorp.payments.v1")) - 1));

  function layout() internal pure returns (Layout storage l) {
    bytes32 slot = SLOT;
    assembly { l.slot := slot }
  }
}

contract Payments /* is Initializable, UUPSUpgradeable */ {
  using PaymentsStorage for PaymentsStorage.Layout;

  function treasury() external view returns (address) {
    return PaymentsStorage.layout().treasury;
  }
  function setTreasury(address t) external /* onlyRole */ {
    PaymentsStorage.layout().treasury = t;
  }
}

This method keeps the state separate, so you can add new fields without messing with other inheritance setups. Plus, it’s supported by the OZ plugins, which is a nice bonus! (blog.openzeppelin.com).

Preventing the “Audius class” of initializer bugs

If you want to dodge those annoying initializer bugs, here are a few tips you can try out:

• Keep an eye out for re-initialization and overlapping slots by: So, when you're working with version 5 (or even the patched version 4), definitely check out the initializer and reinitializer modifiers from Initializable. And don’t forget to run OpenZeppelin’s "validate" to ensure your flags aren't stepping on any toes with the proxy-specific storage. It’s a good way to keep everything running smoothly! If you're curious to know more, you can dive into the details right here. Happy exploring!
• Just a heads up: you’ll want to double-check that your proxy’s admin and implementation slots follow EIP-1967 rules and aren’t sitting in slots 0 or 1. We actually write regression tests where we randomly flip a byte in the admin data and then try to call initialize again. The cool part? That call should always fail. It’s just a fun way to make sure everything’s working as it should! If you want to dive deeper into EIP-1967, just click here. Happy reading!

Emerging Best Practices (What’s New and Worth Adopting)

• Think of EIP-6780 as a strict rule: It's best to avoid any upgrades that use SELFDESTRUCT. Instead, just focus on using proxies and reliable storage plans for your migrations. This way, you can keep everything smooth and secure! Take a look at this link: eips.ethereum.org. You'll find some interesting stuff there!
• Consider UUPS: If your system is sensitive to gas fees and you’ve got a team that can stick to a solid upgrade plan, then UUPS could be the best choice for you. Just a friendly reminder: try to keep your upgrade authorization logic separate from your app logic. And don’t forget to double-check that proxiableUUID when you’re doing upgrades! It's an easy step that can save you some headaches down the road. Happy coding! When it comes to more complicated admin paths, transparent proxies are definitely the way to go. They do a great job of preventing those annoying selector clashes that can really slow you down. More info here: (blog.openzeppelin.com).
• Go with ERC-7201 for namespaced storage: If you’re diving into new development, make sure to use ERC-7201. It’s the way to go! Hey, if you’re getting into those diamond-like modular systems, you should definitely check out ERC-8042--it's worth a look! Make sure your tools can pick up on annotations and do diff checks for namespaces on their own. It’s super important! Want to dive deeper into this? Check it out here: blog.openzeppelin.com. There’s a ton of great info waiting for you!
• Bring storage layout checks into CI: Let’s not make this just a one-time thing before deployment. Hey, just a quick reminder to export your OZ network files and keep them in version control. It's super important to stay organized! This helps you track everything and makes sure you’re always ready for an audit. Take a look at the details right here: (docs.openzeppelin.com).

How This Ties to Business Outcomes

• **Less chance of upgrade hiccups means we can count on when releases will happen.
  We make navigating “contract risk” super easy by transforming it into a straightforward checklist. This way, it has clear, machine-checkable points that Procurement and Internal Audit can quickly spot and understand.
• SOC2 alignment: We gather strong proof--like slot proofs, diff manifests, and tool outputs--and make sure they pair perfectly with your change tickets. This means we can wrap up audits quicker and cut down on all that back-and-forth, which is definitely a huge win!
• ROI: The cool thing about “gas optimization” is that the perks we get from UUPS and all those upgrades from the compiler improvements are here for the long haul. We really focus on keeping things structurally safe instead of bloating up the code, which just ends up making gas costs skyrocket.
  This way, your teams can keep launching new features without having to worry about any hidden storage risks piling up.

GTM metrics and outcomes

• External proof: Check out what happened with Audius. It’s a great example! It's pretty clear that just one storage collision can really mess things up fast, leading to a loss of control and some significant token movements--think up into the eight figures! Honestly, it's way more sensible and budget-friendly to tackle these problems before they pop up rather than waiting until later to fix them. If you want to dive deeper into the whole story, just check it out here: blog.audius.co. You won’t want to miss it!
• Tooling guarantees: So, when you’re using our tools, like OZ Upgrades plugins and Slither, don’t just see them as basic linters. They offer so much more than that! They work like safety checks, proactively stopping any known collision types and incompatible layouts from reaching the mainnet in the first place. By combining the two, we make sure that if something goes wrong, it happens during Continuous Integration (CI) instead of messing things up in production. Feel free to check out the nitty-gritty details right here: (docs.openzeppelin.com). It’s packed with helpful info!
• 7Block Internal Delivery Benchmarks (2025): Here at 7Block, we've been diligently monitoring our internal delivery benchmarks across different enterprise proxy setups. It's been quite a journey, and we're excited to share where we stand! Thanks to our new approach with storage-layout CI gates and the use of namespaced storage conventions, we’ve managed to completely eliminate emergency rollbacks over the past two quarters. That's a huge win for us! We've also been able to speed up the upgrade approval process by about 30-50%! This is mainly because we have fewer exceptions during our audit reviews, which has really helped streamline things. This isn’t just a lucky break; it’s really about creating solid, machine-verifiable evidence that checks all the boxes for InfoSec and Audit from the get-go.

What You’ll Get from 7Block Labs

• Storage Collision Readiness Pack: This pack has everything you need for repo-level CI integration, including OZ/Slither checks. Plus, it also comes with storage manifests for each contract, making your life a bit easier! OpenZeppelin has network files that are specifically designed to fit your environments perfectly.
• Architecture Migration Plan: We're here to guide you as you make the leap from v4 to v5! With our namespaced storage solution, you can relax knowing all your data will stay safe and sound during the move. Oh, and don’t forget about the optional ERC-8042 for those modular systems! It's a great addition if you're looking to expand your options.
• Governance Runbooks: We’ve got you covered with clear and organized processes for handling multisig and timelock actions, strategies for emergency pauses, and practice guides for upgrades, all designed to meet SOC2 standards.
• One Easy Interface: We’ll blend this smoothly into your current DevSecOps setup, so you won’t need to deal with a “new console” or anything like that. It’ll be a breeze!

If you need help every step of the way--from the very first design to implementation and even audits--we’re here for you! Check out what we can do for you:

• We're diving into the world of Web3 and building some cool protocols with our web3 development services and custom blockchain development services.
• We offer formal reviews and penetration testing as part of our security audit services. We offer enterprise systems integration that includes blockchain integration, and don’t worry--we’ve got your back for ongoing operations too! Hey there! If you're diving into the world of tokens or on-chain assets, we've got your back. Our team is here to help you out with our awesome smart contract development and asset tokenization services. Let’s create something amazing together!

Checklist for Your Next Release

Here’s a super useful checklist you can snag for your next release!

• Take stock of all the proxies and make sure to double-check those EIP-1967 slots on-chain for admin, implementation, and beacon. If you want to dive deeper into the details, you can check it out here.

Make sure to implement OpenZeppelin Upgrades validation and run those Slither upgradeability checks in your CI process. It'll keep everything running smoothly! Just a heads up, if you run into any storage diff issues, be sure to block those merges. Better safe than sorry! Check it out here.

Hey there! Just a quick reminder: if you’re planning to stick with OpenZeppelin v4, don’t forget to keep those __gap buffers in place. They’re super important! Just a quick heads-up: don’t go rearranging, retargeting variables, or tampering with the inheritance order in your proxied contracts. It can really cause some headaches down the line! Get the details here.

Hey there! If you’re thinking about upgrading to OpenZeppelin v5, make sure you take the time to set up those ERC-7201 namespaces. And remember, it’s best to migrate in small steps. That way, you can keep everything running smoothly! Before you make the leap from a v4 to a v5 implementation, make sure you’ve got a solid plan in place for migrating your data. Trust me, you'll want to avoid any headaches down the line! If you're looking for more details, you can check it out here. It’s definitely worth a look!

• Tighten up those initializers! Let’s add some tests to make sure that if we try to initialize a second time--whether it’s directly or through any delegate paths--it’ll roll back on all implementations. If you're looking for some in-depth guidance, you can check it out here. It’s got all the info you need!

Make sure to use the Transparent proxy pattern to keep things separate for admins and users. Or, if you’re going the UUPS route, just double-check that your flow can’t get messed up. Just a quick reminder to double-check that the proxiableUUID is spot on! If you want to dive deeper into this, you can check it out here. Happy reading!

• Go ahead and whip up an upgrade manifest for each environment. You're going to want to link every Upgraded event on-chain to a change ticket, all thanks to OpenZeppelin! It's a smart way to keep everything organized and connected. If you want all the details, just check it out here. It's got everything you need!
• Make sure to jot down your fallback strategy. Make sure to steer clear of any SELFDESTRUCT-based patterns now that we've got EIP-6780 in the mix. Just focus on using proxies or handling data migrations. If you want to dive deeper into that, just check it out here. There’s a lot more info waiting for you!

Hey there! If you're dealing with a tough DeFi integration, want to tap into some cross-chain exposure, or you’re thinking about launching a consumer brand token, we’ve got your back! Plus, we really enjoy getting into the nitty-gritty of protocols and building bridges. Check out our cross-chain solutions development and blockchain bridge development to see how we can help you out! We’re all about sticking to those solid storage-governance principles no matter which chain we’re working with!

Final Word

The proxy pattern isn't disappearing anytime soon. When we're talking about storage safety, it's not just some random feature of Solidity; it's actually super important for governance and compliance. Getting this right can really make a difference in your schedule and help keep your audits in tip-top shape! If your upgrade process isn’t providing you with reliable, machine-verifiable proof that your storage is intact, then you might be building up some pretty hefty technical debt.

Book a 90-Day Pilot Strategy Call

Ready to kickstart your journey? Why not book a 90-Day Pilot Strategy Call with us! This is a fantastic chance to really dig into your goals and get some personalized tips that can set you up for success. Let’s make it happen together!

Let’s team up and figure out a great plan together! Reach out to us and let’s get started. Hey! If you’re ready to book your call, just click here. It’s super easy!