In traditional centralized systems, the notion of an account is usually represented by a username and password, which is often linked to an email address in order to facilitate account recovery should the user forget their password. The majority of distributed computing systems replace this model with something known as cryptographic key-pairs. These keys can be mathematically generated on-demand without a third-party or any form of permission. The public key acts as a username and is shared with other participants, whereas the corresponding private key, like a password - must remain secret. Sharing or losing private keys can result in the loss of control for that account - without recovery options.

// An example of an address - which is derived from a public key:

1GzBZ7eK6wzNjp1Wt6AxHo73kJL2tzoErq

// An example of a private key:

L1winVkoRmxMdHKbwssx33Z9ZEuXeJ1eP9CVYvnNn4TdYA32GsWY

This means that whoever has access to the private key has complete control of the corresponding account. If you cannot access your own private keys, the accounts do not really belong to you. Most private keys will eventually find themselves stored on disc on a computer or thumb-drive, perhaps even locked in a vault or under the custody of some third-party service. If this hard-drive or system fails, the account could be lost forever - without any way to recover.

To facilitate account recovery with cryptographic key-pairs, systems typically incorporate what is known as a multi-signature account model. The technicalities used for these systems is dependent upon the specific network and whether or not that network provides native multi-signature accounts. In either case; the results often produce a single address or account, which can only be utilized upon using a predefined number of potential private keys.

The most common multi-signature model is often referred to as two-of-three-multisig, where any two out of three potential private keys are required to be used in order to authorize transactions from a multi-signature account. This method enables account recovery by ensuring that the individual user always has two of the three keys for general day to day usage with one additional key then kept with a third-party service or backup system. Should one of the two user keys become inaccessible, the third key can be used to recover the account.

This same model can also be used for escrow transactions - as seen below:

Please note that there is little value in storing more than one multi-signature key within the same Crypto-Wallet - or even within a system that utilizes the same device or ultimate place of storage, as this would result in a single point of failure.

Crypto-Wallets are applications for managing the generation and storage of cryptographic keys. They provide an interface allowing users to generate accounts and interact with the applications that rely upon the signed transactions that these wallets facilitate. Transactions can represent data updates or the transference of digital tokens and assets to other entities.

The different types of wallets available to consumers includes:

• Software Wallets typically refer to opensource tools available for self-management
• Hardware Wallets typically refer to small physical devices aimed at consumers
• Web Wallets typically refer to a service where providers manage consumer keys

Since the pilot project ultimately relies upon universal token standards to facilitate equity crowdfunding investments and peer-to-peer secondary market trades, all stakeholders are able to use any wallet that supports ERC20 tokens and ERC721 assets as their preferred platform for generating and managing their cryptographic keys.

The Castor Wallet may also be used to generate keys and interact with the various smart contracts required to participate in this pilot project. It uses hierarchical deterministic keys, which are generated privately within the individual user device on-demand, as required. Only the public keys are stored within the device. The private keys are never saved or stored anywhere and only ever generated and used when authorizing transactions.

This is done whilst preserving a simple username and password interface:

Hierarchical Deterministic Keys - often referred to as HD Keys enable an almost unlimited numbers of keys to be programmatically generated from a single master key. They introduce the notion of extended keys, where a master extended key can generate up-to one billion extended child keys, each of which can generate one billion of their own extended child keys, which can be repeatedly extended for up-to one billion generations. This allows for one billion to the power of one billion keys to be programmatically generated from a single master extended key.

// An example of an extended master private key:

xprv9s21ZrQH143K2Ywhg9bhZ5nd31t3EbXsg8v28gkKjSm9PA3PiZ89dWW6YKxWZa2pgTuErQ65K46KGVfu1xCRBCK3Ppd465QGtH7TmxAEiLv

Every extended key has a depth and index attached, but no specific path. Each extended child key can derive its own set of child keys, each with their own unique set of indexes. This means that applications or users must remember the exact path to distant descendant keys.

This method can also be used to store structured data within OP_Return based blockchains such as Bitcoin and Dogecoin, where each child can represent an individual field from within an individual record - as crudly demonstrated below:

The DN-Key Protocol provides a way to utilize DNS TXT records to broadcast public keys - whilst also enabling a more robust method for generating trusted hierarchical deterministic keys between multiple stakeholders.

