Element Protocol Docs
GovernanceCommunityXForum
  • Element Protocol Documentation Portal
  • Getting Started
    • Buying Fixed Rate Assets
    • Earning Variable Rates
    • Providing Liquidity
    • FAQ
    • Glossary
  • Element Protocol
    • Concepts Overview
    • Principal Tokens
      • Use Cases
    • Yield Tokens
      • Use Cases
    • Market Forces
    • Providing Liquidity
    • Element Protocol Smart Contracts
      • Core Protocol Contracts
        • Wrapped Position
        • Tranche
        • Tranche Factory
        • Interest Token
        • User Proxy
      • Integration Contracts
        • Yearn Vault Asset Proxy
      • Custom Balancer Curve
        • Convergent Curve Pool
        • Convergent Curve Pool Factory
  • Developers
    • Public Release Changelog
    • Elf SDK
    • Deployment Guide
    • Security
      • Oracles
    • Github
  • Governance (Council)
    • Council Protocol Overview
      • Voting Vaults and Delegation
      • Governance Steering Council (GSC)
    • Council Protocol Interface
      • Overview
      • Proposals
        • Guide: Voting on a Proposal
      • Delegate
        • Guide: Delegating Voting Power
          • DAO (Social) Proposal Template
          • Protocol (Executable) Proposal Template
    • Element Governance Proposal Framework
      • Guidelines of the Element Governance Proposal Framework (EGPF)
      • Venues For Participating in Governance & Discussion
      • What Governance Controls Today
        • Current Protocol Parameters
        • Current Governance Parameters
      • Current Governance Roles
      • The Governance Process
        • Proposals & Proposal Types
        • The Proposal Process Overview
        • The Proposal Lifecycles
          • DAO (Social) Proposal Lifecycle Breakdown & Criteria
          • Protocol (Executable) Proposal Lifecycle Breakdown & Criteria
        • Off-chain Voting Information (Snapshot)
        • On-chain Voting Information
    • Council Protocol Smart Contracts
      • Core Voting
      • Voting Vaults
        • Locking Vault
        • Vesting Vault
        • Governance Steering Council (GSC) Vault
      • Timelock
      • Treasury
      • Spender
      • Optimistic Grants
      • Optimistic Rewards
      • Simple Proxy
    • Airdrop
      • Storage
      • Guide: Discord ZK Claim Flow
      • History
    • Glossary (Governance)
    • Audits
    • Deployed Contract Addresses
  • ELFIVERSE
    • Guide: Mint Your ELF NFT
  • Community
    • Discord
    • Blog
    • X
    • Telegram Announcements
    • Youtube (Community Calls and Video Guides)
Powered by GitBook
On this page
  • 1. Introduction (Summary)
  • 2. Contract Details
  • 3. Key Mechanisms & Concepts
  • 4. Gotchas (Potential source of user error)
  • 5. Failure Modes (Bounds on Operating Conditions & External Risk Factors)

Was this helpful?

  1. Governance (Council)
  2. Airdrop

Storage

PreviousAirdropNextGuide: Discord ZK Claim Flow

Last updated 2 years ago

Was this helpful?

  • Contract Name: Storage.sol

  • Type/Category: Library

  • Contract Source:

1. Introduction (Summary)

The Storage library is a utility library designed to be used with the simple proxy(link). As a library, it is inherited and extended by all of the logic contracts for proxies.

2. Contract Details

There is a set of functions that allow the reading and setting of variables for every type of contract, indexed by their names. The name and type are hashed together to produce a unique storage location and then assembly is used to set the location of a returned storage structure. For low-level types [address, uintX, bytesX] assembly does not have access to the slot, and custom structs [Addresses, UintX, BytesX] are returned instead. The library also contains custom structs for commonly used packing pairs [(uint128, uint128), (uint96, address)]. As a library, it does not have any storage itself, and only contains the ability to help other contracts layout their storage.

3. Key Mechanisms & Concepts

  • Upgradable proxies in Solidity are harder to use securely because the Solidity compiler gives each storage variable a fixed slot in storage, based on declaration order in the source code. This is why special care must be taken to avoid storage corruption on upgrades.

  • This storage library is a way around that uses a hash of the variable name and variable type to assign storage locations, meaning they can be easily accessed across upgrades. They are also much harder to corrupt.

4. Gotchas (Potential source of user error)

  • Two variables of different types may share the same name, and so when loaded with different type functions, load different locations. Nevertheless, we do not encourage using two variables with the same name as it is bad practice.

  • Due to the custom storage layout, other storage libraries should not be assumed to work with this library. We heavily discourage the usage of normal storage management and especially storage assembly simultaneously as this library.

  • Do not allow external access to inputs that are provided as variable names when calling this library. We strongly encourage all variable names to be constant strings set on compile.

  • Due to the pointer system of this contract memory, corruption can cause storage corruption. We strongly discourage interacting with memory assembly in conjunction with this contract and recommend modern versions of solidity.

  • When using this library we recommend the code to be audited by an auditor with extensive low-level EVM experience.

5. Failure Modes (Bounds on Operating Conditions & External Risk Factors)

  • This contract can cause storage corruption if not used securely or due to cascading failures in other places.

https://github.com/delvtech/council/blob/main/contracts/libraries/Storage.sol