Paul Protocol Whitepaper

V1.0

PAUL PROTOCOL

A Double-Mechanism Risk Resistant Oracle with Superior Performance and Timeliness

1. INTRODUCTION

1.1 Industry Background

Blockchain is the perfect medium for constant storage, information recording and command execution. However, on-chain networks cannot interact with trusted information spontaneously without assistance from external nodes. An oracle is just working as the decentralized bridge between blockchain and trusted information. It submits validated data and information to decentralized applications, thereby allowing smart contracts to give response to external environment. In this way, blockchain can interact with real world with no boundaries.

Since July 2020, as different DEX such as Uniswap and Sushiswap developed increasingly fast, together with the prosperity of the overall supporting ecosystem, DeFi has quickly become the absolute trending topic in the investment market. All financial products are trying their best to look for their decentralized alternative solutions. Under this background, the on-chain derivatives trading has become an inevitable trend. However, restricted by the low efficiency, poor timeliness and high gas of existing oracle solutions in the market, derivatives trading can only be carried out with strict limitations currently. The market demand for blockchain oracles that have higher performance and stronger stability is increasing exponentially and has never been as high as today. Therefore, we decide to design and develop a new oracle protocol that has strong usability, high performance and supports cross-chain interactions, so that it can provide organic soil to the DeFi industry which supports upgraded complexity and diversity of Dapps.

1.2 Design Ideas

We designed our foundational architecture based on the current cross-chain networks. It has introduced and modified based on the quoting system used by global top organizations in high-frequency automatic trading for single benchmark in multiple trading scenarios. Meanwhile, it uses pledged asset quoting and arbitrage validation to build its real-time quoting validation mechanism. In extreme situations, a relatively smooth price curve can be generated to predict the price fluctuation within small timeframe through statistical hypothesis-testing. In a market cycle, the quotes achieved in this way have higher practical value and effectiveness compared with existing oracle solutions, which can be better referenced by different Dapps. In terms of what kind of market data can be considered to be authentic and valid, we believe that only the market can determine the authenticity of the data. If a quote can be easily accepted by arbitragers from an off-chain centralized market, that means the current price error is still significant and the quote should not be adopted; otherwise the effectiveness of the data can be totally proven.

2. PAUL ORACLE PRODUCT INTRODUCTION

2.1 Role Definition of Paul

The overall logic of Paul Oracle can be referred to the following diagram:

Its ecosystem consists of the following parts:

Data Providers:

All participants that contribute to the final quotes in the protocol, including:

Role	Responsibilities
Quoter	Quoters provide the initial price data through the process called quoting mining and then receive Paul Token as reward.
Validator	Validators are responsible for validate the effectiveness of the quotes provided by quoters.
Sword Man	In extreme situations, Sword Men provide elastic data for the stable running of Paul Oracle.

Data Requestors:

All parties who request the quotes provided by Paul Protocol and pay for the data are regarded as Data Requestors in the ecosystem. They might be smart contracts or blockchain accounts, which normally are different kinds of Dapps. We use C to represent the sum of all data requestors.

All participants can apply to become one of the four roles if they meet the eligibility standards, but can only work as one role at one time.

2.2 Price Validation Mechanism

In the oracle design, the topic that is of vital importance for an oracle is how to effectively encourage quoters through a scientific rewards-and-punishments system to continuously conduct data capture. Looking back the entire history of digital asset market, it is not hard to conclude that the best solution to the price validation in an on-chain-delayed situation is to let market itself to evaluate the accuracy of the quote. For this reason, we introduced the role of Validator to supervise the work of quoters.

From the moment when quoters submit a new quote to the smart contract, there is a validation period $T_0$. It determines quoters’ prediction period and the sensitivity level of price. After the validation period, quote that has not reached a deal in the market will be upgraded to be a valid quote, which will thereafter form the block price. Quotes that have reached deals in the market during the validation period will not be finally taken. If a part of a quote reached deals, then the remaining part will still be regarded as valid quote. Only after the validation period, the pledged assets of the quoter can be claimed back.

