This standard defines Content-Addressable Logic Modules (CALM) - minimal, deterministic blocks of code designed for execution via delegatecall within Diamond (ERC-2535, ERC-8109), UUPS (ERC-1822) and other proxy architectures.
A CALM's address is a direct cryptographic commitment to its runtime bytecode. By eliminating deployment-side effects (initialisation code - constructors, immutables), CALM ensures that identical logic resides at identical addresses across all EVM chains. RuntimeBytecode is the Identity.
Current libraries and Diamond Facets are scattered and duplicated within one chain, while being almost impossible to reuse on another chains on the same deployed address. That complicates cross-chain verification and logic reuse increasing operational overhead for multi chain projects.
By standardizing an "atomic" format - free of constructors, immutables, selfdestruct and having the deployment address equal to f(constant, runtimeBytecode) - we enable a global library of Content-Addressable Logic Modules that live at identical addresses on every chain with zero overhead and with option for permissionless redeployment on another chains.
It is expected CALM operates exclusively on the storage context of the calling Proxy. However no checks are required to prevent possessing or initialising its own storage.
To prevent storage collisions and ensure modularity, CALM MUST utilize deterministic storage offsets to manipulate the Proxy’s state.
CALMs SHOULD comply with either ERC-7201 (Namespaced Storage) or ERC-8042 (Diamond Storage) or any future standard of storage separation by defining their internal state at unique, hashed storage locations and utilizing standardized storage slots for shared infrastructure state to ensure interoperability within a proxy.
To comply with the CALM standard, a contract MUST adhere to the following rules during deployment:
No Constructor: The initcode MUST NOT execute any logic other than the deployment of the runtime bytecode as custom constructor will not be considered during re-deployments across chains.
No Immutables: The runtime bytecode MUST NOT contain variables injected during deployment (immutables), as these alter the bytecode hash and break address determinism.
Ensured redeployability onto the same address: CALMs MUST be deployed content addressable based on its runtime bytecode and MUST allow permission-less redeployment onto other chains, i.e. their address is the function:
where publicly known constants are for example:
While such constants are used uniformly with all related CALM contracts on any chain.
Note: CALMs may be authored in any language (e.g. Solidity, Vyper, Huff, Yul) as long as the resulting bytecode adheres to the runtime constraints. The standard focuses on the bytecode output, not the source language.
No Self-Destruct: The contract MUST NOT contain the SELFDESTRUCT (0xFF) opcode. This ensures permanent availability for the proxies relying on the logic on those chains that are not compliant with EIP-6049, EIP-6780 and other SELFDESTRUCT corresponding changes.
Stateless Execution for itself: The contract MUST NOT directly access its own storage.
CALM supports two distinct models for execution:
| Model | Description | Primary Use Case |
|---|---|---|
| Multi-Method (Standard) | Contains an internal dispatcher (e.g. Solidity) that routes calls based on the first 4 bytes in calldata ( standard msg.sig in Solidity ). | Diamond facets containing multiple related functions. Example: Transaction, approval and metadata logic of ERC-20 contract |
| Atomic-Logic (Fallback) | Contains no function dispatcher. All logic resides in one fallback() function. Often used with the Diamond proxy that maps a specific selector directly to such CALM designed facet (so called Single Function Facet). Zero-dispatcher design is compliant with both ERC-2535 and ERC-8109 standards. | Hyper-optimized micro-functions. Example: highly optimised ERC20.transfer() function |
CALMs align with the proposed EIP-7863, which introduces block-level warming for addresses and storage keys allowing accessed addresses to maintain their warm status throughout the execution of an entire block.
This shift provides an economic incentive for Shared Logic. Once a canonical CALM address is invoked by the first transaction in a block, every subsequent call from any other transaction in that same block can benefit from discounted gas costs. By converging on standardized CALM addresses, the community effectively minimizes the "cold access" penalty across the network.
Before EIP-7863 is delivered, CALMs improve Global Cache Efficiency at the node infrastructure level. While warming resets per transaction, execution clients (like Geth or Reth) maintain in-memory LRU caches for frequently accessed bytecode to avoid expensive lookups in the state trie. A community convergence on canonical CALM addresses for standard operations ensures that these "hot" logic blocks remain in node memory, reducing the net I/O pressure on the network and increasing the de facto processing speed of the global state by preventing optimized logic from being fragmented across thousands of unique, cold trie locations.
CALM is the architectural culmination of Ethereum's move toward modular standardization (e.g., ERC-2535, ERC-7201, ERC-8042), establishing a "Registry-less Registry." A contract's address cryptographically proves its functional integrity, eliminating the need for central authorities or registries to verify logic.
As the community identifies optimal, gas-efficient implementations, canonical CALMs emerge. This convergence on fixed, multichain addresses reduces redundant audits and systemic complexity. Since Runtime Bytecode is Identity, optimized logic for common operations (like ownership or token transfers) remains stable and universally accessible across the decentralized stack.
In standard Diamonds, the Proxy performs a delegatecall, and the Facet then performs a second dispatch to find the function by selector. For single function facets that only perform one task, this second dispatch is a waste of gas. CALMs in the form of Single Function Facets allow the Diamond Proxy to map a selector directly to a "naked" logic block, executing the logic immediately upon entry.
Initcode traditionally serves two primary purposes: initializing contract storage and generating runtime bytecode. However, CALMs are designed to bypass both of these steps. The runtime bytecode is directly provided as input, and the intention is to deploy it without any initial storage setup. This design choice is deliberate, aiming to create contracts with immutable bytecode at addresses derived solely from their runtime code content. Consequently, initcode becomes redundant and irrelevant in this context.
A critical distinction exists between social trust and cryptographic proof: Verification (Source Code) is an off-chain, human-centric process (e.g., Sourcify) that asks, "Does this compiler produce this binary?" and offers readability and auditability; while Validation (e.g. using tools like HashCarve.isCarved()) is an on-chain, machine-executable process that asks, "Is this address a direct commitment to its opcodes?" and provides trustless, programmatic certainty of the module's origin and integrity, independent of third-party source hosting.
By default, compilers append a CBOR-encoded metadata footer to the runtime bytecode. This footer includes hashes of the source code, including comments, variable names, abi and compiler settings - see CBOR tooling like Sourcify Playground for details. For CALMs, this is a double-edged sword: changing a single comment alters the deployment address, even if the functional opcodes remain identical. One can achieve pure "Logic-only Identity" of CALM by stripping this metadata e.g., when a contract is compiled with the --no-cbor-metadata flag in Solidity, or using bytecode_hash = “none” and cbor_metadata = false in foundry.toml file.
While stripping metadata ensures that different developers can reach the same address for identical logic, it renders verification on platforms like Sourcify more difficult. They categorize verification into Full (perfect match including metadata) and Partial (logic matches, but metadata differs). Both remain achievable; however, stripping metadata requires a manual handling of the metadata.json file to reach a "Full" match status, as the on-chain fingerprint no longer points to the source.
Once a CALM is verified on one chain, its metadata is indexed, multichain replication tools like CarbonCopy can leverage the Sourcify API to automatically replicate this verification to all other chains where the identical bytecode is detected, thereby creating a "verify once, trust everywhere" network effect. This effectively allows the audit reputation of a CALM to follow its logic across the multichain ecosystem without redundant manual intervention.
Therefore the CALM deployer should decide whether the source codes are to be immutable and strongly linked to the address (metadata impact) of the CALM or whether she needs flexibility in the commenting of the source code for the future and thus being detached from the CALM’s address (no-metadata case). Full verification is achievable in both scenarios, but the choice determines whether the "identity" of the module is defined by its documentation or its pure functional execution.
This standard is fully compatible with ERC-2535 Diamond, ERC-8109 Simplified Diamond, ERC-1822 UUPS proxy, ERC-1167 Clones proxy and potentially other proxy implementations.
This example demonstrates a hyper-optimized Single Function Facet implementing the decimals() function. It leverages the Atomic-Logic pattern, where the proxy maps the specific selector directly to the logic block, bypassing internal dispatching and no CBOR metadata attached.
By using a fallback, we eliminate the Solidity function selector "switch" table, reducing both gas cost and bytecode size.
To ensure the address is a commitment to the logic only, we strip the metadata hash and maximize optimization.
Compiling the above results in the minimal runtime bytecode: 0x60125f5260205ff3. When "carved" via the HashCarve Factory (reference implementation for the permissionless deployment of CALMs at canonical address 0x9c8D020b832Ee8AAF92cB555819Dc8a0c1097F56), the above logic manifests at an identical address on every EVM chain (0xB1fDF38E7ae86bf190654b212bD7e53B542DE958) and can be replicated permissionlessly by anyone onto another (even not yet existing) chains. Runtime Bytecode is Identity.
Because metadata is stripped, platforms like Sourcify require a manual upload of the abi.json and source file for the initial verification on the first chain.
Verification Strategy:
Simple Logic: For trivial CALMs (like Const18 above), stripping metadata is preferred. The bytecode is short enough to be verified via decompilation.
Complex Logic: For sophisticated modules - such as a highly optimized unconditional ERC20.transfer utilizing ERC-8042 (Diamond Storage) - preserving full CBOR metadata is recommended. This ensures that comments, security warnings, and the exact audit environment are cryptographically bound to the CALM's identity.
Since a CALM is "stateless" but "state-manipulating," it must be carefully audited to ensure it only touches the storage namespaces it is authorized for.
Proxies such as Diamonds using CALMs SHOULD audit and test their overall configuration in order to ensure CALMs are not misaligned in the storage handling. For example, mixing ERC-7201 and ERC-8042 storage patterns across CALMs will cause bugs because they reference different storage locations for the same logical state.
Standard contract verification is fragile; an attacker could provide source code that matches the functional opcodes but contains misleading comments or variable names. For high-security modules (like ERC20.transfer), the standard recommends preserving the CBOR metadata. This binds the audit report, developer comments, and exact compiler settings to the address. If an attacker tries to change a comment to hide a bug, the address changes, and the validation for the original logic fails.
Copyright and related rights waived via CC0.