Imagine a user with various wallet addresses for multiple currencies. Rather than needing to remember each of the individual addresses (or public keys) and which is used for which currency, a user can merely share their DN-Key.

For example, reading the DNS TXT record of user.dnkey.org provides the following values:

dnkey-btc=13aaehx6p4QrTHMvQUZy3dTEevXr4Wprap
dnkey-doge=DNvyxwdSTuzhXmHye6PbGvGWk5EEEZvXpF
dnkey-ltc=LMUN5ZPQCym1sz2XxbunhWsfwJc5nKfANN

This enables other entities to obtain the Bitcoin, Dogecoin and Litecoin addresses of the user.

Organizations can simulate central control of self-managed key-generation by enforcing their applications to use DN-Keys, which are managed by their own organizations, rather than the individual - such as employee.organization.com.

Please note that DN-Keys should ONLY ever be used for broadcasting PUBLIC keys.

This pilot project utilizes DN-Keys in the following unique ways:

• Broadcasting multi-signature redeem scripts
• Improving security in the creation of deterministic keys
• Enabling the enforcement of pre-approved or multi-signature accounts

When utilizing native multi-signature accounts such as those offered by Bitcoin, it is necessary for each participant with an active key to also have access to the redeem script that is generated once all the keys are combined. It can sometimes be difficult to communicate and store this script with multiple parties, which also provides several opportunities for DN-Keys.

// An example of a Bitcoin 2-of-3 Multisig Redeem Script:

524104a882d414e478039cd5b52a92ffb13dd5e6bd4515497439dffd691a0f12af9575fa349b5694ed3155b136f09e63975a1700c9f4d4df849323dac06cf3bd6458cd41046ce31db9bdd543e72fe3039a1f1c047dab87037c36a669ff90e28da1848f640de68c2fe913d363a51154a0c62d7adea1b822d05035077418267b1a1379790187410411ffd36c70776538d079fbae117dc38effafb33304af83ce4894589747aee1ef992f63280567f52f5ba870678b4ab4ff6c8ea600bd217870a8b4f1f09f3a8e8353ae

In order to pre-approve accounts whilst also providing account recovery, DN-Keys can also be incorporated into the key generation process - but doing so also enforces the use of specific crypto-wallets that adhere to these processes. However, please note that for the sake of more simplified demonstrations, not only have the DNS settings been simulated via configuration files, but the multi-signature account recovery options have also been disabled. This means that within the open demonstrations, a failure to remember your username or password will result in a total loss of account control, which is why we have opted to use a private network.

In traditional web applications, code is served from a central server and even those that have developed that particular computer program are unable to verify that it is doing what it is supposed to be doing once it has been installed on a server that they do not have access to. Distributed ledger technology introduces a new term, referred to as smart contracts, which are essentially small snippets of code that are served from a distributed network - rather than a central server. This allows for independent parties to verify the authenticity of logic, whilst also providing a guarantee that certain programmable actions will occur once specific triggering conditions have been met, regardless of whether those involved still exist - let alone agree. Smart contracts remove the need to trust the individuals that have made the agreement and instead shift that trust to the developer who programmed the contract.

The vast majority of smart contracts are being used to generate custom token supplies and digital asset systems. In most cases, these new units of value are centrally controlled, unlike the native cryptocurrencies of the underlying platform that is being used. The most popular smart contract enabled blockchain is currently Ethereum. It's native cryptocurrency is called Ether, which has a value that is independently derived from multiple sources around the world. Ether can be spent in order to generate new Custom Tokens, which can be used to represent value or assets from the real-world. However, if the central party issuing or backing those tokens were to vanish, so too would all the value and utility of the token supply. Additionally, transferring those Custom Tokens from one user to another still costs Ether to do so, which makes it challenging to find a use-case that cannot be better served by simply using Ether instead of Custom Tokens.

In fact, every time any kind of data is added to a public blockchain such as Ethereum, there is a cost to do so. Writing data is very expensive. Tens of thousands of dollars per megabyte - whereas reading that data is free of charge. More importantly, that data is available forever - so for very specific use-cases, public blockchains still make sense. Perhaps the most important aspect of smart contracts, or blockchains as a whole is their immutability. This refers to the tamper-proof nature of distributed ledger technology, which in reality is not a simple binary value. The sliding scale of a distributed ledger's immutability can be seen as a direct correlation to how decentralized the network is.

