# Overview

![(Fig. 1 Orbit Chain Ecosystem) ](/files/-Lvnx9MP0JHmlTFdOwvw)

  Orbit Chain is a multi-asset supporting platform to be discussed in this Gitbook. Through multi-asset support, users can utilize various crypto assets of different blockchains on a singular chain. This allows for easy management and transfer of user’s asset, through decentralized communication channels of different chains and Orbit Chain. To Dapp and other decentralized protocol developers, Orbit Chain provides a flexible environment to develop on.  By using Orbit Chain, the need to develop for each individual chain is essentially eliminated, in addition to providing a high level of liquidity between different assets. Orbit Chain project’s infrastructure and road map is available for review in this Gitbook.  Orbit Chain’s support for token economy and governance as a decentralized platform is explained on here as well.  Anyone can create a decentralized service on Orbit Chain, with the guides listed below for development, synchronization, and interface.


# Issues in the Blockchain World

**Interoperability**

Data and assets on the blockchain usually are limited to their own chain resulting to limited access to data and assets on other blockchains. If some blockchains build a centralized approach to handle those data and assets, security and verification issues may arise.

However, Orbit Chain had already built a fully working decentralized IBC protocol which runs with Staking based Validator governance, which is reliable and safe. All assets and data are verified and stored on the blockchain and all those processes are transparently open to everyone.

**Scalability**

Proof of Work (PoW) based Blockchains usually have issues on scalability, speed and expensive fees.

However, Orbit Chain is working with Staking- based BFT consensus by Validator groups which will provide much more scalable and reliable IBC. All the information including assets and data from public chains are rapidly moved to Orbit Chain. Orbit will support parallel connectivity between Orbit Chain and Public Chains to provide faster transaction speed.

**Usability**

Existing blockchains support only one native coin., Additionally, developing and commercializing Dapp services on several blockchains are difficult and are tedious processes. The developer of the Dapp services has to develop for each blockchain for this purpose which consumes a large number of resources and leads to poor and unreliable management.

Orbit as a multi-asset blockchain enables Dapp developers to connect with public chains through the Orbit SDK and develop using on existing and familiar REST, and WebSocket system APIs, which reduces unnecessary resource consumption and helps developers focuses on their Dapp services to develop high-quality services.<br>


# Multi-Asset Blockchain

Token economy of blockchain projects are mostly comprised of Ethereum-based cryptocurrencies.  These cryptocurrencies serve as a transaction fee on chain, and also as a vital part of Governance.  Other assets exist on ERC20 chain in different formats, and their usage vary as well. Orbit Chain allows all assets to exists on its chain in a same format, even the ones that exists in different forms outside of Orbit Chain.

Orbit Chain aims to work as a hub for various public blockchains, for fluid asset movement and interaction within a single blockchain network.  Every blockchain has a different set of constituents and protocols, such as UTXO and Balance-state. Connecting these blockchains together is no easy feat, but through Orbit Chain, all of these chains can be linked and utilized in the same fashion, with the same amount of liquidity.  To this purpose, Orbit Chain provides a system that will use a singular method of transaction to building Dapps, which will then be able to use various assets in the same manner. In doing so, the previous liquidity problem of traditional blockchain systems will be eliminated, in the standardization of multi-asset usage.

Orbit will also include, in addition to cryptocurrencies, more traditional forms of assets within Orbit Chain.  This connection will be made in a different format than cryptocurrencies, yet still connected to all in a similar fashion.


# Value Position

**Cryptocurrency personal users**

Previous users of cryptocurrencies had to use different wallets for every type of cryptocurrencies they owned.  And to trade between different types of cryptocurrencies, they had to be sent to a centralized exchange, and then after trading, had to be sent to another wallet.  This is a hassle that is eliminated in Orbit Chain, as only Orbit Chain is necessary to utilize all cryptocurrencies it supports.&#x20;

**‌Dapp & Protocol developers**

For many Dapp and Protocol developers, choosing a blockchain platform to develop on can be difficult.  They want their service to be accessible to many users. In order to achieve that, a blockchain platform where various assets can easily be accessed would be ideal.  Orbit Chain achieves precisely that, and allows Dapp and Protocol developers to utilize Smart Contract with all assets supported by the chain through transactions.&#x20;

**Public Blockchain Platform Developer**

Most, if not all Blockchain developers want the assets of their ecosystem to be connected and expanded with as many blockchains as possible.  However, to achieve this, a large amount of monetary and developing resources are required. Also, to maintain this connectivity with the latest versions of Mainnets, continual resources are required.  Should these developers connect to Orbit Chain, they can maintain their own Mainnet identity, yet gain access to other blockchains’ ecosystems and utilize DEX and DeFi as their side transaction channels.<br>


# Overview

![(Fig. 2 Orbit Chain Structure)](/files/-LvnyWnFWLOf1MI3WWbD)

**Orbit Chain ( Hub chain )**

* All Public blockchains will be connected to Orbit Chain through the IBC zone to share information, data and asset using a standard format. Orbit Chain will work as the hub chain to gather all the information, data and assets from all different public blockchains. Dapps can easily utilize with smart contracts for their utility.
* Orbit Chain will also support simultaneous communication for multiple public blockchains.

**Orbit Inter Blockchain Communication zone ( IBC zone )**

* Orbit Chain and Public Chain will communicate through a decentralized Inter-Blockchain Communication (IBC) Zone. The IBC Zone will verify information and data from each public blockchain. Those verifications will be processed on the blockchain so it is safer, more reliable and will operate with decentralized communication which doesn’t require centralized operating and validating process.


# Orbit Chain's Design Goal

**Decentralization:** Anybody can participate in the blockchain with O( c ) amount of resources, including but not limited to verification and sending.&#x20;

**Resilience:** The chain is to maintain connectivity even if majority of the nodes on the network becomes disconnected or offline.&#x20;

**Simplicity:** Complexity is lowered, even if it means less efficiency.&#x20;

**Longevity:** The chain is to be built with modular designs regarding functions as to maintain operation continuously despite security / governance flaws while they are being rectified.&#x20;

**Scalability:** Transactions and other functionalities are to be processed in a parallel way to increase scalability.&#x20;

**Connectivity:** The chain is to connect to different systems regardless of their format and design.&#x20;

**Block chain Security:**  Risk of 51% Attack

**Finality reversion:** Should a certain block A be finalized by a Validator, it must be prevented from being finalized again by another individual.&#x20;

**Invalid chain finalization: ‌**A validator cannot finalize an invalid block.&#x20;

**An invalid block must be rejected, following the laws regarding blocks and signature information.**&#x20;

**Liveness denial:** The chain is to continue functioning in the event that a small number of validators stop producing blocks

**Because Orbit Chain is based on PoS consensus algorithm, validators that do not validate are pushed out of validator group by penalization through the algorithm.**&#x20;

**Censorship: ‌**Validator must verify all transactions made on the blockchain fairly.&#x20;

Should the majority of validators choose to take advantage of their majority voting power, a small number of honest nodes may run the chain independently from the main chain through a soft fork process. In this case, the market is left to choose between the original chain, and the new chain.


# Block Consensus

Proof-of-Stake(PoS) is a consensus algorithm that gives voting power equivalent to the amount staked on a Public blockchain.  Unlike Proof-of-Work(PoW)-based blockchains that reward participants that decrypt complex cryptography, Proof-of-Stake give block-producing rights based on the amount of tokens held.  PoS-based systems have, as of recent, become a contender for PoW-based systems, as PoS-based blockchains offer high security, high levels of decentralization, and better energy efficiency.&#x20;

The blockchain, by default, tracks all validators on-chain at all times.  By creating a transaction that stakes a certain amount of assets on to the chain, anyone can become a validator.  Production of a block is generated through the consensus algorithm, and all validators are eligible to participate in this process.&#x20;

‌Previous PoW consensus algorithm used by BTC and Ethereum was regarded as an excessive use of energy to ad infinitum, and this problem is detailed in “EIP1011”.  Mentioned within this article are the various problems of PoW, such as the waste of energy, and the monopoly introduced with mining hardware, and the centralization caused by large mining pools.  All of these problems can be, and must be solved through a switch over to PoS, this article argues. Ethereum is currently being converted into a full-fledged PoS system after a transition through a stage named Casper FFG (Casper the Friendly Finality Gadget), which is a system employing both PoS and PoW.&#x20;

‌Vitalic explains the philosophy behind blockchain consensus algorithm, through his paper titled “A Proof of Stake Design Philosophy.” PoW, he argues, is a method employed by the miners in building the chain through injection of funds, and is representative of a Maximalist philosophy.  Vitalic calls the philosophy behind Casper PoS “Cypherpunk” - a philosophy embodying a desire to respect individualism, and to resist against central systems. This is in line with the message contained within the Genesis Block of Bitcoin, a note left by Satoshi titled “The Times 03/Jan/2009 Chancellor on brink of second bailout for banks.”  This is the very philosophy behind decentralized public ledgers, and the building blocks of all blockchain systems.&#x20;

**PoW ( Proof - of - work )**

**‌**Currently, Blockchain consensus algorithm is the one used by most major (by market cap) blockchains.  It is the algorithm suggested by Nakamoto Satoshi, the creator of Bitcoin, and the one detailed in the paper “Bitcoin: A Peer-to-Peer Electronic Cash System.”  It is used in Bitcoin, Ethereum and other various public blockchains.&#x20;

‌The word “Proof-of-Work” signifies the similarity of block producing to actual mining.  Allow us to explain PoW through the most commonly known blockchain, Bitcoin. Individual blocks in a blockchain contains a unique hash value, called BlockHash.  BlockHash is a value generated from version, Merklehash, bits, previousblockhash, time and nonce values. In order to “mine” the block, a miner must find a specific hash value at the current block height, and this process is done by continuously changing the nonce value to find the right hash value.  Because there is no direct correlation the nonce value and the hash value, mining computers enter random values into nonce continuously until the right hash value has been found. In the process of these computations, a large amount of computing power and electricity is consumed.  &#x20;

**‌**In case of PoW, the blockchain is protected from attackers by the sheer amount of computing power and electricity required to perform an attack.  However, there is still a possibility of an attack succeeding, and when it does, it is not easy to revert. ASIC chip was developed for the purpose of mining, but the possibility of utilizing a large number of these chips to engineer an attack has been raised as an issue.  To combat this problem, a blockchain may change its hash algorithm to protect itself from danger, but this too may change by modifying the ASIC mining equipment. A change in blockchain’s hash algorithm requires a hard fork of blockchain, and the cost of this is incurred against the cost of mining countermeasures of ASIC attackers, which does not maintain system integrity through asymmetry. It means there is a need for another consensus algorithm, so the PoS system is receiving much support as an alternative.

