The Joystream protocol attempts to formalize a content platform that is governed and operated by the platform users. The centerpiece of the protocol is the shared platform state, implemented on top of a blockchain consensus system, which coordinates and provides incentives to all stakeholders. Almost every aspect of a content platform is endogenous to the protocol, including.

- governance

- membership system, with screening and policing

- storage and distribution

- curated content directory

- content search, browsing, and recommendations

- software development finance and coordination

- content production financing

- advertising auctions and placement

- communication: messaging and message boards

and every subsystem is fully accountable to, and directed by, the users, as represented by the gover-

nance system. Capturing such a broad range of systems in the protocol is the distinguishing characteristic of this proposal. It is motivated by the thesis that a high level of platform accountability can be achieved by empowering two user capabilities.

First, the ability to voice discontent and subsequently implement changes based on such voices, which relies on an immutable history of actions, reliable information sharing, and binding execution of policy changes.

Second, the ability to exit the platform at a low cost and create an alternative when the platform decay has gone too far. This relies on having the entire platform state available for wholesale replication, which is not possible if critical parts of the platform state are exogenous to the protocol.


In this section, various avenues of possible or required research and inquiry are explored. — Catastrophic error recovery. Given the rich-on-chain feature set of the platform and the aspiration to conduct frequent on-chain. upgrades, the classical blockchain operations model of absolutely never having bugs in production, in perpetuity, may be too expensive. Among other costs, this requirement may reduce the speed of improvement and encourage a set of trusted developer gatekeepers. These costs are possibly dead weight for a protocol that does not intend on emphasizing operational availability and integrity above all other objectives. As a result, it may be advisable to investigate various formal and informal protocols that may be relied upon to coordinate recovery among validators from some sort of consensus failure.



The currently described model for BRAQ has at least two short comings.

First, due to the presence of an inevitably imperfect screening-based membership introduction (see section 10), the number of malicious BRAQ instances may silently grow over time. At some point, a concerted attack across such memberships can make chain throughput unavailable for some time. If such an attack is timed to cover some sensitive time period, it may automatically cause slashing of a platform member. This problem can be ameliorated by, for example, introducing sensible default transaction inclusion policies that favour non-BRAQ-based transactions or simply by including global limits on how many such transactions can be accepted at any given time, perhaps being implemented as a BRAQ instance itself.

Second, the actual quota is not sensitive to payloads involved in actions, only the number of actions. This is not fit for a range of different purposes and can easily be amended.


The obvious problem and risk in using ATP is regarding coming up with a safe time period for a given transaction, which may also depend on the payload. Moreover, its not entirely clear how a validator must treat the scenario where the processing is not finished, despite the time being up. The simplest approach is to consider it as any other node failure, such as running out of resources, and simply stop the node.

There is also the opportunity of saving on processing resources by making the current proposal into a challenge response protocol. In this alternative approach, the final state can be proposed by anyone, subject to some bond, and this proposal can be challenged by anyone during a challenge period. In a challenge, all validators can actually conduct the normal ATP processing and, this way, adjudicate the final dispute securely. A challenger found to be correct will win the bond.

Another obvious alternative to the entire ATP approach are things like ZkSNARK and Truebit. However, this would impose severe practical limitations on what processing which within scope. For ZkSNARK, it will be, at present, infeasible to generate proofs for just about all processing that can warrant ATP to begin with, by assumption. For both the approaches, one can almost never reuse the existing implementations of the processing in question, even if it is in principle compatible with the approach-specific computing model (e.g. WASM or register machine), which is also not always going to be the case.

- Governance

The current proposal for how governance and elections are organised is relatively naive to obvious problems around liveness, vote buying, and validator censorship. This despite governance being at the heart of the capabilities of the platform and the incentive compatibility of the protocol every other actor faces depends on how effective this process is. Most of the work in this proposal is about how to endow a presumed effective governance system with all the assets constituting a functional content platform. Further work on incorporating more mature ideas is needed.

- Screening and suspension and seb 2.0 assets

One of the biggest weaknesses of the current proposal is that it may or may not be feasible to manage the integrity of the memberships that are established through screening, in particular since it may be difficult to properly identify malicious attacks in production and, even if one could, the corresponding screening authority may no longer be bonded. The most obvious solution to this problem is to make a screening authority the owner of screened memberships and disable them when the authority unbonds. Members could get rescreened with a new authority, using the old keys, in order to preserve their membership. This may coincidentally ameliorate one of the other primary limitations of the platform, due to the state of current infrastructure, which is the inability to properly own assets such as domains and app store entries. An ecosystem of such screeners can own these assets, conduct their own screening procedure, and capture in the upside the membership base they bring to the platform.

- Software development

Keeping this entire development process has resource costs, not primarily in throughput capacity but state size. For example, a very mature large open-source project may have a Git repository that occupies dozens of gigabytes in, primarily, commit object blobs. This is not a non-starter, per say, but clearly has costs that need to be recognized. There are other approaches, such as the OSCoin and the Radicle stack, which aim to keep the entire process off chain, extend the Git protocol to also incorporate the collaborative assets, and delegate consensus to a trusted set of actors. This does not satisfy all the outlined requirements and begs the question of how to make the consensus actors accountable to the platform; however, it has the benefit of being cheaper on the platform blockchain.