Validation period has certain of impact on the quoting cost and the quoting accuracy. The longer the period is, the more difficult it is to predict the future’s price. According to the current demand level and volatility of the current market, it is all reasonable to set $T_0$ as 60s or 30s. Please note that, when a quote survives throughout a validation period, it means that there is no enough arbitrage space between this price and the fair price of the market (the minimum arbitrage space is determined by both and trading cost). Therefore it is indefinitely closed to the actual current price and the period is not a manifestation of price delay.

In essence, quoters provide an option that allows buying long or short and the quote is just the execution price of the option. On the other hand, validators are the representatives of the real market and are responsible for the market-driven adjustment of the quote. With this mechanism, it ensures that the quote is either the fair price of the market or an effective price that are widely recognized by validators within the validation period. Therefore, in order to minimize the quoting cost, quoters need to try their best to provide quotes that are as closed to the market trend in the validation period. This means the quotes given by quoters can strongly resonate with the upcoming price trend. For validators, whether conduct arbitrage behavior (execute the option) or not depends on whether the gap between the quote and the market fair price can cover their cost. We call the smallest gap that leads validators to conduct arbitrage behavior the minimum arbitrage space, which is affected by the length of validation period and the trading cost.

2.3 Quoting Mining

In the entire quoting process, when quoters confirm the quoting benchmark, they should firstly submit a Quoting Form (s, r, x).

In the form, ‘s’ represents which trading pair the quote is for (eg. DOT-ETH). ‘r’ represents the exchange rate of the quote while ‘x’ stands for the asset scale that the quoter is willing to pledge.

After a quoting form successfully becomes a block price, the mining procedures will be officially triggered. Certain amount of Paul Token will be rewarded according to the pledged asset scale of the quoting form. The detailed rules of the mining rewards will be collectively decided upon community voting governance after the official launch.

2.4 Quoting Responsibility Chain-Risk Resistance Mechanism

When a validator decides to conduct arbitrage action, he/she must provide a new quote instead (a validator burns a quote and generates a new quote, becoming the new quoter) and submit it with the arbitrage request together to the smart contract.

Considering some extreme situations, malicious parties try to put the oracle into the indefinite cycle of quoting responsibility chain and deprive the quoting ability from the oracle. To confront with this, a fixed rate λ value is introduced. Assuming the scale of the substitute quoting form provided by validator is $x_{i+1}$, this scale should be λ times of the scale of last quoting form, which means

$$xi+1=λxi (λ>1.5)$$

For example, if there are 5 times of malicious trading that have happened, then assets in a scale that is $(λ5-1)$ times larger than the initial scale have to be pledged to achieve the 6th quoting, which is $x6=(λ5-1) x1$ . Under this policy, it is impossible for any malicious intruders to have enough pledged asset to continually manipulate the price.

2.5 Valid Quote

The prices generated by Paul Oracle are recorded period by period. Generally, a new price will be generated after every $T_0$. A block price, also called Paul-Price, is created with specific algorithm based on the new quote and the previous time sequence.

Assuming the valid quote in a specific time period is $[r1, r2, r3•••rn]$ and the corresponding pledged asset scale is $[x1, x2, x3……xn]$, then the block price is:

$R_m=\sum_{i=1}^{n}{r_ix_i}$

$X_m=\sum_{i=1}^{n}{x_i}$

$R_p=R_m/X_m$

If there is no valid quote in this time period, the previous block price will be used. The valid quote is upgraded to valid deal quote after a round of data processing, so that is can be officially requested by clients.

2.6 Effective Deal Quote and Hypothesis Testing

If there are no new valid quotes generated for three successive validation periods, then the protocol will judge that the price validation mechanism already cannot respond accurately to the market change and the Mechanism B will be triggered automatically. An effective deal quote will be calculated according to the deal quote in the previous time period and its effectiveness will be assessed by the method of hypothesis testing.

