Published in


Orbs: The Node Status Page, Orbs joined MouseBelt Blockchain Education Alliance, The New Lean-Helix Goroutine Model To Be Included In The Upcoming Version v1.2.0., Updated Voting Deadlines Calendar, $ORBS tokens in Metamask

Biweekly update 9th October — 23rd October


Github metrics
  • A basic status page regarding the network status was released (it shows the availability at the specific moment, not accumulation or average over time):

electricmonk has worked on fixing race conditions and flaky tests throughout the codebase. This entailed major refactors, mostly around shutting down the system in an orderly manner during tests.

Itamar Arjuan upgraded to Go 1.12.6 and switched Orbs repo and all its dependencies to use Go modules instead of vendoring.

Ron Bresler made progress with management chain, both on the research/spec front, and in development. Work is underway on the cross-chain adapter that would allow a contract running on the app chain to request data from the management chain’s state.

Ron Bresler resolved various flakiness and stability issues, and fixed a responsiveness issue in Gossip — see PR-1305.

Ido Zilberberg and Ron Bresler have finalized and released the new Lean-Helix goroutine model, to be included in the upcoming version v1.2.0. In the previous Lean-Helix goroutine model, there was only a single goroutine, that did everything — handled incoming messages and events, performed all of Lean-Helix’ logic, and also called and waited on external, time-consuming services, such as collecting transactions into a new proposed block. While the goroutine was blocked on an external service, it naturally was not available for responding to messages and events, resulting in (sometimes significant) lags in response time. In the new model, a new goroutine has been added. The new goroutine, called main loop, steps in as a proxy in front of the worker loop, and gets to handle messages and events first. If a message or events should make a long-running process obsolete, the main loop immediately cancels the context of the long-running process, signaling it to stop as soon as possible. For example — a Leader Election event makes a long-running request for a new block obsolete, because the leader node that called it has now been replaced. Previously the long-running operation would have continued, only to discover when done that its results are stale and ignored. Learn more about via the link. That solution that is described above and was developed, is half-way towards a more comprehensive solution (of creating a separate, short-lived goroutine for every increment of height or view — this is out of scope for this document). This turned out to be counterproductive and led to difficulties in reasoning about errors that cropped up. As an additional complication, the existing tests were found to be flaky (that is, were occasionally failing) so a basic condition — using tests as a safety net for changes — was not met.

Major conclusions:

  1. It is better to come up with an ambitious architecture that is sound engineering-wise than trying to come up with a seemingly quick solution that is not fully perceived by all parties as the right way to go. By “sound engineering-wise”, the meaning is easy to understand, explain to others, and debug when problems arise.
  2. Raise a red flag as soon as a basic condition of having solid tests is found to be false — the vast majority of time spent on the project was in the area of tests and this was not taken into account when planning the project. The whole project’s timeline and scope should have been rethought at that point.
  3. As a positive point — despite difficulties during testing, the contributors persevered and fixed the testing framework so it is now far better than it was before. It would have been easy to simply update the production code with the addition of a new goroutine (production code, excluding tests, was updated in one day) but this would not have been up to par with the high standard of the Orbs project.

Ido Zilberberg and Itamar Arjuan have begun project Marvin for monitoring pre-production networks. With some simplification, there are 2 such networks: testnet-master which holds a release-candidate version, and chain-on-pr which is a virtual chain that is spawned on every push to an existing PR. Monitoring the performance of these networks will:

  1. Provide confidence in the performance of a release-candidate version
  2. Provide quick feedback regression test for developers of new PRs. It will notify if the latest code change caused performance to drop or error count to rise.

Merged PRs by Noam Berg:

  1. — sanitization of contract names
  2. — worked on finalizing time based elections
  3. — self-triggering of system transaction mechanism

Merged PRs by Ido Zilberberg:

  1. Lean-Helix new goroutine model: Lean-Helix v0.2.0
  2. Apply Lean-Helix new goroutine model into Orbs: PR-1255

Technology Engagement


  1. Started working on initial wallet architecture and implemented proof of concept Firefox extension
  2. Started working on JS client SDK 2.0 to increase the security of dApps
  3. Fix 404 and 502 errors in Boyar

Application Use Cases

  1. Implemented non-fungible tokens, styled after Ethereum ERC721
  2. Built a demo for art provenance on top of erc721 library, live version

Developer Experience

  1. Added support for multiple files in contracts:

a) Support multiple files in contracts in orbs-network-go

b) Add multi-file deployment in gamma-cli

c) Add orbs.CreateDeployTransaction in Go client SDK

d) Add Client.createDeployTransaction in JS client SDK

e) Fix passing empty array of variable length to a contract in orbs-network-go

2. Update smart contract whitelist with crypto packages in orbs-network-go

3. Add contractNameToAddressAsBytes in JS client SDK

4. Add ContractNameToAddressAsBytes in Go client SDK

5. Allow experimental libraries import in smart contracts in orbs-network-go

6. Implement append only list in experimental smart contract libraries

7. Orbs project generator — new tool that allows to quickly generate scaffolding, including contracts, JS interfaces, and tests

