In-Depth Analysis of Stablecoin QIAN 2.0 | Multi-Layer Protection For Users’ Assets

13 min readJul 14, 2020

This is the third article of In-Depth Analysis on Stablecoin QIAN 2.0 Series. In this series, I will talk about the development of cryptocurrency, decentralized stablecoin, and DeFi, as well as analyze the innovation in the design of QIAN 2.0, to welcome the upcoming stablecoin QIAN 2.0. Suggestions and corrections from readers who have an interest in DeFi and open crypto finance are welcome and appreciated.

Do you know that every DeFi participant is actually risking every penny of their principal? As now we are still at the early stage of DeFi development, where exists huge room for improvement in terms of product design, technical structure, security, etc.

The followings are several widely known security incidents in DeFi industry.

Bug in ERC777 Standard

Uniswap and Lendf.me were attacked and lost tens of millions of dollars.

2. Bug in MakerDAO Auction Contract

The design of MakerDAO is to buy back DAI with as least collateral as possible, which would work perfectly fine under normal conditions. However, when Ethereum is extremely crowded or the participation in the auction is insufficient, attackers can easily get the collateral at a tremendously low price.

3. bZx Bug Attack

At the first attack attempt, the logical code for risk avoidance did not take effect due to logical errors in bZx code.

In the second attempt, the hacker deceived the contract by manipulating Oracle price. An analysis of the attack revealed that the low cross-platform liquidity and flaws in the price mechanism design both contributed to the incident.

4. Bug in Synthetix’s Collateral Liquidation

Synthetix recently launched a contract where users can stake ETH for sETH in a three-month trial period. At the end of the trial period, all sETH holders will be able to get ETH through liquidation.

However, a bug in the liquidation process logical code would have led any user to burn all the borrowed sETH and get ETH. Thankfully, no economic damage was made due to that it was during the trial period.

Ethereum smart contract is a great invention. It is no longer only a digital cash system, but rather an on-chain computer with logical processing power.

However, due to the asset security and other requirements, Ethereum smart contract was designed as a mechanism that cannot be modified or upgraded, which imposes great challenges to application development on the smart contract.

First, bugs are inevitable. Unnoticeable errors are more likely to emerge in complicated logic in a financial smart contract. It’s impossible to ensure that all codes are correct even after strict and repeated logic checks and code audits. Hence, there is a potential need to fix the bugs in a contract, which unfortunately contradicts the design concept of smart contracts.

Second, despite thorough and detailed consideration and design, problems in existing functions and new function needs will inevitably emerge, which requires smart contracts to be upgradable.

Led by Seamon, a seasoned developer in the crypto trading industry, the Force Protocol proposed three COFi service and technical components: basic component, extended component, and financial component, in response to the existing challenges among Ethereum DApps, including fixed data structure, slow on-chain interaction, poor user experience, lack of necessary infrastructure, and security issues.

As a vital component of The Force Protocol in DeFi industry, QIAN 2.0 also adopted the COFi technical components mentioned above, they are:

Basic component: Assets Protected Elastic Contracts (APEC).
Extended component: Blockchain Enquiring, Auditing & Messaging System (BEAMS).
Financial component:
Global Emergency Lockdown (GEL);
Cooperative Automatic Lockdown Mechanism (CALM);
Multisig Admin Keys (MAK).

Let me explain all the new words for you.

Basic Component — APEC

As the core on-chain structure, APEC is written in Solidity and ensures decentralization and asset ownership while improving on the inconvenience of developing on Ethereum.

The core concept of APEC lies in asset security and component elasticity. QIAN 2.0 smart contract is composed of three modules:

Data: Data from the classic contract structure is isolated and made into data contract(s) for data storage. Only necessary read and write interfaces are revealed to the public.
Logic: logical contracts only cover business logic, not business data.
Router: The field data that the business logic needs to read and write can be queried from the routing table according to the data module and field name, and then accessed based on the positioning result.

1. Routing Table

The routing table is an independent contract, which contains a routing swap table that stores the routing swap of logical contract and data contract addresses. The routing table can be updated with the system upgrade.

After the deployment of the entire contract system, the address of each logical contract will be stored in the routing table. External requests can be granted and access to the routing table to obtain the address swapping of the logical contract and call its interface. Data contracts can perform business logic call or callback through inquiring the routing table and obtaining the logical contract address.

For each set of data, there will be an independent data contract of its own, and the address of the data contract will be automatically stored in the routing table when it is created. Before accessing the specified data, the logical contract will first obtain the data contract address from the routing table and then read and write the data contract through the address.

Every group of data has its own independent data contract, whose address will be stored in the routing table upon creation. Before accessing certain data, the logical contract will first obtain the data contract address from the routing table and then read and write the data contract via the address.

2. Upgradable Logic

Logical contracts do not store assets nor business data. Hence, they do not involve asset security and data migration issues, and they are upgradable and pluggable. After testing and audit, the new version of the logical contract can be deployed on-chain.

