Vena Network

Vena Network—Open protocol for tokenized asset financing and exchange

Abstract

This whitepaper describes a blockchain-based open protocol in which the highly generic architecture enables users to write contract terms to define rules for a series of decentralized financial activities including asset issuance, lending, trading and etc. Users can retain copyrights and hence there is a natural outgrowth of a trading market for smart contract templates in Vena Network. The Vena Protocol guarantees that the underlying interfaces can be freely defined and provides a standard smart contract library of various kinds including debt contracts (debt financing, credit, collateral loan) and transaction contracts, aiming at helping users to build interactive financial DApps (Decentralized Applications) fastly, conveniently, and safely. Vena Protocol is a set of design and description specifications that can be compatibly deployed on any blockchain network that supports smart contract platforms and can break through the "information island predicament" through cross-chain technology, thus further prospering the Vena Protocol ecosystem. At the beginning of designing, Vena Network fully absorbed the ideas of market competition, resource composition and distribution, such as the compensation of different roles in the Vena Network and the value-added collateral of NFT (non fungible tokens) asset portfolio and etc., improving operability for the lending and trading activities built on the protocol. At the same time, the establishment of fiat-to-cryptocurrency exchange channel gives rise to a decentralized jury network for arbitrating off-chain trade disputes, and uses VENA token as an economic incentive to guarantee the fairness of the network. Vena Protocol does not charge any fees and guarantees that it does not favor any party of the participants. A decentralized autonomous organization (DAO) is responsible for upgrade of the protocol and ensures the security and compatibility of the protocol, while the mapping of ENS to the contract address will enhance the friendliness of access and upgrade of the protocol. Finally, we believe that the Vena Protocol will become an open standard and cornerstone for the construction of a global digital asset financing and exchange network.

1. Introduction of Vena Network

1.1. Background Introduction

The digital economy is growing rapidly. In 2012, the Boston Consulting Group estimated that the potential volume of digital economy in G20 countries reached 4.2 trillion US dollars. In addition, another evaluation, based on the joint study made by the Department of Economics of Oxford University and Accenture in 2015, pointed out that the digital economy will contributed 1360 billion US dollars to the global gross domestic product by 2020. As the demands for online payment grows with the rapid development of digital economy, cryptocurrency is becoming an increasingly popular payment solution which can meet the demands of digital economy.

Blockchain represents the network of value transmission constructed by a series of characteristics such as decentralization, immutability, trustlessness, etc. The P2P reliable trust can be established in the network with blockchain technology so that the value transmission process shall break away from the dependency on intermediary agent for realizing the functions between information disclosure and privacy protection, and between codetermination and individual interest protection. Such mechanism shall promote the efficiency of value interaction and decrease the transaction cost.

Today, there are thousands of cryptocurrencies throughout the world, and everyone can hold them safely. However, in many regions in the world, the transaction between cryptocurrency and fiat currency is still difficult, and the cost is very high, which hinders the popularization of cryptocurrencies and distorts the transaction price. At present, the transactions between cryptocurrency and fiat currency are mainly conducted through centralized OTC trading platform. Most countries haven’t established the legislation of cryptocurrency, which means that such platform can be run without any license and regulation. Therefore, users on such platform always have to bear the risk in both fund safety and privacy disclosure; meanwhile, the trading platform may manipulate the transaction price to earn excess profits.

In the centralized cryptocurrency exchange, such as Poloniex, Bitfinex etc., USDT is used as the digital substitute of USD for transaction. However, as a centralized digital currency to anchor US dollars issued by Tether, there have been a number of severe problems existing in USDT, including:

  1. Tether may goes bankrupt.
  2. The bank which Tether opens its accounts may goes bankrupt.
  3. The bank may freezes Tether’s funds.
  4. Tether may excessively issues USDT.
  5. High service charges, slow settlement, and difficult to withdraw funds.
  6. The security problem that the accounts in Tether was stolen once happened.

Obviously, the demands for the digital substitutes of fiat currency such as USDT will decrease significantly if the users are able to safely and conveniently conduct transactions between cryptocurrency and fiat currency.

Another obvious problem in the field of cryptocurrency is that there is no decentralized service to enable the cryptocurrency holders to safely borrow fiat currency by pledging cryptocurrency, but it has become a noteworthy demand, especially for the users who hold a large amount of cryptocurrency, and believe that the cryptocurrency price will rise. Meanwhile, global investors of fiat currency are also looking for a low-risk and high-yield investment channel, and the collateral loan market has been in their good graces. The centralized collateral loan service providers always earn excessive profits via their monopolistic advantage; what’s more, they would also be more easily affected by factors such as market price fluctuation, poor operation and management, inner corruption, regulating policy change etc. In addition, the users’ concern about privacy disclosure risk is also another reason why they transfer to the decentralized service.

Taking a view at ICO (initial coin offering), under the ERC20 token standard, the Ethereum blockchain has constructed a diversified cryptocurrency secondary market ecosystem in a license-free and interoperable manner. The high liquidity of cryptocurrency in the secondary market has attracted an influx of innumerable investors and helped trigger the ICO frenzy, which actually improves the status quo of traditional equity financing. However, debt financing has similar pain points as traditional equity financing. Debt financing in public offering or private placement, like the implementation of equity financing, is customized and inefficient, which means that the debt market is still non-transparent and proprietary.

In Vena Network, we believe that the transactions should be directly conducted by involved parties, without the need of intermediary agents, and people should freely manage their assets without third-party interference. The debt-based assets can be mapped into generic tokens and then be issued publicly, which enables all kinds of investor to participate in the process and helps transformation to public market from proprietary market formed due to monopoly. From the perspective of liquidity and transparency, there will be a gradual improvement over the status quo. The Vena Protocol realizes the ideas of tokenized assets issuance and the closed-loop circulation of the issued tokens and other types of assets. The Vena Protocol enables institute investors to make debt financing and enables individuals to borrow small loans (credit, collateral loan, etc.). At the same time, without the need of trustworthy third party, the transfer of rights of the pledged NFT and exchange of other types of assets, such as fiat-to-cryptocurrency exchange. The Vena Network whitepaper specifies the technical details of Vena Protocol and the follow-up development plan of the team.

1.2. What’s Vena Network?

Vena Network aims to create a decentralized digital asset financing and exchange network through Vena Protocol. The Vena Protocol is divided into two layers: 1) Basic protocol layer, which mainly includes registration, configuration, routing, and management of upper layer financial businesses. 2) The asset protocol layer, based on assets, completes user-defined financial businesses through the implementation of the terms contract interfaces. For example, terms of pledge and repayment can be written into terms contract to make collateral loan; inheriting of ERC721 standard realizes value-added pledge for asset portfolio; establishing individual credit contract model and injecting on-chain and off-chain data to achieve open and transparent credit. In Vena Ecosystem, a closed-loop circulation from tokenized asset issuance to P2P lending or transactions is realized through blockchain. That is, after the digital assets issuance, directly P2P transactions through the Vena Protocol is available, or after digital assets are pledged, right of pledge is transferable and circulation of collaterals (only supporting Stable Coins) is available. All operations are controlled by smart contract codes and are free from human intervention to guard against fraud. Users joining Vena Network can benefit from the development of the cryptocurrency market, realize asset financing and exchange in a cost-effective, safe and efficient manner, while also can mitigate the risks associated with factors such as cryptocurrency price fluctuations and dishonest financial intermediaries.

Vena nodes are the key elements of Vena Network. Vena Protocol pre-sets two roles, appraiser and relayer. A Vena node can consist of either a single role or a combination of two roles, or can contain all kinds of service providers derived from market competition. In the pre-set roles, appraiser is a trustworthy order producer and appraiser of the default risk of the debtor in the business scenario of debt issuance, and relayer accelerates the process of all debt financing orders in Vena Network without need of trustworthy third parties. They can all be authentically appraised based on historical asset performance. Therefore, the market has a clear signal to appraise credit indicators involving any specific appraiser or relayer, and credit indicators include user's debt default risk index, transaction dispute rate and etc. Vena Protocol uses a mixed technology that we call "off-chain relay, on-chain settlement" to achieve a balance between efficiency and security in debt issuance and asset exchange. In this way, both the debt financing orders and trading orders with the encrypted signature are sent through the off-chain channel, and the potential counterparty can inject one or more orders into the corresponding smart contract, and then the contract is automatically completed following the established logic of the contract. Vena Protocol significantly reduces the friction costs of arbitrage dealers because transaction intentions can be sent off-chain, and the on-chain settlements only occur when the value is transferred. We expand Vena Network by opening up applications for Vena nodes, providing template contract trading market services, and designing the Vena Protocol which is uncoupled from applications.

Vena Network provides significant advantages for Vena nodes and users. Vena Protocol utilizes economic incentives such as cost compensation for various roles in different market competitions in Vena ecology to provide users with accurate market data, real credit data, and digital assets distribution, lending, trading and management services in a fair, transparent, secure manner with rich application scenarios. Each Vena Node represents an independent commercial organization which will gain profit from various financial services it provides. Our mission is to promote the healthy development of cryptocurrency communities.

