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:
// 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:
-
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. Theprovideraddress (the caller) and atimestampare recorded for transparency. -
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. -
Reading Registry Data: The
registrymapping is publicly accessible, allowing users to inspect theexists,provider, andtimestampfields 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
{
"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"
}