iscc-evm - EVM Smart Contracts for ISCC declarations

Introduction

The purpose of decentralized ISCC-CODE declarations is to mint unique and short ISCC-IDs that are owned and controled by its declarers. ISCC-IDs connect Actors to Digital Content in a decentralized environment.

Actors are identified by their wallet addresses which they use to sign ISCC-CODE declarations (ledger transactions). Digital Content is identified by ISCC-CODES. The ISCC-ID is derived from an ISCC-CODE, a wallet address and the history of previous declarations. ISCC-IDs are globally unique, short, persistent, authenticated, and resolve to at least exactly one ISCC-CODE and wallet address. Optionaly ISCC-IDs can also be resolved to off-chain ISCC metadata. The ISCC-IDs are not required to be generated or stored on the participating ledgers themselves but are the result of processing the history of transactions according to a Minting Protocol.

This repository implements the decentralized ISCC registry for Ethereum Virtual Machin (EVM) based blockchains.

The ISCC-REGISTRAR contract

An ISCC-REGISTRAR contract offers ISCC-CODE declarations to its users for claimig unique, short and owned ISCC-IDs. To become an ISCC-REGISTRAR a contract must offer an declare method that registers ISCC-CODEs by calling the announce method of the ISCC-HUB contract.

The ISCC-HUB contract

The ISCC-HUB contract exposes the announce interface for other contracts to declare ISCC-CODEs and emits IsccDeclaration-events.

Call Signature: announce(_iscc: String[96], _url: String[128], _message: String[128])

_iscc: The minimal input to the announce method is the ISCC-CODE itself (in canonical base32 uppercase encoding with the ISCC:-prefix removed).

_url: Optionally you can provide a URL that points to off-chain JSON-LD metadata about the registered digital content. The schema of the metadata must conform to the ISCC metadata schema (see https://schema.iscc.codes) to be interpreted, indexed and resolved by an ISCC MetaRegistry. Idealy the URL should use content based addressing (e.g. IPFS).

_message: The message-field can be empty and is reserved for protocol extensions. If you want to make sure that an ISCC declartion stays immutable and does not support any future protocol extensions (updates, transfers, deletes) you can pass in the processing instruction "frz:"

ISCC-CODE declarations are monitored by external observers that follow a deterministic protocol to mint unique, short and owned ISCC-IDs.

The resulting ISCC-ID of an ISCC-CODE declaration is owned/controlled by the signee of the original transaction (tx.origin) and not by the calling contract (msg.sender). ISCC-IDs are minted, indexed, and resolved off-chain by public ISCC MetaRegistries .

The ISCC-HUB ensures that registration events can be monitored efficiently and always include the addreses of the DECLARER (tx.origin) and the REGISTRAR (msg.sender). It is recommended to also provide a URL where additional declaration information conforming to the ISCC metadata schema can be found (see: https://schema.iscc.codes/)