**PoS ( Proof - of - Stake )**

As observed above, PoW ia a method that involves producing blocks through using a tremendous amount of computing power, whether from CPU or GPU.  However, with PoS, a method known as “staking” is used to produce blocks. Staking is a method of distributing new blocks based on the amount of monetary units a participants owns on the chain.  PoS is a block-producing consensus system that was introduced to overcome the limitations of previous PoW systems.&#x20;

As of now, there are quite a few PoS consensus algorithms that was introduced.  EOS DPoS, Tezos LPoS, Cosmos Tendermint are all but a few of those algorithms. PoS is still in its infancy, and is continually being updated through constructive criticism of the community.

The concept of miners of PoW are replaced with validators in PoS.  Two of the most well-known designs of PoS are Chain-based PoS and BFT PoS.  For Chain-based PoS, validators are chosen by periodic random validator selection to choose a block producer.  For BFT PoS, block producers are chosen at random. The block that is to be produced is then put through a Finalization process in which the Finality of the block is verified through a voting process of the validator group.

For PoW, if two blocks are to be produced at equal heights to be incorporated into the chain, the chain with higher heights is chosen to be the more legitimate one.  For PoS, consensus among the validators are used to determine the legitimate block, to prevent a party with higher hash power from altering the chain on purpose.

For EOS, a system known as DPoS is employed.  It is criticized for its lack of decentralization, as only 21 BPs that were selected through a voting process are eligible for producing blocks.  These 21 BP positions can be claimed by wealth, and they can maintain their power in the same fashion. They can also conspire for their own profit, by producing blocks that are in their favor, and actively declining the ones that go against their will.  The fact that the voting against them, and the shift in power and funds occur through the blockchain is a subject for much discussion as the block will be produced by the already-chosen 21 members. PoS can be designed in a variety of ways, and can be improved through such discussions.&#x20;

The core safeguard in decentralization of blockchain is the design that causes the destruction of the system to cost more than to maintain it.  In this regard, PoW is limited in many ways. PoS, however, is maintained by the validators that participate in the system. They become validators through staking, and are rewarded in growing and maintaining the chain in monetary terms.  They are also punished if they were to harm the chain, in monetary terms and other ways. PoS system is the sum of various functions within it, such as what constitutes as efforts to improve the ecosystem, and the compensation in such efforts, and the definition of harming the ecosystem, and the punishment that follows.  The blockchain is maintained by designing the security in asymmetrical fashion, as to make the punishment far harsher than the rewards.

**Byzatine Fault Tolerance**

The idea of implementing a Byzantine Fault Tolerance (BFT) consensus came from the challenges we faced while building blockchain solutions for banks. We chose Ethereum as the baseline protocol mostly because of its smart contract capability. However, the built-in consensus, proof of work or Ethash, is not the ideal choice when settlement finality and minimum latency is required.

Orbit’s consensus algorithm was designed based on the Practical Byzantine Fault Tolerance (PBFT) algorithm. The logic behind our high performance and instant finality is to support the connection of many assets and usability Dapp services utilizing the Orbit chain. We operate Ethereum-based blockchains that support Ethereum Smart Contract. Ethereum has been used as a platform for a long time to build decentralized applications (DApps) through the stability of Ethereum smart contract. Additionally, Ethereum 2.0 technologies such as Plasma, Casper, and Sharding are constantly being updated to create a fully decentralized and permissionless platform. Orbit chain is operated as a PoS consensus blockchain based on the Orbit BFT (OBFT) consensus algorithm which improves the existing Ethereum PoW consensus issue.

The Orbit BFT algorithm is a 3-phase consensus algorithm that consists of PRE-PREPARE, PREPARE, and COMMIT. It confirms immediately after block generation by eliminating the issues caused by the generation of multiple blocks at the same height occurring in existing Ethereum, Bitcoin, and EOS. Therefore, the instant finality is expected to be very supportable in a blockchain where many financial transactions occur.

Block generation consensus by a selected few representatives of staking based PoS improves transaction performance limited to 10-30 per second in previous Ethereum to enable fast block generation and high transaction throughput.

**Block Proposer Selection**

For a fair selection of the next block producer, a completely unpredictable random number is used for the process.  The random variable is generated through RANDAO and VDF, and each individual block producer is chosen to produce the block, and the validators validate the production.&#x20;

**RANDAO**

**‌**RANDAO is performed through the function “commit reveal scheme”.  Each validators submit a random hash value generated locally on the blockchain.  When all the hash values have been collected, the REVEAL function occurs, where all the secret hash values are then calculated through an XOR calculations.&#x20;

For RANDAO, there is a possibility of a Last Revealer Attack.  If the last person to submit the hash value is compromised, there is a possibility of engineering the random number, and RANDAO may become a predictable process.&#x20;

**VDF ( Verifiable Delay Function )**

To prevent Last Revealer Attack from occurring, we have implemented a Verifiable Delay Function, or VDF.  VDF is a function that solves a computational problem that takes a very long time to decode, but very short time to verify should the input and the output values exist.  Through VDF, we can intentionally design the output function so that the last revealer hash value is one that cannot be predictable.<br>


# Orbit Chain IBC

**Basic Design**

Lack of communication made it hard to exchange and transfer the value of assets between chains, leaving their economy isolated. It has been a common practice to mint assets such as USD and BTC in a chain through fixed value in a centralized method using the FIAT Gateway method, and utilize them in a chain. This method is based on the trust of the centralized subject. There are questions about the uncertainty due to lack of information and the security of the assets. To resolve these issues, many protocols have emerged for communication between unconnected blockchains through decentralization of the communication.

‌Orbit IBC protocol enables a decentralized 2-way pegging based on existing lightning network (micropayment for bitcoin) and Plasma (scalability solution for Ethereum 2.0) for public chain scalability and communication.

‌The method presented as Plasma Cash is a single plasma operator method but there are two problems with this approach.

* The Plasma operator can withhold a single block, forcing all users to exit the chain before they can spend their coins
* The Plasma operator can censor and order transactions

Due to these two problems, Plasma operators are in need of higher dependence on trust. This leads to show most of the problems present in a centralized exchange.

The Orbit IBC protocol solves the problems concentrated on one operator by implementing  IBC with the PoS- based validation.

**Inter Blockchain Communication Design**

STEP 1: Propose Orbit Chain block

STEP 2: Make merkle object block

STEP 3: Validate object block

STEP 4: Synchronize object block to public chain

**IBC Zone**

* **Validator**
  * Verifies and audits both of Orbit Chain and Public Chain. Also responsible for verification of Inter-block communication process
* **Operator**
  * Operates Inter-block Communication to relay messages between public chains . Everyone could participate in as an operator.
* **Fishermen**
  * Monitors the operation of validators and operators through a periodical check or bad signal.

![(Fig. 3 Orbit IBC Zone)](/files/-LvnysrJuNtCItr6kn7c)

**Implementation**

Implementation and process of IBC slightly vary depending on the structure of Public blockchain but is subject to below common rules.

* Fixed asset on mainnet cannot be transferred or changed by a single validator
* Asset deposit will be verified in parallel by validators under consensus of Orbit Chain
* Asset withdrawal will be managed by smart contracts on Orbit Chain, which will be verified by Validators simultaneously.
* All communication and settlement between Validators will be on smart contract. There is no off-chain communication and consent.

Blockchain system will be classified by following system/structure. Blockchain system built with these common conditions / specifications.

* UTXO-based blockchain ( BTC, BCH .. )
  * Implement via multiple-signature wallet
* Balance-based blockchain ( ETH, EOS .. )
  * Implement via smart contract
* Ledger-based blockchain ( XRP )
  * Implement via multiple-signature wallet

**IBC Zone component**

**Operator**

* Listen to orbit chain and public chain
* Manage Relay Deposit / Relay Withdraw
* Sending Deposit information to orbit chain
* Sending Withdraw transaction to public chain
* Anyone who is connected to network could be operator.

**Validator**

* Listen to orbit chain and public chain
* Verify information from public and orbit chain
* Signing deposit and withdraw information
* N = 3F + 1 ( N: total validator number , F: Bad validator number )
* Constantly increase validators to enhance network security.
* Staked asset will determine the scale of verification.
* Rewards are given for diligent and successful verification on their duty.
* Malicious actions will cause penalty on staked token by governance agreement.

**Fishermen**

* Checks and monitors the operation of validators and operators through periodic check or bad signals.
* Get rewards by disclose validator's misconduct / malicious actions.


# IBC Network Fee

The Operator and Validator operate the IBC in the Orbit Chain. These two groups generate transactions in the Orbit Chain and the target chain during the transfer of assets. In this case, transaction fees are applied according to the implementation of the Orbit chain and the target chain.

Therefore, the user pays a certain level of fee to the Operator and Validator during the deposit and withdrawal process. Fees are paid differently depending on the rate. The deposit and withdrawal fees are deducted from the total deposit or withdrawal amount.

The fee for a single withdrawal is 1 to 3 USD or the level specified by centralized exchanges. A standard criterion of the fee follows the initial listing, but it can be adjusted by agreement between the Operator and Validator according to the price change of the coin.

## Ethereum IBC Fee

### Deposit

No fee

### Withdrawal

The Ethereum transaction execution fee is used when executing a withdrawal transaction on the Ethereum network.

* Fee: 0.01 ETH

## Ripple IBC Fee

### Deposit

No fee

### Withdrawal

Ripple is used as an execution fee when executing transactions to withdraw XRP from a multi-sig wallet on the ripple network.

* Fee: 1 XRP

## Bitcoin IBC Fee

### Deposit

No fee

### Withdrawal

Fees are used when creating transactions with a new UTXO configuration for withdrawal purposes on the Bitcoin network.

* Fee: 0.0005 BTC

## Terra IBC Fee

### Deposit

No fee

### Withdrawal

Withdrawals from Terra Network require fees equal to Tax + Transaction Fee.

* Fee: 1,000 KRW

## Klaytn IBC Fee

### Deposit

No fee

### Withdrawal

The Klaytn transaction execution fee is used when executing a withdrawal transaction on the Klaytn network.

\*Klaytn Network currently operates a Fee Payer account for service providers. There is no withdrawal fee for as long as the policy is maintained. If the policy is changed later, a withdrawal fee will be applied.

* Fee: -


# Orbit Chain SDK

