Title: Deprecating a Smart Contract: How to Sunset a Protocol Gracefully

When you’re dealing with smart contracts, there are times when you just have to move on. Whether it’s because the code is outdated, there are security issues, or a cooler solution has popped up, carefully deprecating a smart contract is essential. Here’s a friendly guide to help you navigate this process smoothly.

Understanding Deprecation

Deprecation is just a fancy term for signaling that a contract is being phased out. This can happen for a bunch of reasons, like:

• Security Issues: If you discover a vulnerability, it might just be the right moment to rethink things.
• New Features: Perhaps you’ve created something even cooler and want to encourage users to make the switch.
• Obsolete Logic: When the code in your contract starts feeling old or clunky, it’s definitely time for an upgrade.

Steps to Deprecate Your Smart Contract

Here’s a simple way to tackle it:

1. Communicate with Your Users

First things first, keep your users in the loop. Transparency is super important! Use your platform, social media, or even a blog post to break down why you’re moving away from the contract. Make it clear what the timeline looks like and any steps they need to take.

2. Implement a Migration Plan

Having a solid migration plan really makes a difference. It's super important to set up a clear process for users to transition their assets or operations to the new contract. Here’s a rough outline you might want to think about:

• Get the New Contract Ready: Let’s make sure it’s all set to go.
• Build a Migration Tool: This will help automate the switch for users.
• Test Everything Out: Give the migration process a thorough check to ensure it flows smoothly.

3. Disable the Old Contract

Once everything’s set up, it’s time to disable that old contract. You might want to take it step by step:

1. Pause Transactions: Stop any incoming transactions to the old contract for now.
2. List Deprecation Status: Make sure to update your documentation and website to indicate that the contract is no longer active.

4. Offer Support

Even after the old contract is retired, your users will still value your support. It might be a good idea to set up dedicated channels, like a Discord or Slack, where they can ask questions about the migration process.

5. Keep an Eye on Feedback

Once you've deprecated something, keep a close eye on what users are saying. This feedback can really help you tackle any hiccups that pop up during the switch. Plus, it sends a message that you genuinely care about their experience!

Conclusion

Deprecating a smart contract doesn’t need to be complicated. If you keep communication clear, create a solid migration plan, and support your users along the way, you’ll make the transition as seamless as it can be. Just remember, it’s all about keeping the community informed and making sure they feel appreciated throughout the process. Happy sunsetting!

the specific headache you’re likely feeling

• It's time to say goodbye to some of those old contracts (you know, like v1 liquidity pools, vaults, or token wrappers) and help your users transition to v2/v3. The key is to do this without locking up their funds or hurting your total value locked (TVL).
• You've got a setup that mixes both upgradeable and immutable components, plus some on-chain governance rules to consider. And don’t forget, you’re also navigating across L2s where the “canonical” tokens have made some changes (for instance, USDC.e has transitioned to USDC). If you get the deprecation order wrong, you might wind up with stranded assets or broken routes. (docs.optimism.io)
• Simply saying “We’ll selfdestruct and redeploy” doesn’t fly anymore: EIP-6780 has revamped the SELFDESTRUCT rules, so you can't just depend on metamorphic patterns to switch out logic at the same address like in the past. Check it out here: (eips.ethereum.org)
• Don’t overlook the last-mile user journey; it can be a bit shaky. Approvals can drag on (shoutout to Permit2), MEV bots might swoop in and disrupt your migration swaps, and those old LP tokens could lose their liquidity in secondary markets. (docs.uniswap.org)

the Risk if You Get This Wrong

• Missed Deadlines Cascade: When you miss a deadline, it can trigger a chain reaction. Those governance timelocks can really throw a wrench in your upgrade plans. If you hit the brakes at the wrong time, users might not be able to get out safely when they need to. (docs.openzeppelin.com)
• Liquidity Fragmentation: If you mess up the mapping between bridged and native assets (like USDC.e versus USDC on OP/Arbitrum), you might find your new liquidity pools running dry while the older ones continue to scoop up all the volume. In the meantime, your operations team could be left puzzled for months, asking, “Where did all the TVL go?” (docs.optimism.io)
• Security Regressions: If you hurry through UUPS or Transparent upgrades and overlook the storage-layout validation, you could end up with bricked proxies or run into reentrancy issues. While formal tools can detect these problems, they’ll only do their job if you integrate them into your CI before hitting that freeze button. (docs.openzeppelin.com)
• User Losses and Reputational Damage: Reusing Permit2 signatures in phishing attacks can lead to drained wallets, especially during that “approve then migrate” phase. And don’t forget, when you throw bulk exits into the public mempool, you’re basically giving away the scoop to MEV. (decrypt.co)