Data in swap tables of the routing table contract will be updated when deploying new contracts. The address swapping direction for the logical contract will also be modified for other contracts and application front-end to inquire and call.

3. Expansible Data

As an upgradable application, its data structure is also required to be upgradable. However, due to data ownership and asset security requirements, data contracts cannot be upgraded.

The method we adopt here is expansion.

If new fields are required in a new business, the new fields will be stored in a brand new data contract. Meanwhile, the address and field name in this new data contract will be added to the routing table. Business logic can be read and written through the new field’s address obtained from the routing table.

The expansion of data contracts should be limited, as adding new data contracts without a limit will increase the complication of the whole system and hence adversely affect its operating efficiency. The data expansion mechanism only makes it possible to upgrade the data structure. However, the overuse of this mechanism is not encouraged.

When designing and using the data structure, we need to follow the classic contract design principles and the best practice to come up with a sufficient and elastic data structure. In terms of data expansion, we need to exercise restraint to avoid the overuse data expansion mechanism.

4. Asset Security

Following the upgradable logical contracts and expansible data contracts comes the issue of whether data ownership and asset security can be ensured.

It’s widely known that users’ assets are locked in contracts in traditional DeFi DApps. Smart contracts, especially those with open-source codes, guarantee that a third party is not able to touch the assets locked-in contracts. Moreover, the non-tamperability of contracts make it impossible to change the codes once the contract is deployed.

APEC adopts the method of the separation of duties to solve the asset security issue in an upgradable structure.

Business contracts can be modified and upgraded, while data contracts cannot as in classic contracts. During initialization, each data set automatically generates an initial data contract. Once this contract is deployed on the chain, its code logic cannot be modified anymore.

The data contract will maintain a swap table of user addresses and asset details internally. This table exists in the data contract and only provides two interfaces — incoming and outgoing transfers. Other interfaces are not allowed to write or update this asset table.
Incoming transfers will be sent directly to data contract address and call the incoming transfer interface. After the transfer is locked in the contract, the user’s address and asset details will be recorded on the asset swap table. And the logical contract will be called, then the business logic will be processed and recorded.
When making an outgoing transfer, the outgoing transfer interface on the data contract will be called directly and the contract will verify whether the user’s address exists in the asset swap table and then call the logical contract, calculate the transfer and finally make it happen.
For any address that does not exist in the asset swap table, the outgoing transfer interface will not answer its request. This ensures that any asset that is going out belongs to the original address that it went into from a logic level, hence guarantees the ownership and security of assets. And even the operation team itself will not be able to tamper with or steal any locked asset.

It ensures users’ asset ownership and security through the strict ownership constraints of data contracts, making APEC’s security philosophy adhere to the consistent concept of smart contracts, which has already exceeded “don’t be evil” and realized “can’t be evil”.

Extended Component — BEAMS

Blockchain is almost entirely isolated from the real world as it cannot send messages to off-chain proactively. If a smart contract encounters a problem in its logic or is attacked, the real world will not sense it passively. Hence, it requires continuous monitoring of the operation of the contract and strict audit of the data and assets in the contract. It also requires immediate alert when a problem is found to best ensure the security of the application.

For users, the experience of interacting with blockchain is naturally unfriendly. Asynchronous feedback caused by delays, frequent and large amounts of on-chain data reading and business model reconstruction, and the fragmentation between on-chain and off-chain messages has all led to slow and even chaotic interaction.

1. BEAMS Technical Structure

BEAMS refers to Blockchain Enquiring, Auditing, and Messaging System.

2. Data Enquiry

All major transactions that involve QIAN 2.0’s underlying asset changes will trigger customized on-chain events. The enquiring system constantly monitors for the emergence of new events and inquiries the corresponding data contracts of the event content. Data contracts provide the read-only interface that exposes data for the external, and the enquiring system reads the relevant data from the contract according to the data model’s requirements.

All the data read will be sorted and aggregated into the BEAMS data warehouse, and changes in the data will be recorded. As the core of the whole system, the data warehouse will provide quasi-real-time data cache to the front-end through the back-end API interface, and provide the data required for calculation and triggering to the message module. The audit module will use this data to review and audit the state transformation and data changes.

3. Audit Risk Control

The audit risk control module will constantly monitor the state and data changes in every contract. It will use an independent and parallel logic to conduct a secondary review of the asset changes and notify the system administrators to take action in real-time once an abnormality occurs.

The audit risk control module will use different review methods such as total assets, dynamic logic, and status verification to conduct real-time audits of contract data from all directions to improve the accuracy of the audit. The audit module can rate and alert on abnormalities, and the risk control module will have permission to interfere and manage the operation of the on-chain contract when it is evaluated as highly risky.