1.3. Main Characteristics of Vena Network

  • Construct the distributed commercial network by using tokenized economic model
  • Users shall get decentralized identity authentication to conduct credit and fiat currency related transactions
  • Well-defined protocol design. The basic protocol layer is highly abstracted to improve the degree of freedom for secondary development, bringing more ecological roles with more innovation scenarios; the asset protocol layer endogenously supports standard contract library including debt contracts (debt issuance, credit, collateral loan) and trading contracts, which acts as a business forerunner to build an asset financing and exchange ecosystem.
  • Achieve closed-loop circulation of digital assets from asset issuance to the secondary market trading, and can directly complete spot transactions, right of pledge transfer, and the circulation of collaterals (only supporting Stable Coins) within the Vena Ecosystem.
  • Support NFT (non-fungible token) standard and achieve value-added collateral loan for portfolio through self-defined terms contract
  • The third party implementing template contract library in asset protocol layer will retain the copyright, thereby establishing a template contract transaction and service market, and the author may charge the user for the service fee.
  • Different roles in protocol ecosystem will receive compensation, for example, appraiser can use its own data model to provide users with quality credit evaluation services and gain profit.
  • Support ETH, ERC20, BTC, EOS, and BCH, and more cryptocurrencies in the future
  • Support the transaction between cryptocurrency and fiat currency and the collateral loan
  • Solve the risk that the counterparty viciously withdraws from the transaction by smart contract with time lock (Timelock Contract)
  • Only support the irreversible fiat currency transfer so as to minimize the risk of refund (see https://en.bitcoin.it/wiki/Payment_methods)
  • Distributed jury network works as main protection mechanism for fiat-to-cryptocurrency exchange.
  • Restrain the transaction amount (50ETH) in transactions involving fiat currency to lower the overall risk exposure
  • All transaction details are held in smart contract and signed by both trading parties, which can be used as evidence when there is a dispute.
  • Regularly call the price predictor oracle contract through clocks of differenct chains ( such as ethereum-alarm-clock), and obtain the real-time price of token from the trusted-oracles-set
  • Solve the risk of collateral price falling through compulsory liquidation mechanism
  • Solve the risk that the collateral price quickly falls below the debt amount (no time for compulsory liquidation) through additional protocol token issuing mechanism
  • Implement the decentralized governance with Aragon software
  • Safely construct and manage smart contracts with Zeppelin_OS
  • Issue source code with open source permit (AGPL)

1.4. Business Model of Vena Network

Vena Network is an open source project to fill up the gap of cryptocurrency ecosystem rather than a company. Vena Foundation is a non-profit organization established by Vena team in Singapore. The purpose of establishing Vena Foundation is to guarantee the sustainability of Vena project, the effectiveness of decentralized governance, the safety and transparency of fund raising, and the development and business innovation of assisting start-up enterprises based on Vena Protocol.

To promote the healthy development of Vena Network, a comprehensive incentive mechanism has been established by Vena Foundation, mainly including:

  • The Vena node acting as an Appraiser or Relayer should be reviewed and approved and pledge a certain amount of VENA Tokens to the Vena Foundation as a deposit, and the node can make a profit by charging fees.
  • The juror node should be reviewed and approved and pledge a certain number of VENA Tokens to the Vena Foundation as a deposit. At the end of each arbitration, jurors which gave reasonable ruling would receive token rewards, and jurors which gave unreasonable ruling would suffer token losses (see 5.2.3 for details).
  • Users are given a 50% discount when using VENA Tokens to pay fees.
  • Users can get a higher collateral rate and a lower liquidation line when they use VENA Tokens as collateral.
  • When making across-chain trading, the relay node cross-synchronize block head data will receive a reward of VENA Token. The miners making smart contract computing verification that are elected to "quadrant layer" will receive Vena Tokens as rewards.
  • VENA Token holders can participate in the governance of the Vena Protocol and vote on the proposal of protocol improvement proposed by the protocol developers.



2. Application scenario analysis and advantages of the Vena Protocol

Based on the Vena Protocol, we can build a variety of financial scenarios, including debt financing, credit, collateral loan, OTC transactions, etc., in addition to the secondary development of the basic protocol layer to make the scenario innovation, we also provide users with a high degree of freedom in the standard contract library of the scenarios. Since Vena Network provides a standard contract library of debt financing and transaction, in this section we will briefly analyze the problems existing in the existing solutions for such scenarios.

2.1. Offline Transaction

Both parties of the transaction agree on volume, price, time and location of transaction through software, such as Facebook, Telegram, WeChat, QQ etc., without the involvement of any third party. This method is applicable to the local transaction with relatively high fund security risk, and even personal safety risk. Due to the anonymity of cryptocurrency, once a party violates the protocol, the other party’s rights and interests are difficultly guaranteed; what’s more, it is difficult to get and present evidence after such situation. Except in few countries where cryptocurrency transaction is included into the regulatory framework by issuing license, most countries and regions have no legal protection for cryptocurrency transaction, which also increase the possibility that the trader may suffer from fraud risk.

2.2. Centralized OTC Exchange

The OTC trading platforms, such as Localbitcoins, otcbtc, huobi etc., provide the cryptocurrency-to-fiat currency transaction service based on C2C mode, which is a secured trading mode similar to Ebay and Taobao. The seller of cryptocurrency transfers a certain number of cryptocurrency to the address provided by the trading platform, while the buyer fills in and submits an order for purchasing, and the fiat currency should be transferred to the account designated by the seller. After the seller confirms that the fiat currency is received, the trading platform shall transfer the cryptocurrency to the buyer’s address. Any dispute happening during the transaction shall be arbitrated by the trading platform.

Such means of transaction relies on the trust in the centralized trading platform, but the vulnerability of such mode has been proved repeatedly (the well-known exchanges such as Mt.Gox, CoinCheck, Bithumb etc. were once hacked). To be specific, the risked faced by the users of centralized trading platform include:

  1. The trading platform goes bankrupt.
  2. The trading platform embezzles users’ funds.
  3. The trading platform is hacked.
  4. Compliance/regulatory risk.
  5. The trading platform manipulates the price.
  6. The trading platform monopolizes the market and charge high service fees.

2.3. Centralized Collateral Loan Institutions

The centralized collateral loan institutions usually only provide region-oriented and user-oriented services, which is cumbersome and costly to process collateral loan in traditional institutions, such as Banks; what’s more, many unfair and opaque terms are filled with it. Now, cryptocurrency cannot be adopted as a kind of collateral by most of loan institutions. We hope that the cryptocurrency holders can get loans from any place in the world, and no longer rely on local banks or collateral loan institutions.

Today, with the government policy control on currency, inequality affects the global collateral loan market. So, there is interest rate difference between countries and regions due to different risk levels and inflation rates of fiat currency. For instance, the real estate mortgage loan in Brazil may have 32% annual interest rate (adjusted for inflation) while similar loan in Europe may of 0.5%-5% annual interest rate. On the other hand, by setting up access threshold and monopolizing resources such as funds, credit investigation data, market channel etc., the banks and collateral loan institutions always collect high interest rate margin between the depositor and the borrower (the annual interest rate of credit card in China is about 20%, while the annual interest rate of fixed term deposit in the same period is only 1.75%). When the combination between blockchain technology and collateral loan market is launched, a real revolution may be occurred. Relying on Vena Network, the collateral loan market shall be open to all lenders and borrowers without any restrictions such as national boundary, jurisdiction, and bank system. The fiat currency holders can safely provide loans to anyone, and obtain satisfactory interest rate, while the cryptocurrency holders can obtain loans in any place in the world by just bearing the interest rate lower than traditional financial institutions such as bank etc. The cryptocurrency is not controlled by any country or region, so when more and more people start to use Vena Network, more and more liquidity shall be added into the market. Due to fierce competition, the collateral loan market has the same liquidity in China, Europe, or Africa; so, the interest rate margin between countries and regions shall disappear eventually.

2.4. Credit Loan

Traditional credit loans have similar limitations to collateral lending, such as the cumbersome process, high cost, as well as unfair and nontransparent terms. However, the more outstanding problems of credit are risk management, such as the authenticity of credit evaluation and the privacy protection of borrowers. In the current credit market, although various credit institutions can have rich data sources to obtain user credit data and also establish mature credit evaluation models through big data, artificial intelligence and other technical means, the following problems still exist:

  1. Incompleteness of financial data.
  2. Malicious falsification of data sources and tempering of data.
  3. Privacy leaks of the borrowers.
  4. Data islands and geographical restrictions result in the inability to cross-border credit.
  5. Small and medium-sized organizations are out of the market due to high operating costs (the early software and hardware conditions are not complete, operators are unable to obtain data authorization due to unequal rights), and finally a monopoly market is formed.

If the credit platform becomes a Vena node, it will greatly reduce the cost of development, security, the organizations that are incapable of making credit evaluation of the non-financial information of the borrowers can directly obtain the true and complete historical asset performance of borrowers in the blockchain through the Vena Protocol. For end users, borrowing in the Vena Network requires decentralized authentication, while the DID document designed by the Vena Protocol maximizes protection of user privacy. In addition, determined by the characteristics of the blockchain as a global network itself, users can break through the national and geographical restrictions to borrow credit loans, and Vena nodes can provide data support without striving to go across various gateways to obtain financial information from users' permanent residences, which will have a profound impact on the user's transactional processing and emergency handling outside the country.

2.5. Debt Financing

Difficulty for investors to withdraw after the investment and the overlong lock-up period are the root reasons for the situation of rigid venture capital market, the difficulty of direct financing of innovative enterprises and the high cost of financing, making it the major pain point of equity crowdfunding. The emergence of ICO has enabled Bitcoin and Ethereum to become financing tools of “new digital assets and blockchain technology”. It is extremely efficient, inclusive with direct network participation, and has improved the situation when traditional financing is inefficient, long-term, and only limited to a few well-funded and high-net-worth institutional clients. However, in the traditional financial system, debt assets market is larger than stocks in amount, but the market is becoming increasingly rigid. Participant limitation, extent of convenience and market transparency are often criticized. Obviously, if the debt assets are tokenized, it is possible to greatly improve the status quo of the debt market. Moreover, after tokenization of debt assets, it is necessary to have a corresponding secondary market, and investors also need a standardized pricing mechanism to price debt assets. The token value reflecting for a stock is bound with the brand agreement, project quality, or underlying entity, while the token price reflecting a debt asset is typically associated with a historical financial activity of the anonymous counterparty. Therefore, the Vena Protocol provides obiligatory semantic support covering debt assets in the debt-based standard contract library, so that the issuance, management, and circulation of debt assets can relieve the dependence on single centralized data and truly improve the entire huge debt market.

2.6. Ecosystem Advantage of Vena Protocol

We aim at the protocol layer in blockchain to build an ecosystem. The attraction and advantage is that it does not attempt to cater to all market details in the vertical industries, but rather to motivate different roles in the ecosystem to expand market. It is a trend that can be observed in many industries by providing these individuals with the help of infrastructure to create great value. Therefore, we abstract the underlying rules of the financial system with a layered design approach, and gradually promote the emerging markets and roles in the ecosystem based on the Vena Protocol under the strategy taking the debt and transaction scenarios as the leading business. In the case of debt-based scenarios, we do not solve problems by establishing and optimizing a one-for-all system for a specific loan category, whether it is a P2P microfinance network or a decentralized collateral loan Protocol, because such solutions have a common downside – they are narrowly tailored to specific debt categories, and debt covers a wide range of asset types, from accounts receivable factoring to sovereign bonds, building security for each use case. The customized protocol mechanism for every user is very inefficient and redundant. Therefore, we provide our solution. There will be a lot of small ecosystematic superimposition of small ecosystems in the future. Each small ecosystem will have clear and open business, and the Vena ecosystem will also gradually improve and prosper with the development of market competition.

The Vena Protocol builds an expenditure compensation market. There is a variety of roles in the market and any individual can rely on their own competitiveness to provide value-added services to the network to gain profit. Next, we will give a brief introduction to the predefined roles of the Vena Protocol and the template contract market supported by Vena team:

  • Relayer: The relayer is the entity that hosts and maintains the order book. It can form their own competitiveness by providing selective sort order of orders, friendly interactive interfaces and other high-quality services to gather users. It will efficiently promote the order matchmaking and gain profit after the transaction is completed. A more detailed description of the execution process may be that the relayer aggregates the various types of signed orders to obtain a pre-agreed fee, and then it put all the signed orders together on an order book to provide to the end users with its matchmaking service. Relayers do not need to hold any tokens - they just provide a mechanism for end users to view all aggregated signed orders. End users can use this mechanism to issue, borrow, trade various digital assets and complete fiat-to-cryptocurrency exchange without need of trust. The above operations can be performed simply by interaction between the client and contract.
  • Appraiser: An appraiser is a type of role in a market that needs to integrate outside information to provide services. Here we take the debt market as an example. In the traditional debt market, the appraiser is an entity that collects fees by managing and pricing the publicly issued bonds and assessing the default risk of the borrower. In the Vena protocol, this definition is extended and formalized as: a trusted entity that charges fees determined by market for performing the following functions:

    • Use skillful techniques or means (big data, artificial intelligence) to integrate borrowers' financial or non-financial information to assess default risk.
    • Help borrowers draft debt orders.
    • Identify and negotiate debt terms (ie, maturity, interest) with potential debtors.
    • Cryptographically record the specific debt relationship that occurred in the Vena network as the document and evidence for future credit evaluation.
    • Manage debt orders and forward them to any number of relayer nodes.
    • In the event of default by the debtor in its signed debt order, the relayer is obliged to collect the collateral (if the debt is guaranteed) or personal assets through a fiat mechanism and transfer the proceeds to the creditor.

    In fact, it is the same as what most online lenders do in their daily loan acceptance and repayment business, but the Vena Protocol will provide the online lending platform with another inexpensive way to promote their business, and gain a similar profit. They will carry out the original business under the established mechanism of the Vena Protocol and will no longer have to worry about the balance sheet risk. It also saves time and money when raising the necessary debt instruments from traditional investors before starting a business.

  • Contract Author: To support a broader range of financial services, we provide a range of external general interfaces based on basic protocol layers of Vena Protocol, and can dock with general interfaces to make registration, configuration, routing and management internally. It is worth noting that any author who writes a contract can retain its copyright, which can lead to a template contract trading market, and the contract author can charge the contract user through VENA settlement. In the blockchain community, we are adhering to the culture of open source, so everyone can review the contract code or redeploy the contract in a low-cost way on the mainnet. We insist that contract security is very important, the contract that is a copy and redeployed of the original contract will not be maintained and upgraded by the original author, and the security of the funds cannot be guaranteed. According to this, we believe that the template contract market will eventually develop into a natural existence in the Vena Network. Below we introduce the functional interfaces that contract authors may need when designing a particular scenario. It is worth noting that only the description of the possibilities is made here. For specific interface standards, please refer to the documentation in the actual development work.
pragma solidity 0.4.18;


interface TermsContract {
     /// When called, the registerTermStart function registers the fact that
     ///    the debt agreement has begun.  This method is called as a hook by the
     ///    DebtCore when a debt order associated with `agreementId` is filled.
     ///    Method is not required to make any sort of internal state change
     ///    upon the debt agreement's start, but MUST return `true` in order to
     ///    acknowledge receipt of the transaction.  If, for any reason, the
     ///    debt agreement stored at `agreementId` is incompatible with this contract,
     ///    MUST return `false`, which will cause the pertinent order fill to fail.
     ///    If this method is called for a debt agreement whose term has already begun,
     ///    must THROW.  Similarly, if this method is called by any contract other
     ///    than the current DebtCore, must THROW.
     /// @param  agreementId bytes32. The agreement id (issuance hash) of the debt agreement to which this pertains.
     /// @param  debtor address. The debtor in this particular issuance.
     /// @return _success bool. Acknowledgment of whether
    function registerTermStart(
        bytes32 agreementId,
        address debtor
    ) public returns (bool _success);

     /// When called, the registerRepayment function records the debtor's
     ///  repayment, as well as any auxiliary metadata needed by the contract
     ///  to determine ex post facto the value repaid (e.g. current USD
     ///  exchange rate)
     /// @param  agreementId bytes32. The agreement id (issuance hash) of the debt agreement to which this pertains.
     /// @param  payer address. The address of the payer.
     /// @param  beneficiary address. The address of the payment's beneficiary.
     /// @param  unitsOfRepayment uint. The units-of-value repaid in the transaction.
     /// @param  tokenAddress address. The address of the token with which the repayment transaction was executed.
    function registerRepayment(
        bytes32 agreementId,
        address payer,
        address beneficiary,
        uint256 unitsOfRepayment,
        address tokenAddress
    ) public returns (bool _success);

     /// Returns the cumulative units-of-value expected to be repaid by a given block timestamp.
     ///  Note this is not a constant function -- this value can vary on basis of any number of
     ///  conditions (e.g. interest rates can be renegotiated if repayments are delinquent).
     /// @param  agreementId bytes32. The agreement id (issuance hash) of the debt agreement to which this pertains.
     /// @param  timestamp uint. The timestamp of the block for which repayment expectation is being queried.
     /// @return uint256 The cumulative units-of-value expected to be repaid by the time the given timestamp lapses.
    function getExpectedRepaymentValue(
        bytes32 agreementId,
        uint256 timestamp
    ) public view returns (uint256);

     /// Returns the cumulative units-of-value repaid by the point at which this method is called.
     /// @param  agreementId bytes32. The agreement id (issuance hash) of the debt agreement to which this pertains.
     /// @return uint256 The cumulative units-of-value repaid up until now.
    function getValueRepaidToDate(
        bytes32 agreementId
    ) public view returns (uint256);

    /**
     * A method that returns a Unix timestamp representing the end of the debt agreement's term.
     * contract.
     */
    function getTermEndTimestamp(
        bytes32 _agreementId
    ) public view returns (uint);
}

As shown earlier, part of the roles have been described and here are advantages for more roles as follows

Roles Advantages
OTC Trader Process OTC trading conveniently, safely and quickly in a low cost anytime, anywhere
Borrower Borrow a low interest rate loan in fiat currency by pledging digital assets
Creditor Obtain a safe fiat currency investment channel at a yield rate higher than bank interest rate
Author of Contract Write general or specific terms contract and put into market, and get paid by users of contract
Relayer Maintain an order book, earn profits by facilitating transactions and collecting service charges by self-defined competitive strategies and service (such as sorting orders and other value-added services)
Appraiser Gain profit by providing services including debt terms guidance, data integration, credit evaluation models and etc.
Juror Gain awards of tokens by arbitrating disputes that are unable to be settled in smart contract

2.7. Competitors Comparison

Vena Network ETHlend SALT Everex Libra Coinloan
Project type Protocol type (P2P transaction protocol) Platform type (P2P transaction platform) Platform type (P2P transaction platform) Application type (decentralized collateral loan institution) Application type (decentralized collateral loan institution) Platform type (P2P transaction platform)
Degree of decentrali-zation Entire High Medium Low Medium Medium
Safety High (guaranteed by smart contracts) High (guaranteed by smart contracts) Medium (need trusted platform) Medium (need trusted platform) Medium (need trusted platform) Medium (need trusted platform)
Ecosystem scalability Strong (wide profit distribution) Medium Medium Low Medium Medium
Closed loop of circulation including asset issuance, pledge, trade Support Non-support Non-support Non-support Non-support Non-support
Off-chain dispute solution Decentralized network of jurors No Streamline arbitration No No No
Cross-chain technical solution two-way-peg, lightening atomic swap No specific explanation No specific explanation No specific explanation No specific explanation No specific explanation
User privacy protection Decentralized identity authentication No specific explanation Obtain user data after authorization, decentralized storage Obtain user data after authorizati-on No specific explanation No specific explanation
Logic of token apprecia-tion Appreciate for multiple uses including service buying, pledge, guarantee, lend the pledge demand pledge demand pledge demand pledge demand pledge demand pledge demand



3. Detailed Description of Vena Protocol

3.1. Protocol Procedures

3.1.1. Handshake Protocol

3.1.1.1. Trading Handshake

Handshake in trading scenario in which fiat currency is used to purchase cryptocurrency

img

  1. The order producer who intends to use fiat currency to purchase cryptocurrency can request a guarantee service from any trusted appraiser.
  2. The appraiser collects the information of the order producer and evaluates the credit and historical turnover rate, constructing the appraiser’s commitment (including the appraiser's address, service fee and other key information), and signs the appraiser’s commitment hash with the ECDSA, then send the appraiser’s commitment and the ECDSA signature to the order producer.
  3. The order producer reviews the evaluation results and service fees of the appraiser. If the expectations are met, the order producer use the appraiser’s commitment to go to any relayer to make order and entrust it to promote; otherwise, the possible circumstances are: 1) the handshake is terminated; 2) the order producer and the appraiser negotiate again and repeat the step 2; 3) The order producer seeks a new appraiser to commit the service, ie jumps to step 1.
  4. The relayer sends a quotation for the order management and promotion services to the order producer.
  5. The order producer checks the service quotation of the relayer. If expectations are met, the order producer meets the requirement to construct the order. After the order is completed, the relayer promotes the order and updates to the order book for promotion. Note that the relayer’s display and promotion of the order has by default indicated that it accepts all the parameters on the order, so the relayer does not need to sign the order; if expectations are not met, then the possible situation is: 1) the handshake is terminated 2) The order producer sends the order to the relayer and requests a discount offer again, and repeats step 4; 3) the order producer looks for a new relayer to commit the service and repeats to step 4.
  6. order consumer actively goes to the relayer’s order book to select trading order it is interested in and fill in the order.

Handshake in a trading scenario in which order producer is intended to actively sell cryptocurrency in exchange for fiat currency

img

  1. order producer and relayer who intend to actively sell cryptocurrencies negotiate on matters including order management and promotion service fees.
  2. The relayer sends a quotation for the order management and promotion services to the order producer.
  3. The order producer checks the service quotation of the relayer. If the expectations are met, the order producer builds the trade order and entrust the relayer to promote the order, and the relayer updates to the order book for promotion. Note that the relayer's display and promotion of the order has by default indicated that it accepts all the parameters on the order, so the relayer does not need to sign the order; if it does not meet expectations, the possible situation is: 1) handshake is terminated 2) The order producer sends the order to the relayer and requests a discount again, and repeats step 2; 3) The order producer looks for a new relayer for the service, ie jumps to step 1.
  4. The order consumer can request a guarantee service from any trusted appraiser.
  5. The appraiser collects the information of the order consumer and evaluates the credit and historical turnover rate, constructs the appraiser’s commitment (including the appraiser's address, service fee and other key information), and signs the appraiser’s commitment hash with the ECDSA. And send the appraiser’s commitment and the ECDSA signature to the order consumer.
  6. The order consumer reviews the evaluation results and service fees of the appraiser. If the expectations are met, the order consumer picks the matched order from the relayer’s order book and fill the order with the appraiser’s assessment; otherwise, the possible situation is: 1) the handshake is terminated; 2) the order consumer and the appraiser negotiate again and repeat step 5; 3) The order producer seeks a new appraiser to for the service, ie jumps to step 4.
  7. The order consumer completes the order and the relayer sends the order to the order producer for final review.

Handshake in trading scenarios of cryptocurrency-to-cryptocurrency exchange