Setup C Distribution Form:

A number of guard nodes are in place for Paul Oracle. Guard nodes are determined one week before official launch according to the pledged volume of Paul Token. When the night watch procedures are started, these guard nodes will respectively grab a set of time sequence data for a deal price from several authoritative off-chain data sources. Pretreatment will be arranged for the time sequence data, followed by the validation for its smoothness and randomness and a series of technical processing including sequence correlation, heteroscedasticity, multiple collinearity, etc. Finally, a distributed statistics table of the reasonable flag price will be created according to the statistical prediction algorithm, which is called C distribution. C distribution will be the important evaluation criterion for the effective deal price. Every guard node will provide a C distribution form for a specific period of time and submit it to the smart contract.

Paul Oracle will firstly collect the C distribution data sent by guard nodes as the total sample. The earnings of guard nodes will be distributed separately according to their proportion in the total weekly revenue of all general quoters. In brief, what Paul Oracle is recording is the reasonable flag price x in every 5 second t, and the nodes quantity n that provide quotes. Therefore, within the period of , the reasonable flag price of different nodes is:

x_(i,k),i=1⋯n,x ̅=(\sum_{i=1}^{n}{x_(i,k)})/n

It is the average of all the samples of reasonable flag price collected by Paul Oracle within $t_k$.

Among which,

s=\sqrt((\sum_{i=1}^{n}({X_(i,k)-x_k ̅})^2 )/n)

is the standard deviation of all the samples collected by Paul Oracle while n is the number of samples. Therefore, within the period of $t_k$, when the sample volume is n, the evaluation statistical volume $c_(n,k)$ is:

c_(n,k)=(x_(n,k) ̅-μ_(n，k))/(σ_x/\sqrt[]{n} )

$μ_(n，k)$ is the reasonable flag price within the period of $t_k$

With the format indicated above, we can filter the sample volume n by controlling the degree of freedom. Different evaluation values for different sample volume in different time periods can be calculated in this way, so that Paul Oracle can setup its full C distribution system through the large-scale statistics method.

Hypothesis Testing: When calculating reasonable deal price, Paul Oracle will firstly have a routine assumption that $μ=μ_0$ can be used as a reasonable flag price. About the capture of $μ_0$, because the C distribution system built by Paul Oracle will analyze the referenceability of $μ$ provided by different nodes according to previous deal data, the selecting of $μ_0$will also strictly comply with the priority, or weight, of the $μ$.

1) Sample capture: Samples captured by Paul Oracle will be strictly filtered by normal distribution accordingly.

2) Determine the significance level: It is the basis for Paul Oracle to verify whether the hypothesis is true or not. The value will be affected by the sample volume and the degree of freedom, which we call type one risks. Generally its value is constant and determined by the degree of freedom of the samples. It equals 0.05 or 0.1 in most cases.

3) Determine deny domain: After the significance level is determined, the deny domain can be calculated according to evaluation statistics volume. Deny domain is a domain segmented based on the original hypothesis. When the statistics volume of the selected sample volume drop in to this domain, the original hypothesis can be rejected.

4) Determine evaluation statistics volume: the statistics volume for this evaluation is

c_0=(x ̅-μ_0)/(σ_x/\sqrt[]{n} )

among which x ̅ is the average of all samples of reasonable flag price. $σ_x$ is the standard deviation of selected samples, while n is the sample volume.

5) Judge based on sample statistics volume: When deny domain is confirmed, the next step is to calculate the evaluation statistics volume of the sample. If this value drops in the deny domain, the original hypothesis is denied and the system goes to the alternative hypothesis; if the value is out of the deny domain, then the evidence for denying the original hypothesis is not sufficient but it does not mean that the original hypothesis has been fully accepted.