![(Fig. 4 Blockchain based service layer)](/files/-Lvnz1h1enhs1QCBCDF0)

Definition of service system layer for blockchain (fig. Blockchain based service layer) shows that there is some limitations in providing commercialized service on blockchain.

**Limitations of Single Layer Block Chain Services**

* Synchronizing data on legacy centralized database with blockchain database
* Slow and limited throughput of blockchain client
* Limited blockchain query
* Limited interoperability between various blockchain and centralized service

Orbit Chain will provide Orbit SDK to commercialize blockchain based service through the following system layer after many trials and bug fix by ourselves.

* Service layers that considered for direct service and user experience
* Provide REST, SOCKET which will support easy, stable and reliable connectivity between centralized legacy services and decentralized blockchain based service.
* Unified API to connect all blockchain by Orbit SDK
* System that can provide centralized experience without harm to decentralized governance/system
  * JSON RPC wrapper layer
    * Provide lower level standard communication protocol to communicate with various public chains such as Bitcoin, Ethereum and other chains and support extension and interoperability.
  * Sync module : distributed ledger to RDB

    * Instance syncing multi-database system

![(Fig. 5 Orbit sync module)](/files/-Lvnz7Ea9Rb3IS3cKtnP)


# Token Economy

ORC is used as the basis for all transaction, and as an equity for blockchain consensus. Through ORC, the values contained within Orbit Chain is preserved and operated with.&#x20;

**ORC Utility**

* A cost for resource usage through transactions
* A cost for transfer of funds through transactions
* A method of Staking (Participation of block producing and validation)
* Exercise of voting power within the governance
* A cost for utilizing the IBC

**Transaction Fee**

‌Orbit Chain converts assets from other chains into the standardized token within Orbit Chain. All Dapps and transactions on Orbit Chain can utilize transaction services with this standardized token.&#x20;

**‌Within Orbit Chain, there are two major types of fees.**&#x20;

Transaction Fee = Computing Usage Fee + Asset Transfer Fee

1. Computing Usage Fee is a fee incurred from the previous Ethereum chain, for the computing resource that is required for occuring transactions.&#x20;
2. Asset Transfer Fee is a value that is proportionally calculated to the amount of funds being transferred, that exists for the preservation of the network.&#x20;

Asset Transfer Fee = MIN ( Transfer amount \* Asset transfer fee rate, Asset fee cap )

ex)Transaction transfer amount : BTC = 1 BTC / ETH = 10ETH, Asset transfer fee rate : 0.0001

Then, Asset Transfer Fee ( BTC ) = 1 \* 0.0001 = 0.0001BTC / ‌( ETH ) = 10 \* 0.0001 = 0.001 ETH

**‌‌‌**Transaction fees are the backbones of Orbit Chain token economy, as they support the chain and provide security to the value imbued to the chain. Orbit Chain, naturally, wishes to raise the value of its chain.&#x20;

**Validator Economic Incentive**

‌‌A validator participating in blockchain validation will be rewarded with the following.

Total Incentive to Stake = Staking Rewards + Transaction Fees + IBC Fee - Cost to run a Validator

‌All validators that stake their assets on the chain are subject to a monetary award defined by the inflation rate. And they can also receive the transaction fee from the generated block. In addition to all this, should they be responsible in operating the IBC, they will receive additional rewards as compensation.

**Limit of Block Validator Number**

**‌**Anyone can become a validator, provided they meet the minimum requirements. However, to become a block-producing validator, there may be difficulties if there are many validators, as too many block-producing validators may throttle the network with increased number of computations. But increased number of block validators raise the stability of a network, so therefore an upgrade is in the plans to raise the number of block producers in the future through an upgrade in the network. Initial validators will be 21 people, but this number is designed to be increased through governance consensus in the future.&#x20;

**Staking Rewards**

**‌**Validators are rewarded every time a block is generated. This ratio of rewards received is proportional to the amount of funds staked in the entire network. When the staked amount is low, the ratio of reward goes up, whereas if the staked amount is high, the reward is lessened.

**Slashing & Penalty**

**‌**This is a mechanism encouraging the validators to continually participate in producing blocks, through slashing and penalties. If a validator was to go offline, they would be penalized for it.&#x20;

**‌**If a block is finalized and the node becomes offline, the validator would lose an x% of the funds staked. The value x is equal to the current interest rate.&#x20;

‌So for example, if the current yearly interest rate is at 5%, the validator could lose up to 0.0137% of the funds staked. This value is determined on daily basis.&#x20;

‌If over 33% of the validators become offline and the block producing is stopped, then the offline validators could lose up to 60% of their funds in a 18-day period. This mechanism is a safeguard to protect the nodes that are online, so that the network could return to its normal state in a short amount of time.&#x20;

‌If the amount staked is to fall below the minimum required stake, the validator would automatically become excepted from the list of validators.&#x20;

‌If double signing occurs, where two different blocks of the same height are verified, the participants lose 60% of their staked funds, thereby maintaining the security of the network.<br>


# Governance

Orbit Chain uses a set of laws and governance consensus system akin to that of a basic constitution.  Bitcoin and Ethereum have had problems with consensus that led to several forks of chain being created, because they lack basic governance system with consensus.  As such, we believe having governance is paramount to maintaining a good, sustainable system.

‌Governance refers to a set of operational policy centered around a decentralized voting system.  It allows Orbit ecosystem participants to cast their votes to decide the direction and policies Orbit assumes.  However, Orbit Governance is not a pure democracy, but a representative democracy. What that means is, regular holders can delegate their ORC to a Candidate, and will not be able to directly vote on a subject matter. Instead, Candidates will have voting power vested by holders through ORC, and will exercise their influence on the outcome of a voting process.  ‌

**How voting occurs**

**‌**All resolutions are to be voted in agreement or disagreement only, and candidates can participate and exercise their right by choosing favor, oppose, or abstain.&#x20;

‌As such, all resolutions are to be suggested with specific numerical values, and to avoid vague, abstract forms.

‌Resolution Example 1) Let’s lower the yearly inflation rate from 10% to 8%&#x20;

‌Resolution Example 2) Let’s use 20,000,000 ORC for execution of IEO <br>

**Members of the Governance**

**‌(1) Candidate**

**‌‌**Top 7 Validators gain additional block-producing rights (# of Validators to increase in future)

‌Rest of the candidates will be on waitlist to become block producers

‌Candidates are required to participate in voting on Governance resolutions

**(2) Voter**

**‌**Voters are allowed to delegate their tokens by voting on a Validator.  This is their only responsibility and authority.&#x20;

‌\* **Exercising Voting Power on the Governance :** ‌Every Candidate has a Voting Power proportional to the number of ORC delegated

**‌Governance Voting Procedure**

**‌(1) Resolution Initiative**

Required fields: Title, Subject Matter, Numerical Specificities and Reasoning&#x20;

‌‌Requirements: Candidate must have over 3 million in Voting Power

‌Cost: 100,000 ORC (As soon as the resolution is initiated, this amount is locked up, and is excluded from staking)

‌In the case that resolution fails, the initiative cost is moved to the reserve, whereas if it is passed, the cost is returned back to the candidate.&#x20;

**(2) ‌Voting Start**

**‌**Time: Voting starts on D+2 00:00 (UTC) from Resolution Initiative

‌Once Resolution is registered, relevant notice is sent out on Allbit website and other communities

‌Rule 1. For every resolution, Voting Power of a Candidate is determined as per the snapshot taken at the start of Voting

‌Rule 2. During the process of Voting, a change in the number of ORC due to staking/unstaking is not reflected upon Voting Power&#x20;

‌Reason:  Due to the current structure of Orbit Chain, Voting Power of Candidates are subject to fluctuations. &#x20;

**‌(3) Voting Procession**

**‌**Voting Period: 7 Days (168 Hours)

‌Voting Options: One in favor, opposition, and abstention

‌Voting is compulsory, and all candidates are required to participate in the voting process (Responsibility imbued by authority) &#x20;

‌Voting may end prematurely should the valid votes in favor or in opposition pass 50% of total votes, as determined by the snapshot.&#x20;

**(4) Grace Period**

**‌**Voting Grace Period: From the end of voting, until 14 Days (336 Hours) past the start of Voting

Ex) If the voting is completed in 3 days, the grace period may increase to 11 days in total.&#x20;

‌If votes are cast during the Grace Period, the votes are not reflected on the voting results.&#x20;

**‌(5) Voting Finalization**

Should the quorum not be reached by the end of voting, the resolution is deemed invalid.

‌Quorum: Quorum is the minimum number of votes required for a resolution to pass.  Based on the number of votes determined by the snapshot at the time of voting start, the total number of votes excluding the abstention is considered valid.  Quorum is defined as over 40% of these valid votes.&#x20;

‌Only if over half of the valid votes are in favor of the resolution, the resolution is considered to be successful. &#x20;

‌Once the result of a resolution is determined, the Grace Period starts for the said resolution.&#x20;

**‌(6) Penalty for failing to participate in voting**

**‌**Penalty: 1% of Candidate’s Voting Power (Slashing)

The candidate who fails to participate in the voting within the Grace Period loses 1% of the allocated Voting Power, and deducted (slashed) ORC is allocated to the Reserve.&#x20;

**‌(7) Resolution progression**

**‌**There are two major ways that a Resolution may be carried out

‌Immediate Progression: Resolutions that can be carried out immediately within the system, such as inflation or block reward rate.

Subsequential Progression: Resolutions that cannot be carried out immediately, such as development, concept, and direction.  These resolutions are to be reviewed by the Committee, prior to a relevant agenda being shared to the community. ‌


# Use Cases

Orbit Chain is a multi-asset chain based on Inter-Blockchain Protocol.  The fact that various assets of different chains can be exchanged and used on a singular chain solves the biggest problem that previous blockchain-based protocols have in common, which is liquidity.  Many Dapp and protocols currently face problems overcoming the limitations provided by the platform they are based on, and have difficulties growing as a result. The expansion of ecosystems are often hindered by the lack of connectivity to other ecosystems, and protocols, dapps, and even newer platform chains struggle not being connected to the larger ecosystems of Bitcoin, Ethereum and Ripple.&#x20;

**Sidechain for Public Chains**

Orbit Chain is a hub chain of every public chain which is not dependent for a specific public chain. So it means that with Orbit Chain, public chains could be connected to each other to solve the isolation issue and get flexibility and interoperability. One of the key benefits of using Orbit Chain is that it is able to provide borderless multi-chain asset cross transaction without developing a direct communication channel.