7Block Labs’ Methodology to Sunset Safely (and Measurably)

When it's time to wrap up a project, 7Block Labs has got a great strategy in place to make sure everything goes off without a hitch and you can easily monitor how things are going. Here’s how we’ve got it all laid out:

Step-by-Step Approach

1. Assess the Current State

First things first, take a moment to really assess the current situation. Check out the project’s performance metrics, gather user feedback, and identify any technical hurdles. This will give you a clear picture of what’s been successful and what needs some tweaking.

2. Define Success Metrics

Next up, it’s time to nail down what success means for your sunset process. Think about metrics like user retention rates, how well the data migration goes, or even the timeline for wrapping things up.

3. Communicate Early and Often

Don't hold off on sharing the news! It's super important to keep your stakeholders in the loop about what's going on and why. Getting the word out early helps set expectations right and opens the door for some really helpful feedback.

4. Create a Transition Plan

Project Phase-Out Plan

Key Dates

• Start Date: [Insert Start Date]
• Phase-Out Completion Date: [Insert Completion Date]

Tasks

1. Notify Stakeholders
   • Deadline: [Insert Date]
   • Description: Inform all relevant parties about the phase-out and what it entails.
   • Resources Needed: Email template, stakeholder contact list.
2. Document Current Status
   • Deadline: [Insert Date]
   • Description: Create a comprehensive report on the current state of the project, including achievements and outstanding tasks.
   • Resources Needed: Project management software, access to project files.
3. Identify Transition Team
   • Deadline: [Insert Date]
   • Description: Assemble a team responsible for managing the transition process including project leads and key personnel.
   • Resources Needed: Team roster, meeting schedule.
4. Compile Knowledge Transfer Materials
   • Deadline: [Insert Date]
   • Description: Gather documentation, tutorials, and any other resources useful for future projects or teams.
   • Resources Needed: Document templates, existing project documents.
5. Settle Outstanding Tasks
   • Deadline: [Insert Date]
   • Description: Prioritize and complete any remaining tasks or hand them over to other teams.
   • Resources Needed: Task management system, team collaboration tools.
6. Conduct Final Review
   • Deadline: [Insert Date]
   • Description: Host a meeting to review project outcomes, celebrate successes, and discuss lessons learned.
   • Resources Needed: Meeting platform, agenda.
7. Communicate Final Phase-Out
   • Deadline: [Insert Date]
   • Description: Send a final communication to all stakeholders confirming the completion of the phase-out and expressing appreciation for their contributions.
   • Resources Needed: Email template, contact list.

Resources Needed

• Personnel
  • Project managers
  • Team members
  • Stakeholders
• Tools & Software
  • Project management tools (e.g., Trello, Asana)
  • Communication platforms (e.g., Slack, Zoom)
• Documentation
  • Knowledge base articles
  • Reports and summaries

Conclusion

By following this phased approach, we can ensure a smooth transition and leave no loose ends while wrapping up the project. Let’s keep the lines of communication open and support each other throughout the process!

5. Monitor and Adjust

As you begin rolling out the sunset, make sure to monitor your success metrics closely. If things aren’t quite hitting the mark, be prepared to tweak your approach on the go.

Key Takeaways

• Evaluate Performance: Take a moment to figure out how your project is doing right now.
• Set Clear Metrics: Get specific about what success means for the sunset process.
• Communicate: Make sure to keep everyone updated to manage expectations effectively.
• Plan: Put together a solid transition plan that’s ready to roll.
• Stay Flexible: Be ready to adjust your strategy as needed along the way.

