Appendix 5.

16

Underlying technology
Contracts
Offchain Components
Identities
IPO Handling
Trader Flow
Auditing
Diagrams

Smart Contracts and Blockchain Database

The architecture described in this document relies on business logic defined in what are referred to as
Smart Contracts.

Smart contracts are contracts in written computer code which define the movement of electronic funds
and assets, secured on a blockchain database and interacted with only by parties which supply
mathematically verifiable identities and information to the contracts.

A smart contract can, for example, define the movement of electronic funds from one account to
another based on a ⅔ majority of administrators or restrict the transfer of an asset until stipulated
conditions are met by a group of predefined parties.

Smart contract code is secured on a distributed blockchain database. In the architecture described in
this document, this database is the Ethereum blockchain. What makes such databases secure, is the
‘work’ required required to add or update any record contained therein and the mathematical
guarantees that only designated parties can take actions designated in the smart contract code.

In this scheme, when an update is proposed to the blockchain database, all nodes in the network (~25k
distributed across the planet) receive the proposal, verify that the entity issuing the proposal is valid and
meets any and all requirements ( such as those stipulated in a smart contract ), and if all checks out,
performs a verifiable amount of ‘work’ to add this record to the blockchain database.

Since each record contains a verifiable fingerprint of all previous records, and each requires a verifiable
amount of work to be added to the blockchain database, it becomes impossible to alter its history or
current account values. Currently, it would take 500x the computing power on the planet to perform
enough work to change a record that was saved just a few seconds ago. Thus account balances contract
logic are considered to be very secure because the computational effort and expense required to change
or reverse all data inputs on the blockchain would be infeasible, if it could be done at all.
Key pair generation

Each party in the following group (e.g., Cihan Bank, ESX, RDC) must create a mathematically
verifiable identity to interact with the ESX smart contracts. The identity generation process results in 2
keys for each identity: a public key, and a private key.
The public key can be used during audits verify the identity of any actor in the platform. It is the
public identifier of an actor.
The private key is used to sign any actions taken on the smart contract(s). It represents the the
mathematical authority of an actor, (such as ESX, Cihan Bank, RDC, or broker-dealer), to perform their
designated roles and thus must be kept private.

Together, the public and private keys constitute an account.

All actions taken among 3 entities, Cihan Bank, ESX, RDC will be in the form of signed messages
to the ESX smart contract(s). A smart contract responds to actions that are signed by private keys and it
can tell which public key was used.

All parties and constituents will hold such accounts. For example, each broker-dealer trader will
have an account on a secured usb. A secondary copy of each trader’s account will exist in safe storage at
the brokerage. When conducting trades, this USB will be inserted into the trader’s computer and used to
sign trades conducted by the trader. These signed transactions sent to the ESX smart contract(s)
immediately become permanently available for later auditing.

ESX recommends the Nano Ledger.

Multiparty Signatures

