OpenST Mosaic draft sketches

OST releases OpenST Protocol 0.9.3 — fully decentralizing the OpenST Protocol gateway

Jason Goldberg
Published in
7 min readJul 25, 2018


Presents more details on the OpenST Mosaic layer-2 scaling solution for Ethereum

The OpenST Protocol is a framework for building highly scalable blockchain token economies.

Last week the OST company contributed OpenST Protocol 0.9.3 to the community. OpenST 0.9.3 further decentralizes the OpenST Protocol and improves the usability of the Protocol, as described in detail below.

OpenST 0.9.3 builds on three prior OpenST Protocol releases:

  • OpenST 0.9.0 was released by the OpenST Foundation in November 2017. OpenST 0.9.0 established a framework for businesses to mint their own Branded Tokens (e.g. Unsplash Token) on a public utility blockchain (OpenST) backed by staking the OST token on a value blockchain (e.g. Ethereum). The OpenST Protocol functions as a layer-2 scaling and sharding solution for Ethereum, allowing for transposing ownership of tokens from Ethereum to different utility blockchains and back. This framework is designed to enable businesses with tens of millions of customers to safely and securely benefit from having their own token economies on highly scalable open blockchains (offloading high transaction volumes off of public Ethereum and onto auxiliary utility chains).
  • OpenST 0.9.1 was released by the OpenST Foundation in December 2017 on Ethereum mainnet. With OpenST 0.9.1 any developer could build applications on OpenST and improve on (or even fork) the OpenST Protocol. With OpenST 0.9.1 anyone could also run their own OpenST utility chain according to the Protocol specifications.
  • The OST Company contributed OpenST 0.9.2 to the community in March 2018 along with the first alpha releases of OST KIT, OST’s blockchain developer toolkit for businesses, built on OpenST. OpenST 0.9.2 improved on prior OpenST releases by enabling “payments” between Branded Token [“BT”] holders and by providing REST APIs for OpenST. This enabled OST Company to launch OST KIT Alpha I and Alpha II earlier this year, which provided simple web-based dashboards and APIs for developers to stake OST (on testnet) towards minting their own branded tokens on OpenST utility chains (by establishing a fixed conversion rate from OST to BT), setting up various types of transaction types between BT holders (including user-to-user transactions, company-to-user, airdrops, and user-to-company), and integrating BT’s into mainstream apps to enable in-app events to trigger BT transactions and transfers. OST is currently in Alpha III with 200+ development teams participating.

OpenST Gateway Overview

At a technical level, the OpenST Protocol introduces the concept of a gateway between the Ethereum value chain and OpenST utility chains, consisting of 3 elements:

  1. A gateway contract on the value chain (also sometimes referred to as the “origin chain”).
  2. A corresponding co-gateway contract on a utility chain.
  3. A transformation function “t” that acts on tokens types defined on the value chain to transformed tokens on the utility chain.

The first type of gateway defines Branded Tokens on a utility chain with their value backed with ERC20 tokens on Ethereum mainnet. For a branded token, by definition, the gateway allows a precision mapping between the precision of the value token (OST) onto the precision of the branded token, which is expressed in the conversion rate.

The second type of gateway establishes base tokens on a utility chain at a 1:1 ratio for OST staked on the value chain, making the base token of that utility chain equivalent to OST. Each utility chain has only one such gateway, and transactions on the utility chain are therefore effectively paid in OST. Transaction fee rewards earned by validators on the utility chain are earned in OST tokens, as they can unstake the equivalent amount by redeeming the base token from the utility chain.

To achieve atomicity when transposing tokens across a gateway, OpenST combines a 2-phase commit-structure on the value chain (Ethereum) and the utility chain (OpenST) with a hash-timelock (HTL) in the contract. In short, the user first declares intention on Ethereum. She can then prove that intention with Merkle proofs against the committed state root of Ethereum on the utility chain. When she has successfully declared and confirmed the intent on both chains, she can progress by revealing the secret to the hashlock on both Ethereum and the utility chain. By doing so the value tokens are locked on Ethereum, and equivalent new utility tokens, which map to the value of the staked value tokens, are minted on the utility chain.