Orbit Chain is already supporting cross transaction between BTC, ETH, XRP and will connect Stable Coin based blockchain soon. It will give Dapps for more possibilities, utility and even more user pool from the various environment.

**Benefits of Interoperability**

Most public chains have their own DEX protocol, or they run a DEX in which their own token is playing a trading pair role, but they have some difficulties in the following:

1. Exchanging Dapp tokens with other major coins/tokens other than their native token (Dapp Token -> Main Chain Coin -> Centralization Exchange Transfers -> Other Coins / Tokens Exchange),
2. Securing liquidity and users that is the most important feature of cryptocurrency exchange, and
3. Developing 2-way pegging system between different chains. There always has been a demand of an intercommunication system but it is difficult to satisfy the demand because the commercialized cases are rare and it requires high development resources for building the system.

Those problems can be easily, quickly, and efficiently solved by Orbit Chain, which has demonstrated the high-level technology by operating and commercializing the pegging/interworking system for a year.

In the future, Orbit chain will become more diverse by adding more liquidity supply, enabling stable exchange of tokens and allow cross-flow of cross-chain users through linking and interoperability.

**Use Case 1. Decentralized Exchange**

The most basic function that can be performed with currencies, of course, is the exchange of it.  Orbit Chain solves the problem that previous chains have had with liquidity and scalability. O-DEX is the decentralized exchange protocol based on Orbit Chain that allows exchange of currencies, on-chain.&#x20;

‌O-DEX protocol ( allbit.com )

**Use Case 2. Decentralized Finance**

As of recent, the need for decentralization of deposit/loan services of blockchain assets have been growing.  As is with decentralized trading, liquidity and scalability are both important traits a chain must possess in operating decentralized protocols.  Orbit Chain is the chain optimized for such traits, and provides an excellent environment for DeFi protocols to develop on. Currently, a pool-based DeFi protocol Divine operates on Orbit Chain.&#x20;

Divine protocol ( trinito.io )

**Use Case 3. Chain-to-Chain Bridge Gateway**

Orbit Chain is a service that appeals not to Dapp and Decentralized Protocol developers, but to projects that want their blockchain to become connected to other chains.  Simply by connecting their current chain to Orbit, they can utilize the assets of other chains within their own chain, thus gaining more liquidity for their chain.

**Use Case 4. Multi-Asset Dapp**

Many Dapps get trapped within the confines of their platform, once they start developing.  This causes problems with liquidity, as once the development is somewhat complete, their assets may become limited in transferring to and from other chains.


# Roadmap

**2Q, 2019**

* Official introduction of Orbit Chain
* Introduction of Orbit Chain technology, and its structure
* Introduction of major Validator partners, and staking begins
* XRP Mainnet connected

**3Q, 2019**

* Lightpaper released
* Decentralized Governance tool launched
* Developer-friendly Testnet ‘Avocado’ launched
* Terra & Klaytn Mainnet connected

**4Q, 2019**&#x20;

* Whitepaper released
* Decentralized token swap service utilizing IBC launched

**1Q, 2020**

* Orbit Chain Mainnet launched
* Instant Swap-based DEX protocol launched
* Another Mainnet connected to Orbit Chain

**2Q, 2020**&#x20;

* Protocol for DeFi additionally developed, and instated
* 8-10 Dapp development projects secured
* Another Mainnet connected to Orbit Chain

**\*Roadmap schedules are subject to change, depending on development process / company directions.**


# Overview

**BalanceContract** : Manage multi-asset and process balance transfer

**EthPeggingContract** : Manage ETH-Orbit communication

**BtcPeggingContract** : Manage BTC-Orbit communication

**XrpPeggingContract** : Manage XRP-Orbit communication


# Smart contract interface

## Balance contract

```javascript
    event GenesisBalance(address indexed user, bytes32 indexed tokenId, uint balance);
    event BalanceChange(address indexed user, bytes32 indexed tokenId, uint balance);
    event Transfer(address indexed fromAddr, address indexed toAddr, bytes32 indexed tokenId, uint amount);
    event CancelTransfer(address indexed fromAddr, address indexed toAddr, bytes32 indexed tokenId, uint balance);
    event Deposit(address peggingContract, bytes32 tokenId, address toAddr, uint amount);
    event Withdraw(address peggingContract, bytes32 tokenId, address user, address extraUser, bytes destination, uint amount, bytes comment, uint withdrawId, uint feeAmount);
    event GiveBack(address peggingContract, bytes32 tokenId, address user, address extraUser, uint amount, uint feeAmount, uint networkFee, uint backAmount);

    mapping (bytes32 => address) public peggingContracts;
    mapping (bytes32 => bytes32) public tokenIdToSummary;
    mapping (bytes32 => uint) public decimals;
    mapping (bytes32 => bool) public isValidToken;
    mapping (bytes32 => mapping (address => uint)) public balanceOf;
    mapping (address => bool) public isValidPeggingContract;
    mapping (bytes32 => bool) public isUsedTransfer;
    mapping (bytes32 => bool) public isUsedWithdraw;
    mapping (address => bool) public userTransferable;
    mapping (bytes32 => uint) public withdrawFee;

    bool public defaultTransferable;
    uint public withdrawCount = 0;
    address public feeGovernance;
    
    function deposit(bytes32 tokenSummary, address toAddr, uint amount) public
    function deposit(bytes32 tokenSummary, address toAddr, uint amount, address extraToAddr) public
    function giveBack(bytes32 tokenSummary, address toAddr, uint amount, uint networkFee) public
    function giveBack(bytes32 tokenSummary, address toAddr, uint amount, uint networkFee, address extraToAddr) public
    function withdraw(bytes32 tokenId, bytes memory destination, uint amount, bytes memory comment) public
    function withdraw(bytes32 tokenId, address extraUser, bytes memory destination, uint amount, bytes memory comment) public
    function withdrawBySignature(bytes32[] memory bytes32s, uint[] memory uints, address fromAddr, bytes memory destination, bytes memory comment, uint8 v) public
    function cancelWithdrawSignature(address fromAddr, bytes32 tokenId, bytes memory destination, uint amount, bytes memory comment, uint expireTime, bytes32 wNonce, uint8 v, bytes32 r, bytes32 s) public
    function transfer(bytes32 tokenId, address toAddr, uint amount, bool needLog) public
    function transfer(bytes32 tokenId, address toAddr, uint amount, bool needLog, address extraToAddr) public
    function transferBySignature(bytes32[] memory bytesArr, address[] memory addrs, uint amount, uint8 v, bool onlyToSpender, bool needLog) public
    function transferBySignatureWithExtra(bytes32[] memory bytesArr, address[] memory addrs, uint amount, uint8 v, bool onlyToSpender, bool needLog) public
    function cancelTransferSignature(bytes32[] memory bytesArr, address[] memory addrs, uint amount, uint8 v, bool onlyToSpender) public
    function cancelTransferSignatureWithExtra(bytes32[] memory bytesArr, address[] memory addrs, uint amount, uint8 v, bool onlyToSpender) public
    
    function getBalance(bytes32 tokenId, address addr) public view returns(uint)
    function logBalance(bytes32 tokenId, address addr) public
```

## EthPeggingContract

```javascript
    event AddToken(address tokenAddr, bytes32 tokenSummary, bytes32 tokenId);
    event RemoveToken(address tokenAddr, bytes32 tokenSummary, bytes32 tokenId);

    event DepositRelay(address mainAddr, address tokenAddr, address addr, address toAddr, uint amount, uint depositId, address extraToAddr);
    event DepositValidated(address mainAddr, address tokenAddr, address addr, address toAddr, uint amount, uint depositId, address extraToAddr);
    
    event WithdrawRelay(uint withdrawId, address balanceContractAddr, bytes32 tokenSummary, address addr, bytes destination, uint amount, bytes comment);
    event WithdrawValidated(uint withdrawId, address balanceContractAddr, bytes32 tokenSummary, address addr, bytes destination, uint amount, bytes comment);

    mapping (bytes32=>bool) public deposits;
    mapping (bytes32=>address) public tokenAddr;
    mapping (address=>bytes32) public tokenSummaries;
    mapping (bytes32=>bool) public isListing;
    
    struct Withdrawal{
        address user;
        bytes32 tokenSummary;
        bytes destination;
        uint amount;
        bytes comment;
    }
    
    mapping (uint=>Withdrawal) public withdrawals;
    
    function relayDepositToken(address mainAddr, address fromAddr, address toAddr, address token, uint amount, uint depositId, address extraToAddr) public
    function validateDepositToken(address mainAddr, address fromAddr, address toAddr, address token, uint amount, uint depositId, address extraToAddr, address validator, uint8 v, bytes32 r, bytes32 s) public
    function checkValidateDepositToken(address mainAddr, address fromAddr,address toAddr, address token, uint amount, uint depositId, address extraToAddr) public
    function withdraw(uint withdrawId, address user, bytes32 tokenSummary, bytes memory destination, uint amount, bytes memory comment) public
    function withdraw(uint withdrawId, address user, address extraUser, bytes32 tokenSummary, bytes memory destination, uint amount, bytes memory comment) public
    function relayWithdraw(uint withdrawId) public
    function validateWithdraw(uint withdrawId, address validator, uint8 v, bytes32 r, bytes32 s) public
    function checkValidateWithdraw(uint withdrawId) public
    
```

## BtcPeggingContract