With this methodology set up, you can confidently wrap up projects, making sure the whole process is safe and measurable. If you want to dive deeper into our approach, feel free to explore our 7Block Labs website.

Phase 0 -- Control Plane Hardening (Week 0)

• Transfer the upgrade rights to a TimelockController with a minimum delay ranging from 48 to 120 hours. Just ensure that your DAO or multisig is the proposer, while the executor can be either the timelock or open. Once that's done, you can go ahead and renounce any external admin rights. This setup means that every maintenance task, including anything that could lead to deprecation, will be on a delay and can be monitored easily. (docs.openzeppelin.com)
• Connect your on-chain governance to a Governor that supports ERC‑6372 clock-awareness. This way, your voting periods will stay consistent, even if block times vary between chains. Check it out here: (docs.openzeppelin.com)

Phase 1 -- Architecture-specific Deprecation Plan (Week 1-2)

In this phase, we’ll review your deployments and decide on the best way to deprecate each artifact:

1) ERC‑1967 UUPS or Transparent Proxies

• Strategy: We're gearing up for one final upgrade to a "WithdrawOnly" setup that:
  • Shuts down all state-changing functions except for withdraw, unstake, and claim.
  • Slashes transaction fees to zero and sends out a Deprecation Notice that includes the version, new address, and deadline.
  • Optionally adds a grace period with the timelock to keep things crystal clear.
• Why: UUPS has quickly become a popular pick for those looking to save on gas fees. Since UUPS and Transparent proxies use the same ERC‑1967 slots, switching over is pretty simple and easy to follow. You can dive into all the details here.
• Guardrails: Don't forget to run validateUpgrade and do those storage-gap tests as part of your continuous integration setup. It's best to steer clear of "unsafeSkipStorageCheck" unless you've got some strong evidence to support it. For more details, check it out here.

2) Beacon Proxies

• Strategy: Upgrade just one beacon to the WithdrawOnly implementation. This nifty trick allows you to freeze an entire fleet of instances in one go. It’s super effective for factories that manage a bunch of child contracts. For more info, take a look at the details in the OpenZeppelin docs.

Diamonds (ERC‑2535/8109)

• Strategy: Use diamondCut to easily remove or swap out state-changing selectors. Don’t forget to keep the read paths and exit functions intact! And make sure to emit DiamondCut along with a DeprecationFacet to steer users toward vNext. You can find more details here: (eips.ethereum.org)

4) Immutable Contracts (No Proxy)

• Strategy: If your contract has a Pausable feature or an “escape hatch,” it’s a good idea to flip it to withdraw-only mode. If that’s not the case, think about rolling out a Migrator that utilizes Merkle snapshots (or zk attestations if you want to keep things under wraps) so everyone can make their claims to vNext. Just a quick note: SELFDESTRUCT isn’t on the table anymore after EIP-6780. You can dive deeper into this here.

Illustrative Solidity: Withdraw-Only Final Implementation (UUPS/Transparent)

Final Version of the Withdraw-Only Smart Contract

Alright, let’s take a closer look at the finished version of our Withdraw-Only smart contract. This implementation highlights the use of both UUPS and Transparent proxies, giving us some great flexibility and efficiency.

What’s the Deal with Withdraw-Only?

The Withdraw-Only contract is designed for simplicity and security. It lets users deposit their funds and only allows for withdrawals later on. There’s no need to deal with complicated transactions; it’s a really straightforward way to manage assets on the blockchain.

Key Features

• Security First: We’ve layered in top-notch security to make sure that only the right folks can handle withdrawals.
• Proxy Patterns: We're using UUPS and Transparent proxies, which makes upgrades a breeze while keeping the existing state intact.
• Gas Efficiency: Our code is streamlined to help cut down on gas fees for users when they're making transactions.

Smart Contract Code

Here’s the complete code for the Withdraw-Only contract:

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

import "@openzeppelin/contracts/proxy/utils/UUPSUpgradeable.sol";
import "@openzeppelin/contracts-upgradeable/access/OwnableUpgradeable.sol";

