What’s included in this release?

OST Platform includes all of the core features and development tools needed to integrate, test and deploy Brand Tokens to end-users in production (on Ethereum mainnet). Previous alpha versions of OST Platform (known as “”OST KIT,”) enabled developers to run test transactions. OST Platform goes further and contains end-user wallets via the OST Wallet SDK, as well as Sandbox and Production modes to toggle between testing and deploying Brand Tokens.

This release moves OST Platform from private alpha to public general availability. This is a comprehensive release touching everything we work on at OST.

Below I’ve provided an overview of everything new in this release.

New OST Platform SaaS

Easy to use management dashboards for token economy setup. Mint your tokens first in Sandbox mode to quickly explore, learn, and test, then move to Production when ready to deploy.

New OST Platform APIs and Server Side SDKs

Robust RESTful APIs and SDKs to integrate your Brand Token into your applications with ease while observing the highest security standards. The Server-Side APIs and SDKs provide various endpoints/methods that can be used by developers to design and manage their Brand Token Economies.

New OST Developer Resources Center

Comprehensive documentation, guides, and API and SDK references. As a developer exploring the OST platform, we hope you enjoy engaging with the technology and interacting with the OST blockchain protocols, contracts, APIs, and SDKs.

New OST Wallet SDKs for iOS and Android

The OST Wallet SDKs enables end-users to comfortably and safely interact with Brand Tokens within existing mass-market mobile apps. Developers can integrate Brand Tokens into any app without encumbering the user experience, and take advantage of OST’s innovative wallet recovery methods.

Wallets designed for adoption by millions of consumers

With the OST Wallet SDK the user can set a 6 digit PIN to authorize Session Keys. These ephemeral Session Keys, which remain active for a period of time, remove the need for users to sign every transaction within the application. When a session expires, the user may use the 6 digit PIN to authorize a new session.

To further reduce friction, the OST Wallet SDK also supports the use of biometrics.

The intended user experience is that most users will set a 6 digit PIN and then add their biometrics. From that point on all day-to-day usage of the wallet (e.g. spend tokens ) can be done with the biometrics. The PIN is only used thereafter for recovery or if the biometrics are not functioning. (Note: The user does not need to use her PIN or biometrics to view her wallet balance or ledger, rather only to re-authorize a session to spend tokens.)

Wallet Recovery With PIN + Smart Contract

OST Platform enables users to use fully functional wallets with only setting 6 digit PINs for recovery. Normally a 6 digit PIN, on its own, does not provide enough entropy to be secure. The OST Wallet SDK achieves security by combining inputs from the user (PIN), an encrypted secret from the company, and from OST. The concatenated string undergoes a transformation through a cryptographically secure process to generate a recoveryKey that can be used to request recovery using a smart-contract. The recovery smart contract (known as the delayedRecoveryModule) enforces a 12 hour waiting period during which the user can abort the recovery request using any of their authorized devices, further protecting the user from malicious recovery requests. We encourage you to learn more about OST’s innovative wallet recovery model by reviewing the detailed specifications and SDK.

(Optionally OST clients can also enable experiences for their users to recover access to their Brand Tokens from a second device and/or recover from 12 written words, however, these are optional implementations.)

New OST Wallet UX and Implementation Guides

In this new guide, we use an example of a fictitious restaurant recommendation application, “OpenSpoon” to illustrate how a Brand could use the Wallet SDK to integrate the functionality of a user-friendly non-custodial Brand Token wallet into their application.

The UX case study aims to serve as a reference for Brand developers and to help create a faster and smoother implementation of the Wallet SDK with the application.

We demonstrate user stories around sharing favorite local food experiences to illustrate the key concepts of the Wallet SDK implementation and to present some basic ideas for Tokenization.

New OpenST Protocol Releases

OST is designed for internet-grade transaction volumes and speeds. OST leads development of the OpenST Protocol for launching Brand Token economies for mainstream businesses and OpenST Mosaic, a scaling solution for finalizing many thousands of transactions per second asynchronously on Ethereum at low cost.

OpenST Protocol 0.10.0

OpenST v0.10 focuses on enabling the OST Wallet SDK for applications to enable tokens for the end-users in their app. OpenST.js specifically is used to relay transactions from the SDK to the chains and in general interact with the constellation of contracts in the Token Economy. OpenST.js depends on Mosaic.js for managing Ethereum side chains.

OpenST.js provides abstractions for setting up and interacting with the OpenST contracts. Key new features are:

executable transactions (EIP-1077) to act on Token Rules within the economy, and improved logout() functionality for the session keys.

the user now has a Gnosis Safe multisig contract to manage multiple devices and authorize session keys in the TokenHolder contract (github.com/gnosis/safe-contracts)

the user can recover access to the multisig contract if she has lost all device keys with the DelayedRecovery module. The recoveryOwner key she can reconstruct on her new device with her 6-digit PIN mnemonic (and two separate secrets stored by OST and the application).

all the user transactions are gasless meta-transactions relayed from the SDK on the phone to the correct contracts on the side chains (automatically handled by OST Platform if used)

further improvements to include the new work on mosaic, for layer-2 scaling on Ethereum

New Mosaic Protocol Anchor Release

Mosaic 0.10.0 significantly improves the atomic message bus. It removes any time-out logic when sending atomic messages between Ethereum mainnet and a side chain, making it fully asynchronous; instead a revocation message can be sent to attempt to intercept the message before it is executed on the target chain.

Notable changes:

Gateways rely on StateRootProvider and are compatible with both Anchors and a PoS Metablockchain contract

MessageBus now operates on a finite, a-cyclical state-machine, ensuring message delivery on the target chain

Messages are now hashed following EIP-712 structured data

OST is the base coin on the side-chain and can be wrapped to ERC20, so that the same gateway logic is used for the the base coin, as for all ERC20 tokens

Facilitators can be rewarded for completing message transfers

Lacking knowledge of the hashlock secret, messages can now be progressed using multiple Merkle Patricia trie proofs only

Merkle Patricia Proof can now verify valid proof with extension nodes

Anchor uses circular buffer (L=200) to optimise storage of historic state roots

New OST.com website explaining the motivations and promise of OST Platform