User Facing Products

Dashboard — Created a new library to easily read ORBS POS information.

Hedron (Voting UI)

  1. Using the new orbs-pos-data library.
  2. Proxy deprecation has began
  3. It is now possible to see your ORBS tokens in Metamask!

Research and Architecture

Orbs’ research efforts continue with researchers and developers work on different aspects of the Orbs blockchain infrastructure! Here is a breakdown:

  1. (PoS Research) — draft of a spec of the staking contract (previously dubbed locking contract) and reviewed it internally (they also intend to external audit the contract before the deployment). They have decided to use a single staking contract, for both Delegators and Validators. This contract functions as a custodian retaining ORBS tokens for those who want to stake (lock) them in exchange for some rewards. The Orbs blockchain will be directly connected to the staking contract — it will track its state changes and derive reward calculations, election results, and whatever else is necessary for the PoS mechanism. Currently, this is the only staking option. Nevertheless, participating in the PoS ecosystem without staking (locking) still stands. The contract’s spec also considers easy contract migrations. In the case of a migration from one staking contract to another, the staked tokens will move without requiring to withdraw them first.
  2. (Zero-Knowledge) — The first steps towards designing a zero-knowledge-proofs software development kit, intending to make ZKPs more accessible to developers. Working towards a proof of concept that will enable developers to construct a large class of zero-knowledge systems from simpler primitives.
  3. (New Features) — The specs for the features of ’Leader activity reputation’ and ‘Trigger mechanism’ were completed, reviewed, and handed to the Dev team for implementation (see previous R&D update). The ‘Management Chain’ spec has evolved, and they further elaborate on an interesting aspect addressed in it.
  4. (Management Chain) — A critical requirement from the design of the Management Chain is to allow virtual chains (VCs) to obtain close-to real-time information from the Management Chain. Due to the asynchronous way different chains communicate, achieving this goal is not an easy task. Therefore, a simple solution might introduce a non-deterministic execution of a VC, which leads to an agreement problem. To overcome this challenge and to preserve agreement among the Validators, they add a “safe verification rule”. This rule gives a block proposer some flexibility on the possible results coming from the interaction with the Management Chain. Thus assuring that an honest proposer will pass verification with very high probability. Dishonest proposers, though, are not guaranteed to pass verification and may be subject to reputation deterioration.

Social encounters

“Students are demanding blockchain education.”

Read more about it at VentureBeat.

You can also read an article by Coindesk.

“We can’t think of a better way to reach mass adoption than sharing our knowledge base directly with the next generation of students and universities around the world.”

  • UN Hackathon: Afterthought. At the end of September, against the backdrop of the United Nations General Assembly, Orbs partnered up with the GBBC for a hackathon aimed at solving, or “hacking” sustainable development goals.

Other than Orbs and other technology partners, GBBC also teamed up with Blockchain for Social Impact (BSIC), the NYC Blockchain Center, and the New York City Economic Development Corporation (NYCEDC) to host the hackathon around “Scaling Impact for the United Nations Sustainable Development Goals”, a blockchain hackathon at the NYC Blockchain Center on September 21st and 22nd.

Sustainable development goals (or SDGs) address the global challenges humanity faces face, from global poverty to environmental degradation. The participating teams were required to choose one of the following SDGs to focus on:

  1. SDG2: Zero Hunger
  2. SDG6: Clean Water and Sanitation
  3. SDG11: Sustainable Cities and Communitie

Each of the three SDGs carried a reward of $10,000 (USD), to be granted to the best solution presented. Over the next 25 hours or so, the different teams started working on blockchain-based technological solutions to alleviating hunger, water, and sustainable cities. The networks available for use in this challenge were blockchains by Microsoft, IBM, Quorum, and Orbs.

The Winners

From the various teams which opted to use Orbs as their blockchain-of-choice (over legacy giants like Microsoft and IBM), one of them was THE WINNING TEAM!

Dynamic Digital Cooperatives, whose members are Claire Rhodes and David Acton, won the SDG2 challenge by creating a farmer-led cooperative system to connect the unconnected and transform women farmers into entrepreneurs. The reward was granted by Bernhard Kowatsch, Head of Innovation Accelerator, the United Nations’ World Food Programme.

That team managed to successfully write a complete solution, UI and Backend. Behind the scenes, there are three smart-contracts which support the recording data and transactions. David used tools such as the gamma-cli to set up his environment post-build. He was able to rapidly experiment with online IDE to prototype and test his contracts. He then also used the javascript client SDK to connect his web app to the blockchain.

Built with usability as its crown jewel, Orbs blockchain allowed them to rapidly develop. As with the supported toolchain enabling automation and a testing framework, there is really very little the engineer, David, had to worry about other than building his product.

  1. U.N Hackathon Win!
  2. Tel Aviv Blockchain Week
  3. Block TV Founder Interview
  4. ORBS on Metamask
  5. Blockchain Education Webinar
  6. New Orbs Center in Korea
  7. Enterprise Use-Case Panel
  8. KOSDAQ Delegation
  9. Korea Blockchain Week
  10. Blockchain Bridge SF
  11. Orbs Rewards Distribution: Round 2
  12. Mousebelt alliance