contract WithdrawOnly is UUPSUpgradeable, OwnableUpgradeable {
    mapping(address => uint256) private balances;

    function initialize() public initializer {
        __Ownable_init();
    }

    function deposit() external payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw(uint256 amount) external {
        require(balances[msg.sender] >= amount, "Insufficient balance");
        balances[msg.sender] -= amount;
        payable(msg.sender).transfer(amount);
    }

    function _authorizeUpgrade(address newImplementation) internal override onlyOwner {}
}

Explanation of the Code

• Imports: We’re leveraging OpenZeppelin’s libraries to ensure security and smooth upgrades.
• Mapping: This tracks the amount each user has deposited.
• Initialize Function: This sets everything up for the contract, making sure we know who the owner is.
• Deposit Function: Users can add funds here, which increases their balance.
• Withdraw Function: Users can withdraw their funds, as long as they have enough in their balance.
• Authorization: Just the contract owner has the power to upgrade to a new implementation.

Deployment Steps

To get this contract up and running, just follow these easy steps:

1. Set up your environment: First things first, make sure you’ve got Node.js, Truffle, or Hardhat up and running.
2. Compile the contract: Go ahead and execute the compilation command.
3. Deploy: Grab your migration scripts and use them to push the contract onto the blockchain.
4. Interact: Use something like Remix or a JavaScript front-end to start interacting with your contract.

Conclusion

And there you have it! A straightforward Withdraw-Only contract that’s all set to go! No matter if you choose UUPS or Transparent proxies, you're well-equipped to handle user deposits securely. Enjoy your coding journey!

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

import "@openzeppelin/contracts/security/ReentrancyGuard.sol";
import "@openzeppelin/contracts/proxy/utils/UUPSUpgradeable.sol";
import "@openzeppelin/contracts/security/Pausable.sol";

contract Vault_Deprecated is UUPSUpgradeable, ReentrancyGuard, Pausable {
    address public immutable NEW_ADDRESS;
    uint64  public immutable DEPRECATION_DEADLINE; // epoch seconds

    event DeprecationNotice(address indexed newAddress, uint64 deadline);
    event Exit(address indexed user, uint256 assets);

    // storage layout preserved; add vars only if gap permits (use OZ storage gaps)
    uint256[49] private __gap;

    constructor(address _new, uint64 _deadline) {
        NEW_ADDRESS = _new;
        DEPRECATION_DEADLINE = _deadline;
    }

    function initialize() external initializer {
        emit DeprecationNotice(NEW_ADDRESS, DEPRECATION_DEADLINE);
        _pause(); // start paused; unpause only for exit functions below
    }

    // UUPS auth -- restrict to timelock/owner, but we expect no further upgrades
    function _authorizeUpgrade(address) internal view override {
        revert("Sunset: upgrades disabled");
    }

    // Exit path -- allow only withdraws/claims; everything else hard‑reverts
    function withdraw(uint256 assets) external nonReentrant whenPaused {
        // read-only calc; state changes only to settle user balance and transfer
        // ...
        emit Exit(msg.sender, assets);
    }

    // Block any unintended calls
    fallback() external payable { revert("Sunset"); }
    receive() external payable { revert("Sunset"); }
}

Notes:

• UUPS is way more gas efficient than Transparent, and that's all thanks to how the upgrade logic is designed. Just remember to keep your ERC‑1967 slot hygiene in check. Always run validateUpgrade on the live proxy before you schedule anything. Check out the details here: (docs.openzeppelin.com)

Phase 2 -- Cross-chain token and LP migration (week 2-3)

• USDC.e → USDC: When you're transferring assets on OP or Arbitrum, be sure to use the official contract addresses from Circle. Don't forget to follow the guidelines provided by Optimism and Arbitrum. It’s smart to add warnings in the UI and consider setting up an auto-swap for bridged tokens to their native versions through CCTP where it’s applicable. For more info, you can check out the details here.
• LPs: Get yourself a nifty single-step router that can handle burning v1 LP, snagging the assets, and minting v2 LP all in one fell swoop. Don’t forget to use private order flow with Flashbots Protect to dodge those pesky sandwich attacks and keep it a “no revert, no fee” deal. If you want to dive deeper, check out this link.
• Bridges: If you've been working with canonical tokens, don’t forget to let everyone know about the deprecation window. You should keep withdrawals available on the old bridge, but be sure to halt any new deposits once the deadline hits.

