cicnet
/
cic-contracts
5
0
Fork 0
Code Issues Pull Requests 1 Projects Releases Wiki Activity

Start docs

This commit is contained in:
nolash 2021-01-05 20:22:51 +01:00
parent 4bd3dceaa6
commit bc29be7e6c
Signed by: lash
GPG Key ID: 21D2E7BB88C2A746
4 changed files with 197 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
doc/texinfo/Makefile Normal file
View File

@ -0,0 +1,3 @@
all:
makeinfo --html index.texi

1
doc/texinfo/index.texi Normal file
View File

@ -0,0 +1 @@
@include overview.texi

117
doc/texinfo/index/Smart-contract-interfaces.html Normal file
View File

@ -0,0 +1,117 @@
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<!-- Created by GNU Texinfo 6.7, http://www.gnu.org/software/texinfo/ -->
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<title>Smart contract interfaces (Untitled Document)</title>
<meta name="description" content="Smart contract interfaces (Untitled Document)">
<meta name="keywords" content="Smart contract interfaces (Untitled Document)">
<meta name="resource-type" content="document">
<meta name="distribution" content="global">
<meta name="Generator" content="makeinfo">
<link href="#Smart-contract-interfaces" rel="start" title="Smart contract interfaces">
<style type="text/css">
<!--
a.summary-letter {text-decoration: none}
blockquote.indentedblock {margin-right: 0em}
div.display {margin-left: 3.2em}
div.example {margin-left: 3.2em}
div.lisp {margin-left: 3.2em}
kbd {font-style: oblique}
pre.display {font-family: inherit}
pre.format {font-family: inherit}
pre.menu-comment {font-family: serif}
pre.menu-preformatted {font-family: serif}
span.nolinebreak {white-space: nowrap}
span.roman {font-family: initial; font-weight: normal}
span.sansserif {font-family: sans-serif; font-weight: normal}
ul.no-bullet {list-style: none}
-->
</style>
</head>
<body lang="en">
<span id="Smart-contract-interfaces"></span><span id="Smart-contract-interfaces-1"></span><h2 class="chapter">1 Smart contract interfaces</h2>
<span id="Smart-Contracts-in-the-CIC-Network"></span><h3 class="section">1.1 Smart Contracts in the CIC Network</h3>
<span id="Technology"></span><h4 class="subsection">1.1.1 Technology</h4>
<p>The long-term aim of the CIC network is to be agnostic of consensus engines. However, since we have to start <em>somewhere</em>, the current state of development only deals with Smart Contracts on the (Ethereum Virtual Machine (EVM).
</p>
<span id="The-registry-contract"></span><h4 class="subsection">1.1.2 The registry contract</h4>
<p>The CICRegistry contract defines the entry-point to the entire CIC network. All other CIC network resources can be discovered through this contract.
</p>
<p>Its implementation is contained in the <samp>cic-registry</samp> repository. Details about it are documented further in that section.
</p>
<span id="Auxiliary-contracts"></span><h4 class="subsection">1.1.3 Auxiliary contracts</h4>
<p>All other Smart Contracts in the network other than CICRegistry are essentially optional, and each applies <em>at least one</em> the interfaces defined in the <code>cic-contracts</code> repository.
</p>
<span id="Contract-interfaces"></span><h4 class="subsection">1.1.4 Contract interfaces</h4>
<p>All contracts interfaces also implement the <strong>EIP165</strong> Standard Interface Detection.
</p>
<span id="Registry"></span><h4 class="subsubsection">1.1.4.1 Registry</h4>
<p>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.
</p>
<p>It also provides numerical index access to all registered values in order of insertion.
</p>
<span id="Registry-Client"></span><h4 class="subsubsection">1.1.4.2 Registry Client</h4>
<p>A subset of the <code>Registry</code> interface, which defines only the non-transactional methods of the contract. The <code>Registry Client</code> interface is implemented by the <code>CICRegistry</code> contract.
</p>
<span id="Faucet"></span><h4 class="subsubsection">1.1.4.3 Faucet</h4>
<p>Enables disbursement of a set amount of tokens to a requesting address.
</p>
<p>Allows privileged accounts to adjust the amount of tokens to disburse.
</p>
<p>Can be implemented as a periodic or a one-time service per account.
</p>
<span id="Transfer-approval"></span><h4 class="subsubsection">1.1.4.4 Transfer approval</h4>
<p>Enables a third-party approval to spend an ERC20 token allowance.
</p>
<p>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.
</p>
<p>The contract allows the third-party address to either allow or reject the transfer.
</p>
<span id="Declarator"></span><h4 class="subsubsection">1.1.4.5 Declarator</h4>
<p>Stores one or more 32-byte entries as a description of an Ethereum address, <em>signed</em> by another Ethereum address.
</p>
<p>This can be used to <em>describe</em> 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.
</p>
<p>Entries are stored by the transacting address that adds address/description pairs. In other words, any address may have different &quot;opinions&quot; 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 &quot;opinion&quot; of an address by combining data from signatures it trusts.
</p>
<p>Entries typically are text strings or content hashes.
</p>
<span id="Address-Index"></span><h4 class="subsubsection">1.1.4.6 Address Index</h4>
<p>A simple append-only list of addresses. Used to check whether an address is part of a particular group.
</p>
<span id="DEX-Index"></span><h4 class="subsubsection">1.1.4.7 DEX Index</h4>
<p>Methods required to convert between tokens.
</p><hr>
</body>
</html>

76
doc/texinfo/overview.texi Normal file
View File

@ -0,0 +1,76 @@
@node Smart contract interfaces
@chapter Smart contract interfaces
@section Smart Contracts in the CIC Network
@subsection Technology
The long-term aim of the CIC network is to be agnostic of consensus engines. However, since we have to start @emph{somewhere}, the current state of development only deals with Smart Contracts on the (Ethereum Virtual Machine (EVM).
@subsection 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 @file{cic-registry} repository. Details about it are documented further in that section.
@subsection Auxiliary contracts
All other Smart Contracts in the network other than CICRegistry are essentially optional, and each applies @emph{at least one} the interfaces defined in the @code{cic-contracts} repository.
@subsection Contract interfaces
All contracts interfaces also implement the @strong{EIP165} Standard Interface Detection.
@subsubsection 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.
@subsubsection Registry Client
A subset of the @code{Registry} interface, which defines only the non-transactional methods of the contract. The @code{Registry Client} interface is implemented by the @code{CICRegistry} contract.
@subsubsection 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.
@subsubsection 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.
@subsubsection Declarator
Stores one or more 32-byte entries as a description of an Ethereum address, @emph{signed} by another Ethereum address.
This can be used to @emph{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.
@subsubsection Address Index
A simple append-only list of addresses. Used to check whether an address is part of a particular group.
@subsubsection DEX Index
Methods required to convert between tokens.