Decentralization takes many forms - best seen at the Are We Decentralized Yet website:

Open standards are used in order to ensure that different applications and services built by various teams are able to support each other. To facilitate interoperability within the financial service space there needs to be specifications for both fungible tokens and non-fungible assets. Fungibility refers to the unit of value. A fungible system such as time, money, or loyalty points require each unit to have the same value, whereas non-fungible supplies utilize unique values and properties for each unit - such as land titles, share certificates or collectible baseball cards.

Despite it's lack of superiority, ERC20 remains the most popular standard for fungible tokens:

contract ERC20 
{
    // Required functions ...
    function totalSupply() public constant returns (uint);
    function balanceOf(address tokenOwner) public constant returns (uint balance);
    function allowance(address tokenOwner, address spender) public constant returns (uint remaining);
    function transfer(address to, uint tokens) public returns (bool success);
    function approve(address spender, uint tokens) public returns (bool success);
    function transferFrom(address from, address to, uint tokens) public returns (bool success);

    // Required events ...
    event Transfer(address indexed from, address indexed to, uint tokens);
    event Approval(address indexed tokenOwner, address indexed spender, uint tokens);
}

The most popular standard for non-fungible assets is currently ERC721:

contract ERC721 
{
    // Required functions ...
    function balanceOf(address _owner) external view returns (uint256);
    function ownerOf(uint256 _tokenId) external view returns (address);
    function safeTransferFrom(address _from, address _to, uint256 _tokenId, bytes data) external payable;
    function safeTransferFrom(address _from, address _to, uint256 _tokenId) external payable;
    function transferFrom(address _from, address _to, uint256 _tokenId) external payable;
    function approve(address _approved, uint256 _tokenId) external payable;
    function setApprovalForAll(address _operator, bool _approved) external;
    function getApproved(uint256 _tokenId) external view returns (address);
    function isApprovedForAll(address _owner, address _operator) external view returns (bool);

    // Required events ...
    event Transfer(address indexed _from, address indexed _to, uint256 indexed _tokenId);
    event Approval(address indexed _owner, address indexed _approved, uint256 indexed _tokenId);
    event ApprovalForAll(address indexed _owner, address indexed _operator, bool _approved);            
}

This pilot project utilizes ERC20 tokens to represent Digital Ringgit Malaysia (DRM) - whereas ERC721 assets are used to represent Digital Share Certificates (DSC). Interoperability such as this enables external applications and services to engage the various stakeholders from within the pilot project whilst also encouraging open innovation.

One of the main benefits of smart contracts is that once they have been published to a public blockchain, they cannot be altered or removed. Although this is a powerful feature - once you discover an error in the contract or need to update your supply from one standard to another; you soon realize it is a serious problem too. This is especially important in consideration of the fact that over 25% of all smart contracts currently contain unfixable critical errors.

Upgradable smart contracts represent an alternative approach to design where data and logic are split into different contracts rather than storing everything in the same place as traditional contracts do. In order to do this, additional layers of code abstraction are required, which is often achieved through what is known as a key-value store and proxy approach.

Since both the ERC20 and ERC721 contracts require balanceOf() - we will use that as an example of how the key-value proxy method works. In a traditional contract this function looks something a little like this:

// Data is stored locally within this hash table ...
mapping (address => uint256) private balances;

// Anyone can verify the balance of any address ...
function balanceOf(address owner) public view returns (uint256) 
{
    return balances[owner];
}

When utilizing key-value stores - the function looks more like this:

// Proxy address can be updated as required
address public proxyAddress;

function balanceOf(address owner) public view returns (uint256) 
{
    db = DatabaseProxy(proxyAddress);
    return db.getUint('balance', owner);
}

The proxy is used as an anchor that provides a permenant address that the key-value store can then use to index data shared across multiple applications or contract components. This allows the final contract layer to be updated without altering the underyling data - as seen here in the database contract:

// Generic hash table for storing all "uints" ...
mapping(address => mapping(bytes32 => mapping(bytes32 => uint256))) private mappedUints;

