End of the Year Update


Dear OPEN Community

2018 has been a busy year for us, and we are excited to share our end of the year update with you all. As shown by our consistent updates on GitHub, we have finished and released our Platform (API and Scaffold), and we are now heavily focused on developing and releasing OPEN Chain. OPEN Test Net is the first version of the OPEN Chain network and was deployed on public servers and available for use publicly September 25th 2018. We are currently underway making aggressive progress to a main net release. These releases were, as expected, released on our Github, where consistent releases and roadmap items have been completed on or ahead of schedule.

OPEN is also proud of its launch of the Blockchain Innovation Labs and collaboration with USC’s Viterbi School of Engineering. We hope to announce additional BIL partnerships in 2019.

Our OPEN Chain development began with research into various fields including network communication, transaction creation, voting, and block formation in early 2018. After significant research and subsequent publication of our OPEN Chain whitepaper, we began development on OPEN Chain, pushing our public releases in June 2018. Over the past few months, we have made immense progress:

  • Nodes: Users can now run a public node for the testnet
  • Wallet Creation: Wallets can be generated along with seed phrase/password creation
  • Dashboard: OPEN allows for users to send transactions and vote for delegates in the wallet dashboard
  • Voting: Users can vote for a delegate of their choice by entering the node’s ID and paying a transaction fee
  • Smart Contracts: Contract structure and and code analyzation mechanisms have been implemented. We are currently looking to deploy smart contracts and implement multi signature wallets
  • Security Testing: Strong results in regards to security as tests for DOS, double spend, and attack vector testing have all passed
  • Load Testing: High load testing and profiling has been completed. We are consistently looking to improve network performance
  • Stress Testing: Initial stress tests have been completed but additional tests are planned
  • Documentation: Mathematical basis for our consensus and documentation are all in progress

Platform Completion

As you know, the Platform/API has already been completed for some time now and has been ready to use by developers. The API is running on and documentation is available at Also, please visit the public GitHub repository at We encourage developers to try out the Platform/API for themselves.         

OPEN Chain

As mentioned above, we are proud to have completed the platform which includes our API and Scaffold Generator. Any developer can now deploy a scaffold onto the Ethereum blockchain and begin accepting cryptocurrency in their applications. Along with our API, we will be releasing a payment widget which will allow any website to simply embed a payment gateway.

Please visit for our complete documentation on how to deploy a scaffold and our video on our scaffold generator.

As stated in our whitepaper, we have delivered on our platform, and we look forward to developers deploying scaffolds across both centralized and decentralized applications. However, we wanted to leverage our strong technical talent to explore additional ways to disrupt the blockchain space.

Beyond our API, we felt that developing our own protocol would allow us to explore novel developments in the space by focusing on building a scalable and interoperable blockchain. We are proud of our immense progress on OPEN Chain and are excited to highlight our work below.


Running an OPEN Test Net Chain Node

To access an OPEN Chain Wallet, create a new wallet or log in to an existing wallet you need to download, install and run an OPEN Chain node.

  1. Go to OPEN Chain GitHub page at

  1. Go to “Releases” Section

  1. Download latest version of an installer for your operating system
  2. Install and run the OPEN Chain node on your computer
  3. Go to localhost:8080 in your browser

To access OPEN wallet go to localhost:8080 after running the OPEN node and create a wallet.

OPEN Chain Recent Releases

Transaction validation along with block capacity have both been developed. Ongoing improvements to transaction creation and validation are taking place in our private tests. Time synchronization and block synchronization have both been implemented. This will allow for quick verification of transaction history.

The ability to vote and see sum votes has been included. Response pagination has also been improved.

Smart Contract:
We’ve added base initialization, base entities, base service interface, and samples. With smart contract generation, a test contract has also been conducted. Loading of this contract into JVM and basic validation has been performed which are important steps towards deploying live contracts on a public chain. We have recently included the contract executor as well.

Time synchronization protocol accuracy has been improved. New client info now broadcasts across the network and expired messages are filtered. Safeguards have been implemented for failed connection attempts.

Release 1.5 (12/14):
For our most recent release on 12/14, we added our smart contract executor. We implemented a minimum number of nodes that is required to be online while maintaining a number of permanent connections. Time synchronization based on NTP servers was changed and contract variable class validation is supplemented for our smart contracts.

