Crypto.com Chain Dev Update #3

For the Crypto.com 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

Crypto.com Chain Client Prototype

We aim to make Crypto.com 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:

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).

Scalability: as different applications have different performance needs, the client architecture should cater for them.

Portability: while we chose Rust for the Crypto.com Chain implementation, the client architecture could be utilized in other programming languages.

Crypto.com 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.

Crypto.com 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. Crypto.com 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 Crypto.com 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 Crypto.com 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, Crypto.com 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 Crypto.com.

Developer Community

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

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 Crypto.com 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).