Phase 3 -- MEV-safe, Approval-Minimal User Flows (Week 3-4)

• MEV Protection: We're excited to announce that all "migrate" transactions will now automatically route through Flashbots Protect RPC. For our bigger players--often referred to as whales--we’re giving you the option to adjust your MEV-Share settings, so you can strike that perfect balance between hints and privacy. And don’t worry, we’ll only be accepting non-reverting bundles. Just a little tip--if you try to set a 0 priority fee on Protect, it’s not going to fly. You can dive into the details here.
• Approval Hygiene:
  • Whenever we can, let’s take advantage of the ERC-2612 permit for tokens. It really helps us minimize the number of on-chain approvals we need during migration, making everything run a bit smoother.
  • If you’re diving into integrating Permit2, don’t forget to set some limits on allowances, like the amount and duration. Also, try to present this info in a way that’s easy for users to understand. It's super important to keep users in the loop about phishing risks and lay out some straightforward revoke options for them. For more tips, check out the resources here.

Phase 4 -- Security engineering and CI (continuous through freeze)

• Upgrade Safety: Don’t forget to run OpenZeppelin Upgrades’ validate and validateUpgrade in your CI pipeline. It’s super important to ensure that your storage layout changes are tidy, without any gaps, and that there are no unsafe flags lurking around. You can find more details here.
• Static + fuzz + formal:
  • Make sure to use Slither/Aderyn rules to catch any old selfdestruct uses and risky patterns before EIP-6780 kicks in. You can dive deeper into this here.
  • Set up Echidna/Medusa invariants for those “withdraw-only” scenarios and guarantee that your migrator is idempotent. And hey, don’t forget to throw in some action-replay tests for EIP-712 signatures! You can find all the juicy details here.
  • Finally, using Certora rules will be a big help when it comes to upgrade authorization and keeping access invariants intact across timelock/owner paths. Check out the rules here.

Phase 5 -- Communications, Timelines, and Controlled Pausing

• Emergency Stops: Consider Pausable as your go-to tool, not just a one-size-fits-all fix. Keeping those “escape hatches” accessible is key while you're hitting pause on new interactions. OWASP highlights that skipping out on an emergency stop could lead to potential security risks, so ensure that pausing doesn’t leave you stuck. You can dive deeper into this here.
• Governance Scheduling: For deprecation transactions, don’t forget to publish them with the timelock IDs and queue/execution timestamps. This helps integrators like routers, analytics teams, and market makers to plan their reindexing smoothly. If you want to dive deeper into this, check out the info here.

1) Proxy Fleet Sunset via Beacon

• Context: We’re working with a derivative protocol that has tons of per-market proxies all following a beacon pattern.
• Action: We launched a single beacon upgrade that flipped everything to a WithdrawOnly setup. This means we now have an exit-only phase for 21 days, and we’ve also eliminated the fees. On top of that, we sent out DeprecationNotice events with the addresses for the upcoming version.
• Why it worked: With just that one transaction, we were able to update all the proxies simultaneously, keeping everything aligned. Plus, those events made migrating The Graph subgraphs a breeze. For all the nitty-gritty details, check it out here.

2) Immutable Staking v1 → Proxy v2 with Merkle Snapshot

• Context: Remember when v1 was all we had? The only option on the table was the emergencyWithdraw.
• Action: We're excited to let you know that we're taking a snapshot of balances! After that, we'll be rolling out a Migrator using Merkle proofs. This means users can grab their v2 positions with just a quick one-click claim. Don’t worry, everything will be backed by EIP‑712 signed terms for your security. And to top it off, all claims will be processed through Protect RPC.
• Extra: Oh, and we’ve added a nifty “nudge” hook in the v1 front-end that automatically switches to private RPC. This should make your experience a lot smoother!

3) USDC.e to USDC Canonical Shift on OP/Arbitrum

• Context: So, we had these pools that were holding USDC.e, but it turned out that the analytics and routers were a bit slow to adapt to the rise of native USDC.
• Action: We decided to implement on-chain auto-detection for the token type, which allows users to easily switch over to canonical USDC. We also created a 30-day wind-down calendar and added some UI prompts to keep everyone in the loop. And just so you know, we paused new deposits to the USDC.e pools after T+7. For all the details, check this out: (docs.optimism.io)