img

  1. Regardless of whether it is an order initiated for buying or selling cryptocurrency, order producer negotiate with any relayer regarding transaction order management and promotion fees.
  2. The relayer sends a quote for the order management and promotion services to the order producer.
  3. The order producer checks the service quotation of the relayer. If the expectations are met, the order producer builds a trade order, authorizes the Vena Proxy Contract of Token Transfer to use the tokens in its address to be handed over, and entrusts the relayer to promote the order, and the relayer updates the order producer's trade order Promote to the order book. Note that the repeater's display and promotion of the order has by default indicated that it accepts all the parameters on the order, so the relayer does not need to sign the order; if it does not meet expectations, the possible situation is: 1) handshake is terminated 2) The order producer sends the order to the relayer and requests a discount offer again, and repeats to step 1; 3) The order producer looks for a new relayer to commission the service, ie jumps to step 1.
  4. The order consumer actively goes to the relayer’s order book to select matched trade order and fill in the order.
3.1.1.2. Credit Handshake

Debtor initiatively makes a loan order

img

  1. The debtor may request debt services from any credible appraiser, fill in the debt type and the terms of the loan.
  2. The appraiser collects the debtor's information and conducts a credit evaluation, constructing an appraiser's commitment (including the appraiser's address, service fee and other key information) and the debt issuance commitment, and uses ECDSA to sign the appraiser's commitment hash and debt issuance commitment, the appraiser’s commitment and the ECDSA signature are sent to the debtor.
  3. The debtor reviews the credit assessment, order template and fee provided by the appraiser. If the expectations are met, the debtor builds a debt order based on the template and then go to a relayer to negotiate about order promotion and fees of order management; otherwise, the possible circumstances are: 1) the handshake is terminated; 2) the debtor and the appraiser negotiate again and repeat step 2; 3) The debtor seeks a new appraiser to commit the service, ie jumps to step 1.
  4. The relayer sends the quotation of the order management and promotion services to the debtor.
  5. The debtor checks the service quotation fed back by the relayer. If the expectations are met, the debtor uses the parameters formed by the tripartite negotiation to complete the debt order, and the relayer promotes the debt order, and the relayer updates the debtor's debt order to the order book for promotion. Note that the relayer’s display and promotion of the order has by default indicated that it accepts all the parameters on the order, so the relayer does not need to sign the order; if it does not meet the expectations, then the possible circumstances are: 1) the handshake is terminated 2) The debtor sends the order to the relayer and requests to provide a lower quotation again, and repeats step 4; 3) The debtor looks for a new relayer to commit the service and repeats to step 4.
  6. The creditor actively goes to the relayer’s debt order book to select the matched debt order and fill in the order.
  7. The debtor fills in the “Check my creditor” section when creating a debt order. If yes, the creditor is obliged to send the debt order to the debtor and the debtor submits the order to the Vena debt kernal contract; If no, the creditor can submit the order directly to the Vena debt kernal contract. It is worth noting that, in the case of the debtor’s affirmation of the “Check my creditor” column, the Vena debt kernal contract will verify whether the submitter’s address is the debtor’s address, if not then requests will be rejected by the Vena debt kernal contract.

Creditors initiatively make lending orders

img

  1. Creditors may request debt services from any credible appraiser, fill in the debt type and lending terms.
  2. The appraiser gives the creditor feedback on the services that can be provided and the template or tool for creating the debt order, the address of the appraiser and the service fee to be paid.
  3. The creditor reviews the debt order template and service fee information of the appraiser. If the expectations are met, the creditor creates a debt order based on the debt order template provided by the appraiser, then sends the debt order to the relayer and negotiates on the service fee for the relayer to promote and manage the order; if not, the possible situations are: 1) the handshake is terminated; 2) the creditor and the appraiser negotiate again and repeat step 2; 3) the creditor looks for a new appraiser to entrust the service, ie jumps to step 1.
  4. The relayer sends a quotation to the creditor for services such as order management and promotion.
  5. The creditor checks the service quotation fed back by the relayer. If expectations are met, then replys relayer indicating that the delegation is established, the relayer starts to promote the debt order, and the relayer updates the debtor's debt order to the order book for promotion. Note that the relayer’s display and promotion of the order has by default indicated that it accepts all the parameters on the order, so the relayer does not need to sign the order; if it does not meet the expectations, the possible situation is: 1) handshake is terminated 2) The creditor sends the order to the relayer and requests to provide an offer again, and repeats step 4; 3) The creditor looks for a new relayer to entrust the service and repeats step 4.
  6. The debtor actively goes to the relayer’s debt order book to select the matched debt order (including the service fee review for the appraiser and the relayer) and fill in the form.
  7. The debtor returns the order to the appraiser filled in the debt order. The debtor may respond directly to the appraiser's communication address or via the relayer.
  8. The appraiser collects the debtor's information and conducts a credit evaluation, constructing an appraiser's commitment (including the appraiser's address, service fee and other key information) and the debt issuance commitment, and uses the ECDSA to sign the appraiser's commitment hash and the debt issuance commitment, the appraiser’s commitment and the ECDSA signature are sent to the debtor.
  9. The debtor reviews the credit assessment by the appraiser. If the expectations are met, the debtor signs the debt order and sends it to the creditor; otherwise, the possible situation is: 1) the handshake is terminated; 2) the debtor and the appraiser negotiate again and repeat to step 8.

3.1.2. Trading Protocol

3.1.2.1. Exchange between fiat currency and cryptocurrency

Before we elaborate on the protocol, we will simplify the specifications and descriptions of the relevant terms according to the semantics in context:

  1. The transaction subject matter between the order producer and the order consumer is the cryptocurrency Token A and the fiat currency Fiat B.
  2. Users who sell cryptocurrencies in exchange for fiat currency are collectively referred to as cryptocurrency users.
  3. Users who purchase cryptocurrencies with fiat currency are collectively referred to as fiat currency users.
  4. Both cryptocurrency users and fiat currency users may play the role of order producer or order consumer.

The protocol process is as follows:

  1. Complete the transaction handshake between the order producer, the order consumer, the appraiser, and the relayer.
  2. The cryptocurrency user authorizes the Vena Token Transfer Proxy Contract to use Token A in its address.
  3. The cryptocurrency user submits the order to the Vena kernal contract.
  4. After the order is verified by the Vena kernal contract, the Token A in the order will be locked up by the contract, waiting for the fiat currency user to pay.
  5. The fiat currency user transfers Fiat B to the fiat currency account of the cryptocurrency user within the specified time range.
  6. After receiving the fiat currency, the cryptocurrency user initiates a confirmation of fiat currency receipt to the Vena routing contract within the specified time period. The confirmation receipt shall be filled with the actual amount collected.
  7. The Vena routing contract verifies whether the order has expired, whether it has been completely filled, whether the amount is matched, etc. After the verification is successful, the established number of Token A is automatically transferred to the address of the fiat currency user through the Vena token transfer proxy contract.

In particular, in the exchange scenario between fiat currency and cryptocurrency, in theory any user who can pay for gas can submit the transaction order to the Vena kernal contract. In fact, the submission by the cryptocurrency user will be more common in practical cases.

3.1.2.2. Exchange between cryptocurrency and cryptocurrency
  1. Complete the transaction handshake between the order producer, the order consumer, and the relayer.
  2. The order consumer authorizes the Vena Token Transfer Proxy contract to use the tokens in its address that are ready to exchange.
  3. The order consumer submits the order to the Vena kernal contract.
  4. The Vena kernal contract verifies the signature, whether the order has expired, whether it has been completely completed, and after the verification is successful, the token is automatically transferred between the two parties through the Vena token transfer proxy contract with the specified exchange rate.

3.1.3. Debt Protocol

The scenarios of debt issuance are rich and the details of the debt terms are very complicated. Therefore, the Vena Protocol uses a versatile framework to meet various needs in the actual application scenarios, that is, various debt activities can be written by the scenario plug-in contract (ie, the terms contract). However, Vena team officially will take the lead in making a major Protocol description for collateral and credit loans, and eventually package it into a scenario plug-in standard contract library.

3.1.3.1. Collateral Lending

Pledge digital assets to borrow fiat currency

Borrowing a loan:

Before detailing the protocol, we will simplify the specification and explanation according to the semantics in context: the collateral loan subject matter between the debtor and the creditor is the digital asset Token A/NFT and the fiat B respectively.

  1. Complete the loan handshake between the debtor, creditor, appraiser and relayer.
  2. Before the debt order is submitted to the Vena kernal contract, the debtor should have authorized the Vena token transfer proxy contract to use the cryptocurrency Token A/NFT in its address.
  3. The debt order is submitted to the Vena kernel contract. After the verification, the Vena kernel contract acquires the market exchange rate of Token A and Fiat B through Oracle. (If the debtor pledges the subject matter of NFT, then the Vena kernal contract acquire negotiated NFT value from the debt order). The parameter calculation is performed according to the preset loan model. After the calculation is completed, there will be two cases: 1) If the handshake process is carried out in the manner in which the debtor actively makes the loan order, the Vena kernel contract verifies whether the Token A/NFT in the debtor's address exists, if the Token A balance is insufficient/NFT does not exist, the loan fails and the order is cancelled. If the token balance/NFT meets requirement of the total amount including subject matter valuation amount adding the appraiser service fee in the debt order and the relayer service fee, then principle payable will be obtained from the calculation. The collateral Token A/NFT will be locked up in the contract and wait for the creditor to transfer the amount equal to principal amount to debtor's fiat currency account. 2) If the handshake process is carried out in the manner in which the creditor initiatively makes the loan order, the amount of the Token A that debtor should use as collateral actually should be calculated (if the loan subject matter in the debt order is NFT, the NFT value should be already agreed in the handshake process, Vena kernal contract will calculate and verify according to creditor’s loan amount, negotiated NFT valuation, collateral model parameters). Vena kernal contract verifies the Token A balance/NFT in the debtor’s address. If the balance is insufficient / NFT does not exist, the loan fails, the order is cancelled; if the balance of Token A amount is sufficient for the total amount including subject matter valuation amount adding appraiser service fee in the debt order and the relayer service fee / NFT exists and negotiated NFT's valuation meets the total amount of [collateral rate * Amount (Fiat B)] adding the appraiser service fee and the repeater's service fee, then the collateral Token A/NFT is locked up in the contract and wait for the creditor to transfer the principal amount of the loan to the debtor’s fiat currency account.
  4. The creditor transfers the principal payable to fiat currency account designated by the debtor within the specified time period.
  5. After receiving the fiat currency, the debtor initiatively makes a fiat currency receipt confirmation to the Vena routing contract within the specified time period, and the receipt confirmation shall be filled with the amount collected.
  6. Vena routing contract verifies whether the order has expired, whether it has been filled, whether the amount matches, after the verification is successful, the established amount of the appraiser service fee, the relayer service fee is transferred to the corresponding address through the Vena token transfer proxy contract.

Full repayment:

  1. After the loan is due, the Vena kernel contract informs the debtor to repay.
  2. The debtor transfers the total amount of principal and interest payable to the creditor’s fiat currency account within the specified time period.
  3. After the creditor receives the fiat currency, it initiates a fiat currency receipt confirmation to the Vena routing contract within the specified time period. The receipt confirmation shall be filled with the actual amount collected.
  4. The Vena routing contract verifies the creditor's signature, whether the order exists, whether the amount matches, etc. After the verification is successful, the locked-up collateral Token A/NFT is transferred to the debtor's address, and the repayment is registered.

Instalment repayment:

  1. During the loan period, the debtor transfers to the creditor's fiat currency account the required repayment amount determined by the parameters.
  2. After the creditor receives the fiat currency, it initiates a fiat currency receipt confirmation transaction to the Vena routing contract within the specified time period. The receipt confirmation transaction shall be filled with the actual amount collected.
  3. Vena routing contract verifies the signature of the creditor, whether the order exists, whether the amount matches, etc. After the verification is successful, the Vena kernel contract obtains the market exchange rate of Token A and Fiat B through Oracle (if the debtor pledges NFT as subject matter, before the full payment of principle and interest is paid, the NFT is unable to be redeemed). The amount of Token A to be redeemed is obtained by parameter calculation according to the established loan model, and then the amount of Token A equal to the calculated value is transferred through the Vena token transfer proxy contract to the debtor's address and the repayment is registered.

Pledge digital assets to borrow digital assets

Borrowing a loan:

Using digital assets as collaterals to borrow more digital assets will be in the scenario of taking NFT as the subject matter, we use the NFT as collateral to borrow the mainstream cryptocurrency as an example to make the protocol detailed:

  1. Complete the loan handshake between the debtor, creditor, appraiser and relayer.
  2. Before the debt order is submitted to the Vena kernel contract, the debtor should have authorized the Vena token transfer proxy contract to transfer the NFT assets as collateral subject matter in its address. The creditor should have authorized the Vena token transfer proxy contract to transfer mainstream cryptocurrency Token X in its address.
  3. The debt order is submitted to the Vena kernel contract. After verification, the Vena kernel contract acquires the real-time market price of Token X through Oracle, and calculate parameters to obtain the amount of Token X that creditor should lend according to the negotiated valuation of NFT and the established loan model (this value is filled when order is created).The balance of Token X in the address of the creditor will be verified by Vena kernel contract, if the NFT does not exist, the loan fails, the order is cancelled; if the NFT exists and the negotiated valuation of NFT satisfies the amount that the total amount of valuation of Token X that is lent by creditor adding the appraiser service fee and the relayer service fee, the NFT is locked up in the contract through the Vena token transfer proxy contract, and the Token X that should be lent, the amount of the appraiser service fee and the relayer service fee are transferred to the corresponding address respectively.

Repayment:

1. When processing instalment repayment, the debtor shall authorize the Vena token transfer proxy contract to transfer certain amount of Token X, the amount of which is greater than or equal to the expected total principal and interest.
2. The debtor initiates a repayment transaction with the Vena routing contract, and the repayment transaction should be filled with the required repayment amount determined by the parameters. Then, the Vena routing contract will obtain the current beneficiary address of the debt (if no pledge transfer occurs during the loan period, the Vena routing contract obtains the initial creditor address of the debt) and the expected repayment amount is transferred from the debtor’s address to the current beneficiary's address, and the payment is registered.
3. If the debtor's principal and interest are fully paid, the Vena token transfer proxy contract is automatically triggered to transfer the NFT to the debtor's address.

3.1.3.2. Debt Financing / Individual credit loan

The subject matter of financing is fiat currency

Borrowing a loan:

  1. Complete the loan handshake between the debtor, creditor, appraiser and relayer.
  2. After the debt order is submitted to the Vena kernel contract, after the verification is successful, the Vena kernel contract informs the creditor to transfer the fiat currency of the financing amount to the debtor's fiat currency account.
  3. The creditor transfers fiat currency of the amount of principle to account designated by the debtor within the specified time period.
  4. After receiving the fiat currency, the debtor initiates a fiat currency receipt confirmation transaction to the Vena routing contract within the specified time, and the receipt confirmation transaction should be filled with the actual amount collected.
  5. The Vena routing contract verifies whether the order has expired and has been filled. If the amount matches the verification, a NFT carrying the credit certificate will be cast. The NFT, the service fee of the appraiser of the established amount, and the service fee of the relayer is transferred to the address of the creditor, appraiser and relayer through the Vena token transfer proxy contract.

Full repayment:

  1. After the loan expires, the Vena kernel contract informs the debtor to repay the loan.
  2. The debtor transfers the total amount of principal and interest or the remaining principal and interest of the debt to the creditor’s fiat currency account within the specified time period.
  3. After the creditor receives the fiat currency, it needs to authorize the Vena token transfer proxy contract to use the NFT with credit certificate in its address and initiate the fiat currency receipt confirmation transaction to the Vena routing contract within the specified time. The receipt confirmation transaction should be filled with actual amount of the payment.
  4. The Vena routing contract verifies the creditor's signature, whether the order exists, whether the amount matches, and after the verification is successful, the NFT with credit certificate in the creditor's address will be automatically transferred to the debtor's address through the Vena token transfer proxy contract, and the repayment is registered.