// Only approved proxy contracts can read from the key value store ...
function getUint(bytes32 version, bytes32 key) public view returns(uint256)
{
    require(isValidProxyContract(msg.sender) == true);
    return mappedUints[msg.sender][version][key];
}

Token factories provide a way for a single master ERC20 or ERC721 contract to support an unlimited number of different ERC20 or ERC721 supplies. In order for standard ERC20 and ERC721 applications and services to support these factories, new interface contracts need to be generated. The benefit of having these interconnected contracts is that exchanging between different supplies can be automated - as illustrated below:

KYC contracts provide a way to freeze accounts, whilst also registering addresses to personal identification numbers - in the same way that existing financial service providers are required to have the capability to perform. This allows authorized stakeholders to blacklist specific addresses - as seen in the following simplified example:

// Hash table of blacklisted addresses ...
mapping (address => bool) private blacklist;

function transfer(address to, uint tokens) public returns (bool success)
{
    // Additional KYC requirements ...
    require(blacklist[tx.origin] == false);
    require(blacklist[to] == false);

    // Standard ERC20 functionality ...
    require(value <= balances[msg.sender]);
    require(to != address(0));
    balances[msg.sender] = balances[msg.sender].sub(value);
    balances[to] = balances[to].add(value);
    emit Transfer(msg.sender, to, value);
    return true;
}

Within the demonstrations, the KYC process is governed by the ID Providers.

AML contracts provide a way to limit transaction sizes - in the same way that existing operators try to discourage. This allows authorized stakeholders to freeze or restrict specific addresses - as seen in the following simplified example:

// Hash tables of individual transfer boundaries ...
mapping (address => uint) private incomingLimits;
mapping (address => uint) private outgoingLimits;

function transfer(address to, uint tokens) public returns (bool success)
{
    // Additional AML requirements ...
    require(outgoingLimits[tx.origin] >= tokens);
    require(incomingLimits[to] <= tokens);

    // Standard ERC20 functionality ...
    require(value <= balances[msg.sender]);
    require(to != address(0));
    balances[msg.sender] = balances[msg.sender].sub(value);
    balances[to] = balances[to].add(value);
    emit Transfer(msg.sender, to, value);
    return true;
}

Within the demonstrations, the AML process is governed by the Trustees.

In traditional Equity Crowdfunding (ECF) campaigns, investors are required to send funds directly to the operator's appointed trustee. At no point in time does the operator ever handle the money themselves. At the end of the campaign, operators must instruct the trustee to do one of two things. Either the funds need to be returned to the original investors - should the campaign not reach its minimum target, or sent to the issuer's account should the campaign exceed the minimum target. Investors are able to request a refund should they do so before the cooling period for that campaign has passed. If the investment total exceeds the maximum limit the issuers are also required to select which investments to approve. However, in both cases, the operators perform these tasks on behalf of the issuer.

The process is not only expensive, but extremely time consuming too - with some trustees unable to process more than ten transactions a day and in some cases; requests, transfers and settlements can even take several days. Self-executing campaigns look to replace these procedures with more automated workflows, giving control back to the issuer whilst improving effeciency and accountability in the process. Each campaign is represented as an individual contract with its own unique address. It is capable of storing Digital Share Certificates (DSC) that the issuer allocates for the campaign - allowing investors to transfer Digital Ringgit Malaysia (DRM) diretly to the campaign. When the campaign is closed, depending upon its success - it will either issue shares to the investors the issuer selects whilst sending the corresponding funds to the issuer or it will return the investor funds if rejected or unsuccessful.

Escrow contracts are used to facilitate secondary market transactions. They are used once a campaign has been completed and investors then want to buy and sell shares within the market without needing to trust each other or any third party services. Instead, either investor can initiate an escrow contract and define the required price per share and total number of shares to be purchased. Only if and when the contract has both the required Digital Ringgit Malaysia (DRM) and specified Digital Share Certificates (DSC) will it then transfer the corresponding tokens and assets to the respective parties. At any point before both requirements are met, either party can withdraw their deposits.