Another issue requiring further work is how to safely update the platform in concert with user facing applications that make assumptions about how the platform functions at any given point of time. This is further complicated by the objective of wanting to use the platform itself, as the infrastructure to do the application updates.

- Storage and distribution

The major problem in the current approach is that all user-downloaded events result in a set of transactions and leave a permanent public history of downloads. This is infeasible from both a capacity and privacy perspective. The alternative currently being explored involves offloading these transactions into a separate chain with trust model based on fraud proofs, and governance to ensure availability, inspired by the Plasma framework. By committing blocks, and in particular state commitments, into the main blockchain, it becomes possible to make positive claims about the current state in the parallel chain at different times, such as the total amount of data a distributor has moved or the total number of downloads for a particular data object. Expired or fraudulent states can be challenged in the same way during an exit period. Privacy can be introduced by allowing members to use pseudonymous identifier in the parallel chain, which can be proven to match a main chain membership through an appropriate ZkSNARK. The disadvantage of this approach is the complexity and latency of main chain state changes. An alternative can be to dramatically change the trust model and rely on data being shared entirely out of band w.r.t. any shared public state, and then having a voting process-based main chain update based on this objective verifiable data.

A secondary objective is to replace full replication with erasure coding for each data object such that less total storage space is required for a given level of fault based on unavailability risk. This makes the storage costs lower.


This document aims to give a high-level overview of the design approach for of a new protocol for content platforms. This is an evolving document meant as a basis for an iterative review, technical specification and testing, and revised versions will be developed on the basis of that process. Multiple aspects of the protocol are still subject to active research, and any part of the current design may be amended or entirely abandoned as a result of subsequent considerations. Lastly, the descriptive resolution varies substantially across the proposal as a result of different parts at radically different levels of maturity.


Due to a mixture of conspiring factors, such as platform externalities, economies of scale and, jurisdictional arbitrage, dominant contemporary Internet platforms have become some of the least accountable organizations today. The traditionally constraining institutions of market competition, regulation and litigation

simultaneously appear to be unable to push back against their market power. The social cost of this equilibrium is multifaceted, leading to lower innovation, platform rents, and more broadly to the fact that platform policy is only incidentally, not primarily, guided by the objectives of the largest platform stakeholder: users.

Users should be broadly understood as anyone who is participating on a platform in any capacity.


The Joystream protocol is stateful, and the infrastructure for the secure distribution and updating of this state is a blockchain system. A given instantiation of the Joystream protocol runs on its own single-purpose blockchain infrastructure, which only processes transactions related to this instantiation. In the rest of the document, this blockchain will be treated as a silent transaction ordering mechanism; however, in the following section, it will briefly describe the assumptions on the blockchain infrastructure in the protocol design. Here, and in the rest of the document, the platform or platform state will refer to the state upon which transactions operate. In Bitcoin, for example, this would be the UTXO set and be distinctive from the state of the underlying blockchain infrastructure itself, namely the actual chain of blocks designated by the chain selection rule.


The blockchain has a consensus algorithm in the classical BFT algorithm family that is adapted to use Proof-of-Stake-based voting power for a dynamic validator set. A designated platform token, described further in section 5, is used by the validators to stake and is also the unit in which they are rewarded. There is a growing set of such consensus protocols and the following general properties of these systems are of importance to the protocol design. — High throughput and low latency: In benchmarks, these algorithms have been shown to support combinations of confirmation latency, transaction throughput, validator count, and geographic distribution, which are substantially more attractive than that found in typical production Nakamoto consensus chains.

- Light client friendly: The overwhelming majority of end users will need to securely access the platform in computing environments with resource constraints, such as browsers and mobile devices. They should also be able to quickly start interacting with the platform, even if the last sign-on was a long time ago or may even be the first time. In addition, the Joystream protocol will have a large state and transaction history. These constraints make a light client protocol the only genuine interaction model for almost all users.

In these algorithms, a light client only needs to track any potential changes in the validator set, which in practice changes quite infrequently, for example, due to the unbonding period induced delay and not in large increments. Once an up-to-date validator set is identified, the client can securely read any part of the platform state by authenticating merkle proofs from full nodes against state commitments found in the relevant block header.

This is in contrast to Nakamoto consenus systems where all block headers starting at genesis 2 must initially be downloaded, and one must keep up with new blocks as the system moves forward. Headers are validated, and the chain selection rule is applied on a continuous basis. Even if feasible, this requires a long initial synchronization period whenever a client comes on line for the first time or at some point after a hiatus.

- Finality: The finality of block commitment is the property that once two-thirds of the current validator set has signed off on a block, then that block will become, and remain, part of the chain permanently.

This is in contrast to Nakamoto consenus systems where the heaviest chain selection rule can in principle fork off any block, albeit with exponentially declining probability in the block depth, from the chain.

This property has a number of critical benefits. In order for secure assertions about the state of the Joystream chain to be feasible on a different chain, this chain will effectively need to behave as a light client that can track the most up-to-date committed block on the Joystream chain. Finality ensures that tracking this becomes very easy, as there are no reorganization events that can occur. Such events open up the possibility of reverting the basis critical state changes executed on the remote chain prior to the reorganization, e.g. changes in asset ownership. Dealing with this is complex and will often involve introducing delays. Moreover, the light client friendliness discussed above also helps in reducing the information to be submitted to the remote chain light client.



Get the Medium app

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