Emerging Best Practices to Adopt in 2026 Deprecations

• Forget about SELFDESTRUCT for lifecycle control. With EIP-6780 rolling in, it’s only gonna manage ETH transfers and won’t erase code unless it’s tied into the same transaction creation. So, definitely set up your lifecycle switches clearly. You can dive into more details here.
• Choose UUPS over Transparent proxies for your upcoming deployments. It’s important to keep admin roles distinct, so think about using ProxyAdmin or a timelock if necessary. Also, don’t forget to emit Upgraded and AdminChanged events as specified by ERC-1967. For more info, check out this link.
• For those of you handling big modular systems, go with ERC-2535 (or the easier ERC-8109 spec). Rather than risking hot-replacements with facets, think about just deprecating by removing selectors instead. You can find more details here.
• Opt for MEV-aware migrations as your standard choice. It's a good idea to prepare for private order flow and refunds, plus don’t forget to keep track of your Protect RPC settings for your power users. You can dive deeper into this here.
• When it comes to minimizing approvals with Permit2, keep it straightforward. It's super important to show users how to revoke permissions and to build in checks for any stale Permit2 allowances directly in the app. For more tips, take a look here.

Gas Optimization You Can Actually Feel in ROI

• Try to limit those on-chain loops when you're making claims. It’s better to handle the heavy stuff off-chain and use Merkle proofs (or zk proofs if you want things to stay private).
• UUPS upgrades are seriously a game changer! They cut down on the proxy overhead compared to Transparent proxies. Fewer moving parts with each upgrade means lower gas fees and less operational risk. Check it out here: (docs.openzeppelin.com).
• If you're working with temporary adapters or routers that you plan to get rid of after migration, think about using EIP-1167 Clones. They keep things immutable and budget-friendly! You can dive into more details here: (eips.ethereum.org).

What We Deliver (and How Procurement Measures It)

• Migration Risk Register complete with a Gantt chart that includes on-chain proposal IDs, estimated arrival times for each task, execution windows, and the folks assigned to each.
• Governance Artifacts: Here, we're talking about the configurations for the Governor and TimelockController that match up with the ERC‑6372 clocks, including all the necessary quorums and thresholds. Plus, we've kept a careful record of any owner transfers. If you're curious to dive deeper into this, you can check it out here.
• Engineering Assets:
  • We’ve wrapped up the “WithdrawOnly” features for all our upgradeable parts.
  • We’ve got an Immutable Migrator ready to go, complete with Merkle snapshot tools and an easy one-click claim process for users.
  • We’ve also put together a handy guide for getting Flashbots Protect set up, which includes default RPCs and a policy to steer clear of the mempool. Check it out here.
  • To top it off, we’ve set up CI gates using OpenZeppelin’s validateUpgrade, plus checks from Slither and Aderyn to catch deprecated opcodes, validate Echidna invariants, and follow Certora rules for safe access and upgrades. You can check out the details here.
• Cross-Chain Plan: This plan dives into the details of canonical token mapping and sets deadlines (think about native USDC versus bridged tokens), updates for the router, and keeps our partners in the loop. If you want to dig deeper, check it out here.

GTM Metrics Tied to Compensation

Here’s a quick overview of the GTM metrics we consider for compensation:

• TVL Retention: We're really hoping to see at least 95% of our V1 Total Value Locked (TVL) transferred over to vNext within 14 days after it launches.
• Support Burndown: Our goal is to keep migration tickets from active users under 1% after Day 7.
• MEV Slippage: We're aiming for a median slippage of less than 10 basis points on migration swaps routed through Protect, and we want to achieve zero failed on-chain migration transactions by using private bundles. For more details, you can check out docs.flashbots.net.
• Approval Hygiene: We’re shooting for at least 80% of flows to use permit/Permit2 with bounded scopes and auto-revoke prompts. Plus, we want to have zero confirmed Permit2 phishing incidents in our official user experience. You can learn more about this at docs.uniswap.org.

