.png)
This is the second part of a 3-piece blog series on the key ideas behind the Cosmos Network.
The previous part covered the basic ideas behind early Tendermint, an approach to building a cryptocurrency without Proof of Work mining. Early Tendermint merged together a consensus algorithm based on Practical Byzantine Fault Tolerance (PBFT) with the concept of security bonds, in order to enable construction a permissionless cryptocurrency with low operating costs. These ideas were in place by the end of 2014, and early technical work on Tendermint had begun.
The logical next step would have been to conduct an ICO, and attempt to launch a currency based on the Tendermint design. Ethereum trod that path in 2014, so a precedent for that path existed. This was a fork in the road the Tendermint team did not take! It’s journey over the next two years was much richer, and the vision evolved alongside major developments in the blockchain industry. This article tells that story, and will familiarize the reader with the concept of separating out consensus and application logic, leading to application-specific blockchains.
Reading this article will immerse you into the novel possibilities of application-specific chains. The view at the end of the road is spectacular; join us on the journey!
2015 was a unique year — this was the depth of the bear market in cryptocurrency; bringing deep skepticism about the value proposition of cryptocurrency. A few, hitherto fringe, ideas came into prominence. Two of them — decentralized applications and Bitcoin sidechains — will be critical to the Cosmos vision. But we’ll postpone the ripple effects of Bitcoin sidechains to the next article in the series.
The first is the wave of decentralized applications (DApps). Inventors had been adding new applications to Bitcoin — futures contracts, gambling contracts and proof of existence applications for a while already. The Ethereum whitepaper and vision burst onto the scene, popularized the concept of a DApp, and the implementation of Ethereum as a platform for hosting DApps. A DApp can be imagined as open data and code, that lives on a decentralized network (a blockchain or a BitTorrent like network) beyond a corporation’s ownership and delivers some utility to its users. A practical example is the Ethereum Name Service (ENS), which is a decentralized registry of human meaningful names (like meher.eth) that can be owned by Ethereum accounts. A hyperbolic example, which we simply do not have the capacity to implement today, is decentralized Uber — an application with the functionality of Uber, but with all of its data, processing logic and user accounts operating on a blockchain network.
Adherents of the decentralized applications vision were making a radical leap — they were casting away new monetary instruments, like the currency bitcoin, as the centerpiece for leveraging blockchain technology and put applications — exchanges, domain names, social media, prediction markets etc. — as the theater of operation for blockchains. The launch of Ethereum in July 2015 was a seminal event, since Ethereum actually delivered the ability to build decentralized applications like ENS, albeit with a lot of constraints. The constraints were that all of the application data needed to be public, each interaction with the application required the user to bear significant transaction costs in ether and the quantity of data and processing power at an application’s disposal was reminiscent of the 1970s, rather than modern computing. Nonetheless, it was a powerful proof of concept.
Ethereum is built as a general purpose blockchain. In principle, one can write any software application to run on Ethereum. This is the key point of differentiation between the Ethereum vision for DApps, and the Cosmos vision for DApps. Sometime in 2015, the Tendermint team questioned whether a single blockchain ought to host all of the DApps, or whether each DApp ought to be hosted on its own dedicated blockchain. Is the future one of a single dominant DApp hosting platform (Ethereum), or one of a myriad blockchains, each tailored to a specific application? The Tendermint team bet on the latter vision.
This bet altered the demands from Tendermint. Early Tendermint had been developed with the goal of building cryptocurrencies. Now, the need was a deliver a general platform that allowed others to build their own blockchain hosting specifically their own application aka an application-specific blockchain. The focus shifted from the pure accounting of cryptocurrencies to hosting general application logic and data.
Node software for various blockchain networks can be divided into three functional components, each playing a different role. These components are: Networking, Consensus and Application Logic — and they can be thought of as independent modules that work together to make a blockchain node:
Until this point, Bitcoin mixed the subcomponents of these modules into an interwoven codebase. Two projects, Tezos and Tendermint, initiated the effort to separate these components neatly, so that they could be built and upgraded in parallel. Their motivations for such separation are radically different, but that’s a topic for a different day. Over time, other projects have also adopted the design pattern of separating these modules, so much so that it isn’t a particularly unique idea anymore!
Tendermint combined consensus and networking into Tendermint Core. The Application module would run concurrently, on the node, entirely separate from Tendermint Core. A protocol, called ABCI, was developed to facilitate communication between Tendermint Core and the Application module. The following diagram illustrates this new Tendermint architecture.
This concept, and its utility, is better understood via analogies. Let’s consider two analogies — your personal computer and DNA. Ponder this question: What makes a computer “your computer”? All computers share thousands of hardware and software components — cores, buses, BIOS, operating systems etc. What makes your computer yours is the data you input into the computer, and the software you configure on it. Tendermint Core is analogous to the systems that are common to all of the computers — it concerns itself with lower-level tasks like networking and consensus that all blockchains need to perform. If the reader, as an entrepreneur, launches their blockchain for a decentralized exchange and I, launch a different blockchain for a decentralized Twitter application; both our chains can be powered by Tendermint Core. Tendermint Core is akin to an operating system for blockchains.
Let’s zoom in to a blockchain running decentralized Twitter. This specific blockchain requires tailor-made logic and needs to store user data. This logic might, for instance, implement the restriction of tweet length to 140 characters; with each tweet being a transaction on the blockchain. The application data would store a giant list of all historical tweets in a query-able format. It’s the combination of application data and application logic that gives a decentralized Twitter blockchain its “Twitteriness”. Similar to how your data and the software you install make your computer uniquely yours. The new Tendermint design allowed the separation of the Twitter specific items, implemented as an application, from the other, more mundane parts of the blockchain (Tendermint Core).
This design also has inspiration from biology. If one considers the difference between one of your cells and one of mine; the majority of the machinery — amino acids, lipids, organelles etc. — are all common between the two. What differentiates our cells are the differences in our DNA. The Application logic and data, in the diagram, is analogous to DNA while Tendermint core is akin to all of those pieces that are somewhat immaterial to our specific identity.
The value proposition of this design is that future entrepreneurs, launching application-specific blockchains will need to focus only on their application logic. This is powerful in itself, but the Tendermint team went a step further with Cosmos SDK — a framework for writing blockchain applications.
While each application-specific chain has its unique data and logic, many decentralized applications tend to require similar pieces of logic, or base components. For instance, consider tokens and token transfers. Many applications — decentralized exchanges, stablecoins etc. — will require the issuance, transfer, accounting logic and delegations of token rights on the blockchain. To make the creation all of these token operations a cinch, the Cosmos SDK contains a “bank” module with prebuilt logic for token functionality. In a similar vein, the SDK contains modules for governance operations, staking operations etc. Future modules will add functionality like auctions, exchange operations, reputation operations, registry operations etc. The result will be a rich toolset of components to combine in building blockchain applications.
These SDK modules allow for the simplification of developer experience when developing blockchain applications. The aim of the SDK is to be the Ruby on Rails of blockchain applications. If this approach pans out; imagine dozens of application-specific chains hosting disparate functionality, and their own individual tokens.
This incipient world of application-specific chains, each containing their own staking token and validator community, is a powerful alternative to the Ethereum vision of DApps written as smart contracts and hosted on the Ethereum chain. While it remains to be seen how this new model shall fare, the contours of its advantages and disadvantages are already visible.
The first advantage of the application-specific model is community sovereignty — each chain is able to make design decisions tailored for the specific application at hand, independent of the choices made by other applications in their own chains. This serves to avoid contention between different application communities. We’ve seen this kind of contention emerged in the Ethereum ecosystem when the DAO was hacked, and Ethereum holders were forced to make radical decisions to repair the accounts of DAO investors. It emerged again in the Parity multisignature episode. Future upgrades to the Ethereum platform have the potential for affecting different applications differentially. This can become a bone of contention, when different application communities seek fundamentally different upgrades to the Ethereum protocol.
The second feature of the model are the better scaling and performance characteristics of each application-specific chain. Each chain need not specialize in general purpose computation, and can restrict operations to a very small set of transactions. Application logic can be implemented “closer to the metal” making it operationally cheaper. Applications also get their own dedicated capacity, and need not share that capacity with other, high transaction volume, applications. This is an important feature, since ICOs on the Ethereum platform have crowded out capacity for other applications.
However, this model creates some specific downsides. The primary downside is weaker security. Imagine thousands of chains, each carrying their own staking tokens and applications. It is likely that the majority of these tokens will have low market capitalizations (<$100 million), and therefore be vulnerable to alterations of their history. There are a few potential solutions — replicated security and sortition based security — to securing hundreds of application chains. We shall cover these methods in the blog later; but these methods will invariably encroach upon the community sovereignty of application-specific chains.
Some proponents of the Cosmos Internet of Blockchains vision believe that small market capitalization chains (aka small chains), secured by Tendermint, will be secure enough for practical purposes. Their argument is that really egregious attacks on small chains require the attacker to buy up 66% of the voting power in a relatively illiquid staking token. Such large purchases ought to drive up the market capitalization to higher levels, and reduce the incentive to attack the chain once a majority of the tokens are bought by the attacker. Another defense, available to small chain communities, is to (hard) fork out the attacker and disregard their blockchain, similar to what Ethereum did to the DAO attacker. It remains to be seen whether these arguments will survive contact with reality in the next decade.
The second downside is the potential to create application silos, where data and tokens on one application chain are unable to be synergistically used with logic on a different chain. Just as Uber drivers find it really hard to migrate to Lyft, and carry their own reputation; the blockchain sector risks the creations of similar economic incentives for the percolation of silos. Thankfully, the Tendermint team has worked out beautiful concepts, which are the subject of our next article, to route around some of these impending issues.
In this article, we’ve covered the story of how Tendermint responded to the prominence of decentralized applications, by presenting and implementing the toolsets for entrepreneurs to build application-specific chains. These application-specific chains, are potentially, better base layer infrastructure for the realization of decentralized exchange, stablecoin, prediction market, decentralized social media and other incipient technologies.
This vision naturally raises the specter of data and value silos that prevent applications from inter-operating with each other seamlessly. This will be subject of the next article in our series, which covers the development of IBC — a protocol for blockchains to send authenticated value carrying messages to each other — and of the Cosmos Hub. The next article will be last in the series and completes our exposition of the key ideas behind the Cosmos Network.
If you want to discuss Cosmos further, stop by our Chorus One Telegram and say hi. And, of course, we’re happy to answer any questions about delegating to Chorus One.
We are delighted to announce the publication of our Loom Network Investment Thesis:
So why, you might ask yourself, would Chorus One, a leading infrastructure provider for decentralized networks, write an investment thesis about a decentralized network? Isn’t that best left to research analysts? Shouldn’t infrastructure providers stick to running validator nodes?
And running a validator node is easy, right? Someone else writes the code, so you download the software, install it, configure it and you are done. Right?
Well, no. Not really. Not at all, actually.
When Chorus One commits to running a piece of decentralized infrastructure we have every intention of being highly involved with that network for years to come.
We don’t just read all the documentation available. In fact, sometimes there is very little documentation and what is there can often be out of date. So we dive into the code. We understand every detail of the consensus mechanisms, the software configuration options, the potential attack vectors and the application interfaces. We need to know how to run these nodes 24/7/365, so we have to instrument everything, i.e. we need to get visibility of everything that is happening in the network, with real-time data feeds. We need to ensure we can integrate logging, monitoring, alerting, analytics, and fully automate all aspects of the delivery pipeline.
We also commit to being highly engaged community members. We will be actively involved in every governance decision. We will monitor every pull request to see what changes are being made to the codebase to determine if they will impact the security and robustness of our infrastructure or the network at large. We propose changes to the protocols. We contribute code. We build open-source tools for other validators to use. Most importantly, we are always there for our delegators to provide them with advice, to answer their questions and to act as their technical / governance representatives in community discussions.
Most of all we evangelize. We validate on a network because we believe in its vision. The competition between networks is going to be intense. Only the networks that can clearly articulate the value they provide will survive. We are a communications partner for the networks we run. We produce blogs and video podcast updates to educate and inform users, developers, investors and other ecosystem participants.
In short, we make a major long-term investment in a network when we decide to run a validator node. And therefore, we treat the decision like an investment decision. We need to know the size of the opportunity, to map out the ecosystem, to understand the use cases, to assess the competitive threats and the regulatory landscape. We need to assess the overall strategy, the go-to-market, and the cryptoeconomics. Then we need to consolidate all of this information into an overarching thesis so that we can make a go/no-go decision.
Today we are announcing the release of our Loom Investment Thesis, a 26-page document that captures the results of our research to date. We are releasing this document to the community so that everyone can have a chance to learn about this great project.
Last Friday (February 15th) we launched our Loom validator. LOOM token holders can now delegate their tokens to us. The maximum yield on Loom tokens is currently set at 15% (after commissions) in Year 1, so it’s a great opportunity to earn returns on your crypto investment. To find out how to delegate your tokens check out our step by step tutorial here:
blog.chorus.one
Over the coming days and weeks we will be adding more content and insights on Loom. Follow us on Twitter and join our Telegram and mailing list to find our more.
Originally published at blog.chorus.one on February 18, 2019.
Staking is emerging as a way of ensuring Sybil-resistance in permission-less, public blockchain networks. Delegation protocols allow anyone holding a Proof-of-Stake (PoS) cryptoasset to participate in securing these networks and being rewarded for it. An industry surrounding the staking ecosystem is forming. Low barriers to entry mean that any party dealing with staking tokens may become involved directly or indirectly.
After learning about validation and delegation, as well as the incentives in play when considering to participate in staking, this third part of the “Proof-of-Stake Ecosystem” series will cover which players can be expected in a PoS network.
The first group of stakeholders in PoS network that comes to mind are investors, which are usually split into a retail and institutional market. But not only investors will be holding staking tokens; a significant portion is usually held by foundations funding the development of a decentralized network. Other holders include entities dealing with cryptoassets as part of their business activities or as a result of their funding. Similarly, projects hosting their applications or assets on a PoS network might consider to improve the security of it by participating in staking.
Another important stakeholder group are third party services that facilitate the purchase, trading, storage and access to cryptoassets. These will need to consider if and how they will enable their customers to participate in this emerging space. Centralized exchanges, cryptoasset custodians and wallets belong to this group.
An essential emerging part of the PoS puzzle are third party infrastructure providers that enable participation in staking for all of these token holders. This group is also referred to as staking pools, staking providers, or delegation/staking services.
Finally, block explorers, rating websites and potentially delegation marketplaces will assist token holders in choosing fitting staking providers by aggregating information and curating available delegation services, which can be done in a variety of ways. The following graphic depicts an overview of potential participants in the PoS ecosystem:
As highlighted in the second part of this series, the decision to participate in staking comes down to a cost and risk versus rewards analysis that should be carried out by each potential participant. While some may choose not to participate in staking at all, those who will are essentially faced with the decision to either run staking infrastructure themselves, delegate to (a set of) staking provider(s), or potentially a combination of the two.
In the following, I will cover each stakeholder group shortly discussing their connection to staking including some examples.
This is the most diverse group that consists of individuals owning the staking token, ranging from developers and enthusiasts to a grandma that got gifted some cryptoassets by her grandson for Christmas. Retail investors may become part of the staking ecosystem in a variety of ways depending on how they store their cryptoassets. Some technology enthusiast will run staking nodes themselves to improve decentralization of their favorite project. Others might participate in staking through the exchange they decided to leave their cryptoassets on. Some will delegate to their favorite staking providers based on their own research, other will rely on information provided by staking service curation sites or marketplaces (current examples include sites like MyTezosBaker and marketplaces like Rocketpool or Vest).
The staking space for institutional investors differs from that of retail investors, as these entities are mostly bound by regulations or other limitations guiding how they may store and utilize their cryptoassets. Institutional investors include VC firms that invested in an early stage PoS project, hedge funds that may own a staking cryptoasset, and potentially a wide range of other traditional investment companies such as family offices or even banks. These entities may simply hire their own team to run staking infrastructure. Another option would be to partner with a professional staking provider, or to participate in staking through their custodian (see below). Finally, institutional investors can also make use of delegation protocols and outsource validation work by delegating to staking services. We are already starting to see early examples of institutional investors running their own validator infrastructure (e.g. Polychain), hybrid fund/staking provider structures (e.g. Mythos Capital and Mythos Services), as well as partnerships between funds and staking providers (e.g. Bison Trails and Notation Capital).
This is a group that is seemingly largely disregarded, but that might make up a significant portion of the staking market. Many companies and projects involved in the blockchain space will or do currently hold cryptoassets that could be staked. At this point these were mostly received in ICOs or through grants, with a few crypto payment processing companies serving as examples of businesses that are holding cryptoassets.
In line with the previous group that may hold stakeable tokens received in the fundraising process or through business activities, many projects and companies involved in the blockchain ecosystem may have an interest in securing the PoS network on which their application or assets are built. By staking the network’s native cryptoasset, such projects can help to improve how difficult it is to attack the network on which they are relying. An example of a blockchain startup that voiced their interest in staking is Gnosis.
This is one of the most important and controversial participants in a PoS network, as foundations are usually controlling a large share of the staking token. Participating in staking would potentially increase a foundation’s control over the network even further. On the other hand, foundation support for staking might be necessary to secure the network (especially in the early days). Furthermore, staking may provide a way to continuously fund development of a decentralized network. Delegation also enables additional ways to support parties advancing it (e.g. by delegating to validators that contribute to the project). The Tezos Foundation’s approach is an early case study in how foundations might participate in the staking ecosystem by seeding the ecosystem and lowering their influence overtime.
Cryptocurrency wallets have a variety of choices on how they may incorporate staking opportunities in their products. Some potential directions include running their own validator infrastructure or partnering with a staking provider to offer staking to customers. Another direction would be to simply incorporating the delegation protocol and to let users decide how they want to participate in staking themselves. Here, Balance is leading the way with early experimental drafts of how staking might be integrated in their wallet.
Centralized exchanges are another interesting case, as they are essentially controlling their customers funds and may potentially participate in staking on behalf of their users. Another option could be to create some separate type of staking account in their system or integrating a delegation option in the exchange interface itself. An early examples of an exchange participating in staking is gate.io.
Some cryptoasset owners are required to store their assets with a third party and others do not want to be in control of their private keys themselves, which is why a large market of cryptoasset custody services has emerged (BitGo, Coinbase Custody, PolySign, etc.). As an example, US hedge funds with over $150 million in assets under management need to store their assets with a certified custodian. This circumstance puts custodians in a potentially powerful position in the staking economy. Custodians might run their own validator infrastructure or enable customers to delegate tokens to a set of curated partner staking providers etc. Because custodians are a strongly regulated business, it is currently unclear if and how these entities will be able to participate in staking.
Finally, one of the most important emerging parties in the staking context are professional staking providers. These are entities that are focusing on creating secure and reliable staking infrastructure for delegators and other partners. These teams can work together with all of the parties as described above. Chorus One is an example belonging to this group that aims to provide a high quality staking service in multiple Proof-of-Stake networks. Some notable other staking providers that are helping to advance and educate people around the validator and staking ecosystem include Certus One, Cryptium Labs, Figment Networks, Lunamint, and Staking Facilities.
The following post of the “Proof-of-Stake Ecosystem” series will go into some more detail regarding factors that could threaten the security of a PoS network. The series will conclude with a discussion of potential mitigation strategies.
About Chorus One
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Medium: https://medium.com/chorus-one
Slack: https://chorus.one/slack
Telegram: https://chorus.one/telegram
Originally published at blog.chorus.one on November 21, 2018.
As cryptonetworks mature and move from development to usage, cryptoassets will be utilized in many ways. For example, Proof-of-Stake networks enable token holders to participate in securing the network and receive rewards by staking their tokens. To make the most of an investment in a cryptoasset, simply holding it will likely be a suboptimal strategy. Many networks reward participation by inflating tokens and handing them out to protocol following participants resulting in a dilution of non-participating token hodlers. The following post will go into the economic considerations that go into the decision of participating in a Proof-of-Stake network.
This is the second post of the “Proof-of-Stake Ecosystem” introductory series. The first post provided a basic introduction to PoS and the concepts of validating and delegating, you can find it here in case you missed it. Upcoming posts of this series will go into more detail regarding the parties involved in a Proof-of-Stake network, their positions and potentially centralizing factors.
Until now being a long-term cryptoasset investor was a rather straightforward experience: you obtain the desired cryptoasset, store it (or leave it on an exchange) and wait. The popularized “hodl” meme is the epitome of this approach that contrasts short-term trading strategies employed by many speculative crypto investors.
With the advent of protocols that allow for utilization of crytoassets, e.g. staking in Proof-of-Stake networks or lending out tokens, the optimal strategy for long-term investors probably won’t be to simply hodl.
In the following analysis, I will focus on the incentives of participating in a Proof-of-Stake network versus alternatives, especially contrasting validation and delegation. An owner of a Proof-of-Stake cryptoasset can essentially choose from the following options:
1.) Hodl, i.e. keep tokens liquid
2.) Stake
3.) Utilize tokens in another way
From an economic perspective, a rational investor should choose the option with the highest risk-adjusted return. In practice this means that a token holder should figure out what kinds of risks are involved (ideally quantify them), what the expected returns (after subtracting costs and considering other limitations) of the various options are, and finally compare the various alternatives to each other to make the optimal decision based on her risk profile.
To do this kind of analysis, it is important to consider important factors that validating and delegating in a Proof-of-Stake network introduce. These are:
Liquidity risk is prevalent in most Proof-of-Stake protocols; there is often a lockup period associated with staking to be able to penalize potential offenders and to prevent long range attacks. Without this period a malicious party could attack the network and withdraw their stake immediately leaving no chance for the protocol to punish the offense. Because a Proof-of-Stake network is permission-less, anyone fulfilling requirements (i.e. staking enough tokens) can join the validator set. That also means that there needs to be a way to disincentivize not following the protocol. Staked tokens in a PoS network are often subject to being slashed (destroyed) should a malicious action be detected by other network participants. A common slashable offense is the signing of two blocks at the same height, also referred to as double-signing or equivocation.
Additionally, returns in a Proof-of-Stake network depend on the performance of a validator. Failing to propose or verify blocks of transactions means missing out on rewards and can even result in liveness slashings, due to being offline for some extended period of time. Continuously signing and sending messages on behalf of staked tokens as part of the consensus process requires technical and operational excellence. Sound system architecture facilitating a high degree of security is a requirement to be able to guarantee continuous operation of validator infrastructure and to avoid slashings. A validator is an attractive target for parties that want to attack a Proof-of-Stake network. Compromising a validator node could potentially allow double-spend attacks on the network at no cost to the attacker, as only the validator (and his delegators) are subject to slashings should the attack fail. There are countless attack vectors such as DDoS attacks, compromise of validation keys by rogue employees or extortion by outsiders that should be considered when designing the technical architecture and key management system of a validator.
These factors show that building and maintaining a well-performing and secure validator requires technical expertise, time and a complex infrastructure including surrounding tools. When contemplating whether to start a validator operation these requirements should be considered and the associated costs calculated. At Chorus One, by the time of launch, we will have had three people spend a significant portion of their time for roughly a year working on our Cosmos infrastructure. A rational token holder will choose to delegate to a (set of) professional delegation service(s) when the cost incurred of building and operating validator infrastructure exceeds the cost of commission paid when outsourcing validation work.
For many parties whose core business is outside of this scope of secure infrastructure and key management operations, it likely makes sense to delegate tokens to (a set of) professional validators both from a cost and risk minimization perspective.
When considering to run validator infrastructure, there is also the option of accepting delegations, i.e. turning a validator into a delegation service. Doing this will incur further costs associated with operating a validator as a business. These include costs for marketing, customer support, business development, legal, etc. This will likely require a dedicated team and the success of such an operation will largely depend on the quality of the service provided.
The following table shows the most important dimensions and the associated characteristics from the possibility space of a cryptoasset investor introduced above.
As most of the listed options (currently) exclude each other, there are opportunity costs associated with e.g. choosing to delegate instead of loaning out staking tokens. As such, it is possible that staking yields and borrowing rates will converge (as Jake Brukhman from CoinFund notes in this blog post). Furthermore, in some PoS protocols, additional considerations such as varying treatment of reward payouts can also influence decisions.
Finally, there are many not purely financial motives that might be considered when choosing how to participate in staking. These include wanting to support particular parties (especially important in light of protocol governance), improving decentralization of the network, regulatory implications, conflicts of interest, user experience, benefits of staking with a validator on multiple networks and other value-added services that a third party delegation service may provide.
I hope this post gave you a basic understanding of how to think about incentives in a Proof-of-Stake network and the possibilities and risks that token holders in such an environment face. In the next post of the “Proof-of-Stake Ecosystem” series, I will go into what parties can be expected in a PoS network.
Chorus One is a provider of staking services and validation infrastructure with a focus on providing the highest degree of security and quality possible. Our goal is to help token holders earn interest on their cryptoassets. Visit our website and contact us to find out how we could support you in upcoming Proof-of-Stake networks.
About Chorus One
Website: https://chorus.one
Twitter: https://twitter.com/chorusone
Medium: https://medium.com/chorus-one
Slack: https://chorus.one/slack
Telegram: https://chorus.one/telegram
Originally published at blog.chorus.one on November 7, 2018.
.png)