Instalment repayment:

  1. During the loan period, the debtor transfers the creditor's fiat currency of the account of the required repayment determined by the parameters.
  2. After the creditor receives the fiat currency, it initiates a fiat currency receipt confirmation transaction to the Vena routing contract within the specified time. The receipt confirmation transaction shall be filled with the actual amount collected.
  3. The Vena routing contract verifies the signature of the creditor, whether the order exists, whether the amount matches, etc., and the repayment is registered after the verification is successful.

The subject matter of financing is cryptocurrency

Borrowing a loan:

  1. Complete the loan handshake between the debtor, creditor, appraiser and relayer.
  2. Before the debt order is submitted to the Vena kernel contract, the creditor should have authorized the Vena token transfer proxy contract to use the mainstream cryptocurrency Token X in its address.
  3. The debt order is submitted to the Vena kernel contract. After verification, the Vena kernel contract obtains the financing target amount in the debt order and inquires the balance of Token X in the creditor's address. If the balance is insufficient, the financing fails and the order is cancelled. If the balance of Token X satisfies the requirement of sum of the financing target, the appraiser service fee in the debt order, and the relayer service fee, a NFT carrying the credit certificate is cast. The NFT, the target amount of Token X, the appraiser service fee of the established amount, and the relayer service fee are transferred to the address of creditor, debtor, appraiser, and relayer respectively through the Vena token transfer proxy contract.

Repayment:

1. When Instalment repayment or repayment is due, the debtor shall authorize Vena token transfer proxy contract to transfer the Token X of a certain amount, which is greater than or equal to the expected total principal and interest.
2. The debtor initiates a repayment transaction with the Vena routing contract, and the repayment transaction should be filled with the required repayment amount determined by the parameters. Then, the Vena routing contract will obtain the current beneficiary address of the debt (if NFT with credit certificate is not transferred during the loan period, then the Vena routing contract obtains the initial creditor address of the debt) and will return the expected repayment amount to the address of current beneficiary and the repayment is registered. If the repayment is the remaining repayment of the debt, the creditor shall have authorized the Vena token transfer proxy contract to use the NFT with credit certificate and at the same time as the debt is paid off, the NFT with credit certificate will be transferred through the Vena token transfer proxy contract from the address of the creditor to the address of the debtor.

3.2. Format of Order

Corresponding to these two kind of protocol we proposed above, we design two formats of Order: Trading order and Debt order. Order format is kept simple and expandable by design. Meanwhile, both order format is designed with abilities of bidirectional order creation and partial order fill.

Each order is a data package containing transaction parameters of certain format of the order category and relevant signatures. The order parameters are arranged and connected in key ascending order, and hashed as 32 bytes through Keccak SHA3 function. The order producer uses its private key to sign the transaction parameter hashes to generate ECDSA signature.

The relayer in the Vena Network are only responsible for storing and distributing an order book to facilitate the flow of information between the two parties, and charge a small fee (the amount of the fee is determined by the Vena node, the counterparty, etc.). Unlike a centralized organization, the Vena node does not hold the user's cryptocurrency, nor does it represent the two parties of a debt or transaction, which means that the parties do not need to trust the operator of the Vena node.

The relayer can choose whether to place the order in the shared liquidity pool. If the order is placed in a shared liquidity pool and is traded through another relayer, the commission will be split by the two relayers at a pre-set rate prior to the order's closing.

3.2.1. Format of Trading Order

For better semantics, we use the term `Intent` to present the off-chain order, and the term `Fill` to present the on-chain settlement record after `Intent` is filled. A `Fill` could be related to a single or multiple `Intent`, since `Intent` could be partial filled multiple times. The following table show a typical trading order structure:

Name Data Type Description
kernelVersion address Address of the vena kernel contract. When protocol upgrades occur, this address will be updated.
orderType string Order types.
producer address Address of the order producer.
relayer address Address of the relayer.
appraiser address Address of the appraiser wishing to attest to the rating of this debt asset.
appraiserRiskRating uint32 The appraiser's assessment of the average likelihood that any given unit-of-value the debtor is expected to pay will actually be repaid. Must be a value between 0 and 1, encoded as an unsigned integer understood to have 9 decimal points (i.e. a 50% likelihood would be represented as 500000000)
relayerFee uint Fee charged by relayer, cleared from VENA token.
producerFee uint Total fee need to be payed by producer after this intent being filled, cleared by VENA token.
consumerFee uint Total fee need to be payed by consumer after this intent being filled, cleared by VENA token.
appraiserFee uint Fee charged by appraiser, cleared from VENA token.
producerSymbol string The type of asset the order producer wants to send.
producerAmount uint256 The number of assets the order producer wants to send.
producerChannel string The payment method selected by the order producer.
consumerSymbol string The type of asset the order consumer wants to send.
consumerAmount uint256 The number of assets the order consumer wants to send.
minAmount uint The minimum amount of principle that this intent is expected to be partial filled.
expirationTimestamp uint256 Unix timestamp of the time at which this order will no longer be valid if unfilled.
salt uint A pseudo-random salt value used ot differentiate the hashes of debt orders with identical parameters.
intentId byte32 The hash of the whole intent.

When the consumer call contracts to fill the Intent, a Fill is produced on chain:

intentId byte32 The related intent id.
consumer address The address of consumer who fill the intent with intentId above.
fillAmount uint The amount of asset which creditor willing to lend.
salt uint A pseudo-random salt value used ot differentiate the hashes of debt orders with identical parameters.
fillId byte32 The hash of the whole fill.

3.2.2. Format of Debt Order

Debt order definition is slightly different from trading order, since the loan terms is extracted to a external contract for expandability and flexibility. The `loanContract` and `loanContractParameters` are provided when the `Intent` are showed on relayer. Actor who is interested in this `Intent` can go through this contract for audition. Initially, we provide official contract examples(eg. including collateral loan, credit loan, etc), any one in VENA Network ecosystem can write their own contract as long as implant the standard `loanContract` interface in the future. Furthermore, debtor and creditor have the different rights and liabilities under off-chain handshaking and on-chain settlement. Consider the ability of order creation for both debtor and creditor, we design two different order format:

  • Debtor Intent: The order structure which represents borrow intent from the debtor.
  • Creditor Fill: The filled order by creditor.
  • Creditor Intent: The order structure which represent lend intent from the creditor.
  • Debtor Fill: The filled order by debtor.

As an example of debtor-create & creditor-fill schema, the following table show the Debtor Intent format:

Name Data Type Description
kernelVersion address Address of the vena kernel contract. When protocol upgrades occur, this address will be updated.
orderType string Order types.
debtor address Address of the debtor.
relayer address Address of the relayer.
appraiser address Address of the appraiser wishing to attest to the rating of this debt asset.
appraiserRiskRating uint32 The appraiser's assessment of the average likelihood that any given unit-of-value the debtor is expected to pay will actually be repaid. Must be a value between 0 and 1, encoded as an unsigned integer understood to have 9 decimal points (i.e. a 50% likelihood would be represented as 500000000)
relayerFee uint Fee charged by relayer, cleared from VENA token.
debtorFee uint Total fee need to be payed by debtor after this intent being filled, cleared by VENA token.
creditorFee uint Total fee need to be payed by creditor after this intent being filled, cleared by VENA token.
appraiserFee uint Fee charged by appraiser, cleared from VENA token.
principalToken string The kind of asset for principle, which can be "BTC", "CNY", "USD", "USDT", etc.
principalAmount uint The amount of principle.
principleChannel string The payment method selected by the debtor.
minAmount uint The minimum amount of principle that this intent is expected to be partial filled.
loanContract address Address of the Loan Contract Interface adherent smart contract that defines: 1.the repayment terms of the debt. 2. If the loan have collateral, this contract can determine the collateral detail.
loanContractParameters bytes32 Data packet of parameters ingested by the Terms Contract to commit to specific values relevant to the repayment terms (e.g. principal, interest rate, etc.)
payload string The additional information for this intent.
expirationTimestamp uint256 Unix timestamp of the time at which this order will no longer be valid if unfilled.
salt uint A pseudo-random salt value used ot differentiate the hashes of debt orders with identical parameters.
intentId byte32 The hash of the whole intent.

When the creditor call contracts to fill a Debtor Intent, the following table show the Creditor Fill produced on chain:

intentId byte32 The related debt intent id.
creditor address The address of creditor who fill the intent with intentId above.
fillAmount uint The amount of asset which creditor willing to lend.
salt uint A pseudo-random salt value used ot differentiate the hashes of debt orders with identical parameters.
fillId byte32 The hash of the whole fill.

3.3. Price, Interest Rate, Liquidation and Protection Mechanism

Vena node cannot determine the OTC transaction price, but can only recommend a fair current market price to both parties of the transaction, and the specific transaction price shall be determined and agreed by both parties. To promote liquidity, the list of OTC transaction orders in Vena node shall be arranged by price from high to low. Vena node cannot determine the interest rate of mortgage loan as well, which shall be set by the borrowing party. If the lending party is satisfied with interest rate of the borrowing party, both parties can conclude the transaction through a smart contract. Debt orders processed by standard contract library provided by Vena team will be given better risk management strategy, including but not limited to risk parameters, such as the types of token which can be used for collateral, the collateral rate, and the compulsory liquidation limit, which are set by Vena Protocol. These overall settings shall be stored in an Ethereum smart contract deployed by Vena Foundation, and the modification of any parameter should be voted by DAO. To respond to emergency, Vena Foundation can select several members to establish the Vena DAO committee, and the modification can be executed after most members confirm.

During the loan period, use the ethereum-alarm-clock to periodically call the price oracle contract, obtain the real-time price of the collateral from the trusted-oracles-set, and notify all Vena kernel contracts. After receiving the price notice, Vena kernel contract calculates whether the collateral value of all loan orders in this contract is lower than the liquidation line. If the value of the collateral is found to be lower than the liquidation line, the borrower is immediately notified to add collateral to a safe level within the specified time. After the specified time, Vena kernel contract calculates the value of the collateral again, and if it is still below the liquidation line, it will automatically perform the forced liquidation immediately. The liquidation method is as follows: calculate the total amount of principal and interest that should be paid in real time, transfer the token with the value equal to 105% (to most) of the principal and interest to the creditor’s address, and transfer the remaining token to the borrower's address.