OPEN Chain Assets

OPEN Chain Architecture

OPEN Chain consists of our various components. We would like to detail a high level architecture before delving deeper.

Consensus Layer:
* General consensus implementation
* Approving created blocks
* Scheduling blocks production
* Defining epochs
* Handling pending blocks
* Consensus settings

This level consists of the Delegated Proof of Stake (DPoS) consensus implementation. DPoS involves delegated nodes approving and validating blocks on behalf of token holders. This allows for improved scalability and efficiency, shifting away from Proof of Work’s intensive computing requirements. Delegates are governed by the ability for any token holder to become a delegate and any token holder allowed to vote. We believe this helps create a more equitable network as delegates who act maliciously will be financially punished.

Core Layer:
* Transactions creation and validation (transfer, reward, delegation and vote transactions)
* Transaction blocks creation and validation
* Nodes delegation and active delegates appointment
* Genesis blocks creation and validation
* Blocks synchronization
* Nodes configuration
* Errors handling

The core layer encompasses a number of features such as transaction creation and validation. Users can send transactions as well as vote for delegates and network proposals also. This is also where the genesis block is created along with block synchronization and node configuration. OPEN, through tools such as the OPEN Wallet, will allow users to vote for which token holders should become a delegate. This voting system can also be translated to network governance. For example, any token holder can suggest a protocol upgrade. Token holders can decide to vote for the upgrade or pass, constructing a free market of ideas and governance in which financial safeguards are built-in to eliminate malicious players and reward strong participants.

Crypto Layer:
* Seed phrase creation and validation
* Key pairs creation and validation
* Wallet addresses creation and validation
* Transactions and blocks signing
* All coding and decoding functions

The crypto layer is focused more on end user application and use. When a user would like to create a wallet, a seed phrase is generated, serving as a unique group of words that can recover a particular address. A private key is also generated, granting access to the user. The wallet can then be used immediately. Remember to safely store seed phrases/private keys.

Network Layer:
* Setting and sustaining the connection between nodes
* Transactions and blocks distribution in the network
* All messages exchange
* Network synchronization
* RPC Layer 

The network layer plays an important role in the exchange of information between nodes. Once transactions are broadcasted it becomes important that all connected nodes have the most updated blockchain which provides the transaction history, preventing double spend. The synchronization between these nodes allows for a more efficient, scalable network.


Delegated Proof of Stake Development

OPEN Chain leverages Delegated Proof of Stake (DPoS) as its consensus mechanism. We see DPoS as an evolution over proof of work found in Bitcoin. While undoubtedly revolutionary, PoW requires vasts amount of computational power which currently requires expensive hardware and setup costs.

Delegated Proof of Stake takes a different approach through which token holders vote on delegates to confirm blocks. DPoS can be seen as more democratic as any token holder can become a delegate, provided he or she can convince other delegates to vote for them. Nodes that choose to act maliciously can be replaced by voting for other delegates.

There are three types of role in OPEN chain: User, Delegate, Active Delegate.

  1. A user is any participant of the network identified by a unique address or public key. The user is keeping an account in the system. The user is not equivalent to any person or organization in the usual sense: a person/organization can control a number of users and the user could be controlled by a number of persons/organizations.
  2. A delegate is a user responsible for the transactions validation and blocks creation in the Open Chain
  3. An active delegate is a delegate that is chosen to generate blocks.

During each epoch, the vote is held and it should be finished until the end of the current epoch. Each user can vote with his stake at the beginning of the current epoch for any user. After voting all users are ordered descending by their voting score. For the users that haven’t voted for themselves or have the stake less than a minimally allowed delegate stake, their voting scores reset to -1). The first N users are included in the list of delegates and the first Na users – in the list of active delegates (N>>Na).

The active delegates are then ordered randomly, and each active delegate is given a turn to produce a block at a fixed time slot of one block. After a fixed number of such rounds, the epoch is finished. The epoch period of time = Time_Slot*Na*Number_of_rounds. The lists of the delegates and of the active delegates are renewed at the beginning of each next epoch.

If an active delegate does not produce a block in the correspondent time slot, then that time slot is skipped, and the next active delegate produces the block for all transactions that were not included into the latest created block.

We see DPoS as a more efficient consensus mechanism required for high throughput and interoperability.