Implementation Timeline (Reference)

• Week 0: Kick things off by tightening up the control plane (you know, timelock/governor stuff) and sorting out those role transfers. Oh, and don’t forget to publish the calendar and RFC - that’s key!
• Week 1-2: Let’s shift our focus to wrapping up the deprecation implementations. We need continuous integration (CI) to ensure that our storage and layout stay safe and sound.
• Week 2-3: Dive into cross-chain canonical mapping, routers, and CCTP paths. This is also a great time to give our partners, like MMs and indexers, a heads up.
• Week 3-4: Start rolling things out in stages. Make sure to keep those RPC defaults protected, set up some exit-only windows, and whip up those analytics dashboards to keep track of our KPIs.

Where 7Block Fits (and Links)

At 7Block, we’ve got you covered from A to Z--whether you’re looking to plan your migration, ship some code, or conduct thorough audits, it’s all here in one spot. Let’s dive into what we can do for you:

• Smart Contracts and Migrators: Dive into our smart contract development options and tailor-made blockchain services.
  • Smart Contract Development
  • Blockchain Development Services
• DeFi Protocol Upgrades, Vaults/Pools/Routers: Check out what we've got for DeFi development services.
  • DeFi Development Services
• Security Reviews and Upgrade Runbooks: We've got your back with security audits that cover everything from fuzzing to formal integration.
  • Check out our Security Audit Services
• Cross-Chain Liquidity and Bridge Planning: Take a look at our awesome solutions for cross-chain development and blockchain integration.
  • Cross-Chain Solutions Development
  • Blockchain Integration
• dApp UX for Migration Flows: We're all about making migration flows super smooth. This includes ensuring MEV-safe paths and keeping approval hygiene in check as we build our dApp solutions.
  • Check out our dApp Development Solutions

Appendix -- Checklists You Can Copy Into Your Runbook

Here’s a super useful set of checklists you can grab for your runbook. Don’t hesitate to customize them to fit your needs!

Pre-Launch Checklist

• Take a look at the documentation
• Run those final tests
• Double-check the deployment environment
• Give the team a heads-up
• Plan for downtime (if we need to)
• Back up the current version
• Make sure monitoring is ready to go

Post-Launch Checklist

• Make sure the deployment was a success
• Keep an eye on the system for any errors
• Look over user feedback
• Tackle any urgent problems
• Refresh the documentation
• Go over the results in our next team meeting

Incident Response Checklist

• Pinpoint the incident
• Collect all relevant info
• Alert the response team
• Evaluate the impact
• Kick off the initial action plan
• Record actions and discoveries
• Go over the incident post-mortem

Maintenance Checklist

• Take a look at the logs and metrics
• Look for any software updates
• Do those routine backups
• Get rid of old data
• Run some system health checks
• Go over security protocols
• Organize team training sessions

Go ahead and snag any of these lists for your runbook! Customize them however you like to match your workflow. Happy documenting!

Governance and Scheduling

• Set up the TimelockController, defined the proposer and executor roles, and the deployer is no longer active. Also shared the minDelay. (docs.openzeppelin.com)
• Aligned the voting windows for the Governor with the token clock mode (ERC‑6372). (docs.openzeppelin.com)

Contract-level changes

• For proxies: just double-check that validateUpgrade goes through, the Upgraded/AdminChanged events are fired off, and the final implementation is strictly for withdraw-only purposes. (docs.openzeppelin.com)
• For diamonds: make sure to either remove or swap out selectors, and don’t forget to emit DiamondCut. (eips.ethereum.org)
• For immutable: verify that a Pausable escape hatch or a Merkle/zk migrator is up and running. Oh, and remember, we should never count on SELFDESTRUCT. (docs.openzeppelin.com)

Cross-chain and Assets

• We've got confirmed canonical addresses now (you know, like USDC on OP/Arb); USDC.e is marked as legacy, and we've got the CCTP path all documented. If you're curious, dive into the details here.
• Bridges are still allowing withdrawals, but just a heads up--new deposits are currently blocked based on the schedule.

User Flows and MEV

