For the Chain Development Update #3, we have a packed agenda and exciting new features. See below key topics addressed:

  • Initial client backend architecture
  • Sample prototype wallet application
  • Initial governance mechanism
  • Developer community chatroom Chain Client Prototype

We aim to make Chain adoption as frictionless as possible. Thus, we made the decision to separate out client-related functionality into a reusable framework that can be leveraged by different third party applications, be it multi-currency wallet implementations, faucets or internal cryptocurrency exchange infrastructures.

The client architecture will follow our initial design axiom goals in the long term:

  1. Security: we aim the client architecture to leverage highly scrutinized cryptographic libraries and be able to validate its payment data without running a full network node (i.e., provide a variant of Simplified Payment Verification).
  2. Scalability: as different applications have different performance needs, the client architecture should cater for them.
  3. Portability: while we chose Rust for the Chain implementation, the client architecture could be utilized in other programming languages. Chain client architecture is designed to provide useful abstractions and services for easy integration with wallets and blockchain data. The client architecture contains mainly abstractions and functionality for wallet-related operations and blockchain data querying and manipulations.

The client abstracts over several details, such as storage and querying mechanisms, which provides flexibility in the implementation. The underlying implementation could then be seamlessly changed when needed. There is a ready-to-use default implementation of wallet and index, backed by in-memory (for testing) and embedded databases.

Some of the above services are exposed via a JSON-RPC interface. The cross-language integration is thus simple and developers can focus on working with the provided APIs without knowing the underlying implementation. The JSON-RPC client interface now provides APIs for basic wallet operations including wallet creation, balance and transaction querying as well as simple fund transfers. We aim to provide an feature-rich and simple-to-use API interface for developers to integrate with. Chain Sample Wallet Application

To illustrate the usage and portability of the client architecture, we developed a basic sample graphical wallet user interface prototype in TypeScript.

Some sneak peek screenshots:

1. Create your wallet with Passphrase

2. Decrypt your wallet before sending transactions

3. Key in the details of the transaction you are sending

4. Review and click 'Send' to confirm the transaction

5. Transaction sent

6. Show sender your address or corresponding QR code to receive funds

7. Check your transactions

See the LIVE transfer in the following video:

Initial Governance Mechanism

Governance design considerations: Governance is crucial for the sustained success of a blockchain. Chain aims to put in place a robust governance mechanism, producing quality decisions that benefit the larger community.

In designing governance, we have referenced the practices of other projects in the space, including examples of using off-chain governance (e.g., Bitcoin, Ethereum) and on-chain governance (e.g., Dash, Decred). For the initial design, we plan to start with a governance mechanism that is:

  • Intuitive to understand and easy to adopt,
  • Inclusive and allows community participation,
  • Incentivizes contribution to the Chain project.

We will continue to refine and complete the mechanism in phases.

Governance Mechanism (Prototype): To encourage contribution to the ecosystem, we will open up applications for Chain ecosystem grants in the future.

We aim to build a governance system where those who hold or can hold a Seat in a Council Node (i.e., 500K CRO staked) will be eligible to participate in voting. For users who co-contribute to a Seat, we are open to allocating 1 vote to the said shared seat, with contributors deciding autonomously amongst themselves on how to decide on the final vote.

Proposals shortlisted by will be open for community polling, where 1 vote is allocated for each 500K CRO staked (proof of token ownership required). For example, a user with 700K CRO staked will be allocated 1 vote, where as another user with 1,000K CRO staked will be allocated 2 votes.

Polling results would be published after the polling period ends. Referencing the polling results, will make the final funding decision and publish the results. Successful projects that receive ecosystem grants would be required to transparently report their progress and use of funds, subject to review and monitoring of

Developer Community

We moved our developer community chatroom to Gitter.

The purpose of this communication channel is to help technical users with getting started working on Chain’s codebase. As suggested in the contribution guidelines, it is also a good place to start if you are interested in contributing to Chain’s codebase.

Ongoing Bounty Program

Many of our bounties on BountySource are still in process and we welcome more submissions. We would like to thank dingelish for writing up an excellent debugging guide for Rust SGX enclaves that we plan to utilize in Chain.

What’s Next

Fees and staking: In the next update, we expect to provide more details on the enhanced prototype that will extend the accounting model, as changes will be required to facilitate functionality beyond simple transfers, mainly related to basic fee, staking and reward management.

Scalable privacy mechanisms: The other stream of work will focus on scalable privacy mechanisms utilising Trusted Execution Environments (TEEs). The update will contain details on changes in design and related items, such as a system threat model.

Client and wallet: Currently, the client architecture is still under heavy development.

In the upcoming months, we expect it to update with changes in Chain prototype network implementation (such as multisig or initial staking support), extend and stabilize its existing functionality. We will continue to evolve the APIs to support more operations including multiple addresses and creation of more sophisticated transactions.

Long term, we would like to extend the client to support external “signers”, such as hardware wallets or “virtual hardware” wallets in executed secure enclaves. We would also investigate its compilation to WebAssembly for a better portability and distribution in more diverse environments (e.g. web browser plugins).