Delegates participate in the consensus process by signing votes for blocks. There are three types of a stage in the system: Idle, Prepare, Commit. A block is committed by the network when a 2/3 majority of validators had signed and broadcasted commits for that block.

At each height of the blockchain, a round-based protocol is run to determine the next block. Each round is composed of three steps, along with three special steps Vote, Precommit and Genesis.

The first step is the Idle step. At the beginning of the Idle step, the designated proposer for that round broadcasts a proposal to its peers via broadcast. If the active delegate(creator) is locked or incapacitated in epoch the system offers the next active delegate for the building block. During the Idle step, all nodes broadcast the proposal to their neighboring peers.

The Prepare step begins after the block has been created by the active delegate. At the beginning of the Vote step, each delegate makes a decision. It signs and broadcasts a prevote for the proposed block. During the Prepare step, all nodes broadcast all prevotes for the round to their neighboring peers.

At the beginning of the Precommit step each delegate makes a decision.If the block had received more than 2/3 of prevotes for a particular acceptable block then the validator signs and broadcasts a Prepare for that block. If a node had not received more than 2/3 of prevotes for a particular block, then it does not sign. During the Precommit step all nodes broadcast all precommits for the round to all neighboring peers.

At the end of the Precommit step, each delegate makes a decision. If the delegate had received more than 2/3 of precommits for a particular block, then the node enters the Commit step. If a node hadn’t yet received the block precommitted by the network, block enters the Prepare step.

If the network has passed a block after K cycles (Prepare, Vote, Precommit), then the block goes to an Extraordinary situation. In step Extraordinary network transition to the genesis of the block to shuffle the active delegates and/or setting for creating a block.

Commit step. Once the block is received by a validator it signs and broadcasts a commit for that block. The node must wait until it receives at least 2/3 of commits for the block Prepare by the network. Node sets its the current time and broadcast commit block and transitions to the New block step.  If is necessary genesis block after commit system it checks voting and sets initial configuration for the next epoch.

In the delegates menu you can find:

  1. Vote and Delegation section
  2. Delegates section
  3. Vote for a delegate tab
  4. Becoming a delegate tab
  5. All delegates tab
  6. Your votes tab


A transaction is a special data which represents the act of the value or votes transferring between users (nodes).

There are two types of transaction in Open Chain: Transfer transaction, Vote transaction.

Transfer transaction

A transfer transaction is a specially organized information with the following structure:

  1. Transaction UUID: The unique transaction identifier(32-byte integer).
  2. Timestamp: The time when the transaction was created (4-byte integer).
  3. Sender UUID: The unique User identifier (32-byte integer).
  4. Recipient UUID: The unique User identifier (32-byte integer).
  5. Value: The amount of a currency transfered (8-byte integer).
  6. Confirmations: The state of a transaction (binary).

Figure 1: Transfer transaction structure

Vote transaction

A vote transaction  is a transaction used to vote for delegates the following fields are required:

  1. Transaction UUID: The unique transaction identifier (32-byte integer).
  2. Timestamp: The time when the transaction was created (4-byte integer).
  3. Sender UUID: The unique User identifier (32-byte integer).
  4. Recipient UUID: The unique User identifier (32-byte integer).
  5. A number of votes: The number of votes forwarded (8-byte integer).
  6. Confirmations: The state of a transaction (binary).

Figure 2: Vote transaction structure

Review the transaction information and press (1) “CONFIRM” to confirm the transaction or (2) “CANCEL” to cancel the transaction.

Enter the node’s network ID to the “NODE ID” field, review transaction fee (flat fee) and press (3) “CONFIRM” to confirm your vote.

Security and Stability

Double Spending
A double spend can occur anytime a blockchain reorganization excludes a transaction previously included. This means that the witnesses had a communication breakdown caused by disruptions in the infrastructure of the Internet. With DPoS, the probability of a communication breakdown enabling a double spend attack is very low.

The network is able to monitor its own health and can immediately detect any loss in communication which shows up as witnesses failing to produce blocks on schedule. When this occurs, it may be necessary for users to wait until half of the witnesses have confirmed their transactions, which could be up to a minute or two.

