1 Smart contract interfaces

1.1 Smart Contracts in the CIC Network

1.1.1 Technology

The long-term aim of the CIC network is to be agnostic of consensus engines. However, since we have to start somewhere, the current state of development only deals with Smart Contracts on the (Ethereum Virtual Machine (EVM).

1.1.2 The registry contract

The CICRegistry contract defines the entry-point to the entire CIC network. All other CIC network resources can be discovered through this contract.

Its implementation is contained in the cic-registry repository. Details about it are documented further in that section.

1.1.3 Auxiliary contracts

All other Smart Contracts in the network other than CICRegistry are essentially optional, and each applies at least one the interfaces defined in the cic-contracts repository.

1.1.4 Contract interfaces

All contracts interfaces also implement the EIP165 Standard Interface Detection.

1.1.4.1 Registry

A key-value store, which resolves arbitrary 32-byte pointers to Ethereum addresses. Typically, this is used to resolve an address from a well-known identifier, either as a UTF-8 value or a 256-bit hash.

It also provides numerical index access to all registered values in order of insertion.

1.1.4.2 Registry Client

A subset of the Registry interface, which defines only the non-transactional methods of the contract. The Registry Client interface is implemented by the CICRegistry contract.

1.1.4.3 Faucet

Enables disbursement of a set amount of tokens to a requesting address.

Allows privileged accounts to adjust the amount of tokens to disburse.

Can be implemented as a periodic or a one-time service per account.

1.1.4.4 Transfer approval

Enables a third-party approval to spend an ERC20 token allowance.

This is useful in the case of a custodial key store, where a transaction has been initiated by another entity than the owner of the key.

The contract allows the third-party address to either allow or reject the transfer.

1.1.4.5 Declarator

Stores one or more 32-byte entries as a description of an Ethereum address, signed by another Ethereum address.

This can be used to describe network resources, be it tokens, contracts or user accounts. Examples of uses are KYC documentation proofs for users, token metadata used for display, or fraud alerts.

Entries are stored by the transacting address that adds address/description pairs. In other words, any address may have different "opinions" registered about it, depending on which signing address it is queried in the context of. This, in turn, allows the quering entity to compile its own "opinion" of an address by combining data from signatures it trusts.

Entries typically are text strings or content hashes.

1.1.4.6 Address Index

A simple append-only list of addresses. Used to check whether an address is part of a particular group.

1.1.4.7 DEX Index

Methods required to convert between tokens.