To prevent various fraud and attack situations, we adopt (but not limited to) the following protection mechanisms:

  • Users – must conduct transactions through KYC.
  • Vena node – must be approved by Vena Foundation and guarantee deposit.
  • Juror – must be approved by Vena Foundation, guarantee deposit, and anonymously and randomly distributed for arbitration.
  • Orders with digital signature – evidence in which the transaction details cannot be forged.
  • PageSigner evidence – evidence in which the transfer of fiat currency cannot be forged.
  • Transaction amount limit for fiat-to-cryptocurrency exchange or fiat currency debt financing– limit the maximum transaction amount (50ETH) to reduce fraudulent potential incomes.
  • Smart contract with timelock (Timelock Contract) – solve the risk that the counterparty viciously withdraws from the transaction.
  • Only support the irreversible fiat currency transfer to reduce the risk of refund (see https://en.bitcoin.it/wiki/Payment_methods).
  • Price observation mechanism – regularly call the price oracle contract through blockchain clock (such as ethereum-alarm-clock), and obtain the real-time price of mortgage token from trustworthy oracle set (trusted-oracles-set).
  • Trustworthy oracle set – DAO has the right to determine a group of trustworthy oracle nodes by voting. In emergency, some oracle nodes can be increased or deleted after confirmed by most members of DAO committee.
  • Compulsory liquidation mechanism – solve the risk of collateral price falling.
  • Vena Protocol cannot be used in the jurisdictions which cryptocurrency transaction is illegal.

3.4. Black Swan Incident

Black swan Incident refers to unpredictable and unusual incident. which usually arouses negative market chain reaction, and even overthrow. Cryptocurrency market is characterized with huge fluctuation, so we must consider an extreme situation: the price of a pledged token falls rapidly in a short time, and the collateral price has drastically fallen below the debt amount before system has time to execute the compulsory liquidation. To prevent the extending of risk exposure, system will automatically execute compulsory liquidation immediately under such circumstance, and ask Vena ERC20 Contract to additionally issue a certain number that is less than 3% of total amount annually of Vena in accordance with the market price of VENA Token to the lending party to compensate the difference between collateral value and debt amount. Such additional issue mechanism may cause a certain degree of value dilution to VENA Token, but compared with the damage on Vena Network caused by large-scale debt default, such value dilution is mild and controllable, and conforms to long-term interests of most VENA Token holders.

If the cryptocurrency market price fluctuates sharply, Vena DAO committee has the right to remove certain types of cryptocurrency out of the scope of token types which can be pledged, and even temporarily shut down the collateral loan business in the whole network. The main business system of Vena Network is established totally based on the ecosystem of Ethereum, Bitcoin and EOS (it may be extended to other mainstream public chains in the future), therefore the safety and practicality of Vena Network and the price of VENA Token shall depend on the health degree of the ecosystem of Ethereum and bitcoin to a large extent. In the long term, Vena team shall pay close attention to the development orientation of blockchain underlying technology, and Vena Network shall benefit from the prosperity of the whole cryptocurrency ecosystem, and thus gain a sustainable and healthy development.

3.5. Smart Contract Technology

Vena Protocol is to complete a standard implementation through a group of smart contracts deployed on the Ethereum. This group of contract code is open-source (use AGPL protocol to release source code), and can be used free of charge (only require standard gas consumption). Vena team use smart contract language that is secure and ecosystematic complete to provide standard contract library of debt category and transaction category.

3.5.1. Signature Verification

Vena kernel contract can use ecrecover function to verify signatures of participating roles in the transaction order, to prevent from submitting forged order for fraud the function uses hash and signature hash as parameters, and returns to generate the public key address of signature. If the public key address returned by ecrecover equals to Producer’s address, the signature is real.

address publicKeyAddr = ecrecover(hash, signature(hash));
if(publicKeyAddr != signerAddr) throw;

3.5.2. Time Locking

One of the main uses of time lock in the Vena protocol is to solve the problems of manual confirmation timeout and malicious fraud when the fiat currency is transferred off-chain. We simply enumerate a few specific application scenarios, before which the relevant terms are simply standardized and explained according to the meanings in the context:

  1. The seller who sells the cryptocurrency in exchange for the fiat currency, the creditor who lends the cryptocurrency, the debtor who borrows the cryptocurrency, the debtor who repays the cryptocurrency, and the debtor who uses the cryptocurrency as the transfer subject matter are collectively referred to as the cryptocurrency user in the current context.
  2. The buyer who purchases the cryptocurrency through the fiat currency, the creditor who lends the fiat currency, the debtor who borrows the fiat currency, the debtor who repays the fiat currency, and the debtor who uses the fiat currency as the transfer subject matter are collectively referred to as the fiat currency user in the current context.
  3. In a trading scenario in which a fiat currency user participates, after the order is submitted, the fiat currency user must complete the fiat currency transfer within 30 minutes and click the “Transferred” button. Otherwise, it is deemed to abandon the transaction, and the Vena kernel contract will return the locked-up Token/ The NFT to the address of the corresponding cryptocurrency user.
  4. In a trading scenario where a fiat currency user participates, the fiat currency user will receive a notification immediately after clicking the “Transferred” button. After that, the cryptocurrency user must click “receipt cofirmation” or “apply for arbitration” within 1 hour, otherwise it will be regarded as maliciously exiting the transaction, and the Vena kernel contract will transfer the locked-up Token to the address of the fiat currency user.
  5. In the scenario where the fiat currency user is the debtor and the cryptocurrency user is the creditor, after the collateral loan expires, the Vena kernel contract sends a repayment notice to the debtor. The debtor must complete the fiat currency repayment within 24 hours and click “Repayment Confirmation" button, otherwise deemed to be overdue, the Vena kernel contract will immediately perform mandatory liquidation.
  6. In the scenario where the fiat currency user is the debtor and the cryptocurrency user is the creditor, after the collateral loan expires, after the debtor clicks “Repayment Confirmation”, the creditor must click “Receipt” Confirmation or “application for arbitration” within 24 hours. "Otherwise, as a malicious exited transaction, the Vena kernel contract will return the locked-up Token back to the debtor's address."
  7. After either party applies for arbitration, both parties must submit the evidence within 24 hours according to the system requirements, and then enter the jury arbitration stage. If no evidence is submitted, there will be no opportunity to submit the evidence again.

3.5.3. Fill and Partially Fill in the Order

Vena kernel contract stores every order submitted previously, and every order is composed of a structure (struct). The list of orders is stored in a mapping (a solidity data structure similar to hash table). The mapping shall map the 32-bytes block data to the order structure. After the order parameters are transmitted to Keccak SHA3 function, an only 32-bytes hash will be generated, and used as the unique identification of the order (the probability of hash collision is actually zero). The member, ValueFill, in the order structure is used to show the quantity filled in the order. After each order is filled in, mapping will update the accumulated value of quantity filled in the new order.

struct Order {
  ...
  uint256 valueFill;
}
mapping(bytes32 => Order) internal OrderList

While filling in the OTC transaction order and mortgage loan order, order consumer can partially fill in the order through designated additional parameter, valueFill. Only the sum of quantity partially filled in doesn’t exceed the total order quantity, the partial filling can be executed repeatedly for a single order.

Name Data Type Description
valueFill uint256 Total units of token or fiat to be filled (valueFill ≤ valueA or valueB).

While filling in the collateral loan order, creditor should designate the additional parameters such as creditorRealName, paybackChannel, and paybackDetail.

Name Data Type Description
creditorRealName string Real name of Creditor
paybackChannel bytes Fiat payback channel (eg. paypal, alipay)
paybackDetail string Details of payment

3.5.4. Expiration Time

The expiration time of an order is designated by order producer establishing the order, which is an integral value without symbols, and represents a UNIX timestamp. Such value cannot be changed after signed.

We take Ethereum as an example. The time in Ethereum oracle is given is based on the block timestamp set when a new block is mined every time. Therefore, it doesn’t depend on the time when Consumer submits an order to determine whether the order expires, but on the time when the miner executes filling function in EVM. The miner cannot set the timestamp of current block to be earlier than the timestamp of previous block.

3.5.5. Cancellation of Order

Before the order is submitted to Vena kernel contract, order producer can request Relayer to cancel the order. After the order is submitted to Vena kernel contract, order producer can cancel the unfilled and unexpired part of the order through the cancellation function of Vena kernel contract. Such function shall change the valueFill of the order to its maximum value to prevent subsequent filling. Cost may be incurred by cancelling an order through Vena kernel contract, so this function is only used as a standby mechanism. Generally, order producer can match the order expiration time with the time when they plan to update a new order, thus to avoid the on-chain cancellation of order.

There is a problem existing in this method. It may cause that when order producer tries to cancel the order, order consumer tries to fill in the same order, which will result in a failed transaction among the two transactions, and waste gas. The uncertainty of transaction mining order may result in unexpected results sometimes, and if there are a large number of transactions to be processed on the Ethereum blockchain, such uncertainty may increase.

3.6. Multi-chain assets and Vena dispatching

The Vena Protocol is a set of design and description specifications that are compatible for deployment on any blockchain network that supports smart contract platforms. Since the various public chains are heterogeneous and the differentiation characteristics are obvious, the Vena protocol will do more adaptation and performance optimization for specific public chains under the principle of maintaining the uniformity of the protocol itself to fit the chain. In the future, when more public chains become the growth soil of the Vena protocol, we will implement the Vena business dispatching system in the upper layer of the protocol, that is, the business traffic probes are buried on the public chain that has already deployed the Vena protocol, and then the distribution of traffic is uniformly scheduled to alleviate the congestion of blockchain network transactions.

The multi-chain compatible deployment of the Vena protocol is the support of multi-chain assets, and the cross-chain asset circulation is the only way for the protocol ecosystem to prosper. To achieve this goal, we need to rely on technologies and protocols that allow these cryptocurrency networks to communicate with each other. We are happy to see that many excellent teams — for example, Polkadot and Cosmos — are working on this issue. Unfortunately, these projects are still under intense development today—some have either not yet announced a specific release date (such as Polkadot) or some just suit for a blockchain based on a Proof of Stake (PoS) mechanism (such as Cosmos). Therefore, the existing solution for cross-chain communication remains to be explored. After comprehensively comparing various cross-chain technical solutions, the Vena team reviewed the project positioning, selected the route to reuse the existing proven and feasible solutions, and complemented the selected program combinations. In addition, the Vena team is actively designing and exploring universal protocols from the second layer on-chain. For example, a lightweight multi-stakeholder consensus protocol has been proposed that does not completely replicate the underlying chain, does not produce an independent chain, but employs a participant mechanism, such as a jury system. By selecting random jurors, all the juror nodes interact with each of the underlying chains to implement the verification, which maximizes the use of existing blockchains and resources. In this design, all chains can be participants, without the need for "chain-to-chain" anchoring, but by building an extensible, generic "quadrant layer" over each blockchain. And "interoperability" is implemented in the "quadrant layer", so the "quadrant layer" can be regarded as a kind of IP protocol of the cross-chain layer. When cross-chain transitions are required between the various chains, the election contract is triggered to elect a number of nodes to form a jury (the jury is composed of miners in the network of each chain that has a transition between each other, the general election contract is abstracted from the unified interface table of "quadrant layer" and deployed on each public chain, and then a jury election is initiated from the "quadrant layer" to each chain. The selected miner node eventually forms a jury), and the jury will verify authenticity of the transition after the interaction chain is mapped to the "quadrant layer". In the "quadrant layer" state transition T (S, c1, c2, c3, ...) -> S' conversion logic is controlled by the smart contract, because the "quadrant layer" also builds the execution environment of the smart contract. According to this, the work of the jury is actually to verify the implementation of smart contracts in the "quarantine layer". In the process of cross-chain state transition through the “quadrant layer”, the reward and punishment mechanism is used, for example, the VENA Token is used as reward for a jury to verify the execution of the contract; if ordinary miner node wants to register as a jury candidate, it needs to use VENA Token as deposit; The VENA Token of the jury member's miner node will be confiscated once it is discovered to have been malicious. It is worth noting that the jury for cross-chain verification described here is not the same as the jury described in verification (Chapter 5.5) for resolving the off-chain fiat currency transfer disputes, but for the operating entities involved in the ecosystem of the Vena Protocol, the two can be merged together.

3.6.1. The compatibility between base currency of the blockchain and the on-chain application tokens

Before solving the cross-chain asset transfer and exchange, we should pay more attention to the compatibility between the base currency of the blockchain and the application token issued on it. It is a key part in achieving the full-ecosystematic multi-asset circulation closed-loop. Taking Ethereum as an example, the WETH contract solves the problem of on-chain redemption between ETH and VENA and other ERC20 standard Tokens after the mainnet is deployed. First, ERC20 established a standard interface for Ethereum Token to allow Ethereum smart contracts to interact with any standards-compliant Token. ETH is the base currency of Ethereum and does not comply with the ERC20 Token standard. However, many DApp developers have found that writing smart contracts to abstract ETH into ERK20-compatible Tokens enables seamless redemption between ETH and ERC20 Token, eliminating the need for red tape to write codes for conversion.

When the Vena protocol is deployed on Ethereum, we use the WETH contract deployed by the Makerdao team to implement the above functions. When Vena network is deployed on other blockchain networks, the Vena team would write similar smart contracts to solve the compatibility problem between the base currency and the application token.

Contract deployment address:

3.6.2. 2-way Peg Technology

The general description about 2-way peg is as follows: the token of bitcoin on Ethereum is named as E-BTC. When a user “deposits” BTC, such BTC shall be locked on the bitcoin blockchain. The BTC transaction proof is sent to an Ethereum contract, which is naed as PegContract. PegContract verified this transaction, and issue E-BTC to the user’s Ethereum address. 1BTC in bitcoin system equals to 1E-BTC in Ethereum system. After that, when the user wants change E-BTC back to BTC, it just needs to burn E-BTC, and provide a burning proof to the bitcoin blockchain. After verifying that such E-BTC has been destroyed, the bitcoin blockchain shall unlock the original BTC.

Now such PegContract can be implemented on Ethereum, and without need of trust to complete all work. It can verify that BTC has been sent to some address and locked; issue E-BTC; burn E-BTC and provide burning poof. BTC-Relay is such a contract, which realizes the simplified payment verification of bitcoin, thus to verify whether a transaction has been confirmed on the bitcoin blockchain (the verification fee should be paid to Relayer to as to motivate Relayer to continuously submit bitcoin block headers to BTC-Realy contract). Therefore, any transaction in the bitcoin system, from payment to BTC locking, can be verified by Ethereum contract. In a similar way, we can use the Ethereum contract to verify the transactions on bitcoin cash (BCH) blockchain.

The problem existing in the 2-way peg is that we can’t deploy ETH-Relay or any locking contract on the bitcoin blockchain. After the release of RootStock, we can establish a 2-way peg between ETH and RootStock to realize the interaction between bitcoin and Ethereum. Another practical solution is to lock the User’s BTC in a multi-signature address, and every signer must store ETH in Ethereum PegContract. When BTC is locked, PegContract shall issue E-BTC as usual. When E-BTC is returned to PegContract, they will be destroyed and PegContract shall generate a proof. Meanwhile, PegContract starts to count down, to provide sufficient time to signers to destroy proof and unlock BTC. If any signer refuses the multi-signature, the ETH stored by such signer shall be transferred to the user’s Ethereum address. To ensure a smooth redemption process, the signers can get service fee rewards in each deposit/redemption process. The specific theory is shown in the following figure:

img

3.6.3. Lighting Atomic Swap Technology

To ensure the safety of cross-chain transaction, the transaction velocity of 2-way peg technology must meet the following inequation:

V represents safe transaction velocity; v1 and v2 represent the individual safe transaction velocity of two blockchains respectively. It can be perceived from the inequation that the cross-chain safety transaction velocity is slower than the safe transaction velocity on any blockchain. For bitcoin blockchain, the safe transaction confirmation time may be 30 minutes and even longer. On the other hand, there is an on-chain transaction respectively on the two blockchains and a gas fee for SPV verification and a Relayer service fee should be paid, so it is relatively expensive to realize the cross-chain transaction by using 2-way peg technology.

The lightning atomic swap is a real-time cross-chain transaction technology combining lightening network and atomic swap. The lightening network is a protocol which operates by establishing off-chain payment channel between different transactions, and the On-chain transaction is only need to open and close the payment channel. It has three advantages. First, accelerate transaction velocity; second, reduce transaction cost; and third, promote transaction volume. The atomic swap is another protocol which enables both parties to conduct the cross-chain transaction without the need of trust. There are two results for the execution of atomic swap. The one is that both parties complete the digital currency exchange, and the other is that nothing happens. Most importantly, there is no need of trusting any third party, so fraud shall be avoided.

A long waiting time is required to ensure safety when the atomic swap is used separately, and at least on-chain transactions are required. However, on the condition that there is a payment channel on both blockchains, the use of lightening atomic sway can greatly reduce the waiting time, and no on-chain transaction is required. On November 16th, 2017, Lightning Laboratory confirmed that the first lightening atomic swap based on bitcoin-litecoin blockchain in the world had been completed, and the specific technical principle is as shown in the following figure:

img

By the time when this text is written, the bitcoin lightening network has been successfully released on the main bitcoin network, and the lightening network on Ethereum – Raiden Network is intensive development and research phase. We will continuously pay close attention to the progress of relevant projects, and introduce the lightening atomic swap technology into Vena Network at right time (after the reliability of relevant technologies has been verified).



4. Vena Protocol Token

To promote the development of Vena Network, and enable more people to participate in the Vena ecological construction, share Vena ecological earnings, and establish a decentralized collaborative decision-making mechanism, Vena team will issue ERC 20 token based on Ethereum blockchain, VENA Token, which shall be mainly used for the inner circulation of Vena ecosystem, and motivate Vena users to construct, use and maintain Vena Network. VENA Token shall become the lubricant for the stable operation of Vena Network.

4.1. Economic Model of VENA Token

The value storage function and the circulation function of protocol token is a pair of contradiction in the token economic model. If the design of token economic model is partial to the value storage function, due to the anticipation that the price will increase, the token holders will tend to hold but not use such tokens, which further weaken their liquidity. Such self-reinforcing positive feedback will result in high entry threshold for new users, and hinder the expanding of protocol use range. Such situation has been verified in the bitcoin system. It can be predicted that when such self-reinforcement reaches a limit, people will no longer use such tokens in the market, and no new users enter the market; so, the whole token economic model will be close to the edge of breakdown. The token transaction is completely driven by speculation demand, and the token price may suddenly collapse at its peak point. If the design of token economic model is partial to the circulation function, the users will lose the motivation to hold tokens, but select to complete the transaction as soon as possible, especially when the predicted price increase of protocol token is lower than other tokens with value storage function. Under such circumstance, the average time users hold the protocol tokens depends on their prediction about the token price, the use value and use frequency of such token, and the transaction cost between such token and other currency. The decrease of any factor may cause that the users tend to trade, but not hold the tokens, which will further result in the falling anticipation of token price. Such reverse positive feedback will cause the collapse of protocol token price, and even the death of whole protocol ecosystem.

Based on above analysis, we can draw the conclusion that the balance is maintained only when a protocol token has both value storage function and circulation function at the same time, and the price can be stably maintained. Vitalik Buterin discussed this problem in a blog in 2017, and put forward a formula to assess the token price:

MC = TH

  • M represents total supply quantity of tokens.
  • C represents token price.
  • T represents token transaction volume.
  • H represents average time of users holding tokens.

Our design objective of VENA Token economic model is to maintain token price C at a relatively stable long-term increase rate, and to maximize the total market value of tokens MC/TH at the same time. For this reason, we need to pay attention to two aspects. First, enlarge the token transaction volume T as far as possible, and increase the average time of users holding tokens H; second, ensure that the increase rate of total supply quantity of tokens is lower than the increase rate of TH. In the phase when the user volume increases rapidly, the token transaction volume T shall grow at the same time, and the growth of TH is mainly driven by newly increased users T; when the increase of user volume slows down, and even stops, T and H show a negative correlation, and TH has a maximum value. Therefore, in the early stage of Vena Network development, the most effective method to maximize the total market value of VENA Token is to attract more new users to join in Vena Network, and encourage users to hold more VENA Tokens. Only when Vena Network is developed to cover most cryptocurrency users, and the increase of total number of users in the whole cryptocurrency ecosystem slows down, we need to consider to make TH close up to maximum value by promoting the inner liquidity of the system.

After full consideration about the factors mentioned and the usage scenarios of Vena Network, we design a very ingenious and unique token economic model for Vena Protocol. In the design of Vena Protocol, there is a special type of token transaction – token deposit. When the VENA Tokens are deposited, we still can treat them to be held by users, because the liquidity in the market is not increased. By encouraging users to use VENA Tokens as deposit, we promote their demands for VENA Tokens and prolong the time when they hold such tokens. It is named as a “using and holding” token economic model. Obviously, such model shall greatly stimulate the increase of VENA Token price, so we need to design an additional token issue mechanism to control the increase of VENA Token price within a reasonable range. Fortunately, there are abundant scenarios in the Vena Protocol ecosystem enabling us to motivate users to jointly construct and maintain Vena Network by issuing additional VENA Tokens. Some specific examples and additional issue scenarios are given in the subsection 4.2 and 4.3.

In addition, we also design an additional community incentive mechanism based on the VENA Token model. By establishing Vena investment funds, we will invest in the enterprises and DAO in the Vena Protocol ecosystem, and use a part of incomes from investment to pay back to the community through events, including but not limited to hackathons.

4.2. Use Cases of VENA Token

  • To establish a verified Vena node, a certain number of VENA Tokens should be deposited in Vena Foundation.
  • To take the post of Vena verification juror, a certain number of VENA Tokens should be deposited in Vena Foundation.
  • Paying OTC trade service charges in VENA Tokens can enjoy 50% discount.
  • Users borrowing money with VENA Tokens as collateral can enjoy 50% service charge discount, and obtain higher loan-to-value ratio and lower liquidation limit.
  • The order of borrowing money with VENA Tokens as collateral shall be highlighted.
  • VENA Token holders can participate in Vena DAO voting, and become a member of protocol governance decision-making level.

4.3. Additional Issue of VENA Tokens and Bounty Pool

The initial issue volume of VENA Tokens is 1 billion, also there is a bounty pool which is funded by Vena Foundation, and later, a certain number of additional tokens shall be issued every year. The additional issue volume of VENA Tokens is closely related to the operation state of Vena Network, now the additional issue scenarios which have been determined are as follows:

  • Vena jurors may obtain VENA Token rewards for appropriate arbitration, and the reward part shall be generated by bounty pool, the insufficient part will be produced by additional issuance. If the juror node is malicious, the punish token will be counted into bounty pool.
  • When any black swan event happens, execute the compulsory liquidation immediately, and issue additional VENA Tokens to compensate the lending party, thus to avoid debt default. The additional part of Vena Token will be confirmed by DAO and compensated to the party made collateral in less than 3 working days.
  • For any scenario in which additional issue of VENA Token is required, submit a proposal to Vena DAO for voting. Additional issuance will not be more than 3% of the total token amount of the year.

4.4. Aragon DAO Governance

Aragon released in 2017 is an operating system of Decentralized Autonomous Organization(DAO). In Aragon, a simple and easy-to-use set of basic administration components for Decentralized Autonomous Organization(DAO) can be easily realized, which includes token distribution management, organization member management, voting management, crowdfunding management, financial management etc. The behaviors of Aragon organization can be easily defined by modifying regulations. In addition, Aragon organization can be extended through the third-party module for organizing contract interaction.

img

VENA Token holders can vote on every aspect of Vena Protocol through the voting module of Aragon software, and such aspects include but are not limited to:

  • Vena Protocol upgrading proposal.
  • Proposal for additional issue of VENA Tokens.
  • Vena DAO committee election.
  • Trusted oracle set modification proposal.
  • Vena Network general parameter (scope of tokens which can be mortgaged, mortgage rate, compulsory liquidation limit, service charge, transfer channels in which fiat currency can be used etc.) modification proposal.
  • Vena Network temporary open and close proposal.

It largely depends on a robust decentralized ecosystem to promote liquidity whether Vena Network can be recognized by the public eventually. The roles participating in ecological construction are not limited to VENA Token holders, but also developers, terminal users etc. To effectively and widely take advice, we follow the concept of distributed governance to establish a set of standard decision-making procedures, and host them in Aragon, which involve member and authority management with Aragon Group, financial management with Aragon Finance, and other management modules.

With the release of AragonOS release 3.0, the voting management has become a more flexible entrance for DAO governance, we can manage different voting scenarios in accordance with ACL self-defined parameter rules, or easily forward the voting results to different DAO management application programs with Forwarders. A program for a self-defined parameter rule verification is as follows:

function verifyCombinatedParams() {
    Param[] memory params = new Param[](7);
    params[0] = Param(LOGIC_OP_PARAM_ID, uint8(Op.IF_ELSE), encodeIfElse(1, 4, 6));
    params[1] = Param(LOGIC_OP_PARAM_ID, uint8(Op.AND), encodeOperator(2, 3));
    params[2] = Param(ORACLE_PARAM_ID, uint8(Op.EQ), uint240(new AcceptOracle()));
    params[3] = Param(BLOCK_NUMBER_PARAM_ID, uint8(Op.GT), uint240(block.number - 1));
    params[4] = Param(LOGIC_OP_PARAM_ID, uint8(Op.OR), encodeOperator(5, 2));
    params[5] = Param(0, uint8(Op.LT), uint240(10));
    params[6] = Param(PARAM_VALUE_PRARM_ID, uint8(Op.RET),0);

    assertEval(params, arr(uint256(10)), true);
}

DAO governance model is diversified and dynamically adjusted, and AragonOS provides both convenience and certain security assurance.

4.5. Token Distribution Plan

The total amount of VENA Token issuance is 1 billion. And the tokens for teams, advisors, private sale, crowdfunding sale, foundation, and incentive pool will be distributed by smart contracts as follows:

img

  • Team and Advisors: This part accounts for 15% of the total amount of issued VENA tokens, 1/4 of the part will be distributed immediately after token issuance; the remaining 3/4 of the part will be locked up for one year, and after the one-year lock-up period, the tokens will be distributed as follows: 1) VENA tokens of advisors will be distributed immediately; 2) 1/4 of the tokens of the team will be distributed immediately and the remaining will be distributed in stages over a period of 12 months.
  • Private sale: VENA tokens of private sale will be distributed in two methods: 1) The part of tokens that are not included in the lock-up plan will be distributed to the participant's wallet within 2 days before the listing in exchange; 2) The part of tokens that are included in the lock-up plan will be locked in smart contract after listing in exchange, which will be unlocked and distributed to participants' wallets by stages according to established rules.
  • Public sale: After public sale, this part will be distributed to the participants' wallets within 2 days before listing in exchange.
  • Foundation: This part will be held by smart contract and unlocked monthly in two years. The use of unlocked funds will be subject to the approval of Vena DAO with disclosure of details during use.
  • Bounty Pool: Each year the team and community developers will be given a fixed share of 1% for 10 consecutive years; the remaining 5% will be used for introduction of important resources, including but not limited to talents, strategic partners, etc.
  • Reservation: Funds can be raised from the reserved part through the DAO when the team lacks funds, or the reserved part can be transferred to the fund pool of the foundation to promote ecosystematic development.

