4.2 Architecture and technology

1xBinary architecture is based on two major parts:

▸ Smart contract systems (to ensure transparency of bets).

▸ An oracle providing the reliable data on occurring events to a smart contract (in particular, exchange rates).

SMART CONTRACTS ARCHITECTURE

Main purpose of smart contracts is ensuring a transparent betting mechanism for the common pool of liquidity. Smart contracts were built under the following restrictions:

▸ The bet occurs by the means of transferring the SBT token into a common liquidity pool for a given event in the system;

▸ The network commission (Ethereum) should be as small as possible;

▸ Reward payout (including the transfer of the commission) is realized by a smart contract based on the data received from the oracle.

The architectural system is based on the following smart contracts:

▸ SBT token contract complies with ERC-20 standard. SBT is a stable (relatively to the USD rate) token, the exchange rate of which is artificially maintained, with emissions and burning made during the exchange operations.

▸ Exchange contract is a smart contract for automatic exchange of ETH to SBT and vice versa. ETH/SBT rate is regularly updated with an oracle and artificially maintained at 1:1 / USD level. When crediting ETH, the required amount of SBT is being emitted. When withdrawing ETH, a corresponding amount of SBT tokens is being burned.

▸ It is also planned to implement time restrictions on the token use. If the token is not used in the 1xBinary system for a certain period of time, it is automatically exchanged back to the ETH source address. This may prevent speculation with tokens.

▸ 1xBinary smart contract is a management system for liquidity pools (betting baskets). It accepts bids by moving SBT to a specific pool (basket) for a limited period of time. After the waiting time has expired, the payout is redistributed among the players based on the oracle data.

▸ Commission smart contract is the contract-aggregator of commission fees. It charges the entire commission from operations in the system. The distribution of the commission is made by this contract once in a certain period of time (currently, once in 24 hours).

▸ Referral smart contract is contract managing the referral program. 1xBinary supports a single level referral program and redistributes part of the commission to the referral addresses. This smart contract stores the necessary dependencies. The implementation of smart contracts is carried out considering all modern practices and approaches, including the overflow checks, 100% test coverage and statistical control of Gas used. MANAGEMENT OF LIQUIDITY POOLS. POOL‟S LIFECYCLE. Each pool of liquidity (basket) in the 1xBinary system has following time characteristics:

▹ Time for bet placements;

▹ Waiting time for exit; These time intervals are limited by:

▹ The moment of opening;

▹ The moment of closing;

▹ The moment of payment; From the point of view of a smart contract, each of these moments is implemented using a special system transaction.

The problem here is the uncontrolled time of the transaction (from the time it hits the Tx pool to the time it was confirmed), as well as the allowable deviation of the system variable (solidity block. Timestamp) in 900 seconds compared to the real time.

The lifecycle of a pool includes the following:

▹ Opening/creating a pool

During realization of the 1xBinary smart contract it was decided to give up transaction at the moment of opening the pool for the sake of creating a system of identifiers. Thus, in order to execute a bet, you only need to know the pool ID. If there is no pool at the time of the bet, it will be created automatically.

▹ Closing the pool

Closing the pool is implemented using a system transaction, which is carried out from a predetermined address (and is part of the 1xBinary smart contract management system). The closure essentially means a ban on accepting bets from a certain moment. Closing the pool should occur faster with respect to other transactions (including bets), so this transaction is conducted with an increased gas price.

▹ Payouts

Payouts are realized using a system transaction (or series of transactions), which is conducted from a predefined address. The calculation of winnings and the transfer of tokens is carried out inside the smart contract, so, potentially, such a transaction may not be invested in the gas limit of the block (with a large number of bets), so the system has the opportunity to pay winnings by sending a series of transactions, which makes it possible to work with a large number of users.

BETS

The betting process is a transaction of transferring tokens to the address of the 1xBinary smart contract, indicating the type of bet and the pool ID. The bet is accepted by the system until the pool is closed.

Bet options

At the moment, the system supports 2 types of bets — on growth and falling. In the future, we plan to expand this list to support bets for other types of events.

SYSTEM RESTRICTIONS

Since transactions are accepted and confirmed by the network in asynchronous mode, it creates a number of problems when the system is running. Let's view them in more detail using the figure below.

When processing the transaction Bet 1, the pool is in the open state, and it’s long enough will the closing time for the transaction to get the network confirmation. As we, technically, do not limit users in the bets until the basket is closed (it's possible to bet earlier, not later), the bet will be considered successful.

When processing the Bet 2 transaction, the pool is also in the open state, but the transaction may fail to receive confirmation before the pool is closed. In this case, transactions Bet 2 and close are in the Tx pool simultaneously at a certain point of time.

The gas price of the close transaction is selected by the 1xBinary system higher than the rest of the transactions (including the bet transactions), so the probability of confirming the transaction close is higher than that of the Bet 2 transaction. If the pool has time to close before confirmation of the Bet 2 transaction, the bet will not occur, even if formally the user sent the transaction until the pool was closed.

When processing the transaction Bet 3, the pool is still in the open state, because transaction close is not yet approved by the network. But, as in the case of Bet 2, the probability of Bet 3 confirmation is lower than that of transaction close, so the probability of Bet 3 rejection will be higher than its acceptance.

POOL CLOSING ATTACK

The only way to place a bet into the pool at the time when the close transaction has already been sent is to set a larger gas price for the bet transaction than the close transaction. In the same way, you can hammer the Tx pool of the Ethereum network with transactions with a large gas price, without giving the opportunity to confirm the transaction close. In general, this kind of user behavior is possible, yet it is costly and time-consuming. To protect 1xBinary system from such attacks, we have implemented two principles:

▸ The time intervals chosen for waiting for pools are sufficiently large;

▸ Gas price of the close transaction is determined by total bet amount in a pool.

Thus, the price of attack increases until it gets unreasonable in terms of costs.

ORACLE The basis for deciding the outcome of each round in the 1xBinary system is the resulting composite rate (Outcome Rate) provided by the oracle, so the oracle is a critical component of the system that is located separately from the rest of its parts. The work of the oracle is built on the principle of publicity and transparency. The results of its work (in the form of payment transactions) will be available for verification through the blockchain explorer (etherescan.io for the Ethereum network).

Every time, the 1xBinary composite rate is calculated as the average weighted of the exchange rates on the main exchanges. Each trading pair has a separate list of exchanges with significant volume for this particular pair. Thereby, the weight factor is trade volume on each of the exchanges.

In case one of the exchanges stops delivering data on the rates, its rate (the latter value) continues to participate in determining the composite rate, the strike rate of which includes the data of this exchange. This prevents sharp artificial jumps of the composite rate due to the redistribution of weight values.

With a fixed rate from one data provider, the courses of the remaining suppliers continue to move the composite course according to the current market situation. This is how we smooth out such an abnormal situation as correctly as possible.

If the data supplied by this exchange is not resumed by the start of the new round, the strike rate will be calculated without considering the rate from this exchange. Thus, such data provider will be temporarily "disqualified" in the 1xBinary system.

For each oracle in the 1xBinary system, we also plan to publish the source data and the methodology for obtaining the result, according to which the composite rate was calculated at each time point.