--- eip: 8144 title: Multi-Chain GS1 Product Identifier Resolver description: A decentralized approach to resolving GS1 product identifiers. GS1 provides the globally recognized framework for product identification. author: Ricardo Lando Brown (@apriloracle) discussions-to: https://ethereum-magicians.org/t/eip-8144-multi-chain-product-identifier-resolution-for-gs1/27616 status: Draft type: Standards Track category: ERC created: 2026-02-02 --- ## Abstract GS1 is a neutral, not-for-profit, global organization that develops and maintains the world's most widely used supply chain standards system. It manages the system of international product numbering and barcode standards, enabling the unique identification and transmission of information about products, services, locations, and more. GS1 standards provide companies with a common international business language and grammar, ensuring that product identifiers like GTINs (Global Trade Item Numbers—the numbers you see under barcodes) are unique, global, and verifiable. With over a million member companies across 150+ countries executing more than five billion transactions daily, GS1 standards are the de facto global standard for product identification. This EIP describes an open, multi-chain approach for resolving product identifiers that follow GS1 standardized formats (such as Global Trade Item Numbers, GTINs) to publicly available product information. The described architecture uses deterministic smart contract deployment across multiple EVM-compatible networks to enable redundant, token-free access to open product data sources, including publicly available databases. The system is described as public digital infrastructure, emphasizing non-discriminatory resolution services without requiring token ownership, fees, or privileged access. ## Motivation Resolution of GS1-based product identifiers is commonly provided through centralized services operated by standards organizations or commercial entities. While such systems are widely deployed, they introduce several structural limitations: * **Single points of failure:** Centralized resolver services may experience outages, policy changes, or permanent service discontinuation. * **Access restrictions:** Some resolver services require memberships, contractual agreements, fees, or authentication. * **Geographical limitations:** Availability and performance may vary across jurisdictions. * **Limited transparency:** Resolution logic and underlying data sources are often not publicly auditable. Recent advances in deterministic smart contract deployment and the availability of multiple EVM-compatible networks enable alternative approaches to identifier resolution. A decentralized, multi-chain resolver mesh can provide redundant resolution paths, transparent resolution logic, and open access independent of any single operator, organization, or jurisdiction. Such properties are particularly relevant for use cases including supply chain transparency, food information systems, and digital product passports, where broad public access to product information serves a public-interest function. The architecture described in this EIP is informed by previously published research.[^1] ## Specification This EIP is informational and does not define a protocol-level specification. The architectural specification is described in the following subsections. ### Architecture Overview The described system consists of a set of smart contracts deployed deterministically at identical addresses across multiple EVM-compatible networks. These contracts expose read-only resolution functionality that maps GS1-compliant product identifiers to references or pointers to publicly available product information. Resolution requests may be performed on any supported network. Clients may query one or multiple networks and treat the results as interchangeable, thereby achieving redundancy and fault tolerance at the application level. No single chain is designated as canonical. The contracts do not require native tokens, ERC tokens, or payment mechanisms to perform resolution. All interactions are designed to be publicly accessible read-only calls. The resolver smart contract is permanently deployed and contains no upgrade or administrative mechanisms; all evolution of resolved product information occurs off-chain. ### Resolver Contract Interface The resolver contract has been deployed deterministically across 10 EVM-compatible mainnets, including Ethereum mainnet, using the CREATE2 opcode to ensure the same address on every supported chain. The contract is deployed at 0xeFaAB5Ec699d8c3Bd63d783025268c545357d45F on all supported networks. The contract implementation is as follows: ```solidity // SPDX-License-Identifier: MIT pragma solidity ^0.8.18; /** * @title HolocronRouter * @notice A Universal Registry for Coordinate Existence. * @dev Deployed via CREATE2 to exist at the same address on all chains. */ contract HolocronRouter { struct HolocronEntry { bool exists; address provider; uint40 timestamp; } // Mapping: Universal Coordinate -> Entry mapping(uint256 => HolocronEntry) public registry; event HolocronStocked(uint256 indexed coordinate, address indexed provider); // No constructor arguments to keep CREATE2 deployment simple. // If you need an owner, use 'initialize' pattern or hardcode it via internal logic. /** * @notice Register a coordinate. * @param _coordinate The Universal HolOutHash provided by the Agent. */ function stock(uint256 _coordinate) external { // Idempotency: If already stocked, stop to save gas. if (registry[_coordinate].exists) { return; } registry[_coordinate] = HolocronEntry({ exists: true, provider: msg.sender, timestamp: uint40(block.timestamp) }); emit HolocronStocked(_coordinate, msg.sender); } /** * @notice Check if a coordinate exists in the registry. * @param _coordinate The Universal HolOutHash to query. * @return bool True if the coordinate has been stocked. */ function checkExistence(uint256 _coordinate) external view returns (bool) { return registry[_coordinate].exists; } } ``` ### User Interaction Flow Users interact with the resolver contract through the following operations: 1. **Stocking a Coordinate:** Any user can call the `stock(uint256 _coordinate)` function to register a GS1 product identifier. The function is idempotent—if the coordinate already exists, the call will silently return without reverting, saving gas. The `provider` address (the caller) and a `timestamp` are recorded for transparency. 2. **Checking Existence:** Users can call `checkExistence(uint256 _coordinate)` as a read-only function to verify whether a specific product identifier has been registered on the current chain. This call does not require any tokens or payment. 3. **Reading Registry Data:** The `registry` mapping is publicly accessible, allowing users to inspect the `exists`, `provider`, and `timestamp` fields for any coordinate. Clients may query one or multiple networks and treat the results as interchangeable, achieving redundancy and fault tolerance at the application level. No single chain is designated as canonical. The contracts do not require native tokens, ERC tokens, or payment mechanisms to perform resolution. All interactions are designed to be publicly accessible read-only calls (with the exception of `stock`, which requires a transaction to write to the registry). The resolver smart contract is permanently deployed and contains no upgrade or administrative mechanisms; all evolution of resolved product information occurs off-chain. ### Design Note: Open Registration The `stock` function is intentionally permissionless. Any address may register any coordinate on a first-come, first-served basis. This design choice reflects the principle that the resolver serves as public digital infrastructure rather than a gatekeeper of identifier ownership. The on-chain registry does not assert legal ownership, authenticity, or exclusive commercial rights over any GS1 identifier. Consumers of the registry data should not treat the `provider` address as an authoritative source without additional off-chain verification. The resolver simply provides a transparent, immutable record of *who* registered a coordinate and *when*, leaving trust and validation to the application layer. ### Identifier Resolution Model Product identifiers are represented in accordance with GS1 standardized formats, such as GTINs. The on-chain resolution logic does not assert ownership, authenticity, or commercial rights over identifiers. Instead, it provides a deterministic mapping from identifier values to data references. Resolved data may include: * Content-addressed references (e.g., hashes) * URLs pointing to publicly accessible datasets * Structured metadata stored directly on-chain, where appropriate The architecture is intentionally data-source-agnostic and does not privilege or depend on any single data provider. ## Rationale ### Deterministic Deployment Deterministic contract deployment enables identical resolver logic to exist at the same address across multiple networks. This simplifies client implementations and allows applications to treat multiple networks as redundant resolution backends. ### Multi-Chain Approach No single blockchain network is assumed to be universally available, stable, or globally accessible. A multi-chain approach reduces dependency on any single execution environment and improves resilience against outages, governance changes, or network-specific failures. ### Token-Free Access The absence of token requirements avoids introducing economic barriers to access and simplifies integration for public-interest applications. This design choice aligns with the goal of treating identifier resolution as public digital infrastructure rather than as a monetized service. ### Informational Scope This EIP does not define a mandatory interface, contract ABI, or application-level standard. It documents an architectural approach that may inform future implementations, research, or standardization efforts without prescribing a specific solution. ## Security Considerations The architecture described in this EIP introduces several security considerations that implementers and users should evaluate carefully. ### Data Integrity and Trust While resolution logic may be transparent and auditable, the correctness of resolved product data depends on external data sources. Malicious, outdated, or incorrect off-chain data may be referenced without violating on-chain logic. ### Immutability and Data Correction The resolver smart contracts described in this EIP are intentionally non-upgradable and permanently deployed. The on-chain logic is fixed and does not support modification, replacement, or redeployment. As a result, any errors or updates in resolved product information cannot be addressed through changes to on-chain code. Corrections and updates to product data are managed entirely by off-chain components of the resolver mesh and by the underlying public data sources referenced by the on-chain resolver. This design preserves long-term verifiability and transparency of on-chain resolution logic while allowing product information itself to evolve independently off-chain. ### Chain Reorganizations and Availability Although resolution calls are typically read-only, network instability or reorganization events may affect availability or consistency across chains. Clients querying multiple networks should be prepared to handle inconsistent responses. ### Spoofing and Identifier Abuse The system does not enforce ownership or authorization over GS1 identifiers. This avoids centralized gatekeeping but may allow misleading or fraudulent associations to be published. Consumers of resolved data should apply appropriate validation and trust heuristics. ### Dependency on Off-Chain Infrastructure Practical use of resolved references often depends on off-chain infrastructure such as HTTP gateways, indexers, or content distribution networks. These components may reintroduce centralized points of failure outside the blockchain layer. ## Copyright Copyright and related rights waived via [CC0](../LICENSE.md) [^1]: ```csl-json { "type": "report", "id": "zenodo-18332235", "title": "Decentralized Multi-Chain Infrastructure for GS1 Product Identifier Resolution", "author": [ { "family": "Brown", "given": "R." } ], "issued": { "date-parts": [[2026, 1, 22]] }, "publisher": "Zenodo", "DOI": "10.5281/zenodo.18332235", "URL": "https://doi.org/10.5281/zenodo.18332235" }