4.6. Vena Investment Fund

After Vena Network's fundraising work is completed, the Vena Foundation will establish a Vena investment fund specifically for investing and incubating companies and DAOs within the Vena Ecosystem, from the funds raised and the fund pools in the Vena Foundation, respectively. The direction of investment includes blockchain underlying technologies, blockchain protocols and applications, and Vena Protocol extensions. The Vena investment fund is directly managed by the Vena DAO Committee, accompanied with a professional investment research team and post-investment management team. Some of the fund income will be paid back to the community through events including, but not limited to, hackathons, and the residual income will be used for continuous rolling investment.



5. Vena Protocol Ecosystem

5.1. The Overall Architecture of Vena Network

img

5.2. Network of Jurors

The smart contract can resolve disputes by controlling transactions on the chain, but it cannot control transactions under the chain. The network of jurors is used to handle situations which cannot be judged by the smart contract and submit the results to the smart contract. When users apply for arbitration during the transaction, the juror network will initiate. The network of jurors is designed to establish a decentralized dispute resolution mechanism through economic incentives, avoiding absolute trust from a single arbitral institution and thereby providing a higher degree of security. The full set of arbitration software runs on the infrastructure built by Ethereum and IPFS. Through a simple user interface, the juror can easily receive the evidence submitted by the parties to the dispute and arbitrate. All records for arbitration will be permanently stored on the Ethereum blockchain. All tamper-proof cryptographic evidence (generated by PageSigner) will be permanently stored in the nodes of the IPFS network.

5.2.1. Juror Application

To join the Vena juror network, you need to first submit an application to Vena DAO and provide proof of identity. After passing the review, you need to participate in online training and assessment of Vena juror. After the assessment is passed, you are required to sign a contract online with the Vena Foundation and purchase a certain number of VENA Token to mortgage to the Vena Foundation. The juror is not allowed to use the mortgage token during the contract term. If the contract will not be renewed after its expiry, the Vena Foundation will return the mortgage token to the juror.

5.2.2. Arbitration

  • Phase1: The user initiates an arbitration request and the arbitration software will notify both parties, requesting both parties to submit a cryptographic evidence in the prescribed format within 24 hours (using PageSigner, a Firefox/Chrome plug-in that allows the user to generate tamper-evident webpage evidence) and other supplementary evidences (text, pictures, voice, video, etc.). All evidences are packaged, signed and uploaded to IPFS. At the same time, the arbitration software will randomly select three jurors from the contracted jurors and notify them to prepare for the arbitration(excluding the jurors' possibility of arbitrating themselves through KYC data verification). The juror must response within 8 hours. If the juror does not response timely, it will be fined X (mortgage token), and the arbitration software will re-select the juror. The entire process must be completed within 24 hours.
  • Phase2: The jurors accept the evidences submitted by both parties to the dispute, verify the signature and review the evidences. The jurors can also request to review the KYC data of both parties. In order to avoid conspiracy to commit fraud, the jurors cannot communicate with each other nor can they directly communicate with both parties. The juror must complete the review within 8 hours and make an independent conclusion (may support the disputing party or may not be able to make a decision). The juror will be fined if it do not make a decision timely. Subsequently, the arbitration software will judge the arbitration result as follows:
    • If three jurors support the same party, such party wins and the arbitration ends. The arbitration software informs the DEX Contract of the arbitration results.
    • Otherwise, the arbitration will go to Phase3.
  • Phase3: If the arbitration does not end in Phase2, then the evidences submitted by both parties and the decisions of the three jurors will be submitted to the Vena DAO Committee for final decision. The Vena DAO Committee may request both parties to submit additional evidences, and may even request video s or screen sharing with both parties when necessary to ensure the conclusion is correct. All evidences and video materials will be uploaded to IPFS. There is no fixed time limit for phase 3, and the arbitration will continue until the Vena DAO Committee makes a final decision.

5.2.3. Economic Incentives and Deposits

In order to motivate the jurors to exercise the jury power properly, the jurors need to use a certain amount of VENA Token as deposit in Vena DAO. After each arbitration is completed, the arbitration system rewards or punishes each of the three jurors (A, B, and C) according to their decision and the final result R. The specific rules are as follows (+X indicates reward X. ,-X means fine X, 0 means neither rewards nor punishments):

Decision Reward or Punishment
A B C A B C
R R R +X +X +X
R R ¬R +X +X -X
R R Can not Decide +X +X 0
R R Overtime +X +X -2X
R ¬R ¬R +X 0 0
R ¬R Can not Decide +X -X 0
R ¬R Overtime +X -X -2X
R Can not Decide Can not Decide +X 0 0
R Can not Decide Overtime +X 0 -2X
R Overtime Overtime +X -2X -2X
¬R ¬R Can not Decide 0 0 +X
¬R ¬R Overtime 0 0 -2X
¬R Can not Decide Can not Decide -X +X/2 +X/2
¬R Can not Decide Overtime -X +X/2 -2X
¬R Overtime Overtime 0 -2X -2X
Can not Decide Can not Decide Can not Decide +X/2 +X/2 +X/2
Can not Decide Can not Decide Overtime +X/2 +X/2 -2X
Can not Decide Overtime Overtime 0 -2X -2X
Overtime Overtime Overtime -2X -2X -2X

Because the order of A, B, and C is irrelevant, the above table already contains all possible combinations of the decisions of the three jurors. The fact that the jurors did not make a decision in the time limit is rare, as this would result in the juror being subject to double the fine of tokens.

5.2.4. Exit Mechanism

If the following circumstances occur during the contract term, an exit mechanism will be initiated.

  • The juror applies for exit: The juror who is not within an arbitration period may apply for exit to Vena DAO. After reviewed by the Vena DAO Committee, if it is confirmed that the juror has no misconducts, the application will be approved and the remaining deposited tokens and reward tokens will be returned.
  • Fined more than 5 times during the contract term: The quit process will be initiated mandatorily. After reviewed by the Vena DAO Committee, if it is confirmed that the juror has no other misconducts, the juror is forced to quit from the network and the remaining deposited tokens and reward tokens will be returned.
  • The Vena DAO Committee determined that the juror had obvious misconduct (such as conspiracy to defraud): All deposited tokens and reward tokens will be deducted, the juror is forced to exit from the network and Vena DAO reserves the right to further investigate the juror.

5.3. Vena Node Network

The main role of the Vena node network is to promote the liquidity of Vena Network and provide users with comprehensive transaction and loan services. Vena nodes may be established through the deployment of Vena open source software or achievement of self-developed (secondary development) Vena Protocol, and make a profit from transaction fees. To apply for becoming a verified Vena node, the following conditions must be met:

  • Shall occupy the operational qualifications of microfinance lending of the place where it operates, corporate entity and fixed office space, and experience in the operation of microfinance lending industry. Vena officially provides a full set of open source software and secondary development technical support (free technical training, engineers 7 * 24 remote technical support). Shall sign for three years for the first time.
  • Shall purchase 1000000Vena at the price of 1ETH = 10000Vena (the first batch, the purchase price and quantity will be adjusted in the future with the change of Vena price) and mortgage it in the Vena Foundation. During the contract term. the trading service provider is not allowed to use this deposit. If the contract will not be renewed after its expiry, the Vena Foundation will return the mortgage token to the juror.
  • Must comply with the laws, regulations, and policies of the place where it operates. If the trading service provider violates the law, the Vena DAO Committee has the right to fine the trading service provider until it is disqualified.
  • Shall ensure that the trading software can fully implement all the Vena Protocol requirements and strictly execute them. Any trading service provider that does not comply with the Vena Protocol will be fined until it is disqualified.
  • Not allowed to apply for quit during the contract term.</p>

5.4. Decentralized Identity Authentication

In order to ensure transaction security, users shall complete authentication before using the Vena Network. The traditional KYC/AML system stores user identity data on a centralized server, which leads to a serious risk of user privacy leakage and it has aggravated the inequality of the right between users and service providers. We will return the ownership of user data on Vena Network to the user. To implement this purpose, we designed a set of decentralized authentication protocols for Vena Network. Users can register, request, send certificates, and securely manage their key and privacy data on the Vena Network.

5.4.1. DID and DID Documents

Our authentication protocol design refers to the work of the W3C Credentials Community Group on Decentralized Identifiers and Identity Credentials (see https://w3c-ccg.github.io/did-spec/, https://opencreds.org/specs/source/identity-credentials/ ). The identity is identified by a decentralized identifier (DID) and points to a DID document. The combination of the DID and its associated DID document forms the root record of the decentralized identifier.

The DID generation methods currently supported by Vena Network are as follows:

vena-did = "did:vena:"vena-specific-idstring
vena-specific-idstring = network":"address
network = "mainnet"/"ropsten"/"rinkeby"/"kovan"
address = 40*HEXDIG
  • The network currently only supports Ethereum's "mainnet", "ropsten", "rinkeby", and "kovan", but it can be extended in the future to support arbitrary Ethereum instances (including private instances).
  • address is the Ethereum address HEX encoded (without 0x prefix).

The DID document shall be a single JSON object, the format of which is specified in JSON-LD. JSON-LD is a format used for mapping JSON data to the RDF semantic graph model defined by [JSON-LD]. A basic example of a DID document is shown as follows:

{
  "@context": "https://github.com/venanetwork/vena-connect/vena-did-v1.jsonld",
  "@id": "did:vena:mainnet:d278018404b0889326f1799beecf8724b61d691e",
  "@type": "Person",
  "name": "Bob",
  "email": "bob@vena.network",
  "born": "1990-01-01",
  "credential": [{
    "@graph": {
      "@context": "https://w3id.org/identity/v1",
      "@id": "http://example.gov/credentials/3732",
      "@type": ["Credential", "PassportCredential"],
      "name": "Passport",
      "issuer": "https://example.gov",
      "issued": "2010-01-01",
      "claim": {
        "@id": "did:ebfeb1f712ebc6f1c276e12ec21",
        "name": "Alice Bobman",
        "birthDate": "1985-12-14",
        "gender": "female",
        "nationality": {
          "name": "United States"
        },
        "address": {
          "@type": "PostalAddress",
          "addressStreet": "372 Sumter Lane",
          "addressLocality": "Blackrock",
          "addressRegion": "Nevada",
          "postalCode": "237842",
          "addressCountry": "US"
        },
        "passport": {
          "@type": "Passport",
          "name": "United States Passport",
          "documentId": "123-45-6789",
          "issuer": "https://example.gov",
          "issued": "2010-01-07T01:02:03Z",
          "expires": "2020-01-07T01:02:03Z"
        }
      },
      "signature": {
        "@type": "LinkedDataSignature2015",
        "creator": "https://example.gov/keys/27",
        "signature": "3780eyfh3q0fhhfiq3q9f8ahsidfhf29rhaish"
      }
    }
  }],
  "signature": {
    "@type": "EcdsaKoblitzSignature2016",
    "created": "2016-10-23T05:50:16Z",
    "creator": "ecdsa-koblitz-pubkey:020d79074ef137d4f338c2e6bef2a49c618109eccf1cd01ccc3286634789baef4b",
    "signatureValue": "..."
  }
}

The DID document uses the SHA256 hash as the file name, with the public key encrypted and stored on the IPFS. The mapping relationship between DID and DID documents is stored in the etcd cluster maintained by Vena Certified Exchange (The storage of this mapping relationship in the Ethereum smart contract will result in transaction fees. Considering most of the Vena users creating their identities initially do not hold the ether, this will significantly increase the threshold for the user to use Vena Network). Users can create identities (DID documents) through Vena DApp (WEB/Mobile) and bind with an Ethereum address (DID). After the identity is successfully created, the user can authorize a Vena exchange to access its identity data to complete KYC. After successfully authenticated, the Vena Exchange will issue a digital certificate to the user. The user may store such digital certificate in the DID document, which can be used for identification in the future.

5.4.2. Vena Connect

We plan to upgrade the Vena decentralized authentication protocol to Vena Connect in the future (2019-2020), which is an Ethereum identity management infrastructure, allowing users to log in to all Ethereum DApps using a unique DID, register their identities, request and send certificates of identity, send Ethereum transactions, share data with anyone they trust, and manage their key and private data safely. Some other projects, such as uport and kec.fiat, are also making similar attempts, but we think it is difficult to succeed for a decentralized identity authentication project lacking use scenario and user size base. The development of Vena Connect will rely on the huge ecological network and strict KYC requirements of the Vena Network project. With the expansion of the scale of Vena Network users, Vena Connect will be widely applied in the fields of finance, insurance, recruitment, e-commerce, credit, etc.

5.5. Shared Liquidity Pool

Liquidity is the “soul” of any market, and the user can obtain an excellent transaction experience in a dynamic market. Therefore, we provide a shared liquidity pool to maintain the liquidity of transactions in the Vena Network. The shared liquidity pool mainly has the following applicable scenarios:

  • If a Vena node‘s liquidity is insufficient, he can put his own resting orders on the shared liquidity pool and the other Vena node can pick orders from the shared liquidity pool to their own Vena node for presentation. If the order is done, the two Vena nodes will get the commission of the transaction in proportion to the value of the order attribute in margin Split Percentage.
  • If the user wants to borrow fiat currency from an Vena node where the fiat currency is not in circulation, the Vena node can provide a channel that directly forwards the order to the shared liquidity pool, prompting the transaction to be quickly traded on other eligible Vena nodes to improve the user experience. The transaction commission is still charged in proportion by the two Vena nodes based on the value of the order attribute in margin Split Percentage.

5.5.1. Shared Orders

We said that the orders that the Vena nodes want to place into the shared liquidity pool are shared orders. Its format is as follows:

message sharedOrder {
  string originExAddr/DID;
  bytes rawOrder;
  uint8 marginSplitPercentage; // [1-100]; we will set a default value:3;
  uint8 v;
  bytes r;
  bytes s;
  uint256 nonce;
}

5.5.2. Micro-services and Clusters

In the Vena Network, the shared liquidity pool exists in the form of a service organization. In order to be able to expand and upgrade service better in the future, we have adopted micro-service architecture design. The nodes participating in the maintenance of the shared liquidity pool need to pay the security bond and submit the server parameter configuration and other related materials to the Vena Foundation. After passing the certification, they can join the service cluster. For honest nodes that provide services for long-term stability, we use VENA Token for settlement through quality-of-service-weighted charging or on-time charging.

From a simple and secure perspective, to support the RESTful API access and optional SSL client certificate authentication, we use etcd as the primary technology for the shared liquidity pool. Etcd is a high-availability KV storage system that can be used to share configuration and service discovery. In the persistence layer, the service list and the order list are mainly maintained, the service list is used for service searching when the exchange consumption data is used, such as an exchange initiative choosing orders, a hot spot account configuration, and the like; The order list is a collection of orders placed by the Exchange to a shared liquidity pool, and in order to ensure the source of orders, each order in the order list is signed by a private key of the source exchange for a parameter hash other than the field origin ExAddr. Therefore, it is also necessary for the exchange to select the order to check the signature, if the checking is not passed, the feedback order is invalid, and the cluster service will be updated in the order list. In the service layer, in general, a change in the Topic global version number is broadcast by using the Pub-Sub mode. The so-ed Topic global version number update is a change in the Topic directed any service list or order list, and this Topic version number is incremented. The exchange that receives the subscribed Topic version number changes can request services to the target server.

var pubsub = new PubSub(),
    grab = function(shareOrder) {
        // do something
        putToEx(sharedOrder)
        ...
    };

pubsub.on('orderList', grab);
pubsub.emit('orderList', newOrders);

When the amount of the shared orders is too high, since the service cluster tracks the data of each exchange for a long time and analyzes the log data, we can improve the transaction efficiency by setting high performance nodes in the cluster according to the conclusion in order to actively push orders to the high liquidity exchanges.

img

5.6. Trusted Oracle Set

Because the subjectivity of smart contracts deployed on the Blockchain network is reflected in the access to on-chain data, the off-chain data can only be passively accepted. Therefore, we need a trusted entity——Oracle to complete the input of honest data. The Oracle is a bridge between the Blockchain and the real world. It provides an accurate, immutable, stable and auditable data query interface. A general process of acquiring Out- chain data in a Blockchain system: Smart contracts can obtain and input data from a data source outside the chain at a predetermined time or through an event trigger, and then the smart contract takes a preset action in accordance with the acquired data. However, the realization of the process needs to resolve two key issues: 1) Consensus; 2) Credit Receiver.