```javascript
    struct DepositItem {
        bytes32 txid;
        uint vout;
        uint amount;
        bytes scriptPubKey;
        address toAddr;
        address extraToAddr;
        bool deposited;
        bytes32 depositPubKeyX;
        bytes32 depositPubKeyY;
    }

    struct WithdrawItem {
        uint wtype; // 0: default, 1: send to cold
        uint withdrawId;
        bytes destination;
        uint amount;
    }

    struct Utxo {
        bytes32 txid;
        uint vout;
        uint amount;
        bytes scriptPubKey;
        bool used;
    }

    struct WithdrawTx {
        bytes32 suggestHash;
        bytes32[] keyHashs;
        bytes32[] inputHashs;
        uint outputStart;
        uint outputSize;
        uint fee;
        uint change;
    }
    
    struct Destination {
        address toAddr;
        address extraToAddr;
    }

    mapping(bytes32 => DepositItem) public deposits;
    mapping(uint => WithdrawItem) public withdrawals;
    mapping(bytes32 => Utxo) public utxos;
    mapping(uint => WithdrawTx) public suggestions;
    mapping(uint => WithdrawTx) public selections;
    mapping(uint => bytes32) public utxoKeys;
    mapping(bytes32 => mapping(bytes32 => Destination)) public depositDestinations;
    mapping(bytes32 => bool) public isUsedMappingHash;

    bool public isActivated = true;
    uint public utxoCount = 0;
    uint public validUtxoCount = 0;
    uint public withdrawalCount = 0;
    uint public withdrewCount = 0;
    uint public suggestCount = 0;
    uint public selectionCount = 0;
    uint public btcBalance = 0;
    uint public holdingLimit = 0;

    address tokenAddr = 0x0000000000000000000000000000000000000001;
    bytes coldAddr;
    bytes public redeemScript;
    
    event DepositDestinationsMapping(bytes32 btcPubKeyX, bytes32 btcPubKeyY, address toAddr, address extraToAddr);
    event DepositRelay(bytes32 txid, uint vout, uint amount, bytes scriptPubKey, bytes32 depositPubKeyX, bytes32 depositPubKeyY);
    event DepositValidated(bytes32 txid, uint vout, uint amount, bytes scriptPubKey, address toAddr, address extraToAddr, bytes32 depositPubKeyX, bytes32 depositPubKeyY);
    event WithdrawAdded(address balanceAddr, uint wtype, uint withdrawId, address user, uint withdrawIndex, bytes32 tokenSummary, bytes destination, uint amount);
    event TxSuggestAdded(bytes32 suggestHash, uint suggestIndex, bytes32[] keyHashs, bytes32[] inputHashs, uint outputStart, uint outputSize, uint fee, uint change);
    event TxSuggestRelay(bytes32 suggestHash, uint suggestIndex, bytes32[] keyHashs, bytes32[] inputHashs, uint outputStart, uint outputSize, uint fee, uint change);
    event TxSelected(uint selectionIndex, bytes32[] keyHashs, bytes32[] inputHashs, uint outputStart, uint outputSize, uint fee, uint change);
    event TxSelectedRelay(uint selectionIndex, bytes32[] keyHashs, bytes32[] inputHashs, uint outputStart, uint outputSize, uint fee, uint change);
    event WithdrawValidated(uint selectionIndex, bytes32[] keyHashs, bytes32[] inputHashs, uint outputStart, uint outputSize, uint fee);
    event UsableUtxoRelay(bytes32 txid, uint vout, uint amount, bytes scriptPubKey);
    event UtxoAdded(uint utxoIndex, bytes32 txid, uint vout, uint amount, bytes scriptPubKey, bytes32 keyHash);
    
    function getSuggestKeyHashs(uint suggestIndex) public view returns(bytes32[] memory)
    function getSuggestInputHashs(uint suggestIndex) public view returns(bytes32[] memory)
    function getSelectionKeyHashs(uint selectionIndex) public view returns(bytes32[] memory)
    function getSelectionInputHashs(uint selectionIndex) public view returns(bytes32[] memory)
    function bytes32ToAddress(bytes32 data) public pure returns (address)
    
    function setDepositDestinations(bytes32[] memory btcPubKeyX, bytes32[] memory btcPubKeyY, address[] memory toAddrs, address[] memory extraToAddrs, bytes32[] memory nonces, uint8[] memory v, bytes32[] memory r, bytes32[] memory s) public
    function relayDepositUtxo(bytes32 txid, uint vout, uint amount, bytes memory scriptPubKey, bytes32 depositPubKeyX, bytes32 depositPubKeyY) public onlyActivated
    function relayUsableUtxo(bytes32 txid, uint vout, uint amount, bytes memory scriptPubKey) public
    function validateDepositUtxo(bytes32 depositKeyHash, address validator, uint8 v, bytes32 r, bytes32 s) public onlyActivated
    function validateUsableUtxo(bytes32 txid, uint vout, uint amount, bytes memory scriptPubKey, address validator, uint8 v, bytes32 r, bytes32 s) public
    function withdraw(uint withdrawId, address user, bytes32 tokenSummary, bytes memory destination, uint amount, bytes memory comment) public onlyActivated
    function withdraw(uint withdrawId, address user, address extraUser, bytes32 tokenSummary, bytes memory destination, uint amount, bytes memory comment) public onlyActivated
    function withdrawColdScript() public onlyActivated
    function suggestWithdrawTx(bytes32[] memory keyHashs, bytes32[] memory inputHashs, uint outputSize, uint fee, uint change) public
    function relayTxSuggest(uint suggestIndex) public
    function validateSuggest(bytes32 suggestHash, uint suggestIndex, address validator, uint8 v, bytes32 r, bytes32 s) public
    function relayTxSelected(uint selectionIndex) public
    function validateWithdraw(uint selectionIndex, address validator, uint8[] memory v, bytes32[] memory r, bytes32[] memory s) public
    
```

## XrpPeggingContract

```javascript
    struct Withdrawal {
        uint wtype; // 0: default, 1: send to cold
        address user;
        address extraUser;
        bytes from;
        bytes dest;
        bytes tag;
        uint amount;
        bool validated;
        bool isCanceled;
        uint fee;
        uint seq;
        mapping(address => bytes32) signatureHashs;
    }

    struct Suggestion {
        address[] validators;
        bytes32[] signatureHashs;
        uint fee;
        uint seq;
    }

    mapping(bytes32 => bool) public isDeposited;
    mapping(uint => Withdrawal) public withdrawals;
    mapping(uint => mapping(uint => Suggestion)) public suggestions;

    bool public isActivated = true;
    uint public withdrawalCount;
    uint public suggestCount;
    uint public lastWithdrew;
    uint public lastSelected;
    uint public lastSequence;
    uint public xrpBalance;
    uint public holdingLimit;
    bytes public xrpWallet;

    bytes coldAddr;
    bytes32 public tSummary = sha256(abi.encodePacked('XRP', address(1)));
    
    event XrpDepositRelay(bytes32 txid, bytes xrpWallet, address toAddr, uint amount, address extraToAddr);
    event XrpDepositValidated(bytes32 txid, bytes xrpWallet, address toAddr, uint amount, address extraToAddr);
    event XrpDepositColdRelay(bytes32 txid, bytes xrpWallet, uint amount);
    event XrpDepositColdValidated(bytes32 txid, bytes xrpWallet, uint amount);
    event XrpWithdrawAdded(uint withdrawId, address balanceAddr, uint withdrawIndex, bytes xrpWallet, uint wtype, address user, address extraUser, bytes dest, bytes tag, uint amount);
    event XrpWithdrawSuggested(uint suggestIndex, uint withdrawIndex, address[] validators, bytes32[] sigHashs, uint fee, uint seq);
    event XrpSuggestionValidated(uint suggestIndex, uint withdrawIndex, uint fee, uint seq);
    event XrpWithdrawValidated(uint withdrawIndex);
    event XrpTransactionFailed(uint withdrawIndex);
    event XrpWithdrawCanceled(uint withdrawIndex);

    function relayDeposit(bytes32 txid, address toAddr, uint amount, address extraToAddr) public onlyActivated
    function relayDepositCold(bytes32 txid, uint amount) public onlyActivated
    function validateDeposit(bytes32 txid, address toAddr, uint amount, address extraToAddr, address validator, uint8 vSig, bytes32 rSig, bytes32 sSig) public
    function validateDepositCold(bytes32 txid, uint amount, address validator, uint8 vSig, bytes32 rSig, bytes32 sSig) public
    function withdraw(uint withdrawId, address user, bytes32 tokenSummary, bytes memory destination, uint amount, bytes memory comment) public onlyActivated
    function withdraw(uint withdrawId, address user, address extraUser, bytes32 tokenSummary, bytes memory destination, uint amount, bytes memory comment) public onlyActivated
    function transferToCold() public
    function suggestWithdraw(uint withdrawIndex, address[] memory validators, bytes32[] memory sigHashs, uint fee, uint seq) public
    function relaySuggestion(uint withdrawIndex, uint suggestIndex) public
    function validateSuggestion(uint withdrawIndex, uint suggestIndex, address validator, uint8 vSig, bytes32 rSig, bytes32 sSig) public
    function relayWithdraw(uint suggestIndex, uint withdrawIndex) public
    function validateWithdraw(uint withdrawIndex, address validator, uint8[] memory vSigs, bytes32[] memory rSigs, bytes32[] memory sSigs) public
    function relayTransactionFailed(uint withdrawIndex) public
    function cancelWithdraw(uint withdrawIndex, address validator, uint8 vSig, bytes32 rSig, bytes32 sSig) public
    
    function withdrawIndexToSuggest() public view returns(uint)
    function withdrawIndexToSign() public view returns(uint)
    function getSuggestionValidators(uint withdrawIndex, uint suggestIndex) public view returns (address[] memory)
    function getSuggestionSigHashs(uint withdrawIndex, uint suggestIndex) public view returns (bytes32[] memory)
    function getSignatureHash(uint withdrawIndex, address validator) public view returns (bytes32)
```


# Ethereum IBC protocol

## Deposit

If you want to send ERC20 token to the Orbit IBC contract, you should check that the token is registered

`decimal(address tokenAddr)`

Send a deposit transaction to the Orbit IBC contract on the Ethereum MAINNET/ROPSTEN&#x20;

```javascript
// deposit ETH
function deposit(address toAddr, address extraToAddr) payable public
// deposit ERC20 TOKEN
function depositToken(address token, address toAddr, uint amount, address extraToAddr) public
```

If your transaction succeed,&#x20;

```javascript
event Deposit(address tokenAddr, address addr, address toAddr, uint amount, uint depositId, address extraToAddr);
```

Deposit event occur in your transaction&#x20;

Then, Ethereum IBC operator and Validator begin to proceed this deposit

When deposit is completed in the Orbit chain, DepositValidated and BalanceChange event occur

```javascript
// EthpeggingContract
event DepositValidated(address mainAddr, address tokenAddr, address addr, address toAddr, uint amount, uint depositId, address extraToAddr)
// BalanceContract
event BalanceChange(address indexed user, bytes32 indexed tokenId, uint balance);
```

## Withdrawal

Send a withdrawal transaction to OrbitChain BalanceContract

```javascript
function withdrawBySignature(bytes32[] memory bytes32s, uint[] memory uints, address fromAddr, bytes memory destination, bytes memory comment, uint8 v) public
function withdraw(bytes32 tokenId, bytes memory destination, uint amount, bytes memory comment) public
```

Then, Ethereum IBC operator and Validator begin to proceed this withdrawal

When withdrawal is completed in Ethereum, Withdrawal event occur

```javascript
event Withdraw(address tokenAddr, address addr, address toAddr, uint amount, bytes32 whash, uint withdrawId, bytes comment);
```