6） Transform statistical results into actual results: If the evaluation statistics volume does not drop into the deny domain, then the quote can be regarded as the effective deal quote and can be utilized officially as the reasonable data, otherwise we need to select new value according to their weights based on the C distribution form and conduct hypothesis testing again.

Therefore, the prices of Paul Oracle are determined by two mechanisms collectively: Valid Quote and Effective Deal Quote. The double-mechanism design can effectively ensure the timeliness and usability of Paul-Price all day long.

2.7 Price Sequence and Fluctuation Rate

Every time period will have a corresponding Paul-Price and then it forms a price-related time sequence. Using this time sequence, specific data can be generated, which includes:

A. Moving smooth price is provided for public requests from DeFi, which includes the moving smooth prices of N successive time periods,

$EMA_i=α*r_i+(1-α)*EMA_(i-1),α=2/(N+1)$

or the weighted average price $R_p$ of N successive blocks works as the valid quote.

$R_m=\sum_{i=1}^{n}{r_iy}$

$X_m=\sum_{i=1}^{n}{x_i}$

$R_p=R_m/X_m$

B. Fluctuation rate should be provided for the public requests from various derivatives DeFi, such as the dynamic fluctuation rate for 50 consecutive quotes or different customized fluctuation rate of DeFi.

C. Other statistics values

2.8 Competitive Advantages of Paul Oracle

In comparison with the existing oracles in the market, Paul Oracle has its unique strengths and competitive advantages.

Compared with aggregation oracle and traditional oracle:

One of the typical oracles is Chainlink, which is also the one with the highest market value and largest market share in the current oracle market. Its decentralization mainly relies on its token economy and trust system. Transactions are necessary for the trigger of its oracle system. Nodes are responsible for uploading price and it will be validated by voting. The major drawback of Chainlink is that all voting is conducted on blockchain, which will cause excessive gas consumption. Other traditional oracles, such as DOS, Tellor and Band, basically follow the common logic that data is collected off-chain while validation is carried out on-chain. The core issue of these oracles is that their validation process is dependent on third party, which is vulnerable to external attacks.

The biggest advantage of Paul Oracle is that it can provide the quote in a superior timely manner and at a very low gas cost. The process is driven by the decentralized asset validation. Because of the existence of λ value, to compromise the Paul Oracle system, hackers need to bear almost infinite cost, which is apparently impossible.

Compared with similar type of arbitrage validation oracles:

Currently, a few oracles are following the similar logic, using valid quote as its primary data. Nest Protocol is the typical example. However, it takes more than 25 ETH blocks to confirm a valid quote (5-10 minutes), which leads to a series of problem:

1) When the market is experiencing strong one-directional trend (which is very common in the past few months), the mechanism of Nest will break down because the quoting has been updated again and again but it cannot be upgraded to a valid one. Its oracle price cannot be updated for a long time as a result.

2) It costs high gas fee to make a quote, which make the minimum arbitrage space is visible. For those financial services that are extremely sensitive to the price precision, it is difficult to refer to the Nest quote. For those miners who participate in the quoting process, if their quotes end up with failures for multiple times due to unexpected deals, their overall cost may be higher than their revenue. There are no necessary mechanism that can effectively protect the benefits and willingness of quoters.

Compared with Nest, Paul Oracle has the following advantages:

a) More sensitive price index (the price confirmation speed is increased by 5-10 times)

b) Price is more precise (the minimum arbitrage space is controlled to a very low level)

c) Resistant to extreme market situations (Double-mechanism to ensure its stable processing)

d) Benefits of quoters are protected (Valid quote and effective deal are both eligible for rewarding)

3. PAUL PROTOCOL ECOSYSTEM

3.1 Token Issuance

Paul Token (PAUL) is the governance token of Paul Protocol. Its total supply is 10,000,000,000. Token distribution is shown as follows:

A. Public Sale --- 3.5%

Used for IDO event and project activation