The Vena Network uses reputation system and mobile service mechanism to solve the above problems. Firstly, we select N Oracles to form a hybrid network and establish a 1: M relationship between a single Oracle and a data source in the network. Secondly, a reputation system is respectively arranged on the data source and the Oracle, and a double-layer safeguard mechanism is formed for the trust input. Finally, according to the data source and the credit accumulation of the multiple workflow of the Oracle, the mobile service is carried out so as to form forward feedback to improve the efficiency of data query and data input.

img

Both the Oracle network and the data source are dynamic, and it is the basis for realizing the mobile service. Each Oracle contract instance needs to be registered in the Vena Network and populated with target data keywords, fees, margin thresholds, participation thresholds, and so on. When you need to get out-of-chain data, the Vena Network formally tries to match the demand side and the Oracle based on the contract instance content and composes the Oracle network through pledging VENA Token after matching successfully. In the consensus phase, check whether the quantity of Oracles reaching a consensus meets the preset value in the Oracle contract instance, and if it is in conformity, then conduct Data Feed and distribute the bounty; If not, then the Data Feed process is blocked and all Oracles retry the process that has not exceeding the limited K times to obtain data from the data source and the process of the consensus. In the process of retry, Oracle has the right to update the data source and maintain a list of data source credit integration updates to improve the query efficiency. If a consensus cannot be reached after a limited number of K retries, it is dealt with in the following cases:

The pre-set conditions, the number of the Oracle network nodes N, the preset value of the consensus node number C, where C satisfies:

                    

  1. When the number of actual consensus nodes is N/2
  2. When the number of actual consensus nodes is N/3 <=C'<=N/2, all Oracle network nodes lose the reputation point and actively update the list of data source credit integration maintained by itself.
  3. When the number of actual consensus nodes is C'

img

The following describes the attributes that Oracle contracts need to include but are not limited to:

Field Type Description
charge uint64 Service charge, bounty.
deposit uint64 Prevent Oracle Nodes from doing evil.
reputation uint32 The credit threshold for participating in Oracles network.
sourceType string Keywords for reducing search scope and improving query efficiency.eg:"chaindata,UML".
oracleCount uint8 Expected number of Oracle.
agreeCount uint8 The number of Oracle reaching a consensus.
threshold uint32 Comprehensive assessment of Oracle and the list of data sources it maintains.

5.7. Vena Open Source Software

The Vena team will provide but is not limited to the following software in the future:

  • Vena node SDK
  • Debt and trading market DApp
  • Debt and trading market H5 plug-in
  • Jury arbitration software
  • Senario plug-in contract trading software



6. Protocol Safety Analysis

6.1. Fiat Currency Transfer Risk

The asset trading and lending in the Vena Network have realized the conversion between Token and fiat currency. Therefore, it’s a problem that mismatch between the irreversibility of the Blockchain encryption assets transfer and retractability of many methods of fiat currency payment we often considered when performing a transaction. Common payment methods and their transaction reversibility are as follows:

Payment Method Currencies Reversibility of Transactions
PayPal - regular Most world currencies Extremely easy to charge back. Also, since trading bitcoin is against their ToS, good luck disputing the chargeback.
Paypal - personal Most world currencies If funded via bank, requires person to dispute the ACH, which may be more arduous. If funded via credit card, requires person to dispute the CC charge, which is pretty easy. Since there's no way to tell what the funding source was... it's a gamble. Also, if paypal account is reported stolen, paypal will probably attempt to claw back the money.
AliPay / Wechat Pay CNY There are reports of reversed AliPay payments can be found on the Internet.
Dwolla USD Since Dwolla amounts are funded via ACH, Dwolla will now reverse payments if the funds were the result of fraud. Additionally, Dwolla's Terms and Conditions now state that peyments received are subject to chargebacks as the result of their internal dispute resolution process.
Credit / Debit card Any currency Extremely easy to charge back.

In response to this mismatch, the Vena Foundation will make relevant requirements for the payment methods of the fiat currency supported by the Vena nodes, and must choose payment methods with irreversibility of transactions (such as Bank wire, MoneyPak, Webmoney, LavaPay, OKPay, etc) that are compliant with regional laws and regulations, to match the characteristics of Blockchain asset transfer to achieve a broad degree of transactional atomicity and prevent fraud and other risks.

6.2. Oracle Attack

The effective contract operations under the Vena Protocol are reflected to the changes of the global state of Ethereum Blockchain, namely APPLY (S, TX) - > S '. and protocol stack is composed of a set or several sets of stateful contracts, and a non-correct (false data, disorder, etc) input will make the unintended results permanently written into the account books. Input and output with dependence on forward and backward states mean to have orderliness and logical, which put high demands on the robustness of the contract procedure and the correctness of the input. Contract writing needs our careful thinking, good coding habits and detailed audit work. Data input needs to ensure that data source is reliable. In the Vena Network, for data source access and preventing the Oracle nodes from evilly cooperating with each other, we set the application-level consensus, reputation systems, mortgage bond liquidity services and other mechanisms. When the matching demand is to feed prices from the external market, we must consider the fluctuation of prices and the timeliness of transactions. A limited K retries without a consensus among Oracles could become an attack point. We will ensure the security of the system according to multiple factors such as traffic monitoring, design the dynamic adjustment strategy for K value and combine with the processing mode of culling the maximum and minimum data and then taking the mean to feed prices. In addition, for a specific external data input we also set up encryption and decryption Oracles to protect the data and promote the safety of the system.

6.3. Middleman Attack

A middleman attack occurs primarily in the process of communicating between the user and the server. In the Vena Network, there are shared liquidity pools of distributed cluster services and decentralized juror networks. In that cluster of shared liquidity pool, the exchange needs to communicate directly with the service node, in normal case the content is encrypted under the TLS connection, and the third party cannot decrypt even if all the data can be detected. But the third party, that is, the middleman can establish a connection with the exchange, and then the middleman establishes a connection with the service node and forwards the content between them. At this time, the middleman can decrypt and obtain the plaintext information and modify it. If the middleman intercepts a shared order issued by the exchange, forwarding it to the service node after being tampered with will cause a large number of garbage transactions to be filled in the shared liquidity pool, so that other exchanges may acquire a large number of invalid shared orders. Thus, the Vena Foundation will defend against such attacks by issuing certificates to certified cluster nodes based on their DID through DAO. In the juror network, we have adopted the content push-and-pull split design so that the user does not interact directly with the jury network. Instead, the content of the evidence is hashed On-chain and stored through the PageSigner or other methods, and the juror actively reviews the evidence, thus preventing the middleman attack.

6.4. Sybil or Denial of Service Attack

Disguising multiple nodes to perform a malicious activity is a Sybil attack, which causes an attacker to withstand the false data of the multi-party camouflage nodes. A denial of service attack is an attacker trying to stop the target machine from providing services. Sybil and DOS attack models can often be combined. For example, only 20 witch nodes are needed, DOS can completely attack the database of a P2P oracles to take it offline, and can also archive all traffic on the network. There exists a dependency relationship of the security between the Vena Network and the Ethereum Blockchain. One of the purposes of the workload proof in the Ethereum is to make the creation of the block difficult, thereby preventing the witch attacker from malicious re-generating block chains. In the Vena Protocol ecosystem, the jurors, traders, and the shared liquidity pool cluster nodes undergo decentralized identity authentication. There is no attacker who can broadcast multiple identity IDs to the network to act as a plurality of different nodes by only deploying one entity. In addition, the DDOS attacks on shared liquidity pools can be defended with solutions such as spider systems.

It is also worth noting that in the context of mortgage loan, the role of the witch attacker may be played by the lender due to the presence and floating of mortgage loan rate. The intention of the attacker is to use a large number of fraudulent identities to initiate mortgage loan orders according to the mortgage loan rate and the analysis of market conditions. After the transaction, all of them are in default or intentionally overdue to make profits. Vena Protocol at this stage, however, is designed to be secured debt, even if the attack is successful, the gains are minimal. Besides, our requirement is that all the debt/creditors require decentralized identity authentication, so do not have conditions to initiate the witch attack.

6.5. Penny-Spend Attack

Penny-spend attack refers to a waste of node’s storage resources via sending a huge number of small-value transactions or an interest arbitrage strategy for defrauding VENA Token by attackers. Under the mode “Off-Chain Ordering and On-Chain Settlement” based on Vena Protocol, consolidating orders in the preceding settlement of transactions is an effective precautionary measure in case of attack caused by zero-cost discretionary order (In practice, this is a common business mode in tradition centralized transaction). However, the exchange itself probably want to pollute shared liquidity pool via sending a huge number of invalid shared orders; in response, we can trace the source of shared order according to its DID/originExAddr, monitor malicious behavior in the cluster service, and submit application for accreditation disqualification and cash deposit confiscation if malicious behavior is convicted. What’s more, to avoid the situation of gaining VENA Token in exchange via scalping transaction volume, the avoidable measure is verifying the legitimacy of transaction by Ethereum miner due to its commission charge is happened after on-chain settlement.

6.6. Confidence Attack

Confidence attack refers to the attackers’ taking advantage of typical human features such as greed, dishonesty, vanity, opportunism, desire, sympathy, gullibility, irresponsibility, despair and innocence to scam the target. However, the reflection of confidence attacks in the Vena Network is mainly characterized by the fact that an attacker has acquired relevant information of the counterpart, and analyzes the data to learn about its vulnerability. Firstly, the trust cheating is obtained. (An attacker usually establishes a sample database and carries out cluster analysis in order to carry out the attack. After obtaining information, the corresponding attack means can be quickly adopted though only matching with the oracles), and the transaction between the two parties can be completed in the scene which is separated from the Vena Protocol through the guidance mode. In order to protect against such attacks, we require traders to present risk warnings such as "Do not transfer transactions outside the Vena Network” on the provided transaction tools. In addition, in the case of the system itself, we have designed a decentralized identity authentication mechanism with a high degree of privacy protection. It is difficult for an attacker to obtain the target privacy data in the Vena Network. At the same time, we also encourage the users to pay attention to the reasonable maintenance of the weak correlation between their own capital account addresses and the social attribute App, and to promote the self-privacy protection consciousness.

6.7. Code Audit for Smart Contract

Looking back on the DAO event on June 17, 2016, the bug of Parity multi-signature contract on November 6, 2017, and the recent SMT, BEC contract integer overflow vulnerability events, etc., all contributed to financial losses. Without strict code auditing and safety protection, ecological construction becomes a blank paper. Therefore, all contract codes of the Vena Network will be reviewed and fully tested through professional smart contract security audit institutions and the test report and related materials will also be submitted.

In view of the upgrade of the protocol, some components of the Vena Network are likely to be built on the Zeppelin_OS. Zeppelin_OS is a decentralised platform for securely building and managing a smart contract application for EVM ecosystem. It is equipped with a security mechanism to manage and upgrade the contract code, while also providing a toolbox for attack response to prevent attacks. When an attack is encountered, Zeppelin_OS will be triggered an emergency pause to recover to the previously unaffected state.