## Contract Methods

### addToken

{% hint style="info" %}
Only owner address can execute this function.
{% endhint %}

{% code title="Smart Contract" %}

```javascript
function addToken(address _tokenAddr) public onlyOwner;
```

{% endcode %}

| Parameter    | Type    |             Description |
| ------------ | ------- | ----------------------: |
| tokenAddress | address | Token address to append |

### removeToken

{% hint style="info" %}
Only owner address can execute this function.
{% endhint %}

{% code title="Smart Contract" %}

```javascript
function removeToken(address _tokenAddr) public onlyOwner;
```

{% endcode %}

| Parameter    | Type    |             Description |
| ------------ | ------- | ----------------------: |
| tokenAddress | address | Token address to remove |

### relayDepositToken

{% code title="Smart Contract" %}

```javascript
function relayDepositToken(address mainAddr, address fromAddr, address toAddr, address token, uint amount, uint depositId, address extraToAddr) public;
```

{% endcode %}

| Parameter   | Type    |                                       Description |
| ----------- | ------- | ------------------------------------------------: |
| mainAddr    | address | Ethereum reserve contract address on main network |
| fromAddr    | address |                                 Address of sender |
| toAddr      | address |                    Receiver address on OrbitChain |
| token       | address |                                  Address of token |
| amount      | uint256 |                                   Amount of token |
| depositId   | uint256 |                             Identifier of deposit |
| extraToAddr | address |              Extra receiver address on OrbitChain |

### validateDepositToken

{% code title="Smart Contract" %}

```javascript
function validateDepositToken(address mainAddr, address fromAddr, address toAddr, address token, uint amount, uint depositId, address extraToAddr, address validator, uint8 v, bytes32 r, bytes32 s) public;
```

{% endcode %}

You should hash following parameters to sign or validate deposit request.

{% code title="" %}

```
sha256(mainAddr, fromAddr, toAddr, token, amount, depositId, extraToAddr);
```

{% endcode %}

| Parameter   | Type    |                                       Description |
| ----------- | ------- | ------------------------------------------------: |
| mainAddr    | address | Ethereum reserve contract address on main network |
| fromAddr    | address |                                 Address of sender |
| toAddr      | address |                    Receiver address on OrbitChain |
| token       | address |                                  Address of token |
| amount      | uint256 |                                   Amount of token |
| depositId   | uint256 |                             Identifier of deposit |
| extraToAddr | address |              Extra receiver address on OrbitChain |
| validator   | address |                       Address of signer/validator |
| v           | uint8   |                                    v of signature |
| r           | bytes32 |                                    r of signature |
| s           | bytes32 |                                    s of signature |

### checkValidateDepositToken

{% code title="Smart Contract" %}

```javascript
function checkValidateDepositToken(address mainAddr, address fromAddr, address toAddr, address token, uint amount, uint depositId, address extraToAddr) public;
```

{% endcode %}

| Parameter   | Type    |                                       Description |
| ----------- | ------- | ------------------------------------------------: |
| mainAddr    | address | Ethereum reserve contract address on main network |
| fromAddr    | address |                                 Address of sender |
| toAddr      | address |                    Receiver address on OrbitChain |
| token       | address |                                  Address of token |
| amount      | uint256 |                                   Amount of token |
| depositId   | uint256 |                             Identifier of deposit |
| extraToAddr | address |              Extra receiver address on OrbitChain |

### withdraw

{% hint style="info" %}
Only BalanceContract can execute this function.
{% endhint %}

{% code title="Smart Contract" %}

```javascript
function withdraw(uint withdrawId, address user, bytes32 tokenSummary, bytes memory destination, uint amount, bytes memory comment) public;
```

{% endcode %}

| Parameter    | Type    |                              Description |
| ------------ | ------- | ---------------------------------------: |
| withdrawId   | uint256 | Identifier of BalanceContract withdrawal |
| user         | address |             Sender address on OrbitChain |
| tokenSummary | bytes32 |                            Token summary |
| destination  | bytes   |        Address of withdrawal destination |
| uint256      | amount  |                     Amount of withdrawal |
| bytes        | comment |                               Extra data |

### withdraw

{% hint style="info" %}
Only BalanceContract can execute this function.
{% endhint %}

{% code title="Smart Contract" %}

```javascript
function withdraw(uint withdrawId, address user, address extraUser, bytes32 tokenSummary, bytes memory destination, uint amount, bytes memory comment) public;
```

{% endcode %}

| Parameter    | Type    |                                       Description |
| ------------ | ------- | ------------------------------------------------: |
| withdrawId   | uint256 |          Identifier of BalanceContract withdrawal |
| user         | address |                      Sender address on OrbitChain |
| extraUser    | address | Extra sender address on OrbitChain (for Giveback) |
| tokenSummary | bytes32 |                                     Token summary |
| destination  | bytes   |                 Address of withdrawal destination |
| uint256      | amount  |                              Amount of withdrawal |
| bytes        | comment |                                        Extra data |

### relayWithdraw

{% code title="Smart Contract" %}

```javascript
function relayWithdraw(uint withdrawId) public;
```

{% endcode %}

| Parameter  | Type    | Description |
| ---------- | ------- | ----------: |
| withdrawId | uint256 | Withdraw ID |

### validateWithdraw

{% code title="Smart Contract" %}

```javascript
function validateWithdraw(uint withdrawId, address validator, uint8 v, bytes32 r, bytes32 s) public;
```

{% endcode %}

| Parameter  | Type    |                 Description |
| ---------- | ------- | --------------------------: |
| withdrawId | uint256 |                 Withdraw ID |
| validator  | address | Address of signer/validator |

### checkValidateWithdraw

{% code title="Smart Contract" %}

```javascript
function validateWithdraw(uint withdrawId) public;
```

{% endcode %}

| Parameter  | Type    | Description |
| ---------- | ------- | ----------: |
| withdrawId | uint256 | Withdraw ID |

### \_

{% code title="Smart Contract" %}

```javascript
```

{% endcode %}

| Parameter | Type | Description |
| --------- | ---- | ----------: |
|           |      |             |


# Bitcoin IBC protocol

## Deposit

Before you send Bitcoin to our multi-sig wallet, you have to do mapping your BTC address and Orbit address to the Orbit network

For mapping your address, you have to send mapping transaction to BtcPeggingContract

```javascript
function setDepositDestinations(bytes32[] memory btcPubKeyX, bytes32[] memory btcPubKeyY, address[] memory toAddrs, address[] memory extraToAddrs, bytes32[] memory nonces, uint8[] memory v, bytes32[] memory r, bytes32[] memory s) public
```

If mapping succeed,

```javascript
event DepositDestinationsMapping(bytes32 btcPubKeyX, bytes32 btcPubKeyY, address toAddr, address extraToAddr);
```

DepositDestinationsMapping event occur in BtcPeggingContract

After deposit destination is mapped, you can send Bitcoin to our multi-sig wallet

{% hint style="info" %}
You have to use p2sh wallet for sending bitcoin to our multi-sig wallet.

V\[in] UTXO in your transaction have to solve by public key
{% endhint %}

After your transaction is 1 confirmed, Orbit btc operator, validator will begin to proceed your deposit

```javascript
//BtcPeggingContract
event DepositValidated(bytes32 txid, uint vout, uint amount, bytes scriptPubKey, address toAddr, address extraToAddr, bytes32 depositPubKeyX, bytes32 depositPubKeyY)
//BalanceContract
event BalanceChange(address indexed user, bytes32 indexed tokenId, uint balance);
```

## Withdrawal

Send a withdrawal transaction to Orbit Balancecontract

```javascript
function withdrawBySignature(bytes32[] memory bytes32s, uint[] memory uints, address fromAddr, bytes memory destination, bytes memory comment, uint8 v) public
function withdraw(bytes32 tokenId, bytes memory destination, uint amount, bytes memory comment) public
```

Then, Bitcoin IBC operator and Validator begin to proceed this withdrawal


# Ripple IBC protocol

## Deposit

Send a XRP to our multi-sig wallet

Send Transaction Required&#x20;

* memo field&#x20;

```
memos = [{
    data : <to_addr>,
    type : 'toAddr'
    },
    {
    data : <extra_addr>,
    type : 'extraToAddr'
    }]
```

* Transaction Type&#x20;

```
Payment
```

## Withdrawal

Send a withdrawal transaction to Orbit BalanceContract

```javascript
function withdrawBySignature(bytes32[] memory bytes32s, uint[] memory uints, address fromAddr, bytes memory destination, bytes memory comment, uint8 v) public
function withdraw(bytes32 tokenId, bytes memory destination, uint amount, bytes memory comment) public
```

Then, Xrp IBC operator and validator begin to proceed this withdrawal


# API references


# Network information

### DEV Contract Info

Ethereum : Ropsten

Bitcoin : testnet

Ripple : testnet

Orbit : testnet

```
{
    "BtcPeggingContract": "0x3a74f74f0919cbea19436c685566d07ecf59ef27",
    "EthPeggingContract": "0x3f56dcf049e4f7a8c97c39382bc492430493e32b",
    "XrpPeggingContract": "0x69d3b152cc89ffc142575b9c73e72f705a34ad79",
    "BalanceContract": "0x2bcfc53ca5b854102aca4efd06043b0c8d5e350c",
    "MessageMultiSigWallet": "0xc9ad2f690e20141ab3713504a7a4c9331dfa1f1d",
    "Token": {
        "ETH": "0x1eb2446153a5e6448f696d5bd4af5e2327dc0be0ea519a78698843e85372513e",
        "BTC": "0x9c0434e49b8af3a18516eaca9a465725c02f79505733cd7a4586f7f9e292975b",
        "XRP": "0xc6e0854a337ccf328468f545ae3868dcdc31b51259ffef85d41b74612048e6af",
    },
    "Eth": {
        "EthReserveContract": "0x2bcfc53ca5b854102aca4efd06043b0c8d5e350c",
        "MessageMultiSigWallet": "0x264109015567D0746f89480109dD0dD3A8be8213"
    },
    "Btc": {
        "MultiSigWallet": "2Mv86UUFnoi2XUFDNX3sFW8wavYFLmBogXr",
        "RedeemScript": "5221025a1d3dec12725a76a4517eeee5ed2b4a03c34451d52ada7f79061be43eb0f5d02103ed5111f25840d18d4c7d0f3dd5796b666b42dd00ba6169e90b81e00863381d4e2102552c46fd2941fc5ef9fea42967b5cbd403e322db5909a8eac0914dfb12dadb8653ae"
    },
    "Xrp": {
        "MultiSigWallet": "rf6Ynf2rt3Po2K5PENBqBVNiMksKSs6L25"
    }
}
```