B. Liquidity Mining --- 30%

Liquidity incentives for early stage. Vested in 36 months.

C. Quoter Rewards --- 54.5%

To reward the ecosystem members that provide valid quote and effective deal quote. Vested in 36 months.

D. Community Governance Fund --- 12%

Used for the initiation of early-stage project liquidity and event incentives

3.2 Token Value

In this ecosystem, every role can receive the reward that they deserve.

Quoters:

1. Quoting Fee: quoters need to pay certain quoting form fee when submitting quotes.

2. Valid Quote Reward: When a quoter’s quoting form is upgraded to be valid, he/she will receive Paul Token as reward for the quoting mining.

3. Effective Deal Quote Reward: When a quoter’s quote is validated to be effective deal price by hypothesis testing, Paul Token will be distributed as reward.

Validator:

1. Arbitrage: Profit can be reaped when deal is reached with a lagging quote.

2. Effective Deal Price: When validators’ deal price is proven to be effective by hypothesis testing, they will earn the reward in Paul Token.

Sword Man:

Sword Men will earn Paul Token reward when they successfully provide off-chain data and help to prove the effective deal quote by hypothesis testing.

Data Requesters:

Fees need to be paid when requesting Paul-Price.

Paul Token Deflation Mechanism:

There is an asset pool prepared for the deflation-burn up of Paul Token. The capital sources of the fund include:

Source 1: Fee paid by quoters during the quoting mining process. Quoters need to pay fees when participate in the quoting procedures, which will finally flow to the system asset pool.

Source 2: The value generated by Paul-Price. When DeFi products request Paul-Price, they need to pay for the service of Paul Protocol, which will finally flow to the system asset pool.

Profit Leveling Mechanism: The system will take 10% from the periodic asset pool (usually by week) and save it to the leveling smart contract. The remaining 90% will be deposited to the liquidity pool of DEX to buy back Paul Token and burn it up. Assets in leveling smart contract will be saved for long term to get ready for the case that the profit in some periods is inadequate. This mechanism ensures that the supply of Paul Token will be deflated continuously and the token value can be consolidated. This is beneficial to the stability and sustainability of Paul ecosystem.

For every participant in Paul Protocol ecosystem, the overall value is far beyond its overall cost. Its value is strongly supported by the ever-growing DeFi ecosystem.

3.3 Governance Solution

As we know, no system architecture is perfect from its beginning, even if it is Bitcoin. Paul Protocol still needs to be optimized and upgrade continuously, to ensure its security, scalability, openness and decentralization. In this process, we need an autonomy organization to guide and drive the development of Paul Protocol. We call the organization Paul DAO.

In essence, Paul DAO is an on-chain governance system. To start, any wallet addresses that hold Paul Token will naturally have the voting rights to join the Paul voting. The voting system itself is a smart contract. To initiate a new voting event, the initiator needs to deploy a new voting smart contract. The voting smart contract should be open source and the voting content should be explained clearly. To encourage PAUL holders to participate in the voting, the initiators can deposit some Paul Token into the voting smart contract as deflation incentives. If the voting plan is approved, the deposited Paul Token will be burnt up while if not approved, the initiator (contract deployer) can get the tokens back.

Paul Token holders can make their own judgment and decision after carefully reading the voting smart contract code and voting content (vote as support; give up as not support). When voted Paul Token volume exceeds 51% of the circulating volume, the voting will be considered officially approved. After that, everyone can trigger the voting smart contract and execute the content described in the contract.

Advantages of governance by DAO:

1. Coordinate resources under the situation that members do not know each other

2. Make the contributions of different stakeholders match with the overall objectives

3. Operate the organization in a way that is consensus proof

4. Track and verify the participation and contribution of voters

5. Give convenience to contributions from different levels

6. Allow individuals and enterprises to contribute to the project without concerns on their jurisdictions.

7. More flexible organizational structure compared with traditional organizations