Sybil Attack and Monopoly
Sybil attacks are another security vulnerability specific to peer-to-peer decentralized networks which are open and therefore allow anonymous entrants.  The main component of the Sybil attack comprises of creating a large number of pseudonymous identities. Once the identities are accepted as peers they try to gain control of the network and subvert the network from within. The network’s resilience depends on how easy it is to create an identity and be accepted as a peer. As there is no 100% fail proof firewall against these types of attacks, the best defense against Sybil attacks is to make it as impractical as possible.

Realization of attack in our network does not make sense. Creating multiple accounts will not bring benefits because the weight of the wallet and its credibility will affect the network.

Nothing-at-Stake problem
The system locks all transactions of the delegates for their delegate period. If some delegate acted maliciously against the rules of the system, his stake will be blocked for a long period of time.   

Byzantine Fault Tolerance
If there are less than 1/3 in Byzantine voting power and at least one good validator decides on a block B, then no good validator will decide on any block other than B.  Consider the earliest round R where at least one good validator commits block B at round R. This validator received more than 2/3 of precommitsfor block B at round R. Considering that less than 1/3 are Byzantine, by arithmetic at least 1/3 of good validators must have precommitted block B at round R. These good validators must have a lock on block B at round R. No other block can be committed by good validators unless some of the good validators unlock from B,which is impossible.

Proof of Live
If there are less than 1/3 in Byzantine voting power then this protocol does not deadlock. The only way the consensus process can deadlock is if two different blocks had been locked by some good validators from different rounds (a rare occurrence without an active global adversary). Say that some good validators lockedon block B and round R, and some good validators locked on block B′ at round R′, where R < R′. In this case, the proof-of-lock from R′ included in a proposal by a good validator will eventually unlock those validators locked on R allowing the consensus process to continue.

Under DPoS, every stakeholder has influence that is directly proportional to their stake, and no stakeholders are excluded from exercising this influence. Every other consensus system on the market excludes the vast majority of stakeholders from participating. Only DPoS ensures that block production is evenly distributed among most people and that everyone has an economically viable way to influence who those people are.

While the system is robust against natural chain reorganization events, there is still some potential for software bugs, network interruptions, or incompetent or malicious delegates to create multiple competing histories that are longer than a block or two. The software always selects the blockchain with the highest delegates participation rate. A delegate operating on their own can only produce one block per round and will always have a lower participation rate than the majority. There is nothing that any delegates (or minority group of delegates) can do to produce a blockchain with a higher participation rate. The participation rate is calculated by comparing the expected number of blocks produced vs the actual number of blocks produced.

Open Chain Development Snapshot

  • Smart contractsIn progress
    • Define structure — Done
    • Implement code analyzation mechanism — Done
    • Deploying — In progress
    • Execution — Planned
    • Multisignature Wallets — Planned
  • AssetsPlanned
    • Tokens (ERC20) — Planned
  • Security testingDone
    • DOS attacks — Done
    • Double spend attack — Done
    • Attack vector — Done
    • Malicious nodes — Done
  • Load testingIn progress
    • High load testing — Done
    • Profiling — Done
    • Performance improvement — In progress
  • Stress testingPlanned
    • Overload testing — Planned
  • DocumentationIn progress
    • Consensus mathematical basis — In progress
    • Consensus and Network description — In progress

Please see above for an updated technical roadmap. Significant progress and GitHub releases have been made regarding transaction creation, block formation, security testing, performance improvements, and much more. In the near future, we will be completing our work on multi signature wallets, smart contract deployment, load testing, and documentation.


In summary this past year we’ve made significant, consistent public updates completing our original roadmap and making great progress on our open source chain project combined with consistent updates on our Github from January to the end of year here in December.

We plan to continue to make our consistent regular updates as needed up until the completion of our open source chain protocol.  Despite a current temporary wane in developer interest in public protocols we hope this is temporary and look forward to increased interest in blockchain protocols and projects. We understand the industry from a development perspective is at a very early stage and we have a long way to go before we can garner developer interest similar to that of traditional or centralized technology development we see today. The objective is to see decentralized technology start to rise and eventually take a place in every day consumer or business application. Our goal now is to foster interest in our open source platform and to complete our open source Open Chain to provide a protocol as a tool for those interested in furthering blockchain technology adoption. We look forward to completing the Open Chain as our hope is that developers and interested parties among other protocols that become available utilize, contribute, fork or build upon it as a contribution to the early evolving decentralized ecosystem.

Thank you all for your support and interest – The future is OPEN!
– The OPEN Team

About the Author open