There are two versions of the SCM Wallet. If downloaded and hosted on your own server or local machine, it can be configured to connect to a number of different networks (public, private and local). It also has the capability to communicate with and deploy its own upgradable smart contracts. However, this documentation is designed specifically for the online demonstrations hosted by Securities Commission of Malaysia. The online version is locked-in for use with the non-upgradable private network, whereas the upgradable contracts are only available on your own local network. In order to get started with the online version, you will first need to register a Pilot Project account, as this will then allow us to send you private Ether - with which you can then interact with the private network. Once you have registered a Pilot Project account, you will then be able to access your personal wallet and in-turn register your device.

The device registration page should look like this:

IMPORTANT WARNING

This wallet uses deterministic keys. We do not store any of this information anywhere. Failure to remember any of the credentials used when registering your device could result in a total loss of control.

Username

When used in combination with DN-Keys, usernames must match a valid domain name under control of the user. For the demonstrations, any username of any kind can be used.

Full Name

Using a real name will make it easier to remember later.

Date of Birth

When used in combination with DN-Keys, the date of birth would be used as part of a cross-reference check with KYC records. For the demonstrations, any date of birth can be used.

Password

Ideally, this should be different to the password for your Pilot Project account, which like most CMS systems, stores hashed passwords in a database - whereas the SCM Wallet does not store any passwords anywhere.

Upon successfully registering and authenticating your device for the first time, a personal account will be automatically generated. However, please note that the wallet allows for the generation of multiple accounts - as seen below:

Please note that each account is able to perform the following actions:

Scan

This will read from the blockchain and present the latest balance and the number of sent transactions (nonce).

Add

This allows you to easily add ERC20 and ERC721 supplies, merely be providing a compatible contract address:

Send

This is used in order to transfer funds, tokens or assets to another address.

Remove

This allows you to remove the account from local storage.

To access your cryptographic keys, you should visit the SCM Wallet settings page:

You will notice that only the public keys and public addresses belonging to each of the accounts is visible. This is because the private keys are not stored anywhere. In order to access the private keys or use them for future transactions, users are always required to fill-in the necessary username and password - as seen on the right side under Access Private Keys. It is from this page that users may also clear all information from the browser, which can also be used to simulate a loss of device or a refreshed local storage - as can sometimes occur when updating browser versions. Since the account generated is deterministic, users should be comfortable deleting and then recreating their accounts. Doing so should result in the exact same keys being produced, assuming you re-type everything exactly the same as you did last time.

In order to start investing into campaigns, you must first register your account with an ID Provider. The SCM Wallet contracts page enables you to interact with any contracts on any of the supported chains, simply by providing the necessary address and ABI Interface options. It was not designed to specifically function as an interface to this pilot project, but instead provides a place for users to interact with any kind of contract. The left side of the contract interface is used to freely read data from functions - whereas the right hand side is for utilizing functions that write to the blockchain. The online demonstration comes pre-bundled with the neccessary contracts required for various stakeholders and automatically installs the required investor contracts upon registration.

The Castor Users Contract

To get started, you will first need to register with the Castor Users contract:

If your account has the neccessary funds, and neither the identification number nor the email address you submitted have been used before, you should be presented with the following success message:

This does not mean that you are registered, but does imply that your request was successful.

An ID Provider is required to approve your request, for which there is currently no notification process. You can instead enter the address of your account into the Is Approved function, click scan and wait for the value to change to true. Behind the scenes, this currently relies upon a manual process from an observing ID Provider and could take anywhere upto a day for them to process the indentification verification request.

Once your account has been verified, you should be able to retreave your personal information by entering your Ethereum address into the Get User Profile function and then clicking scan

Please note that upon clicking the small scan buttons within the contracts page, they will activate a loop for that individual function to then get automatically re-scanned every minute. This will be re-set when refreshing the page.

The Digital Ringgit Contract

The Digital Ringgit contract provides an ERC20 interface for utilizing tokenized money:

Important contract functions worth noting include:

Balance Of

This can be used to verify the current (DRM) balance of an account.

Transfer

Assuming both accounts are actively authenticated funds (DRM) can be transferred from one account to another.

The Neuroware Campaign Contract

And then?

The Neuroware Shares Contract

The Neuroware Shares contract provides an ERC721 interface for utilizing tokenized shares:

Important contract functions worth noting include:

Balance Of

This can be used to verify the current (DSC) balance of an account.

Transfer From

Assuming both accounts are actively authenticated shares (DSC) can be transferred from one account to another.