In practice, all accounts on the ESX platform will consist of composite ‘keys’ and henceforth
referred to as ‘multisig` accounts. When a multisig account is created, the amount of parties making up
the account is specified as well as the number of constituent accounts required to approve any action.

Smart Contract Tokens

In order to manage discrete units of value ( such as currency) or digital assets ( such as securities
), values and assets are ‘tokenized’. Thus, we represent 1.99 dinar in Cihan bank in the form of a
particular smart contract token. Analogously for 1 share of a particular company being traded, we
represent the 1 share as another particular smart contract token.

Tokens are ownable and can be transferred by a designated account. This is facilitated by ESX trading
software.
 
Contracts:

ESX Contract

Parties: Broker
Function: Details of open orders, ownership. Validates intended transactions. Transfers token ownership
from one account to another

We base this on publicly audited EtherDelta contract which has moved X hundred million dollars worth
of value with no cases of fraud

Dinar Factory Contract

Parties: Cihan Bank, ESX, RDC
Function: Mints ‘Dinar’ units of account backed by bank-deposited Dinar currency at 1-1 ratio.
Requires multisig from all parties to mint Dinars.

Dinar Contract
Parties: ESX Contract, Broker
Function: Defines behaviour of ‘Dinar’ units of account.
Transfer is restricted to Cihan multisig wallet and whitelisted broker

Security Token Factory Contract

Parties: RDC multisig
Function: Mints new token contracts for each registered security.

Security Token Contract(s)

Parties: ESX Contract, Broker, RDC multisig
Function: Each security token contract defines behaviour for each security token. This includes
Whitelists of brokers allowed to transfer the tokens as well as minting of new shares.

Only RDC multisig can mint new tokens of an existing security and only RDC multisig can edit the
whitelist of brokers allowed to make trades

 
Off-chain Components

Multisig accounts
Software enabling each party of a set of parties defined as having authority over functionality of
a contract function ( such as RDC’s multisig authority to mint new security tokens from existing security).
Utilizing each parties private key to make required signature and defines required signature threshold to
execute transaction
ESX Interface
Software facilitating trade of securities by brokers whitelisted to trade respective securities.
Final authority to execute trade determined by ESX contract after broker submits a prospective trade
from the ESX orderbook, thus secured by Ethereum network

Order book
This is off-chain collection of orders maintained by ESX organization and RDC. All orders
contained are received via events emitted from ESX contract when a broker puts up a ‘buy’ or ‘sell’. If a
fraudulent order is added to the offchain orderbook, transactions will be rejected by the ESX contract

 Identities

Cihan multisig: able to withdraw, deposit ‘Dinars’

Brokers: able to transfer security tokens
ESX contract: able to transfer security tokens
RDC multisig: able to mint security tokens
Cihan, RDC: able to mint ‘Dinars’

 IPO Handling:

RDC receives offering documentation.

Through ESX software, requisite quantities of security tokens are minted

RDC receives terms of IPO of security. To interact with the ESX exchange system, securities are to be
represented by smart contract tokens.

M of N parties at RDC agree to mint tokens using credentialed portal.

 
Trader Flow:

ESX Contract and off-chain order book manages all open and closed trades as well as shareholder
balances.

Broker is whitelist maintained by the RDC multisig which has authority to add, remove brokers from
trading whitelists.

Each broker holds separate accounts for each of their investors as well as a broker-specific liquidity
account. Whitelists defined by RDC are enforced by Security Token Smart contract, making it impossible
to execute trades outside these authorized parties.

Cihan funds broker liquidity accounts in ‘Dinar’. `Dinar` is only allowed by Dinar Smart Contract to be
transferred
by Cihan multisig account to and from broker accounts
 and
by broker accounts, to and from the ESX contract, and to and from Cihan

Logged into ESX trading software with their investor accounts, broker is able to push trades to the ESX
contract, for example “SELL 100 ASAI”.

ESX software submits order details to the ESX Smart Contract with broker account signature. This
signature will allow any party possessing the public identifier of the broker account to prove the trade
has been authorized by the broker account.

The ESX contract verifies that the order parameters are valid ( broker has 100 ASAI to sell). If valid, a
fingerprint of the signed order is saved to the smart contract. This will be used to validate any future
corresponding order fulfillment, for example “BUY 100 ASAI”.

The contract then emits the details of the trade to the offchain orderbooks housed by ESX and optionally
by the RDC or extraneous auditing body. The offchain orderbook contains signed trade details, tested by
ESX Smart Contract as valid at time of submission and is used to populate orderbooks seen in ESX trading
software.
The offchain order book cannot be tampered with in any meaning sense because the ESX Smart Contract
contains mathematical proof of signed and verified orders. If a fraudulent transaction has been added to
the offchain orderbook, and is submitted to the ESX Smart Contract, the contract will reject it’s
fingerprint.

The ESX Smart Contract is the final arbiter of trade execution and is thus constructed to be
mathematically deterministic in its verification and execution of valid trades.

The RDC, as legal authority, holds a multisig account with technical authority to halt otherwise valid
trades from executing in the ESX Smart Contract

 Auditing:

The offchain orderbook, visible by ESX trading software, the RDC and any other necessary parties
contains a complete log of trades and balances held, mathematically verifiable against the ESX Smart
Contract.

It thus serves the dual purpose of populating ESX trading software with only valid transactions as well as
a complete and mathematically verifiable audit trail for RDC and/or other bodies overseeing securities
compliance.
RDC Smart Contract Operations
Bank Smart Contract Operations
ESX Smart Contract Operations