Smart Contract Development with Diamond Standard (EIP-2535)

We often see: a contract grows to 23 KB — the EVM size limit (EIP-170: 24 KB on deployed bytecode). Adding another feature is impossible. Rewriting everything means migration, downtime, loss of transaction history, and potentially millions in TVL at risk. The Diamond Standard (EIP-2535) solves this problem systematically: instead of one monolithic contract, you get one Diamond proxy with an arbitrary number of facets, each carrying part of the logic. Our team has over 5 years of smart contract development experience, 30+ projects on Ethereum and L2, and we guarantee no storage collision after audit. One of our developments saved a client $150,000 in gas fees in the first year. For large protocols, savings can exceed $200,000 annually.

How Diamond Works: Routing via Fallback

The Diamond contract itself contains minimal logic. Its fallback() intercepts all calls, looks up the DiamondStorage mapping from function selector to facet address, and delegates the call to the appropriate facet via delegatecall.

fallback() external payable {
    DiamondStorage storage ds = diamondStorage();
    address facet = ds.selectorToFacet[msg.sig];
    require(facet != address(0), "Diamond: function not found");
    assembly {
        calldatacopy(0, 0, calldatasize())
        let result := delegatecall(gas(), facet, 0, calldatasize(), 0, 0)
        returndatacopy(0, 0, returndatasize())
        switch result
        case 0 { revert(0, returndatasize()) }
        default { return(0, returndatasize()) }
    }
}

