OpenST Protocol White Paper Benjamin Bollen1, Nishith Shah, Lionello Lunesu, Sunil Khedar, Antoine Cote, Jason Banks, Jason Goldberg, Matt Chwierut, Brian Lio Draft published for peer-review, v0.8.31. Last updated 1 June, 2018. This update only reflects rebrand from Simple Token to OST “Open Simple Token.” 1 For review contact [email protected]
Definitions 2 Disclaimers 3 Executive Summary 5 Process explainer for extended team and reviewers 6 Introduction 7 Related Work 8 A Protocol for OST 10 Staking Value for Utility 10 Establishing a Bridge 10 Two Sides of the Same Token 11 Minting Utility Tokens 12 OST EIP20 15 Branded Utility Tokens 16 Making Tokens Simple 18 Nothing Lost 18 Paying in Simple Token 19 OpenST Platform 23 Network of Networks 23 OST Architecture 24 User Privacy Considerations 25 Roadmap 26 Milestone 1 : OpenST Platform v0.9 26 Milestone 2 : OpenST Platform v1.0 27 Milestone 3 : Public Launch of Initial OST Partner Companies 27 Milestone 4 : 10 Founding OST Partner Companies 27 Milestone 5 : Consolidation of OpenST as open platform 28 Acknowledgements 28 Appendix 30 Resource Paths for Branded Tokens 30 Sequence diagrams 32 Change Log 36 OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 1
Definitions ● OST (“Open Simple Token”) also referred to as “The Simple Token Project” is a project of OpenST Ltd and OST.com Limited (formerly registered as The Simple Token Company Limited). OpenST Ltd and OST.com are independent organizations with their own independent missions and governance. OpenST has contracted with OST.com in 2018 to further develop the OpenST protocol and related software. Other companies can also contract with OpenST to enhance and strengthen the protocol. ● OpenST Ltd. Also referred to as “The Foundation,” or “OpenST” is a limited by guarantee company incorporated in Hong Kong. It proposes to operate as a not-for-profit company, with all surplus revenues to be used to support the mission of the Foundation. The Foundation shall have five impartial directors on its board, with oversight over token supply, token distribution, and allocation of Foundation resources. The Foundation's intended purpose is to promote the real world application of the OpenST protocol and its implementations, referred to as “the OpenST Platform” or “the Platform.” It will have its own robust governance model. ● OST.com . (Previously known as “Simple Token Company”) or “The Company” is a for-profit Hong Kong incorporated company that is developing software and value added services based on the OpenST Platform. The relationship between OST.com and the Foundation is on a as-mutually-beneficial basis only and non-exclusive. The two companies are distinct and all services that may be provided would be on an at arms-length basis. ● Simple Tokens, or “OST” or “$OST” and previously referred to as “ST.” Tokens created by The Foundation. OST holders to can stake against launching their own Branded Tokens. ● Branded Tokens, or “BT”. Tokens created by OST Partner Companies for use within their communities, powered by OST. Branded Tokens function on side-chains and are not freely floated currencies (there’s no secondary market for branded tokens and BT are prohibited and technically incapable of being traded outside of the Partner Company’s community. ● OST Partner Companies. Companies or organizations who have been granted membership in the OST platform for the purpose of deploying Branded Tokens powered by Simple Token. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 2
Disclaimers This document is a vision document and should not be considered a specification. In the appendix we provide first iterations of specifications extracted from our work with member companies who build on the OpenST Platform. The second milestone set out in the roadmap aims to complete a first round of open peer-review to come to a first full specification. This is for general informational purposes only and may change as the Platform is developed over time. Simple Token or OST is not intended to constitute a regulated product in any jurisdiction. This explanatory note does not constitute advice to purchase anyOSTor OST, nor should this note be relied upon in connection with any contract or purchasing decision. See https://simpletoken.org/ for further information. Recipients are specifically notified as follows: ● No offer of securities: "OST" (as described in this Overview) is not intended to constitute securities in any jurisdiction. This Overview does not constitute a prospectus nor offer document of any sort and is not intended to constitute an offer or solicitation of securities or any other investment or other product in any jurisdiction. ● No advice: This OST Technical White Paper does not constitute advice to purchase any OST nor should it be relied upon in connection with, any contract or purchasing decision. ● No representations: No representations or warranties have been made to the recipient or it advisers as to the accuracy or completeness of the information, statements, opinions or matters (express or implied) arising out of, contained in or derived from this Overview or any omission from this document or of any other written or oral information or opinions provided now or in the future to any interested party or their advisers. No representation or warranty is given as to the achievement or reasonableness of any plans, future projections or prospects and nothing in this document is or should be relied upon as a promise or representation as to the future. To the fullest extent, all liability for any loss or damage of whatsoever kind (whether foreseeable or not) which may arise from any person acting on any information and opinions contained in this Overview or any information which is made available in connection with any further enquiries, notwithstanding any negligence, default or lack of care, is disclaimed. ● Risk warning: Potential purchasers should assess their own appetite for such risks independently and consult their advisors before making a decision to purchase any Tokens. ● Translations: This Overview and related materials are issued in English. Any translation is for reference purposes only and is not certified by any person. If there is any inconsistency between a translation and the English version of this Overview, the OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 3
English version prevails. Unless otherwise stated, all references to “$” and “dollars” in this Overview pertain to United States dollars. ● This Overview has not been reviewed by any regulatory authority in any jurisdiction. ● References in this Overview to specific companies and platforms are for illustrative purposes only. ● Other than The Simple Token Company Limited (“OST Company”) and the Foundation, the use of any company and/ or platform names and trademarks does not imply any affiliation with, or endorsement by, any of those parties. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 4
Executive Summary Simple Token ["OST"] is an EIP20 token2 and OpenST is a protocol to support token economies in mainstream consumer applications. The business and technical challenge we set out to solve is to enable mainstream consumer applications to benefit from deploying their own branded crypto-backed token economies, in a scalable and cryptographically auditable manner, without needing to mint and maintain their own publicly-tradeable EIP20 tokens. The OpenST protocol enables the creation of utility tokens on a utility blockchain while the value of those tokens is backed by staked crypto-assets on a value blockchain. In the first part of the paper we outline the protocol and in the second part we explain how the protocol can be applied to build the OpenST Platform which allows companies to stake OST on Ethereum mainnet to create branded tokens to use within their applications. Mainstream consumer applications can use the OpenST Platform to have a simple, integrated development experience to tokenize and build their economy with their user base. Building on OpenST also enables participating companies to benefit from network effects across the participating companies that would be much harder for companies to achieve on their own. Such benefits accrue to both the companies and their end-users; by being part of an open network of networks end-users can earn and spend seamlessly between different consumer applications. With OpenST Protocol, we build on the active work of great teams in the decentralization space and we refer to them where appropriate and in detail in the Related Work section. Simple Token solves for the user experience problem currently slowing down mainstream adoption of cryptographically secure tokens thereby enabling crypto-economics within consumer applications. Meaningfully addressing this problem requires an orchestrated effort of economic, legal, and technological engineering. In this technical white paper we focus on the mechanisms for the OpenST protocol. It is intended as a complement to the OST Project & Vision Deck and the Simple Token sidepapers. 2 ERC20 has recently been approved, and as a consequence is now referred to as EIP20. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 5
Process explainer for extended team and reviewers ● First publication date : Monday 2 October, 2017 ● Second publication date: 28th october 2017 ● Third publication date: 5th November 2017 ● Update 23 March, 2018 for rebrand from Simple Token to OST ● We want to keep this document a calm place for invited reviewers and unfiltered discussions, so we will not make this shared document publicly available; rather a duplicated version will be published publicly. ● We will produce a duplicate of this document (verbatim to best efforts of accepted comments and corrections), at regular intervals to update the version of the public document in a planned release. Only this page will be removed from open published versions. ● IMPORTANT: please add your name to the acknowledgement section if I have not already; or message [email protected] / leave a comment explicitly requesting not to be acknowledged if that is your wish. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 6
Introduction Ethereum introduced to the blockchain open and independently cryptographically toolset stateful accounts. The storage verifiable. space associated with these accounts is OpenST operates as a non-profit and write-protected by code, and we refer to governs the development of the OpenST these accounts as smart contracts3. This Protocol. In addition it performs high-level general purpose capability of Ethereum has guardian tasks on the instance of the spurred a vast wave of innovations and a protocol that is associated with the OST leading use-case of Ethereum has been the EIP20 token on public Ethereum. These ability to create a token on top of Ethereum. guardian tasks are limited but necessary For tokens on Ethereum, ERC204 has when a technical answer only is insufficient. recently been adopted as the standard A primary example can be the review of a interface for a smart contract defining such new member company which desires to a token. However in order to engineer utility launch its own branded token within the into a token to incent greater uptake, OpenST platform. several more challenges become apparent. First we establish a lexicon to help present Some of these challenges include latency, the new patterns OpenST Protocol transaction fees, scale and privacy; for introduces in the token space. For a young these challenges we attempt to contribute token economy, speculative value of a towards solutions in this technical token can easily drown out the intended whitepaper. Other challenges come from utility. We describe how a utility token can legal requirements and economic modeling be built on top of value assets that back it. to support a token economy; confronting We introduce Simple Token as a freely these forms an integral part of the OST tradable EIP20 token on Ethereum mainnet. project5. OST can be staked as a valuable With Simple Token we set out to be crypto-asset to mint utility tokens. pragmatic about the capabilities of existing Furthermore Simple Token functions as the decentralization technologies and look to base token on the utility chains accounting find answers that solve for these problems for gas consumption. today with a clear roadmap towards We continue to outline how desired internet-scale performance. All the while we behavior can be enforced on the utility strive that all technical mechanisms are tokens so that the token serves the user transactions within an existing consumer application. We call such utility tokens branded tokens. We describe how user 3 We use smart contract interchangeably for the financial sovereignty is preserved on the code associated with an account, or the stateful instantiation of that code; the meaning should be blockchain as a user can choose to clear from the context. hard-exit the value of the branded tokens on 4 See EIP20 (formerly ERC20) Ethereum mainnet. 5 Find our thinking on governance, economic In the next section of the protocol we modeling and incentives in Simple Token sidepapers. describe how rich interactions in consumer OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 7
applications can be mapped to fundamental Platform can execute. We discuss these transactions on the blockchain by providing architectural requirements lastly and how an API for developers to integrate OpenST OpenST can contribute to existing projects into their application - making the in this area. This concludes the OpenST development of a consumer tokenized Platform as the second part of this paper. economy simple. Lastly we put forward the roadmap for While these last mechanisms are off-chain OpenST. mechanisms, we consider them an integral part of the protocol to enable any third-party developer to build on top of the OpenST Related Work Platform. Additionally including them in the OpenST has been born out of the chasm protocol enables open innovation and audits between two worlds. One side holds the to realize best practices for minimizing promise of open payment networks and correlatable data on chain of financial sovereignty of users in a digital pseudo-anonymous accounts that could world. On the other side sit millions of empower inferring personally identifiable potential users for whom the technical data or application metrics. Future work in adoption curve is steep, and businesses this part of the protocol layer as such who are looking to tokenize, but who need includes technology to increase the to work within existing regulations and tax noise-to-signal ratio on-chain, or reduce the law. Challenges currently facing signal by moving it off-chain with payment cryptocurrencies and applications hoping to channels. leverage tokenization include To conclude we describe how no trust user-experience, economic and legal needs to be placed in the validator pool of constraints and the opportunities that can the utility chain, as in the case of chain be unlocked with the right technical solution. halting, all ownership state can be carried While the OpenST protocol white paper may back to the value chain. read at times like a scalability proposal - We recapitulate the protocol at a high level and obviously a scalable architecture is a using an explicit example and build on this requirement - it is not, nor do we intend it to example to illustrate how an end-user can become that. We set out to build on and use OST on Ethereum to obtain and interact contribute to the work done by great teams with a branded token. to present a protocol that helps bridge We describe how OpenST Platform can be cutting-edge blockchain technology with an open network of utility chains, serving mainstream consumer applications. different consumer applications and Interledger Protocol - Interledger uses a provided by third-parties. two-phased escrow on two ledgers where a While the OpenST Protocol and Platform connector has funds on both ledgers and concerns only application logic - and functions as a market maker between the OpenST will focus on implementing it as two chains; additionally allowing for a graph Ethereum smart contracts - and off-chain of connectors to transfer across multiple technology, it is still worthwhile to detail our hops. We drew inspiration from the considerations with respect to the available Interledger protocol, but solved for a chain technology upon which the OpenST different problem: we look to mint a new OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 8
token representation on a utility chain of the volume of transactions for their branded value staked on a value chain. token off the utility chain. In this sense Tendermint - Tendermint is a leading payment channels also aid in protecting protocol for cryptographically sealed user privacy and help shield a member Byzantine fault-tolerant, Proof-of-Stake company’s inner metrics of its application to consensus. It is used / implemented by the outside world, while being open and Ethermint, Parity and Hyperledger Burrow. accountable with their branded tokens. Cosmos - Cosmos by Tendermint is a Plasma - while we didn’t learn about framework for interoperability between Plasma until it was published, we are blockchains. It has pioneered the concept enthused that OpenST can be seen as a of InterBlockchain Communication (IBC), very specific application of some of the which we apply here in a specific context for ideas that are also abstractly proposed in transferring proofs of utility between the Plasma white paper. We welcome the Ethereum and a utility chain. alignment and look forward to mutual Cosmos as a network also provides contributions. structure between different chains. We Polkadot - Polkadot is a protocol for explore for utility chains to be natively heterogeneous general state transfer compatible as Cosmos zones (when between multiple chains. With OpenST we running Tendermint consensus). aim to solve a particular problem, but see Lightning / Raiden - work on payment benefits to strengthening the guarantees channels has both inspired the OpenST against Byzantine validators across utility protocol, and also forms a natural chains. complement to OpenST. Raiden can Casper - as OpenST spans out over many transfer Simple Token between different utility chains with all value staked on utility chains (and Ethereum mainnet). Ethereum, all work to strengthen and scale Payment channels specifically can be Ethereum greatly benefits the ecosystem, hosted by member companies to scale the and as a result OpenST. A Protocol for OST blockchain. The utility chain needs to Staking Value for Utility support lower transaction fees and lower transaction confirmation times than the The OpenST Protocol establishes a bridge value chain. We put forward this condition between two differently purposed seeing as one desired outcome of the blockchains. A value blockchain, which is OpenST Protocol is to enable required in order to hold cryptographically micro-transactions within mainstream secured valuable assets; and a utility consumer applications using the utility blockchain, which has utility tokens in favor tokens. of which the assets are held on the value OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 9
We present the discussion for two In the opposite direction, to report the latest Ethereum-based chains, but note that this is block hash of the utility chain to the value not a requirement for the value chain. chain, the logic involves no subjective Through the lens of the OST project and the threshold parameter when the utility chain is Simple Token EIP20 token on public cryptographically sealed by a known set of Ethereum, the value chain in our discussion validators as a complete light client can be is planned to be Ethereum mainnet. For the implemented as a smart contract on utility chain we consider an Ethereum-based Ethereum. chain with a Byzantine fault-tolerant In general a value chain is a Proof-of-Work consensus engine which seals blocks generated chain (for the near future at cryptographically, as examples least), while a utility chain for efficiency Proof-of-Authority6 or Proof-of-Stake reasons should be assumed to be consensus engines. cryptographically sealed. It is therefore worthwhile to note that this asymmetry is by Establishing a Bridge design: any halting or Byzantine failure of the utility chain can be proven by any user To establish a channel between two chains, on the value chain to forcefully recover the we require both chains to have a light client staked assets on the value chain after a smart contract on each chain tracking the sufficiently long grace period should the blocks on the other chain. In several utility chain fail to recover. This way users configurations prior or ongoing work already are assured to always be able to recover exists. their original assets on the value chain. On When we take into consideration the the other hand a value chain can hard-fork specifics of these chains then we can at which point the utility chain can evaluate consider specific light client contracts which out of band whether to track both or one of relieve the responsibility of a central party the forked value chains going forward. on mutually committing the latest state As a net result of having complementary hashes on the other chain. light client tracking contracts on both chains, As Ethereum mainnet operates a Nakamoto the smart contracts have at their disposition consensus engine (as the value chain) there knowledge of the state root of the other is a soft requirement to set a threshold for chain7. Such transactions committing the the number of block confirmations to wait for blocks allow consequentially for state from until a state transition on Ethereum is the other chain to be asserted as true only if considered finalised. If the utility chain is a Merkle-proof for those state variables can cryptographically validated by a known set be proven against the committed root hash. of validators then those validators can each Committing the root hash of the alternate report the block hashes they have seen on chain allows for any party to present public Ethereum and a block hash is statements of what is true on that chain, considered final when consensus among removing the need for trusted oracles or the validators is reached. 7 What we outlined here is in effect an 6 Proof-of-Authority is not Byzantine application of the concept of InterBlockchain fault-tolerant, but it can still be considered useful Communication (IBC) as proposed by in the context of utility chains. Tendermint in the Cosmos Whitepaper. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 10
trusted parties. A second benefit of this When a user adds crypto-assets on the approach is that it strengthens immutability value chain to the grouped value, she of either chain as the latest blocks are should expect to receive an equivalent anchored into an independent chain. In amount of utility tokens on the utility chain. particular if the utility chain is While we call this process minting utility cryptographically sealed, anchoring the tokens, no value is created, only a new latest block on regular intervals into a representation of that original value is (Proof-of-Work) value chain prevents any of created while the value assets themselves the validators from rewriting the block are locked. history. In the reverse process, if she can prove ownership of utility tokens and intent to Two Sides of the Same Token return them in favor of an equivalent stake of the grouped value, then our user can do Tokens form a natural basis upon which to so at any point. As the utility tokens are build functional sharding. Tokens, like backed for the full value at any time, all smart contracts, are contained within the users can “run on the bank” and they would blockchain they are defined on. Unlike all recover their full value on the smart contracts, tokens have a universal value chain. metric for coarse graining, namely their total supply, and the extrinsic property of their market valuation. Minting Utility Tokens If we consider the total supply of a token To mint utility tokens on a utility chain out of then all forms of monetary transactions value staked on a value chain, or to redeem leave the total supply of tokens unchanged. value on the value chain by relinquishing Whether it concerns a send transaction, an ownership of utility tokens on the utility escrow, or even an Interledger protocol chain, the protocol needs to atomically act exchange across different ledgers, within on two blockchains. OpenST Protocol the chain defining the tokens, the total requires a two-phased commit for either supply is unaffected by these transactions. action. To declare a utility token the user By grouping value on a value chain we can needs to deploy a staking contract with denominate that value as a new token, a hashed timelock escrow (HTLC) utility token, and transactions of the utility functionality on the value chain; on the utility token do not change the total amount of chain the user deploys a corresponding grouped value. If the utility token would be minting contract with a similar HTLC defined on the same blockchain, then we escrow, where both contracts need to be would not have gained additional linked to the respective light client contract transaction throughput capacity. However, that tracks the state root of the opposite by defining this utility token on a new chain, chain. the utility chain, transactions of the utility When a user wants to stake value she can token need not concern the value chain, transfer her crypto-assets into the escrow of and we have a logical model for functional the staking contract on the value chain. The sharding of transactions. escrow function of the staking contract must OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 11
hash the intent data8 of the user together Note that the security for the information with a staking sequence number, chain transfer between the chains is not derived identifier and the escrow time-out block from the transaction signature. Anyone can height. By storing this hash under a key in submit the mint-precommit on behalf of the the Merkle-tree a Merkle-proof can be user. Whether or not the mint-precommit is constructed that provides the hash path of valid is determined by whether it is this key and its stored value to the state root consistent and can be proven against the of the block in which this transaction is light client tracking contract. accepted (or a later block for as long as the If the minting contract on the utility chain hash is stored in the escrow). We require a determines the mint-precommit is valid and unique sequence number to be included in with sufficient time left on the staking the pre-image data to avoid a replay attack, escrow, it can mint the corresponding similarly as a sequence number is included amount of utility tokens into timed-release in a transaction. escrow9 of the minting contract to benefit The pre-image data together with the hash the user who staked the original and its Merkle-proof can now be considered crypto-assets on the value chain. as a mint-precommit. The user has To release the minted utility tokens from the declared the intent to stake a certain escrow the user needs to present a signed amount of crypto-assets on the value chain receipt to the utility chain. This receipt is the in favor of obtaining utility tokens on the mint-commit. The same mint-commit needs utility chain into the same address - as she to be presented to the value chain to move controls the private key for that address on the crypto-assets from the escrow into the the value chain, she also controls the same staking contract fully. address on the utility chain. While only the user can sign a receipt to Before the mint-precommit can be accepted complete the second phase of the minting on the utility chain, the light client tracking process, we want to ensure that the receipt contract on the utility chain needs to is first presented to the value chain before it acknowledge a block of the value chain in is presented to the utility chain. Once which the staking escrow contract holds the presented on either chain, any observer can crypto-assets of the user. Once such a carry it to the other chain. The user block is accepted, the user can submit a however can stand to benefit to only present transaction with the mint-precommit to the the receipt on the utility chain, and not on minting contract on the utility chain. The minting contract can verify the Merkle-proof 9 This escrow needs to revert before the escrow included in the mint-precommit against the on the value chain allows reverting. Safe relevant state root it can query from the light margins can be made because approximations client tracking contract; it can verify that the to the relative blockspeed of the two chains is pre-image data in the mint-precommit known and considered a constant, but the light client tracking contract allows for precise triggers hashes to the one proven by the to ensure the correct order of closing on both Merkle-proof. chains. Note that the time-out on staking escrow should be as long as acceptable as a 8 Intent data of moving crypto-assets into the mechanism design choice. The time-out on the staking contract escrow must include the asset minting escrow contract can be acceptably identifier, amount staked and the user account. short. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 12
the value chain, as it would (after long To unstake crypto-assets on the value chain time-out) release the crypto-assets from the ownership of utility tokens needs to be escrow. proven on the utility chain. This process We therefore require the user to have put runs analogous to the staking process but forward a bounty before she can start the the value chain and utility chain are two-phase minting process. Anyone who interchanged. presents the receipt to the value chain, who The user has to move her utility tokens into is not the user, will receive a fraction of the escrow on the minting contract. This bounty and the remainder is donated to a escrow contract now carries the long non-OpenST foundation. This stake gives a time-out and bounty requirement. The user strong incentive for the user to present the can construct the claim-precommit from the receipt to the value chain first (as the hash stored by the escrow resulting from signature of the receipt is unknowable by the relevant intent data and similar others until first presented) and then identifiers as we listed for the secondly she can present the receipt to the mint-precommit. She can present the utility chain for risk of never obtaining the claim-precommit to the staking contract on utility tokens she now staked for. the value chain once the light client tracking Should she not present the receipt in this contract on the value chain acknowledges order - first on the value chain, secondly on the block against which she can prove her the utility chain - she might hope to obtain claim-precommit. On validation of the both the utility tokens and eventually have claim-precommit, the staking contract can her crypto-assets reverted back to her. move the equivalent portion of the staked However by presenting the receipt on the value into escrow benefiting the user. utility chain, her signature becomes known, Similarly as before the user can only move and anyone can race to present the receipt the escrows forward by presenting a signed on the value chain before her, claiming her receipt, the claim-commit, and similarly we bounty and completing the two-phased want to ensure that she has an incentive to minting process successfully. We note that first present it to the utility chain which is while the two-phased commit can accomplished by the long time-out on this reasonably complete in three blocks on the escrow and the bounty10 to benefit any other value chain, the escrow on the staking user presenting her receipt first. contract should have a large time-out in the As there is a strong symmetry between the order of weeks (or longer) to block any two processes we will present the attempts on gaming the synchronicity of carrying back receipts between the chains. 10 This bounty needs to be put up on the utility The net effect of the two-phased commit chain for the unstaking process. The bounty process has been that the user’s cannot be put forward in a utility token as that crypto-assets are controlled by the staking would defeat the purpose of the bounty (it needs to be independently valued). The resolution lies contract on the value chain and the minting in that we need the utility chain to have a base contract on the utility chain has minted an token - like Ethereum has Ether - that pays for equivalent amount of utility tokens on the gas consumption. The user will be required to utility chain and transferred them to the put up a bounty in the base token of the utility chain. We will describe how the base token is user. obtained on the utility chain in the next section. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 13
specification of these processes in an The first use of Simple Token on Ethereum abstracted form in the specification is for a user to stake Simple Token in a documents. We call this part of the OpenST staking contract on Ethereum as the value Protocol Proof-of-Utility, as it provides chain in order to mint a newly designed cryptographic proof that a minted token on a utility token on a utility chain, which she can more performant substrate has been name and define specific behaviours for at backed with cryptographically valuable the time of creating the staking and minting assets on a different chain, anchoring the contracts. Importantly she can also at that value of the token, and freeing up its utility. point define what the conversion rate is between the value of staked assets on Ethereum and the utility token; effectively Simple Token EIP20 determining the denomination of the utility A utility chain, in this case an token. Ethereum-based chain, cannot function A special case of this minting process is without a base token that can pay for the where a staking contract and minting gas cost of transactions. On Ethereum contract is created where Simple Token is mainnet Ether is this token, and gas is - of staked at a one-to-one ratio for a utility sorts - a hidden utility token bought and sold token on the utility chain. If there are no at the beginning and end of every restrictions on who can stake additional transaction execution from and to the miner. Simple Token into the staking contract, or While on a cryptographically sealed chain unstake it, and there is no special behaviour the costs incurred by validators securing the enforced on the utility token, then the utility chain are significantly reduced11, for it to be token is freely tradable on the utility chain in an open chain12 a gas cost is still a the same way as its unstaked Simple Token requirement to protect the chain from DDOS counterpart on Ethereum. attacks. This base token needs to be a If in addition the genesis block of the utility market valued asset for a real cost to be chain specifies that at genesis eight associated with the executions of hundred million base tokens for the chain transactions on the utility chain. are awarded to this special minting contract, Simple Token (ST) will be issued at a fixed then this minting contract can award to supply of eight hundred million Simple users the base token, rather than a smart Token in an EIP20 contract on Ethereum contract defined EIP20 token. This mainnet. construction allows the creators of a utility chain to define Simple Token as the base token on that utility chain. It is important 11 The electricity cost required by Proof-of-Work here that the minting contract requires in is removed, however, the costs of Hardware this case knowledge of an upper bound on Security Modules (HSM) for production use is the number value tokens that can be staked not negligible. 12 We consider a chain open if transactions sent as the contract cannot produce new base to it are valid or invalid on their own right as tokens on the utility chain. Therefore the determined by the smart contract execution, and total supply of the tokens that can be staked anyone can connect a fully verifying node to the in favor of them needs to be have an upper peer-to-peer network and submit transaction through this node to the network. bound to. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 14
The first reason why Simple Token is issued By tokenizing an existing application, a at a constant supply is to give any utility company’s users can earn and spend token derived from staking Simple Token tokens that have redeemable external EIP20 freedom to define its own monetary value, increasing the appeal of the policy for this utility token. Having a application to new and existing users. It is constant Simple Token supply shields the worth emphasizing that this differs from monetary policies of different utility tokens. existing reward programs. As an example Secondly, as a technical benefit, a constant airline miles can be redeemed within the supply of Simple Token makes it a suitable network of services, but can only at the currency for a base token on a utility chain, discretion of the airline and at a very low as a utility chain can be created with a rate that is arbitrarily set by the airline and constant supply of base tokens in the doesn’t reflect the actual “market” value. designated minting contract. With utility tokens cryptographically backed We refer to Simple Token staked as a by crypto-assets on Ethereum users can valuable asset to obtain a freely tradable redeem the tokens they own either through utility token that has a one-to-one mapping the member company, at a price determined to Simple Token on Ethereum as Simple solely within the discretion of the member Token prime [“ ST’ ”] if it functions as the company, or forcibly through the protocol on base token on that utility chain. Simple Ethereum into Simple Token. Token prime can then be sent between Thus far we only indicated performance account balances on the utility chain and be gains by having a more performant utility charged for gas prices of transactions chain that has its capacity dedicated to a set without acting on Ethereum mainnet. In this of applications. We have not yet elaborated manner Simple Token when transferred on how utility can be constructed. To define (through the minting process) to a utility utility we require a context in which services chain effectively takes the position Ether are rendered; for Simple Token these has on Ethereum mainnet as the base token contexts are the consumer applications. that gas costs get paid in. Clearly there is A company can set out a monetary policy no block reward for Simple Token prime for the utility token in the staking smart beyond the transaction fees; no new Simple contract when it designs the token for the Token prime is awarded to validators for the purposes of its user base and puts up the act of sealing blocks. initial stake. As a consequence the staking contract needs to be whitelisted for minting new utility tokens. Otherwise any user can Branded Utility Tokens stake crypto-assets, increasing the total In the preceding sections we built up supply of the utility tokens in circulation. A mechanisms for us to obtain the capability utility token where the staking contract is to issue a token on a utility chain that has a whitelisted is called a branded token, as it known value locked in a staking contract on carries the brand of the company that put up Ethereum mainnet. We set out to have the stake to create its branded token. such a utility token to allow existing When a branded token is redeemable for its mainstream consumer applications to known value that has been staked on a tokenize the interactions of their user base. value chain, a secondary market for trading OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 15
these branded tokens is strongly For a company to be a Partner Company of suppressed. However, for existing OpenST we will require13 that the company consumer companies to tokenize the complies with signing recovery receipts for interactions of their users it could be the users if requested. important for legal reasons that no Under normal circumstances the users of a secondary market exists. branded token enter the economy through Additionally putting consumer interactions the Partner Company itself. on a blockchain has implications for user experience concerning key management and user privacy exposing correlatable data Making Tokens Simple even through pseudo-anonymous While we acknowledge the user experience addresses. for managing keys is a hard problem, so is For these reasons we look to onboard such blockchain technology for most consumer users with an embedded wallet within these companies not a core competency. applications. The embedded wallet implies To this end we include as part of the Simple that the keys owning the branded tokens Token project open-source code that helps are managed by the company on behalf of translate mapping complex user interactions the user. within the consumer application to Simple Token strongly believes in your key, fundamental transactions on the chain. your coin. To balance a good user We set out to provide a REST API that experience with ownership of private keys a logically maps to the EIP20 token interface, user can present to the company a while in the background the server handles recovery-address. The company must then signing with a hardware security module, provide signed receipts to the user’s transaction formulations and contract standalone wallet asserting which managed invocation on the relevant chain(s). While addresses belong to the user. This allows these form the basic requirements, we the user to assert off-chain that her additionally provide pessimistic concurrency managed balances are all recoverable into control to minimize the response time on the the recovery-address(es) of which only her API call and provide settlement finality at standalone wallet knows the private keys. the API level: the API will assume the most While this is an emergency mechanism, pessimistic (lowest) balance when returning should the user wish to abruptly exit the a success or failure code to the caller, while managed keys, she can present the receipts waiting for settlement finality. This way the signed by the company to the utility chain. API call can respond in the millisecond The branded tokens will then be transferred range, even when transactions take to her recovery-address, but they will be seconds to finalize on the utility chain. frozen and non-transferrable. At this point Lastly the API must provide a clean the user can only return the branded tokens mapping to smart contract events and to the minting contract to recover the translate them back to the user space. equivalent portion of the stake on the value chain. 13 This will be a legal requirement for member companies. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 16
In the appendix, we provide the resource result the crypto-assets would remain paths for interacting with branded token as locked in the staking contracts on the value an application developer for a consumer chain, even if the utility has disappeared. application together with first specifications OpenST will enable a multitude of utility for developers to integrate with the APIs. chains and thus it is critical that while the By extending Simple Token beyond the validators on any cryptographically sealed smart contracts, we not only achieve a chain are whitelisted, there should be better experience for companies developing nothing special about the instance of the on top of OpenST; we open a part of the utility chain. This is achieved when the stack crucial to future work on scalability utility chain, while stateful, can be abruptly and user privacy. exited and all ownerships proofs can be All companies can benefit from contributing effected on the value chain. best practices on minimizing exposure of In particular when the utility chain halts the user correlatable data when submitting light client contract on the value chain that transactions to the chain. If a company tracks the utility chain will no longer be able wants to integrate payment channels to to progress its acknowledged block height. radically increase transaction throughput Any user can put forward a deposit to claim and shield both its own and its users’ that the utility chain has halted at a given transaction details, that company can block height which initiates a significantly contribute such code back to OpenST for all long waiting period. Chain halting should be companies to reuse, without changing the exceptional behavior, and providing a long integration at the API layer to its own waiting period allows the validators of that application. We will in a later publication utility chain to recover and continue the detail how important technical hurdles for chain. Note that they have to be able to payment channels are mitigated within the resolve the halting building onward from the context of Simple Token. latest acknowledged block height, as the light client contract on the value chain does not allow for rolling back the block height. Nothing Lost If the validators succeed within the waiting Lastly we briefly discuss OpenST Protocol period to continue the chain, they will be in case of Byzantine behavior on the utility able to report to the light client contract a chain, or if in general it halts. higher block height resolving the claim that OpenST Protocol describes how to the chain had halted. The bounty will be atomically act on both the utility and the forwarded to a non-OpenST foundation14. value chain. However, if the utility chain If the waiting period expires without halts, then all users who hold utility tokens progressing the light client contract to a on the halted chain can no longer initiate the claim process, as no new transactions can 14 In case the chain successfully restarts the claimant loses his stake, but neither should the get processed. This makes it impossible to validators of the chain be rewarded for restarting move utility tokens into the escrow of the the chain. Therefore Ethereum foundation can minting contract, which would be the be a good candidate for rewarding such bounty minimal step required to unstake the too, as they provided Ethereum mainnet as impartial judge to resolve the chain halting crypto-assets on the value chain. As a problem. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 17
higher block height then the contract can to mint the first PepoCoin [“PC”]. PepoCoin unlock and the both the staking and utility is set here at a 100 PC for every ST. chains are deprecated. When the staking contract is unlocked a Step 1: Pepo starts out with 10.000 ST, a reduced claim process can take place. At staking contract for PepoCoin on Ethereum the height at which the utility chain has been that has no ST, and a minting contract on deprecated all Merkle-proofs for ownership the utility chain; and no PC exist on the of branded token are considered valid - utility chain. there is no need to return the branded token Ethereum Utility to the minting contract as there is only the value chain left. Pepo 10.000 ST 0 PC Note that in order to allow for Esc.Stake 0 ST recovery-addresses to be presented a time-window is inserted to present the PC Stake 0 ST recovery-receipts users may have to the value chain, before the stake can be PC Esc.Mint 0 PC effectively claimed on the value chain. Further note that the validators will have Step 2: To declare its intent Pepo moves had to stake Simple Token Prime on the 10.000OSTinto the escrow of the PepoCoin utility chain in order to be a validator. At the staking contract on Ethereum mainnet. point where the utility chain is deprecated all Ethereum Utility validators lose this stake, as it is excluded from the recovery process and these OST Pepo 0 ST 0 PC remain locked in the staking contract on Esc.Stake 10.000 ST Ethereum mainnet. PC Stake 0 ST Paying in Simple Token PC Esc.Mint 0 PC To recapitulate OpenST protocol we run Step 3: A proof of the intent by Pepo to mint over an explicit example at the highest level detailing the two-phased commit and use it one million PepoCoin out of ten thousand to illustrate how a Partner Company could Simple Token is proven on the utility chain. go about accepting Simple Token from Ethereum Utility users for services directly or to receive branded tokens. Pepo 0 ST 0 PC As an explicit example we use Pepo15 as a Esc.Stake 10.000 ST Founding Partner Company. For Milestone 1 (see Roadmap) we want Pepo to stake PC Stake 0 ST 10.000 Simple Token on Ethereum mainnet PC Esc.Mint 1.000.000 PC 15 epo.com is a local expertise mainstream P consumer application that is engaged with Simple Token to integrate OpenST early on into Pepo. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 18
Step 4: A signed receipt by Pepo is first PC Esc.Mint 0 PC presented on Ethereum to move the stake into a locked position in the staking contract. Step 7: To accept payments inOSTwithout minting new PepoCoin Pepo can have a Ethereum Utility payment-escrow contract on Ethereum. Pepo 0 ST 0 PC Alice moves her 100OSTinto the Pepo payment-escrow contract. The escrow is Esc.Stake 0 ST locked until Alice signs for having a valid receipt from Pepo. PC Stake 10.000 ST Ethereum Utility PC Esc.Mint 1.000.000 PC Pepo 0 ST 1.000.000 PC Step 5: The same signed receipt can now Esc.Pepo 100 ST be used by Pepo to release the million PC into its account. Alice 0 ST 0 PC Ethereum Utility Esc.Stake 0 ST Pepo 0 ST 1.000.000 PC PC Stake 10.000 ST Esc.Stake 0 ST PC Esc.Mint 0 PC PC Stake 10.000 ST Pepo conducts know-your-customer PC Esc.Mint 0 PC processes (KYC) on the funds received into the payment-escrow on Ethereum from Imagine Alice has 100 Simple Token on Alice. When the KYC clears, Pepo creates Ethereum mainnet and wants to obtain a managed account for Alice on the utility 10.000 PepoCoin. We will use this example chain and moves the equivalent amount of to additionally illustrate the use of managed PepoCoin into this account. Note that for accounts and keys owned by Alice herself. the managed account, Alice does not have the private key. Step 6: We add Alice to the story. She has 100OSTon Ethereum and wants to Step 8: With the KYC for Alice cleared Pepo participate in Pepo. moves 10.000 PC into a managed account for Alice. Ethereum Utility Ethereum Utility Pepo 0 ST 1.000.000 PC Pepo 0 ST 990.000 PC Alice 100 ST 0 PC Esc.Pepo 100 ST Esc.Stake 0 ST Man.Alice 10.000 PC PC Stake 10.000 ST Alice 0 ST 0 PC OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 19
her behalf and Alice can continue to verify Esc.Stake 0 ST that they are correct. PC Stake 10.000 ST Should Alice wish to hard-exit from PepoCoin, she can use the same receipts, PC Esc.Mint 0 PC but present them on the utility chain as we described before. Pepo sends Alice off-chain a signed receipt that asserts that the funds in the managed Step 10: Alice preserves her sovereignty account for Alice are in fact Alice’s because she can at any point present the (identified by her account on Ethereum). receipts from Pepo on the utility chain and Alice can verify that on the utility chain the move her managed funds on the utility chain funds have moved into a managed account into an account controlled by her. on her behalf. She can sign on Ethereum Ethereum Utility that she accepts the receipt and this releases theOSTto Pepo. Pepo 100 ST 990.000 PC Step 9: Alice receives the receipt off-chain Esc.Pepo 0 ST from Pepo and verifies that the appropriate funds are managed on her behalf within Man.Alice 0 PC Pepo. She signs the receipt on Ethereum Alice 0 ST 10.000 PC and this releases the funds to Pepo. Esc.Stake 0 ST Ethereum Utility PC Stake 10.000 ST Pepo 100 ST 990.000 PC PC Esc.Mint 0 PC Esc.Pepo 0 ST Man.Alice 10.000 PC While this hard-exit scenario should practically never occur, as it is cheaper and Alice 0 ST 0 PC more efficient to sell out of her share of PepoCoin, it is crucial that the OpenST Esc.Stake 0 ST provides an exit path where Alice can act PC Stake 10.000 ST independently, without anyone’s permission. PC Esc.Mint 0 PC Step 11: When Alice has hard-exited her PepoCoins, she can no longer use them Within the Pepo application Pepo manages within the Pepo application, but she can use the private keys of the users. Alice however the unstaking process to recover her share possesses the signed receipt she received of Simple Token on Ethereum. The from Pepo that asserts which accounts are end-result of which is given below. managed on her behalf. She presents this Ethereum Utility on Ethereum to move the Simple Token to Pepo. Pepo will continue to present her Pepo 100 ST 990.000 PC with receipts for all managed accounts on OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 20
Esc.Pepo 0 ST Man.Alice 0 PC Alice 100 ST 0 PC Esc.Stake 0 ST PC Stake 9.900 ST PC Esc.Mint 0 PC We note that this example ignored loss due to transaction fees on Ethereum, the utility chain, and commissions, fees and taxes to Pepo or applicable authorities. The example is illustrative only. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 21
OpenST Platform The OpenST Protocol described in the first in the staking contract of the branded chapter allows for value on Ethereum tokens. mainnet (the value chain) to be staked in If we consider multiple utility chains, they favor of a branded token on a utility chain. each have a base token Simple Token An important balance to strike for Simple prime, Simple Token double prime, etc. Token is to bridge a good end-user each equivalent to Simple Token on experience with actual cryptographic value Ethereum mainnet, and by transition stored on Ethereum. We require this bridge equivalent to each other. to be cryptographically secured. Even if we Existing inter-chain exchange or transfer want to be realistic and acknowledge that protocols can be applied to allow the the majority of end-users may never want to efficient value transfer of Simple Token manage their own private keys, it is (prime and double prime) between different important that any user at any point can utility chains; again without touching on decide to take control over her private keys. Ethereum mainnet, which keeps the staking Likewise, while we present utility chains as contracts for branded tokens on different a more performant and dedicated substrate chains invariant. on which applications can settle accounts, A user who holds Simple Token (with OpenST ensures at a protocol level that no Simple Token Wallet) can then seamlessly trust needs to be placed in the utility chains earn and spend across different branded or their validators, as all value can, if tokens - without needing to be aware she is needed, be recovered on Ethereum moving value across chains in the mainnet, while at the same time achieving background. transaction throughput and user privacy As an open protocol OpenST describes how using functional sharding, account different utility chains can interface with scrambling and payment channels. each other and with a value chain. In the case of the OpenST Platform Simple Token EIP20 is defined on Ethereum mainnet from Network of Networks where it allows utility chains to shard for An end-user can obtain or return branded specific applications with branded tokens. tokens through the Partner Company that Value can flow between these utility chains hosts the consumer application for Simple further catalysing the adoption of existing Token. As Simple Token prime is present protocols that solve for various needs. on the utility chain as its base token, it is It is crucial to point out that there is no also equivalent to Simple Token EIP20 on preferred entity hosting these utility chains. Ethereum mainnet. The transfer of branded While a given utility chain will have token for Simple Token transaction can dedicated validators, the OpenST Platform happen therefore on the utility chain (in itself spans across chains and any utility Simple Token prime), making it instant, and chain, hosted by any set of validators, can removing the need to stake or unstake OST interact with the other utility chains on open and equal footing. Every utility chain is OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 22
always guaranteed to be fully redeemable Partner Companies are responsible for on Ethereum mainnet and as such always funding the balances of the managed replaceable. accounts (just-in-time) with Simple Token prime17. This way there are no transaction costs charged to the user when acting Simple Token Architecture within the consumer application - but any As OpenST is an open network of utility user transferring Simple Token prime (or chains, each hosting one or more branded exiting her branded tokens to her own keys) tokens with value staked on Ethereum pays for this in Simple Token prime. mainnet, it is paramount that each utility OpenST is agnostic to the blockchain chain (and Ethereum) have a unique chain implementation used to deploy an instance identifier associated with it (derived from the of the OpenST contracts. As the OpenST genesis block that started that utility chain Platform originates from Simple Token for fork-accountable chains). All EIP20 on Ethereum mainnet, Ethereum transactions need to enforce that they are mainnet forms the pivot point for all utility only valid on the intended utility chain. chains within the OpenST platform. To this Further it is desirable that a utility chain can end we expect to work with be restricted to not accept the creation of Ethereum-based implementations, where new smart contract code when a transaction the only condition on the consensus engine deploys code to a new address. Ethereum is that a light client tracking contract can be mainnet functions as a general computation implemented on Ethereum mainnet for the substrate that allows anyone to deploy any utility chain’s specific node implementation code contract. We note that this is not a and consensus mechanism. requirement, but a preference to be decided OpenST will therefore aim to not depend on by the validators of the utility chain. a single node implementation and will want Simple Token prime is present on the utility to work with and contribute back to existing chain as the base token to account for all cryptographically sealed Ethereum gas usage. In this sense there is no blockchains. These can have a consensus requirement to make the utility chain engine that runs on Proof-of-Authority, application-specific. However, while a cost PBFT, or Proof-of-Stake Tendermint - or will be accounted for running foreign other Byzantine fault-tolerant (BFT) contracts on the utility chain, it eats into the cryptographically sealed consensus engines capacity of the chain that could otherwise 18 . be used for the branded tokens within the consumer applications. token balances into recovery-addresses for We explained that, in the case of branded which they control the private keys. tokens, by default users start out with 17 The Simple Token prime balances of accounts managed by the respective managed accounts do not get transferred to the recovery-address, as this is Simple Token prime branding Partner Company16. As such OST owned by the Partner Company. 18 We note that Proof-of-Authority (PoA) is not 16 While users start by default with managed Byzantine fault-tolerant; however a light client keys, OpenST requires they be provided - upon tracking contract for PoA can be implemented request - with signed receipts that can be on Ethereum mainnet and this strengthens the submitted to the utility chain to claim branded security guarantees a PoA-utility chain would OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 23
User Privacy Considerations As OpenST looks to connect mainstream consumers with blockchain records user privacy is paramount. To start of utility chains only store pseudo-anonymous addresses and their balances. Unlike Ethereum mainnet, because utility chains themselves only serve as an application substrate they can have a finite lifetime and user balances can over longer timespans migrate over different chains, allowing for possible and eventual erasure of these pseudo-anonymous addresses. To strengthen privacy considerations for both the member companies and their users the use of payment channels helps keep the details of microtransactions off the utility chain, only regularly settling the netting on the utility chain. Finally there may still be correlatable data from pseudo-anonymous balances extractable from the utility chain. As users for their balances of branded tokens within a consumer application are managed by the member company, user balances can be deterministically - but derived from off-chain information shared through receipts with the user - be broken up; forcefully breaking correlations between transfers on the utility chain. have, compared to running independently. This security down-grade can be balanced against the increased robustness and throughput of a PoA consensus engine. Note that a light client tracking contract on Ethereum for PoA utility chain should not naively be implemented, but improvements can be envisioned. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 24
Roadmap At the highest level this diagram represents past work and future roadmap items. Below we describe in more detail how we break down this roadmap into milestones and demos. All milestones and work items are indicative only. Milestone 1 : OpenST Platform v0.9 Expected 7 November 2017 OpenST is a comprehensive project focusing first on user-experience for member companies, as they adopt cryptographically secured tokens into their applications, and for their end-users. For this reason we want to ensure that the protocol is developed with real use-cases in mind. We’ve set out a technical vision in this document. To work towards this goal we plan a first milestone to (i) have a cryptographically auditable pathway for a member company to stake Simple Token on Ethereum testnet to create branded tokens on a utility chain (Ethereum Proof-of-Authority); (ii) have a member company’s users earn and spend branded tokens within their app (registered on a utility chain); and (iii) have a member company (a) transfer branded tokens to and (b) receive transfers of branded tokens from its users. The code for milestone 1 is published on https://github.com/OpenSTFoundation. The smart contracts implementing the protocol are in the repository openst-protocol. The middleware and api is open-sourced in the openst-platform repository. The version is v0.9.0. After the token generation event for Simple Token completes on Ethereum mainnet, the OpenST Foundation plans to deploy the OpenST platform v0.9 on Ethereum mainnet, allowing the member company developers to start building on the OpenST platform and integrating their branded tokens in their applications. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 25
See appendix for sequence diagram outlining intended functionality for Milestone 1. Milestone 2 : OpenST Platform v1.0 Q1 2018 For the OpenST platform v0.9 milestone, we preserve the two-phased commit structure to act atomically on both chains; however we monitor the process more closely by preserving a judge to act on the escrow steps; this role is taken by OpenST Foundation up to milestone 1. With milestone 2 we want to remove the judge role of OpenST, and rely on the InterBlockchain Communication transfer of Merkle-proofs to transfer the mint- and claim- precommit proofs between Ethereum mainnet and the utility chain. We also want to test the user sovereignty mechanism in milestone 2. With this milestone we look to have completed thorough security audits of the protocol and the implementation. Working towards milestone 2 we look to actively support and engage with third party developers to build on the OpenST protocol and create software and tools that provide a rich user-experience. This can take the form of grants and bounties. Milestone 3 : Public Launch of Initial OST Partner Companies Q2 2018 With milestone 1 and 2, we intend to engage with the initial member companies to introduce token economy use-cases to a small subset of their users. With milestone 3, we want to further work to improve the OpenST platform, have it reviewed by the wider crypto community, and engage with the initial member companies to prepare them to deploy the token economy use-cases to their entire user-base. Milestone 4 : 10 Founding OST Partner Companies Q3-Q4 2018 We aim for end-users to earn and spend seamlessly across member companies by continuing work on enabling standalone wallets to integrate with OpenST. We plan to standardize the OpenST API for third-party developers to build value-added services for mainstream consumer applications further stimulating the open tokenized ecosystem. Milestone 5 : Consolidation of OpenST as open platform 2019 We set out to consolidate the integration of mature decentralized scaling technologies into OpenST to support an open platform where +10.000 member companies can (without technical guidance) tokenize their existing mainstream consumer applications. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 26
Acknowledgements We thank our advisors and extended team. Smith+Crown has and continues to provide invaluable expertise on token economics. Considerations on how vibrant token economies can grow have been paramount to shape technical mechanisms presented here. Enuma Technologies has been instrumental to provide grounding blockchain engineering realism. We thank them for sharing our bold vision and working with us to break it down into a roadmap that bridges an earliest minimal utility for the protocol to an open platform for tokenized mainstream consumer applications. Special thanks go to the teams of King & Wood Mallesons and Perkins Coie for continued legal and regulatory review of the technical proposals put forward across uoh - thank you for gorgeous graphics and designs (and the incredible speed of jurisdictions. D turning these over in near real-time as we worked through technical proposals)! Very special thanks goes to Jehan Chu, John Fiorelli and the entire team at Kenetic for their support and advice from the early days of Simple Token. Last but not least, thanks to the amazing teams and support from P epo who are working closely with us to integrate the very first prototypes already into Pepo, and to Pepo’s early financial backers whose support enabled the Simple Token concepts and project to develop over the past 18 months. For their invaluable supporting work on Simple Token we thank Bok Consulting, Cure+53, and Zeppelin Solutions as auditors of our token sale smart contracts. A second paragraph is reserved for our future team members. We are hiring in Berlin, Germany and Pune, India. We have our work carved out and are looking for exceptional and driven [email protected] and share your insights people to join us on this journey. Reach out on h on Simple Token with us! If you’re not currently in those locations, we still want to hear from you. And finally let’s take a step back. We want to thank a great many amazing decentralization technology teams, often underappreciated for the hard work they deliver that keeps pushing the technology forward at mind-boggling speeds. This is truly an open-source community where the free flow of ideas and technologies makes us all stronger. Simple Token would not be possible if it could not build on ground breaking work. Simple Token and OpenST will look to earn its place in this ecosystem and contribute back where possible. Specifically thanks goes out Go-Ethereum, Solidity, Tendermint/Cosmos, Parity and the wider Ethereum community in no particular order. A word of thanks goes out to the Bitcoin community for kicking all this off, and being the first fighters for user financial sovereignty. Lastly we want to thank - again in no specific order - for discussions, advice, review and friendship [...]. All errors are our own. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 27
OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 28
Appendix Resource Paths for Branded Tokens We want a branded token to effectively behave as the established EIP20 tokens on the public Ethereum mainnet, but with the additional benefits of the architecture laid out in body of this paper. The REST APIs are therefore an extension of the familiar EIP20 interface. In the resources paths below SYM represents the respective token’s symbol. Resource path Query parameter / Result Comment GET /newkey seed=... Optional seed {"data": "0xADDR"} JSON result GET /SYM/name {"data": "Xcoin"} JSON result GET /SYM/decimals {"data": 2} JSON result GET /SYM/totalSupply {"data": 1000000000000000} JSON result GET /SYM/balanceOf owner=0xADDR Owner’s address {"data": 100000000} JSON result GET /SYM/transfer sender=0xADDR Sender’s address value=100 Token balance to=0xADDR Receiver’s address tag=upvote Optional tag {"data": "0xTXID"} JSON result GET /SYM/approve sender=0xADDR Sender’s address spender=0xADDR Spender’s address value=100 Token value of allowance tag=upvote Optional tag {"data": "0xTXID"} JSON result GET /SYM/allowance owner=0xADDR Owner’s address spender=0xADDR Spender’s address {"data": 100} JSON result OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 29
GET /SYM/transferFrom sender=0xADDR Sender’s address from=0xADDR Spender’s address value=100 Token balance to=0xADDR Receiver’s address tag=upvote Optional tag {"data": "0xTXID"} JSON result GET /SYM/log owner=0xADDR Owner’s address {"data": [{ JSON result "date": "2017-09-20T08:37:27.725Z", "from": "0xADDR", "to": "0xADDR", "value": 123, "tag": "upvote", "txid": "0xTXID" }, ...]} All REST calls MUST happen over SSL and use HTTP Basic Authentication for authenticating the Partner Company client with the Simple Token host. In addition to the exposed REST APIs, a Partner Company MAY register with the host a call back URL for receiving HTTP callbacks for side-chain events related to the branded token. This callback MUST happen over SSL using HTTP Basic Authentication to the callback URL that was provided by the Partner Company at registration time. The JSON payload for the callback is identical to a single event’s payload as it is returned by the /SYM/log REST API. OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 30
Sequence diagrams These sequence diagrams are under reservation of corrections. Milestone 1 : OpenST Platform v0.9 Deployment and staking of Simple Token OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 31
User transfers Simple Token for branded token to Partner Company User payments in branded tokens OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 32
User transfers branded token for OST to Partner Company OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 33
Change Log 2 October 2017 Published first draft for peer-review v0.8.0 28 October 2017 Improved language for protocol 23 March 2018 Improved roadmap and added links to GitHub open-source code OpenST Protocol White Paper 0.8.31 23 June 2018 All concepts and technical proposals outlined in this document are working hypotheses and subject to change and correction. 34