<br>


# Chain APIs

API related to Orbitchain.

API request is limited before mainnet launched (2020 1Q).

* GasLimit: 3000000 / tx
* TxLimit: 50 / sec ( total limit 100 / sec)
* DeployTxLimit : 1 / min
* CallLimit : 120 / min

## **\[POST] /v1/ozys/sendRawTransaction**

* **Parameters**

| Name           | Type   | Description                                 |
| -------------- | ------ | ------------------------------------------- |
| rawTransaction | String | Hex string result of signed raw transaction |

* **Return values**

| type        | Descripttion                        |
| ----------- | ----------------------------------- |
| JSON String | transaction hash of raw transaction |

* **Example**

```
>curl -d "rawTransaction=0xa13.....9ab" [API_DOMAIN]/v1/ozys/sendRawTransaction
{"txHash" : "0xbb508f.......5bf"}
```

## \[POST] /v1/ozys/deployContract

* **Parameters**

| Name           | Type   | Description                                 |
| -------------- | ------ | ------------------------------------------- |
| rawTransaction | String | Hex string result of signed raw transaction |

* **Return values**

| Type        | Description                         |
| ----------- | ----------------------------------- |
| JSON String | transaction hash of raw transaction |

* **Example**

```
>curl -d "rawTransaction=0xa13.....9ab" [API_DOMAIN]/v1/ozys/sendRawTransaction
{"txHash" : "0xbb508f.......5bf"}
```

## \[GET] /call/getBlockNumber

* **Return values**

| Type        | Description                        |
| ----------- | ---------------------------------- |
| JSON String | latest block number and block hash |

* **Example**

```
> curl localhost:8084/v1/ozys/call/getBlockNumber
{"number":3293487,"hash":"0x42baf6219b9234acd18ccdbde975e3a5e5f40916937f520117f7e7d038f5c991"}
```

## \[GET] /call/tx/:thash

* **Return values**

| Type        | Description                                                     |
| ----------- | --------------------------------------------------------------- |
| JSON String | Block and transaction information which transaction is included |

* **Example**

```
>curl localhost:8084/v1/ozys/call/tx/0x83f570d10d1450a72608cabedfba69ac9fa874b080fdb13696523e861d452d43
{"difficulty":"1","gasLimit":800000000,"gasUsed":94976,"hash":"0x9a7ec78f469889d89e3bdc7cdceae6a0d5409a5a5f3c0ce8eece3e1c9ffd6cad","miner":"0x0000000000000000000000000000000000000000","mixHash":"0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365","nonce":"0x0000000000000000","number":3293482,"parentHash":"0x9dfd9ed098acdb659a81c28774ba09a64179ccc7b5cd6c369262e805ef7ef464","receiptsRoot":"0x2eba27df580dab0349ef4a940b8c87d37b5daccfd37d7e97e43f492fecbc7d64","sha3Uncles":"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347","size":1341,"stateRoot":"0x3256062401094189daf95100d3a179497920a51d62a588e98761374c081a361d","timestamp":1570158014,"totalDifficulty":"3293483","transactions":[{"blockHash":"0x9a7ec78f469889d89e3bdc7cdceae6a0d5409a5a5f3c0ce8eece3e1c9ffd6cad","blockNumber":3293482,"from":"0x56153404a3518Dc63F87df060EC881028EF441b2","gas":200000000,"gasPrice":"0","hash":"0x83f570d10d1450a72608cabedfba69ac9fa874b080fdb13696523e861d452d43","input":"0xf5137c5a00000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000140000000000000000000000000c688866cf20ac5e47f34203e1b4aed2375c16ed1000000000000000000000000f50bfa247f91ddd98b7df5b0eab36db84b4833c2000000000000000000000000000000000000000000000000000000000000001c0000000000000000000000000000000000000000000000000000000000000004ed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf298a99c2ccc796be78a5950a33214da933f3deed6de7e5f89fb930cb2358abfc58c5fc36d46798a4b456f444494f1f3d53e487e9ee3669478b3ac2643e6887396b0d5a5663a939df563fb2e01cb3d55213b0a02662dc4f22d918dc629cb407b59c00000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000013bb50000000000000000000000000000000000000000000000008ac7230489e8000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001","nonce":967,"to":"0xc688866CF20aC5E47F34203e1B4AEd2375C16eD1","transactionIndex":0,"value":"0","v":"0x1c","r":"0x4d63efa6387aadbf58f841dff7820416391689eb01561e50f154e060efa4b982","s":"0x69d0ec7fc07934f2aa033498e7844e581acf68a7d5ca9090e46cbef578b674a4","receiptStatus":"0x0"}],"transactionsRoot":"0x27fc28f983dda2382b2971965d7e40c44d7aef4505ce9a2288837a21845072f3","uncles":[]}
```

## \[POST] /call/getBalance

* **Parameters**

| Name  | Type   | Description               |
| ----- | ------ | ------------------------- |
| addr  | String | Orbitchain wallet address |
| token | String | Orbitchain token address  |

* **Return values**

| Type        | Description                                                       |
| ----------- | ----------------------------------------------------------------- |
| JSON String | Json object which key is token address and value is token balance |

* **Example**

```
> curl -d "addr=0xba8b9183115b4f1716c78cbf483901df38e73b87&token=0x376fe2ae676892e508182c9e720e56a77fe68242a3e6a551bafea4027c981a98" localhost:8084/v1/ozys/call/getBalance/
{"0x376fe2ae676892e508182c9e720e56a77fe68242a3e6a551bafea4027c981a98":"0"}
```

## \[POST] /call/getNextNonce

* **Parameters**

| Name | Type   | Description               |
| ---- | ------ | ------------------------- |
| addr | String | Orbitchain wallet address |

* **Return values**

| Type | Description         |
| ---- | ------------------- |
| Hex  | Wallet's next nonce |

* **Example**

```
> curl -d "addr=0xba8b9183115b4f1716c78cbf483901df38e73b87" localhost:8084/v1/ozys/call/getNextNonce
"0x1"
```

## \[POST] /call/getBlock

* **Parameters**

| Name     | Type    | Description                       |
| -------- | ------- | --------------------------------- |
| blockNum | Integer | Target block number               |
| txObj    | Boolean | transaction object include or not |

* **Return values**

| Type        | Description            |
| ----------- | ---------------------- |
| JSON String | Block information data |

* **Example**

```
> curl -d "blockNum=3293482&txObj=true" localhost:8084/v1/ozys/call/getBlock
{"number":3293482,"hash":"0x9a7ec78f469889d89e3bdc7cdceae6a0d5409a5a5f3c0ce8eece3e1c9ffd6cad","timestamp":1570158014,"transaction":[{"blockHash":"0x9a7ec78f469889d89e3bdc7cdceae6a0d5409a5a5f3c0ce8eece3e1c9ffd6cad","blockNumber":3293482,"from":"0x56153404a3518Dc63F87df060EC881028EF441b2","gas":200000000,"gasPrice":"0","hash":"0x83f570d10d1450a72608cabedfba69ac9fa874b080fdb13696523e861d452d43","input":"0xf5137c5a00000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000140000000000000000000000000c688866cf20ac5e47f34203e1b4aed2375c16ed1000000000000000000000000f50bfa247f91ddd98b7df5b0eab36db84b4833c2000000000000000000000000000000000000000000000000000000000000001c0000000000000000000000000000000000000000000000000000000000000004ed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf298a99c2ccc796be78a5950a33214da933f3deed6de7e5f89fb930cb2358abfc58c5fc36d46798a4b456f444494f1f3d53e487e9ee3669478b3ac2643e6887396b0d5a5663a939df563fb2e01cb3d55213b0a02662dc4f22d918dc629cb407b59c00000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000013bb50000000000000000000000000000000000000000000000008ac7230489e8000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001","nonce":967,"to":"0xc688866CF20aC5E47F34203e1B4AEd2375C16eD1","transactionIndex":0,"value":"0","v":"0x1c","r":"0x4d63efa6387aadbf58f841dff7820416391689eb01561e50f154e060efa4b982","s":"0x69d0ec7fc07934f2aa033498e7844e581acf68a7d5ca9090e46cbef578b674a4"}]}
```

## \[POST] /call/getBlockLogs

* **Parameters**

| Name     | Type    | Description                       |
| -------- | ------- | --------------------------------- |
| startNum | Integer | Start block number want to search |
| endNum   | Integer | End block number want to search   |
| parse    | Boolean | Parse address or not              |

* **Return values**

| Type        | Description                        |
| ----------- | ---------------------------------- |
| JSON String | blocks information with event logs |

* **Example**