We believe that a series of rigorous and detailed research and development work will be able to protect the ecological construction road of the Vena Network.



7. Market Analysis

7.1. The Present Market Situation of Cryptocurrency

According to CoinMarketCap’s research, in September 2017, the average daily trading volume of the cryptocurrency has exceeded $4 billion, and the total market value of the cryptocurrency market has exceeded $13 billion. However, the cryptocurrency market is still small compared with the global legal currency transactions. For example, the trading volume of the global foreign exchange market assessed by the BIS is $5.1 trillion. It is probable that the similar trading volume with the foreign exchange market will be achieved within the next three years according to the current growth rate of the cryptocurrency. Because we will soon live in a reality dominated by digital currency.

In terms of market response and data, the cryptocurrency market in 2017 has reached the size that the government cannot ignore. As a result, an increasing number of countries will recognize the cryptocurrency and carry out relevant regulations and legislation. It is clear that the cryptocurrency has a huge potential of development in the future.

7.2. Attitudes from Countries about Blockchain

In general, most countries hold a welcome attitude towards cryptocurrency and Blockchain technologies, and attempt to promote the application of cryptocurrency and to explore and innovate technology:

  • China: Although China is currently keeping a conservative attitude towards the exchange of cryptocurrency, it has never stopped the research of the underlying technology of the Blockchain at the government level.

In February, 2016, Zhou Xiaochuan, the central bank governor of China, stated that the digital currency must be issued by the central bank, and the Blockchain has become an optional technology for the development of digital currency.

In December, 2016, the country put the Blockchain in the 13th National Five-Year Informatization Plan.

In October, 2016, the MIIT released the 2016 China Blockchain Technology and Application Development White Paper.

In September, 2017, ICO is an unauthorized illegal public financing act, which jointly determined by the People's Bank of China and other seven ministries. It is suspected of illegally selling token tickets, illegally issuing securities, and illegally raising funds, financial fraud and pyramid schemes.

  • Russia: Russia's attitude is more complex, and Russia has banned citizens from holding and trading Bitcoin, but it's very popular for Blockchain technology.

In June, 2017, Russian President Vladimir Putin met the founder of the Ethereum, Vitalik Buterin.

In August, 2017, Russia's National Development Bank o and the Ethereum Foundation have reached strategic cooperation.

  • South Korea: South Korea is supporting the Blockchain at present, and has strengthened supervision over digital assets such as Bitcoin and Ethereum.

In February, 2016, South Korea's Central Bank proposed to encourage exploration of Blockchain technology in the report.

In September, 2017, South Korea FSC announced how to regulate digital currencies, such as Bitcoin and ether. South Korea has stepped up its regulation to investigate illegal trade in money-laundering, illicit financing and other digital currencies.

  • India: India, as a country with great population and powerful software development, has always attached importance to the application of Blockchain technology.

In January, 2017, India's Central Bank issued a comprehensive Blockchain white paper, arguing that the time for the Blockchain to launch digital currencies in India was ripe.

In June, 2017, the Government Committee of India announced its support for the establishment of a dedicated task group to regulate Bitcoin, and the creation of regulatory framework plans to fully complete the legalization of Bitcoin in a short time.

  • Australia: Australia pays more attention to the application of Blockchain technology and the formulation of standards.

In April, 2016, Australian Bureau of Standards ed for the formulation of global ISO Blockchain standards.

In March 2017, the Australian National Bureau of Standards issued a route map for the development of conceptual standards for the international community in line with the tasks assigned by ISO.

In August, 2017, Australian Government announced the incorporation of digital currencies and exchanges in the regulation of Australia Transaction Data Analysis Center. The Australian stock exchanges and other institutions are using Blockchain technology to conduct transactions.

  • UK: Britain is the first country in Europe to conduct research and validation of the Blockchain.

On January 19, 2016, the UK government took the lead in publishing the 88-page white paper Distributed Ledger Technology: Beyond the Blockchain, while actively assessing the potential of Blockchain technology, considering that it will be used in the field of reducing financial fraud and reducing costs.

In March, 2016, ECB publicly announced in this consulting report The future vision of the euro system —— The future of European financial market infrastructure that it is exploring ways to use Blockchain technology for its own use.

  • Netherlands: The Dutch Central Bank issued a view that Blockchain technology could improve its financial business quality.

In September, 2016, a Blockchain park was established in the Netherlands, and banks and financial companies were cooperating to develop the application of Blockchain technology in the field of payment and general finance.

  • Germany: Germany will seize the opportunity and meet the challenges under the new situation of the Blockchain.

In November, 2016, Deutsche Bundesbank and Frankfurt School of Financial Management jointly convened a conference of Blockchain technology opportunities and challenges. The main purpose of the conference is to research the potential application of distributed Ledger, including cross-border payment, cross-bank transfers and the storage of trade data, etc.

  • USA: USA supports the development of Blockchain through legislation.

In June, 2014, the governor of California, USA, signed a legal document numbered AB129 to protect the legalization of the California Bitcoin and other digital currency transactions.

In June, 2016, and USA Department of Homeland Security subsidized six development companies that are dedicated to government management applications.

In February, 2017, Arizona, USA, passed Blockchain Signature and Smart Contract Legitimacy Act. In the same month, ONC, the USA healthcare department, was developing a marathon using health-care hackers to apply Blockchain technology to health care. The USA Congress announced the establishment of the Congress Blockchain decision-making committee and recognized the potential of Blockchain and ed for the application of Blockchain technology in the public sector, while attitudes towards Bitcoin, USA were also encouraged to invest and enforce strict supervision.

In July, 2017, the SEC determined that the Ethereum token belongs to the securities, and the issuer shall handle the registration of securities issuance in accordance with the law. In the same month, the CFTC approved LedgerX to provide a liquidation service with an option and derivatives linked to the cryptocurrency market.

  • Japan: Japan has a very positive attitude. Japan's Central Bank is trying some Blockchain projects, which is largely based on the application of digital assets such as Bitcoin.

In March, 2016, the Japanese Cabinet voted for Bitcoin and digital currency as digital equivalent currencies.

On April 1, 2017, Japan implemented The Payment Services Act and formally recognized that Bitcoin is a legal means of payment and provides clear regulatory requirements for the digital asset exchanges.

In July, 2017, Japan's new consumption tax officially took effect, and Bitcoin transactions would no longer need to pay 8% consumption tax.

  • Singapore: Singapore is a fertile soil for Blockchain. The country’s Prime Minister, Li Xianlong, publicly urged the Singapore financial sectors to keep pace with the development of Blockchain technology. As a result, Singapore is far more open to regulatory policies of Blockchain securities financial innovation than other Asian countries.

In June,2016, Singapore's Monetary Authority, has launched Sandbox mechanism, which allows the business to be engaged in conflict with existing laws and regulations as long as any financial science and technology company registered under the law has been reported in advance, even if the related business is later officially terminated, the relevant legal responsibilities are not pursued.. Through this Sandbox mechanism, the Singapore government is able to encourage enterprises to carry out various financial innovation of Blockchain within a controlled range.

According to the above analysis, the Vena team will strictly abide by the relevant policies and regulations of all countries in the world when issuing tokens in the future, and begin to develop from Singapore with relatively open digital monetary policy to other countries.

img

7.3. SWOT Analysis

img



8. Roadmap

img

Numeral 2018.Q2 Official launch of white paper & Vena Network website
Proof of concept & launch development
Community building in countries including the United States of America, China, Canada, Australia, Russia, etc.
Shape 2018.Q3 Launch public sale
VENA Token is listed in exchange
Open to application for dealers
Pythagorean 2018.Q4 open source SDK of Vena Network is available in github
Pilot run of official exchange and operation simulation
Vena 1.0 release
First dealer introduction
Harmony 2019.Q1 Vena 1.1 release
Fully develop the ecosystem, start the city partner program, and introduce 20+ dealers
2019.Q2 Vena 2.0 release
Accelerate the expansion of global business, Introduce 50+ dealers"



9. Team Introduction

  • CEO: Ching Zhu

Ching Zhu, a gainer of the Honors Outstanding Students from UESTC, is the founder of the ChainBoard Technology. Ching held the post of technical director of a famous fintech company ICE KREDIT in charging of designing and leading the R&D for integrated platform of risk management and big data-based credit platform. She has accumulated rich experience in the design of credit investigation and financial risk management on internet and the R&D for architecture design of microservice system. In 2016, Ching began to lead the team to master and successfully developed the blockchain-based industry application, and participate in the operation of the Blockchain project in a listed company. She has served as a special technical consultant to provide consultation service on architecture and design to a number of listed companies and has served as a lecturer to share keynote speeches at several well-known technical forums.

  • CTO: Jeremy Lan

Jeremy Lan, a senior Blockchain engineer, is the co-founder and CTO of Hardrole. He is interested in logic and strategic research and is abundant with experience in internet practice and deep technical insight. Jeremy has held the post of principal of a well-known artificial intelligence company Hiscene in charging of cloud architecture design and product development. With years of striving in the blockchain field, Jeremy is familiar with the underlying technology of Blockchain, multi-currency digital wallet and exchange, as well as all kinds of safety protection. In addition, Jeremy is also a member of Core Team participating in Metaverse Blockchain. Currently, he commit himself to actively explore and solve problems in projects, such as scalability of Blockchain and the ordering scheme of DAG partial sequence network.

  • Operation Director: May Du

May Du, master in Finance of Nanyang Technological University, bachelor of China XIAMEN University. And she has rich experience in entrepreneurship. Achieved her first venture capital exit by founding SATORI BCC PTE. LTD. In 2017, stepped in as CEO and sold out the shares to SETTING IT in 2018. Now leading a highly professional team to provide one-stop in-house operational support to global technology companies, especially blockchain startups.

  • CSO: Yuanfei Zhu

Yuanfei Zhu, recommend him for admission to Shanghai Jiao Tong University as one of top students majoring in computer science and technology with excellent performance in the computer/physics competition during his senior high school. He has founded Moregg during his suspension of schooling, and thus gained a lot of achievements from nothing to something while achieving outstanding result. After his graduation, he mainly engaged in the work of algorithm for big data in situations of online advertising, marketing and security and for machine learning in Silicon Valley, and and is abundant with rich experience in data analysis and operation experience at Yahoo. Since participating in Blockchain project development in 2016 as an early developer of Ethereum, he has pursued the bottom technology of the Blockchain and has participated in the high-performance exchange architecture design, operated the ico delegated investment platform Beico, and successfully completed a series of smart contracts-based projects such as ENS. In 2017, he established Satori in Singapore and managing a professional team providing world-class services such as overseas compliance for funds and foundations. The partners have served and estanlished cooperative relationship with IOST, ZJL, TNC, etc.

  • Bussiness Director: Zed Zhao

Zed Zhao, graduated from UESTC. He previously worked as project manager In CETC, led the whole process of building encrypted platform and cyber security system for Armed Police. And He was in charge of the national cloud computing encrypted application white paper, Sichuan Provincial Government Cloud and Yunnan Cloud project which worth over 500 million RMB. Currently Zed focus on product research and market operation in the blockchain field.

  • Product Director: Yoki Wang

Yoki Wang, graduated from UESTC. She has rich experience in the Internet industry and previously worked for well-known Internet companies, eg. NetEase, Inc. (NASDAQ: NTES), etc. the product she engaged in has more than 100 million users.Yoki is familiar with the user analysis of PC and mobile products, good at front-end and back-end product design, 2B2C product design, rich experience in project design and data analysis, previously engaged in product management of more than 10 products.

  • Overseas Market Manager: Amira Zhou

Amira Zhou, practitioner with seven-year experience in business negotiation and project management in overseas markets, once held the post of the principal in charging of overseas market business in a well-known vehicle networking company Dina Technology. Her contribution in achieving cooperation with ten million level operator in Malaysia has created a pioneer practice that domestic vehicle networking companies provide overseas operators with integrated solutions including the car networking big data platform and hardware. Also, she has held the post of a senior English interpreter serving as a simultaneous interpreter at the Shanghai G20 Finance Ministers' Meeting. Currently, she focuses on industry research and market operations related with cryptocurrency investment and Blockchain based on her extensive experience in overseas business and project operations.



10. Advisors

  • Benjamin Gu

Benjamin Gu, mmaster on business administration from University of Texas, master from University of Notre Dame, master of China University of Science and Technology, and bachelor of Shandong University. Benjamin is currently holding the posts of chief strategy officer and Chairman of the foundation of DAEX. He has held the post of Deputy Chief Information Technology Officer of Huatai United Securities and Chief Operating Officer of several financial services companies. He has accumulated rich working experience in senior management and R&D in the well-known Internet finance companies in both China and the United States. Also, Benjamin previously held a post of principal in charging of the development and operation of ENCORE, sole clearing system for the US options trading market in the U.S. Options Clearing Company.

  • Yang Zhao

Yang Zhao, ex-president of E Surfing Credit Investigation of China Telecom, is currently holding the post of Chief Operating Officer of Shanghai Xinyan Credit Investigation Service Co., Ltd. Zhao has accumulated years’ experience in applying data from telecom operators to credit investigation and risk management. Now, he is leading a professional team to co-establish Xinyan concentrating on big data-based credit investigation. With their professional products and high quality services, Xinyan has thrived in the market.

  • Yongchao Zhai

    Chief Architect of Yonghui Yunchuang, founder of SpringCloud Chinese Community (bbs.springcloud.com.cn), and joint initiator of Spring4All community (spring4all.com). Having obtained Master’s degree from Donghua University, he is author of “Spring Cloud Microservice Practice”, who is fully devoted to the Java ecosystem and distributed system. Mr. Zhai is mainly in charge of the implementation of microservice architecture based on Spring Cloud and is the early evangelist of Spring Boot/Spring Cloud. He is an expert in various technology stacks including Java backend, microservice architecture, operation and maintenance development, system monitoring and blockchain, and is active in online and offline technical communities for relevant research and knowledge sharing.



11. References

[1] W3C. JSON-LD 1.0, https://www.w3.org/TR/json-ld/, 2014.
[2] Jorge Izquierdo. The new operating system for protocols and DApps, https://blog.aragon.one/introducing-aragonos-3-0-alpha-the-new-operating-system-for-protocols-and-dapps-348f7ac92cff, 2018.
[3] BitcoinWiki. Payment methods, https://en.bitcoin.it/wiki/Payment_methods, 2016.
[4] Joseph Poon, Thaddeus Dryja. The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments, 2016.
[5] Vitalik Buterin. A Next-Generation Smart Contract and Decentralized Application Platform, https://github.com/ethereum/wiki/wiki/White-Paper, 2014.
[6] Nadav Hollander. Dharma: A Generic Protocol for Tokenized Debt Issuance, https://whitepaper.dharma.io/, 2017.
[7] Vitalik Buterin. On Medium-of-Exchange Token Valuations, https://vitalik.ca/general/2017/10/17/moe.html, 2017.
[8] Conner Fromknecht. Connecting Blockchains: Instant Cross-Chain Transactions On Lightning, https://blog.lightning.engineering/announcement/2017/11/16/ln-swap.html, 2017.
[9] Alex Evans. On Value, Velocity and Monetary Theory, https://medium.com/blockchannel/on-value-velocity-and-monetary-theory-a-new-approach-to-cryptoasset-valuations-32c9b22e3b6f, 2018.
[10] Matus Lestan, Joe Urgo, Alexander Khoriaty. district0x Network: A cooperative of decentralized marketplaces and communities, 2017.
[11] Shiliang Huang. Refusal of payment arbitrage attack -- An attack technique in OTC transactions and precautions for it, https://mp.weixin.qq.com/s?__biz=MzIxNTA0NDQzMA==&mid=2651798518&idx=1&sn=4e91bac98cea5bc600e8429f1af3a728, 2017.
[12] RSK Labs. Sidechains, Drivechains, and RSK 2-Way peg Design, https://www.rsk.co/blog/sidechains-drivechains-and-rsk-2-way-peg-design, 2017.

results matching ""

    No results matching ""