This EIP proposes an interoperable indexing strategy designed to enhance the organization and retrieval of digital media information across multiple smart contracts and EVM-compatible blockchains. This system enhances the traceability and verification of cross-contract and cross-chain data, facilitating a more efficient discovery of storage locations and crucial information related to media assets. The major purpose is to foster an integrated digital media environment on the blockchain.


Given the significant role digital media files play on the Internet, it’s crucial to have a robust and efficient method for indexing immutable information. Existing systems encounter challenges due to the absence of a universal, interoperable identifier for digital media content. This leads to fragmentation and complications in retrieving metadata, storage information, or the provenance of specific media assets. The issues become increasingly critical as the volume of digital media continues to expand.

The motivation behind this EIP is to establish a standardized, decentralized, and interoperable approach to index digital media across EVM-compatible networks. By integrating Decentralized Content Identifiers (CIDs) and Commit events, this EIP puts forward a mechanism enabling unique identification and indexing of each digital media file. Moreover, this system suggests a way for users to access a complete history of data associated with digital media assets, from creation to the current status. This full view enhances transparency, thereby providing users with the necessary information for future interactions with digital media.

This method creates a common interface that any digital media system can use to provide a standard way of indexing and searching their content.

Figure 1: Digital Media Indexing Relationships and Lookup

This EIP aims to create an interoperable indexing system to associate all data of the same digital content together (Figure 1). This will make it easier for users to find and trust digital media content, and it will also make it easier for systems to share and exchange information about this digital media content.


The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in RFC 2119 and RFC 8174.

Content Identifier

Content Identifier in this EIP is the content address generated by passing the content of a digital media through a cryptographic hash function. Before the indexing process for digital media can begin, it is REQUIRED to generate unique Content Identifiers for each file. This identifier should the same as the Content Identifiers on the decentralized storage, ensuring each identifier provides access to the metadata, media information, and the content file itself.

Commit Function

To index digital media, we shall call the commit function and generate Commit event:

 * @notice Emitted when a new commit is made.
 * @param recorder The address of the account making the commit.
 * @param assetCid The content identifier of the asset being committed.
 * @param commitData The data associated with the commit.
event Commit(address indexed recorder, string indexed assetCid, string commitData);

 * @notice Registers a commit for an asset.
 * Emits a Commit event and records the block number of the commit in the recordLogs mapping for the provided assetCid.
 * @dev Emits a Commit event and logs the block number of the commit event.
 * @param assetCid The content identifier of the asset being committed.
 * @param commitData The data associated with the commit.
 * @return The block number at which the commit was made.
function commit(string memory assetCid, string memory commitData) public returns (uint256 blockNumber);


The design decisions in this EIP prioritize the effectiveness and efficiency of the indexing method. To achieve this, Decentralized Content Identifiers (CIDs) are utilized to uniquely identify digital media content across all systems. This approach offers accurate and precise searching of media, along with the following benefits:

  1. Strengthened data integrity: CIDs serve as cryptographic hashes of the content, ensuring their uniqueness and preventing forgery. With the content in hand, obtaining the CID allows for searching relevant information associated with that content.

  2. Streamlined data portability: CIDs enable the seamless transfer of digital media content across different systems, eliminating the need for re-encoding or reconfiguration of protocols. This promotes a more interoperable and open indexing system. For example, in cases where Non-Fungible Tokens (NFTs) are created prior to Commit events, the digital media content can still be indexed by converting the file referenced by the tokenURI using the same mechanism. This conversion process ensures that the digital media content associated with NFT tokens can be indexed with a consistent identification approach.

Reference Implementation

// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.4;

import "@openzeppelin/contracts/utils/cryptography/ECDSA.sol";
import "@openzeppelin/contracts-upgradeable/proxy/utils/Initializable.sol";

contract CommitRegister is Initializable {
    using ECDSA for bytes32;

    mapping(string => uint[]) public commitLogs;

    event Commit(address indexed recorder, string indexed assetCid, string commitData);

    function initialize() public initializer {}

    function commit(string memory assetCid, string memory commitData) public returns (uint256 blockNumber) {
        emit Commit(msg.sender, assetCid, commitData);
        return block.number;

    function getCommits(string memory assetCid) public view returns (uint[] memory) {
        return commitLogs[assetCid];

Security Considerations

When implementing this EIP, it’s essential to address several security aspects to ensure the safety and integrity of the digital media index:

  1. Input Validation: Given that commit function accepts string parameters, it’s important to validate these inputs to avoid potential injection attacks. Although such attacks are less common in smart contracts than traditional web development, caution should be exercised.

  2. Data Integrity: The commit function relies on CIDs, which are assumed to be correct and point to the right data. It’s important to note that this EIP doesn’t validate the content behind the CIDs and the commit data, which remains a responsibility of the users or implementing applications.

  3. Event Listening: Systems relying on listening to the Commit events for changes need to be aware of potential missed events or incorrect ordering, especially during periods of network congestion or reorganizations.

Implementers should consider these security aspects in the context of their specific use case and deployment scenario. It is strongly recommended to perform a comprehensive security audit before deploying any implementation of this EIP to a live network.

Copyright and related rights waived via CC0.