```
> curl -d "parse=true&endNum=3293482&startNum=3293480" localhost:8084/v1/ozys/call/getBlockLogs
[{"address":"0x2bcFc53CA5b854102ACa4eFD06043B0C8d5e350C","topics":["0x30b1b5fbdedaf2927859653636cb63ab6abd50b621af19a175f1490cb85118a3","0x0000000000000000000000004cc351186c3aec007cad66601aa599dc53c5d688","0x0000000000000000000000007ca39bbb6d8f68db3912384ca4b6f0526b774d98","0xed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf29"],"data":"0x0000000000000000000000000000000000000000000000008ac7230489e80000","blockNumber":3293481,"transactionHash":"0xdbf295fe597ab87c9d42891d976aefee85ddb3c00b3d5f8e961eff75e568ee78","transactionIndex":1,"blockHash":"0x9dfd9ed098acdb659a81c28774ba09a64179ccc7b5cd6c369262e805ef7ef464","logIndex":0,"removed":false,"id":"log_500c3127","ozys":"bal","oaddr":"0x2bcfc53ca5b854102aca4efd06043b0c8d5e350c","decoded":{"event":"Transfer","data":{"fromAddr":"0x4cc351186c3AEC007CAd66601aA599dC53c5D688","toAddr":"0x7cA39BbB6d8F68DB3912384Ca4B6f0526b774D98","tokenId":"0xed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf29","amount":"10000000000000000000"}}},{"address":"0x2bcFc53CA5b854102ACa4eFD06043B0C8d5e350C","topics":["0x540cb287c1b7845ba43c77af00dff093b528b8c6dd8ec0c8c51a6ff6046521b4","0x0000000000000000000000004cc351186c3aec007cad66601aa599dc53c5d688","0xed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf29"],"data":"0x00000000000000000000000000000000000000000008336e3c43246832ee1456","blockNumber":3293481,"transactionHash":"0xdbf295fe597ab87c9d42891d976aefee85ddb3c00b3d5f8e961eff75e568ee78","transactionIndex":1,"blockHash":"0x9dfd9ed098acdb659a81c28774ba09a64179ccc7b5cd6c369262e805ef7ef464","logIndex":1,"removed":false,"id":"log_ca2aa491","ozys":"bal","oaddr":"0x2bcfc53ca5b854102aca4efd06043b0c8d5e350c","decoded":{"event":"BalanceChange","data":{"user":"0x4cc351186c3AEC007CAd66601aA599dC53c5D688","tokenId":"0xed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf29","balance":"9914280731745989019178070"}}},{"address":"0x2bcFc53CA5b854102ACa4eFD06043B0C8d5e350C","topics":["0x540cb287c1b7845ba43c77af00dff093b528b8c6dd8ec0c8c51a6ff6046521b4","0x0000000000000000000000007ca39bbb6d8f68db3912384ca4b6f0526b774d98","0xed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf29"],"data":"0x000000000000000000000000000000000000314dc6448d93c3887e0e89e80000","blockNumber":3293481,"transactionHash":"0xdbf295fe597ab87c9d42891d976aefee85ddb3c00b3d5f8e961eff75e568ee78","transactionIndex":1,"blockHash":"0x9dfd9ed098acdb659a81c28774ba09a64179ccc7b5cd6c369262e805ef7ef464","logIndex":2,"removed":false,"id":"log_cd7e6773","ozys":"bal","oaddr":"0x2bcfc53ca5b854102aca4efd06043b0c8d5e350c","decoded":{"event":"BalanceChange","data":{"user":"0x7cA39BbB6d8F68DB3912384Ca4B6f0526b774D98","tokenId":"0xed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf29","balance":"1000000000000010000000000000000000"}}},{"address":"0x2bcFc53CA5b854102ACa4eFD06043B0C8d5e350C","topics":["0x30b1b5fbdedaf2927859653636cb63ab6abd50b621af19a175f1490cb85118a3","0x0000000000000000000000007ca39bbb6d8f68db3912384ca4b6f0526b774d98","0x0000000000000000000000009bebae0c6ce651a33a3cee421bdc1ff7441e28fa","0xed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf29"],"data":"0x0000000000000000000000000000000000000000000000008ac7230489e80000","blockNumber":3293481,"transactionHash":"0xdbf295fe597ab87c9d42891d976aefee85ddb3c00b3d5f8e961eff75e568ee78","transactionIndex":1,"blockHash":"0x9dfd9ed098acdb659a81c28774ba09a64179ccc7b5cd6c369262e805ef7ef464","logIndex":3,"removed":false,"id":"log_9bf60a37","ozys":"bal","oaddr":"0x2bcfc53ca5b854102aca4efd06043b0c8d5e350c","decoded":{"event":"Transfer","data":{"fromAddr":"0x7cA39BbB6d8F68DB3912384Ca4B6f0526b774D98","toAddr":"0x9BebaE0C6Ce651A33A3CEe421bDC1fF7441e28Fa","tokenId":"0xed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf29","amount":"10000000000000000000"}}},{"address":"0x2bcFc53CA5b854102ACa4eFD06043B0C8d5e350C","topics":["0x540cb287c1b7845ba43c77af00dff093b528b8c6dd8ec0c8c51a6ff6046521b4","0x0000000000000000000000007ca39bbb6d8f68db3912384ca4b6f0526b774d98","0xed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf29"],"data":"0x000000000000000000000000000000000000314dc6448d9338c15b0a00000000","blockNumber":3293481,"transactionHash":"0xdbf295fe597ab87c9d42891d976aefee85ddb3c00b3d5f8e961eff75e568ee78","transactionIndex":1,"blockHash":"0x9dfd9ed098acdb659a81c28774ba09a64179ccc7b5cd6c369262e805ef7ef464","logIndex":4,"removed":false,"id":"log_837d9efb","ozys":"bal","oaddr":"0x2bcfc53ca5b854102aca4efd06043b0c8d5e350c","decoded":{"event":"BalanceChange","data":{"user":"0x7cA39BbB6d8F68DB3912384Ca4B6f0526b774D98","tokenId":"0xed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf29","balance":"1000000000000000000000000000000000"}}},{"address":"0x2bcFc53CA5b854102ACa4eFD06043B0C8d5e350C","topics":["0x540cb287c1b7845ba43c77af00dff093b528b8c6dd8ec0c8c51a6ff6046521b4","0x0000000000000000000000009bebae0c6ce651a33a3cee421bdc1ff7441e28fa","0xed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf29"],"data":"0x000000000000000000000000000000000000314dc64514a13166c741cfda98a4","blockNumber":3293481,"transactionHash":"0xdbf295fe597ab87c9d42891d976aefee85ddb3c00b3d5f8e961eff75e568ee78","transactionIndex":1,"blockHash":"0x9dfd9ed098acdb659a81c28774ba09a64179ccc7b5cd6c369262e805ef7ef464","logIndex":5,"removed":false,"id":"log_b054444d","ozys":"bal","oaddr":"0x2bcfc53ca5b854102aca4efd06043b0c8d5e350c","decoded":{"event":"BalanceChange","data":{"user":"0x9BebaE0C6Ce651A33A3CEe421bDC1fF7441e28Fa","tokenId":"0xed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf29","balance":"1000000000637777199706039857617060"}}},{"address":"0x7cA39BbB6d8F68DB3912384Ca4B6f0526b774D98","topics":["0x8da05741ae9e80cea2ff03db92d167711736941cab1249d5979ec30f6256aa45"],"data":"0x0000000000000000000000004cc351186c3aec007cad66601aa599dc53c5d6885bb3b06a83dfd23b042f07e30555ff9c8216ddd5a087c6fcf4cbe2dfbe198caed9dabe5aff70e142d46a6c996aeec509b5be7fef87400654d5a4c8779091c6560000000000000000000000000000000000000000000000000000000000009ddb0000000000000000000000000000000000000000000000000000000000000000ed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf290000000000000000000000000000000000000000000000008ac7230489e800000000000000000000000000000000000000000000000000000000000000000001","blockNumber":3293481,"transactionHash":"0xdbf295fe597ab87c9d42891d976aefee85ddb3c00b3d5f8e961eff75e568ee78","transactionIndex":1,"blockHash":"0x9dfd9ed098acdb659a81c28774ba09a64179ccc7b5cd6c369262e805ef7ef464","logIndex":6,"removed":false,"id":"log_54220326"}]
```

## \[POST] /call/getFullBlock

* **Parameters**

| Name     | Type    | Description         |
| -------- | ------- | ------------------- |
| blockNum | Integer | Target block number |

* **Return values**

| Type        | Description                        |
| ----------- | ---------------------------------- |
| JSON String | block information with events logs |

* **Example**

```
> curl -d "blockNum=3293480" localhost:8084/v1/ozys/call/getFullBlock
{"difficulty":"1","gasLimit":800000000,"gasUsed":94976,"hash":"0x9a7ec78f469889d89e3bdc7cdceae6a0d5409a5a5f3c0ce8eece3e1c9ffd6cad","miner":"0x0000000000000000000000000000000000000000","mixHash":"0x63746963616c2062797a616e74696e65206661756c7420746f6c6572616e6365","nonce":"0x0000000000000000","number":3293482,"parentHash":"0x9dfd9ed098acdb659a81c28774ba09a64179ccc7b5cd6c369262e805ef7ef464","receiptsRoot":"0x2eba27df580dab0349ef4a940b8c87d37b5daccfd37d7e97e43f492fecbc7d64","sha3Uncles":"0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347","size":1341,"stateRoot":"0x3256062401094189daf95100d3a179497920a51d62a588e98761374c081a361d","timestamp":1570158014,"totalDifficulty":"3293483","transactions":[{"blockHash":"0x9a7ec78f469889d89e3bdc7cdceae6a0d5409a5a5f3c0ce8eece3e1c9ffd6cad","blockNumber":3293482,"from":"0x56153404a3518Dc63F87df060EC881028EF441b2","gas":200000000,"gasPrice":"0","hash":"0x83f570d10d1450a72608cabedfba69ac9fa874b080fdb13696523e861d452d43","input":"0xf5137c5a00000000000000000000000000000000000000000000000000000000000000a00000000000000000000000000000000000000000000000000000000000000140000000000000000000000000c688866cf20ac5e47f34203e1b4aed2375c16ed1000000000000000000000000f50bfa247f91ddd98b7df5b0eab36db84b4833c2000000000000000000000000000000000000000000000000000000000000001c0000000000000000000000000000000000000000000000000000000000000004ed00eb3eb3380073a132218ff0555df225b7c550cfe01bf6c4bb054137c5bf298a99c2ccc796be78a5950a33214da933f3deed6de7e5f89fb930cb2358abfc58c5fc36d46798a4b456f444494f1f3d53e487e9ee3669478b3ac2643e6887396b0d5a5663a939df563fb2e01cb3d55213b0a02662dc4f22d918dc629cb407b59c00000000000000000000000000000000000000000000000000000000000000040000000000000000000000000000000000000000000000000000000000013bb50000000000000000000000000000000000000000000000008ac7230489e8000000000000000000000000000000000000000000000000000000000000000000010000000000000000000000000000000000000000000000000000000000000001","nonce":967,"to":"0xc688866CF20aC5E47F34203e1B4AEd2375C16eD1","transactionIndex":0,"value":"0","v":"0x1c","r":"0x4d63efa6387aadbf58f841dff7820416391689eb01561e50f154e060efa4b982","s":"0x69d0ec7fc07934f2aa033498e7844e581acf68a7d5ca9090e46cbef578b674a4","receiptStatus":"0x0"}],"transactionsRoot":"0x27fc28f983dda2382b2971965d7e40c44d7aef4505ce9a2288837a21845072f3","uncles":[]}
```


# Social Networks & Media Kit

Follow and keep up to date with the Orbit Chain.

## Social Networks

* [Medium](https://medium.com/orbit-chain)
* [Telegram (Global)](https://t.me/OrbitChainGlobal)
* [Telegram (Korean)](https://t.me/Orbit_Chain)
* [Twitter](https://twitter.com/Orbit_Chain)
* [Discord](https://discord.com/channels/616813342530600960/616819866128613388)

## Media Kit

{% file src="/files/2Wda6K5YiCYCsrPBbZqg" %}