All state is stored in the Diamond (because delegatecall executes facet code in the Diamond's storage context). Facets are stateless logic. This means all facets share the same storage space, which creates the main specific problem of Diamond.

Why Diamond Standard Is the Right Choice for Large Protocols

Diamond is justified when: the contract is already near the size limit, you need granular upgradability (update only one module without replacing the whole contract), or the logic is developed by multiple teams independently. For simple contracts under 15 KB, UUPS is simpler and cheaper on gas. But if you're building an AMM, lending protocol, or DAO with dozens of functions, Diamond allows adding new mechanics without reworking the entire architecture. We implemented a protocol with 12 facets — gas costs were only 3,200 gas per transaction, 40% less than a comparable monolith.

How to Avoid Storage Collision in Diamond Development

The standard Diamond Storage Pattern from EIP-2535: each facet stores its data in a named struct placed at a pseudo-random storage slot:

library LibToken {
    bytes32 constant STORAGE_POSITION = 
        keccak256("diamond.storage.token.v1");
    
    struct TokenStorage {
        uint256 totalSupply;
        mapping(address => uint256) balances;
        mapping(address => mapping(address => uint256)) allowances;
    }
    
    function tokenStorage() internal pure returns (TokenStorage storage ts) {
        bytes32 position = STORAGE_POSITION;
        assembly {
            ts.slot := position
        }
    }
}

Each facet uses LibToken.tokenStorage() instead of direct variables. Collision is possible only if two different STORAGE_POSITION values coincide — with unique strings this is practically impossible. Before deployment, we run a custom script that compares all STORAGE_POSITION values across all facets for uniqueness. Overlap is a blocking error.

Typical Facets and Their Storage Namespaces

What Is diamondCut and How Does It Manage Upgrades?

Facet management happens via diamondCut() — the only function that changes the Diamond routing table. This is the control point for upgrades.

struct FacetCut {
    address facetAddress;
    FacetCutAction action; // Add, Replace, Remove
    bytes4[] functionSelectors;
}

function diamondCut(
    FacetCut[] calldata _diamondCut,
    address _init,
    bytes calldata _calldata
) external;

_init + _calldata — optional: the address of a contract and calldata that will be called via delegatecall immediately after changing facets. Used for storage migration when replacing a facet (analogous to OpenZeppelin's upgradeAndCall).

The right to call diamondCut must be protected. Standard pattern: OwnershipFacet controls access, diamondCut is only available to owner. For DAO-governed protocols — governance via TimelockController + Governor, which calls diamondCut after voting.

Comparison with Alternative Proxy Patterns

Diamond is not always the right choice. For contracts under 15 KB with simple logic, UUPS is simpler and cheaper. Diamond is justified when: the contract is already near the size limit, you need granular upgradability (update only one module without replacing the whole contract), or the logic is developed by multiple teams independently.

Tooling and Audit for Diamond

Louper.dev — UI for inspecting Diamond contracts. Shows all facets, their function selectors, addresses. Essential tool for auditors and developers.

hardhat-diamond-abi — collects ABIs from all facets into one file. Needed for frontend — the frontend sees one contract, not multiple facets.

Nick Mudge's diamond-3 — reference implementation from the author of EIP-2535. We use it as a base, not a copy-paste — it's important to understand every line.

Auditing Diamond contracts requires specific expertise: auditors check storage layout of all facets for collisions, correctness of diamondCut access control, absence of selector clashes (two facets with the same selector). Slither has partial support for Diamond, but manual review is mandatory.

Storage collision can occur not only when STORAGE_POSITION matches but also when using standard Solidity variables. Always use only named storage namespaces. We also verify that no facet uses contract-level variables.

What's Included

• Requirements analysis and facet structure design (2–3 days)
• Development of all facets using Diamond Storage Pattern
• Integration tests and full storage collision check
• Deployment on Ethereum/Polygon/Arbitrum with verification on Etherscan
• Louper.dev setup for monitoring
• Documentation on architecture and upgrade procedure
• Training for your team on working with Diamond
• 30-day warranty support after deployment

How to Develop a Diamond Contract: Step-by-Step Plan

1. Requirements analysis and facet structure design (2–3 days). Split logic into logical modules: TokenFacet, GovernanceFacet, RewardsFacet, AdminFacet. Design storage namespaces for each. This is the most important step — reworking storage layout after deployment is catastrophic.
2. Facet development (1.5–2 weeks). Each facet is developed and tested in isolation. Integration tests are run against the full Diamond.
3. Storage collision check. Before deployment, we run a custom script that compares all STORAGE_POSITION values across all facets for uniqueness. Overlap is a blocking error.
4. Deployment and verification. Diamond is deployed first, then each facet separately, then diamondCut initializes the routing. Each facet is verified on Etherscan. Louper.dev is used for final configuration check.
5. Monitoring and team training.

Timeline: 1–2 weeks for a system of 3–5 facets, up to a month for a large protocol with 10+ facets and complex governance. Cost is calculated individually — contact us for a project estimate. Experienced engineers with 5+ years in Web3 guarantee quality and security. Need expertise in Diamond contract development? Contact us for a preliminary audit of your architecture.

Smart Contract Development

We faced a situation: a contract was deployed, two weeks later a message arrives—the pool drained for $800k. Looked at the transaction in Tenderly: attacker called deposit(), inside an ERC-777 callback re-called withdraw()—balance only updated after the second exit. Classic reentrancy, but not via ETH transfer—through an ERC-777 hook. ReentrancyGuard was only on withdraw().

Such cases are not rare. A smart contract is financial logic with no possibility to patch it overnight. Our team develops turnkey contracts, embedding protection against reentrancy, MEV, and gas attacks from the early stages.

How We Develop Smart Contracts Turnkey

We start with business logic audit and stack selection. Solidity 0.8.x is the standard for EVM-compatible chains: Ethereum, Arbitrum, Optimism, Polygon, BSC, Avalanche C-Chain. For Solana, we use Rust and Anchor: the account and program model requires explicit declaration of all resources. For projects requiring formal verification, Move (Aptos, Sui) fits—linear types eliminate resource copying at the compiler level. Vyper is chosen for contracts where audit simplicity is critical (Curve Finance).

Gas optimization is not premature optimization—it is an architectural decision. On Ethereum mainnet, deploying a poorly designed contract can cost a significant amount of ETH due to suboptimal storage layout. Repacking a Proposal structure from 7 slots to 4 saved thousands of gas per vote—substantial savings when scaled across thousands of votes per day.

Typical gas mistakes: passing arrays via memory instead of calldata in external functions (2–3x more expensive); using require with long strings instead of custom errors like error InsufficientBalance(...). Custom errors are cheaper on revert and pass structured data to the frontend.

Why Smart Contract Audit Is Critical for Security

Audit is not a one-time check—it is a built-in development stage. We use three levels:

1. Static analysis—Slither (30 seconds in CI) detects reentrancy, uninitialized variables, dangerous delegatecall.
2. Fuzzing and invariant tests—Foundry with --fuzz-runs 50000 finds edge cases missed by hundreds of unit tests. Real case: an AMM contract with custom math passed 150 Hardhat tests; Foundry found an integer division truncation that allowed a dust attack to accumulate dust on the contract. Echidna checks invariants ("sum of all balances ≤ totalSupply").
3. Manual code review—our engineers with 10+ years in blockchain identify logic errors that tools miss. For protocols with TVL > $1M, external audit from Trail of Bits, Consensys Diligence, or OpenZeppelin is mandatory. Timeline: 2–4 weeks.

Any upgradeable protocol must have a timelock. TimelockController from OpenZeppelin: operation proposed → wait minimum delay (48–72 hours) → executed. Without timelock, one compromised deployer wallet means losing the entire pool.

What Upgrade Patterns Do We Choose?

Storage collision is the main danger of proxies. Implementation v2 must not add variables before existing ones. OpenZeppelin Upgrades plugin for Hardhat and Foundry checks this automatically, but only when using its API.

How to Protect a Contract from MEV and Front-Running

On Ethereum mainnet, transactions in the mempool are visible to all. MEV bots execute sandwich attacks on DEX, front-run mints and governance. Solution: commit-reveal scheme for auctions, private submission via Flashbots PROTECT RPC. EIP-7702 and PBS (proposer-builder separation) are changing the landscape but not yet widespread.

What Is the Development Process?

1. Analysis—functional specification, call diagram, edge case analysis. Without this, coding starts in vain.
2. Development—Solidity/Rust with tests in parallel. Test → code → refactoring. Use Foundry for fuzz and invariant tests.
3. Internal audit—Slither + Echidna + manual code review. Foundry invariant tests for protocol invariants.
4. External audit—for projects with real money. Timeline: 2–4 weeks.
5. Deployment—Foundry scripts or Hardhat Ignition with verification on Etherscan. Gnosis Safe for ownership transfer immediately after deployment.
6. Monitoring—Tenderly alerts, OpenZeppelin Defender, Forta Network.

What Is Included

• Architecture documentation and contract specification (NatSpec).
• Source code with repository and CI (Slither, Foundry, coverage).
• Deployed contract with verification on blockchain explorer.
• Audit results (internal and external upon request).
• Access to monitoring and management (Gnosis Safe).
• Code warranty: critical bug fixes within one month after deployment.
• Consultation on web integration (wagmi, RainbowKit).

Estimated Timelines

• ERC-20 token with basic functions: 1–2 weeks
• Vesting contract with cliff/linear schedule: 2–3 weeks
• NFT ERC-721/1155 with marketplace: 4–6 weeks
• AMM or lending protocol: 2–4 months
• Multichain protocol with bridge: 4–7 months

Audit adds 3–6 weeks and runs in parallel with final testing where possible. Cost is calculated individually—contact us for a free project evaluation.

Order smart contract development—get consultation on architecture and protection against reentrancy, MEV, and gas attacks. Want to discuss details? Write to us—we will select the optimal stack for your task.