In the reverse process the user has to declare the intention to redeem the utility tokens on the utility chain to unstake the value tokens backing them. Doing so she can prove her intent with Merkle proofs against the committed state root of the utility chain on Ethereum. With the intent to redeem the utility tokens confirmed on Ethereum, she can progress again by revealing the secret to the hashlock, which burns the utility tokens, and unstakes the equivalent amount of value tokens from the gateway contract. This process is initiated through the co-gateway on the utility chain; we are currently developing the co-gateway.

OpenST 0.9.3 Released

With the release of OpenST 0.9.3 the gateway in OpenST is fully decentralised and any actor can move ownership across the gateway, transforming value tokens on Ethereum into utility tokens on the utility chains and back. The process currently requires the user to be online and submit transactions to two blockchains.

To make it easier for end-users OpenST 0.9.3 also introduces the concept of the “facilitator,” which can be any agent who is capable of doing the actions on behalf of the user (e.g. the OST KIT user interface and APIs function as a facilitator by handling staking and minting on behalf of OST KIT’s users). Smart contracts bind the actions of the facilitator so the user does not need to trust the facilitator; the facilitator is at risk of losing a staked bounty if she would fail to follow the process correctly.

With OpenST 0.9.3, the gateway relies only on Merkle proofs of the remote blockchain to prove user intentions, and as such we completed an implementation of “interblockchain communication”, where information can be transferred directly between blockchains without relying on the signature of a trusted party — i.e. anyone can submit the transactions containing the Merkle proofs.

OpenST Mosaic Update

Alongside the work on gateways in OpenST 0.9.3, our teams have also been making good progress on OpenST Mosaic which will eventually completely decentralize OpenST Protocol and enable it to run autonomously.

OpenST Mosaic secures utility chains and the gateways by introducing an open validator set on Ethereum whose task is to verify the blocks that have been produced by the utility chains. As the gateways hold all the value on Ethereum in staking contracts, the consensus by the validators about the state root of the utility chains finalises the redistribution of ownership for the value tokens without overhead on Ethereum (as the user needs to present a Merkle proof against this state root should she want to unstake value tokens on Ethereum, burning her utility tokens in the process). In addition, these Mosaic consensus rules can be well-constructed such that by aggregating supermajority votes and compressing fraud proofs on the utility chains — rather than directly on Ethereum — transactions on the utility chains can be considered final even before the validators commit their supermajority vote about the utility chains to Ethereum.

As such the consensus rules of OpenST Mosaic are constructed “asynchronously.” This means the security of the utility chains is not dependent on timely reporting of the final state back to Ethereum, hence avoiding timing attacks altogether. Importantly it also follows that many utility chains can be secured by Ethereum as there are no time constraints for all validators to simultaneously report back to Ethereum.

OpenST Mosaic validators will be rewarded the gas fees in OST for the transactions on the utility chains they have verified and committed to Ethereum. This new OST gas price market can be made collaborative as the security is already derived from the adversarial ETH (PoW) gas price market. As a result it is expected that the OST gas price for executing transactions on the OpenST utility chains will be notably lower than executing directly on Ethereum.

To summarize:

  • OpenST Mosaic is layer-2 scaling solution for Ethereum for finalising significantly more transactions per second on Ethereum and at a lower gas price than on Ethereum.
  • OpenST Mosaic will be usable by any Ethereum DApp, including existing ERC20 tokens.
  • OpenST Mosaic will eventually completely decentralize OpenST Protocol and enable it to run autonomously.

OST Chief Blockchain Scientist Benjamin Bollen and the OST Protocol team will be publishing an OpenST Mosaic paper in September 2018 for further feedback from the community.

Future Developments

The OpenST Protocol team is now pushing forward on OpenST 0.9.4, which improves the interface between the OpenST-Mosaic as a layer-2 scaling solution and OST KIT.

OpenST 0.9.4 will also introduce work on token holder contracts to enable user-friendly, decentralised key management solutions for mainstream apps and continue work on modular token rules for developers to design incentives in their token economies (building on the work started in OpenST 0.9.2).

OpenST 0.9.5 will test these functionalities on mainnet alongside OpenST Mosaic alpha, followed by OpenST 0.10.0, the official mainnet release enabling OST KIT Beta on mainnet.

A final note: We will publish a detailed roadmap encompassing our long term plans for OST and OpenST on 31 July, 2018.



Jason Goldberg

Founder, CEO, product at Pepo, Ost Technology, openst, mosaicdao.