• Migrations are now using Flashbots Protect RPC automatically! This means that public mempool usage is disabled in the app. We're also offering some privacy tips specifically for whales. Check it out here: (docs.flashbots.net).
• We've implemented Permit and Permit2 with limited approvals, created a straightforward revoke UX, and added phishing warnings to keep everyone safe online. Get more details here: (docs.uniswap.org).

Security & CI

• Let’s kick things off by running a Slither/Aderyn pass. We need to keep an eye out for those "selfdestruct deprecated" flags. Check this out: (rya-sge.github.io)
• Next, we should get our Echidna invariants set up. Remember: (1) exits need to be idempotent, (2) no state-increasing paths allowed, and (3) let’s make sure claims are within the snapshot bounds. More info here: (github.com)
• Oh, and don't forget--according to the Certora rules, only the timelock can handle deprecations. Also, writing after the deadline is off-limits unless it’s for exits. Just a reminder: (docs.certora.com)

If you're after a migration that emphasizes accountability rather than just hoping for the best, we’re going to approach this like a real project. We’ll establish clear KPIs and assign someone specific to oversee governance, code, communications, and partnerships. Let’s gear up for your next launch by focusing on delivering vNext instead of wrestling with the issues of vOld.

CTA: Let’s Chat About Your DeFi Sunset Strategy! Schedule Your Call Today!

References

• Take a look at EIP‑6780 on changes to SELFDESTRUCT. It's your friendly reminder not to rely too much on metamorphic redeploy patterns. (eips.ethereum.org)
• If you're working with UUPS or Transparent proxies, the ERC‑1967 storage slots are super handy. OpenZeppelin has some excellent tips on this. (eips.ethereum.org)
• Interested in the UUPS proxy pattern? You can find out all the awesome perks right here. (docs.openzeppelin.com)
• The Diamond standard is definitely a game changer for modular systems--think ERC‑2535 and the draft for ERC‑8109. You’ll want to check it out! (eips.ethereum.org)
• If governance is your thing, OpenZeppelin's got some solid best practices for timelocks using ERC‑6372 clocks. It's worth a read! (docs.openzeppelin.com)
• Flashbots Protect and MEV‑Share documents do a great job explaining private order flow and refunds. Definitely take a peek! (docs.flashbots.net)
• Uniswap's Permit2 comes with some fantastic benefits, but keep your eyes peeled for phishing risks. Get the lowdown here. (docs.uniswap.org)
• USDC is now native on OP/Arbitrum, and they’ve got info on migrating from USDC.e. Check it out! (docs.optimism.io)
• The Upgrades CI tool is super useful for checking storage layout validation and spotting gaps. Very helpful! (docs.openzeppelin.com)
• Got some tech goodies for you: Slither/Aderyn selfdestruct detectors, Echidna/Medusa fuzzing, and Certora Prover rules, all in one spot. (rya-sge.github.io)

7Block Labs Services (Quick Links)

• Check out our Blockchain development services for all your development needs.
• Don't overlook our Security audit services to ensure everything's locked down.
• Looking for seamless interactions? Dive into our Cross-chain solutions development.
• Explore our DeFi development services and tap into the world of decentralized finance.
• Interested in automating agreements? Our Smart contract development has got you covered.
• And if you need to connect everything, our Blockchain integration makes it a breeze!

Book a DeFi Sunset Strategy Call

Ready to Dive into DeFi?

Let’s talk strategy!

What’s a DeFi Sunset Strategy Call?

Here’s your opportunity to dive into the world of decentralized finance and see how it can benefit you. We’ll chat about your goals and break down the latest trends in the DeFi scene, helping you map out your next moves.

How to Book Your Call

1. Pick a Date & Time: Check out our calendar and choose a time that fits your schedule.
2. Complete the Form: Share a little about yourself and what you’re looking to accomplish.
3. Confirmation: After you book, we’ll shoot you a confirmation email with all the info you need.

What to Expect

On our call, we’ll talk about:

• Your take on DeFi right now
• What you’re hoping to achieve
• Important trends and tools you should check out
• Practical tips just for you

Ready to Get Started?

Why wait? Schedule your DeFi Sunset Strategy Call today and kick off your journey to mastering decentralized finance!