The audit risk control module is also in charge of statistical analysis. It will count and analyze system operation data including user order records, historical returns, asset change curves, real-time return indicators of the platform, and historical return curves. The audit risk control will also predict and control risks, and provide data reference for product operation direction.

4. Message Push

In order to improve the user experience of asynchronous feedback caused by blockchain’s characteristics, the message push module will play an important role in all aspects of the use process. A blockchain that lacks infrastructure needs a message push system to coordinate, especially when it comes to information that may affect users’ interests.

On one side of the page, the message push module will preferentially use the Websocket long connection mode and establish a two-way real-time link with users through the front-end page. It will monitor the execution of the transaction on-chain in each link and push transaction results and on-chain state to users when a transaction is finished.

In terms of messages regarding asset liquidation, returns distribution, and withdrawal reminders, the message push module will conduct constant monitoring and analysis on the contract date and push reminders and warnings to users in various forms including emailing and text messaging in real-time when the action is triggered. You may have already noticed that with the support from BEAMS, QIAN 2.0 now has the technical foundation for launching a mobile wallet.

Financial Component

The security philosophy for QIAN 2.0 can be concluded as three principles for COFi financial security of the layer defense concept.

Protect the platform from attack and invasion
Protect the assets once the platform is invaded
Minimize the loss when the assets are no longer secure

The COFi financial security system is a comprehensive multi-layer system. Decentralization is the core and the foundation, but it is not the only and everything. A secure and reliable open finance application with good scalability, capacity to serve tens of millions of users in the future, and complete risk control ability, is impossible to build by merely relying on decentralized infrastructure.

You may criticize me for not being “decentralized” enough. After all, without decentralization, DeFi is nothing but traditional finance.

Please let me finish first and I’ll leave it to you to decide if QIAN 2.0 upholds the principles of DeFi.

The financial component of QIAN 2.0 includes three parts:

1. GEL

GEL refers to Global Emergency Lockdown.

In the COFi system, all smart contract interfaces that involve asset changes have a GEL switch. Once a problem occurs to the contract, the switch can be manually or automatically triggered and all incoming and outgoing transfer interfaces will be banned, to protect the assets locked in the contract.

2. CALM

CALM refers to Cooperative Automatic Lockdown Mechanism.

CALM is an off-chain risk control mechanism. It adopts finance-level risk control standards, utilizes an independent high availability master-slave cluster with a hot standby configuration, and runs 24/7.

CALM checks the contract state once every 5 seconds and conducts strict bookkeeping and reconciliation for all financial assets in the contract. Once a potential asset risk is discovered, the GEL will be immediately and automatically triggered to stop all interfaces related to the involved assets, to minimize asset loss. Meanwhile, it will notify administrators and the operation team to react quickly and conduct human intervention and investigation.

3. MAK

MAK refers to Multisig Admin Keys.

QIAN 2.0 adopts the admin key mechanism, where the administrator can use the key to set various permissions, like contract router update permission, oracle price feed permission, global lock flag setting permission, etc.

The administrator key can add, delete, and update subordinate permissions. When the subordinate permission key is leaked, it can be replaced quickly.

In order to avoid the loss of the admin key, we have adopted a multi-signature mechanism. Currently, we use 3–2 multi-signature, and with the volume increase of locked assets on the platform, we will gradually upgrade to 5–3 or even 7–5 mechanism.

Taking 3–2 multi-signature as an example, three admin keys are stored in the contract. When performing actions with the highest security level, such as replacing the admin key, at least two admin keys must be used to perform multi-signature at the same time, to make the action happen.

The multi-signature mechanism of the admin key guarantees that

If an admin key is stolen, the attacker cannot use the key to complete high-level permissions. And the platform administrator can use the multi-signature mechanism to delete the leaked key and make it invalid.
If an admin key is lost, the remaining admin keys can be used to add a new admin key and delete the lost one.
The admin key multi-signature mechanism makes every high-level authority operation depend on collective decision-making and execution, which has effectively prevented internal control risks and further protected the assets.

Smart contract deployment, fix, upgrade, etc. all require permissions granted by the administrator key. This is very critical under the current technical conditions. QIAN 2.0 keeps the administrator key function and embraces multisig mechanism to boost its security. It also lays a solid foundation for better distributed key storage and uses.

In the future, QIAN’s stakeholders including its operation team, the core team of the payment network, and the community governance committee will all maintain a part of the administrator key in the multisig mechanism. All major proposed changes of QIAN will need confirmation through FOR’s voting mechanism. The community proposals will be strictly carried out by all parties to constantly run the Decentralized Autonomous Organization (DAO) of QIAN 2.0.

I believe that readers who finished reading this rather technical article have already comprehended the strict risk control concept and design of QIAN 2.0. I look forward to the launch of QIAN 2.0 and testing its security mechanism in practices to better protect users’ crypto assets.

Please contact me if you are interested in QIAN 2.0 through david@theforceprotocol.com.