Upcoming events:

  1. Blockstack | Oct 23rd, San Francisco California
  2. San Francisco Blockchain Week | Oct 30th
  3. Orbs is hosting an enterprise summit event on October 30th in SF, and will share more about how the Orbs Network could be the best platform for big enterprise to develop their own blockchain use cases on top of.
  4. Also for November, the Orbs team was chosen to participate in the Singapore Fintech Festival (SFF) as part of the Israeli pavilion. This event is the largest fintech event in Singapore, hosted by the Monetary Authority of Singapore (MAS) and the Bank Association. Last year it had 45k attendees from 130 countries! More on the festival at

Orbs Universe

Delegators, in order to receive rewards, you should delegate to an active guardian who does not miss voting deadlines. If your guardian misses voting deadlines, you will not get rewards in this period.

Guardians, please note that elections are every 20000 Ethereum blocks, it is approximately 3 days. A Guardian vote is valid for about 1 week. We recommend voting every 6 days to be on the safe side.

Voting deadlines calendar (estimated)

Tools for Guardians: We launched specific delegation template for Guardians, so they can present themselves by deploying their own web-site using our instructions. Later, we are going to create other tools for the comfortable use.

This is how we use the Template to introduce ourselves:

Our GitHub with Template:

You can delegate your Orbs tokens via link. After the end of the closest voting period, you can check your rewards here.




What’s next?

According to the new Roadmap:

  1. Proof-of-Stake Core Infrastructure V2 — Implement the next version of the Orbs Proof-of-Stake architecture with various improvements making the existing implementation more efficient, easier to use and more powerful with the ability to rely on stronger incentives like locking.

2. Proof-of-Stake Ecosystem Tools — Create tools for participants in the Orbs PoS Universe. Validators will benefit from easier ways to keep their node healthy. Guardians will have better ways to measure Validators. Delegators will have easier ways to stake and observe network activity.

3. Orbs Audit Node — Audit nodes are important for network security. They allow any external participant (not necessarily a Validator) to verify that the network operation is correct. Audit nodes may choose to audit only a single or subset of virtual chains.

4. Orbs Two Tier Consensus — Two tier consensus is the hybrid aspect of Orbs. It allows to build permissioned apps — where the app can select its own block producers. These apps run over a permissionless infrastructure — where validators are selected by the network.

5. Virtual Chains Infrastructure — Virtual chains are a key feature of Orbs that provides isolation between apps. It gives the network infinite scalability and sharding; and provides apps with lower cost of operation, guaranteed resources and independent governance.

6. Validator Node Deployment V2 — The next generation of how a Validator deploys and operates an Orbs node. Improvements include efficiency for reduced operation cost, higher availability and uptime, optimizations for even more scaling and improved security.

7. Orbs Smart Contract SDK — Allow developers to build even better apps with Orbs for more versatile use cases. Developers are requesting richer API’s that support more languages, more powerful data structures and more flexible interoperability.

8. App Developer Experience — Increase developer adoption by making the app development experience on Orbs easier than ever. Help developers learn how to build on Orbs and give better developer tools to debug and test their smart contracts.

9. Ready-Made Use Case Templates — Increase business adoption of the Orbs network by offering solutions for popular blockchain use-cases. These templates reduce the integration time of blockchain technology into a business from months to days.

10. Network Production Enhancements — The Orbs network is in production mainnet from March 2019. Continue the process of making the network more mature, reliable stable, performant and secure — so it can host even bigger apps with more users and more value.

11. Protocol Enhancement Research — Long term research for core improvements to the Orbs protocol. Every big feature like privacy with zero-knowledge proofs requires months of academic research before being implemented in production and added to the core.

12. Online IDE for App Developers — Similar to Ethereum’s Remix, the online IDE lets app developers write smart contracts directly from their web browser without installing any tools. This is a great way to make experimentation with Orbs easier with less friction.

13. Prism Block Explorer — Prism is the Orbs block explorer which lets users access the chain directly, find transactions and inspect blocks. Prism is also a developer tool because it lets smart contract developers investigate their contracts and learn how they’re used.

Partnerships and team members

No updates.


  • Picture from Telegram Chat:
  • Telegram Chat serious thread:

Join Orbs Telegram Chat for more!

About Orbs

Orbs Architecture

Orbs Speed

Orbs Reliability

Orbs Virtual Chains

Social media metrics

Social media activity
Social media dynamics
Social media dynamics

The graph above shows the dynamics of changes in the number of Orbs Facebook likes, Reddit subscribers and Twitter followers. The information is taken from

This is not financial advice.

Subscribe to detailed companies’ updates by Paradigm!

Medium. Twitter. Telegram. Reddit.



Paradigm is an ecosystem that incorporates a venture fund, a research agency and an accelerator focused on crypto, DLT, neuroscience, space technologies, robotics, and biometrics — technologies that combined together will alter how we perceive reality.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store