Friday at 9:07:42 PM CET December the 9th, 2022, the genesis block of the Joystream mainnet, with hash 0x6b5e488e0fa8f9821110d5c13f4c468abcd43ce5e297e62b34c53c3346465956, was finalised, and production and finalisation of the first blocks began. The full release, including node binaries and chainspec, can be found on the Github release page. For the uninitiated, the Joystream blockchain is a new standalone PoS L1 blockchain based on Substrate, but it is not a parachain. The easiest place to explore the network at this time is this block explorer, where you for example can check your account balances and early validation candidates.

The Launch

While the chain is live and memberships have been migrated, the launch itself is not over. This will happen over a number of stages, and we are now only in the initial Frozen stage. For a full breakdown, read our launch process guide, but we have summarised the major stages and their role in the table below.

History

Recent times have been a difficult period in the blockchain and tech industry broadly, and so it's worth taking a step back and appreciating the long journey the Jsgensis team and broader Joystream community has been on to reach this milestone. One factor which always set Joystream apart as a project was that the objective to have the system be financed, directed and operated by the community was taken very seriously as a requirement to be satisfied from the very first mainnet block. Since the project also had a very broad and ambitious scope, that meant that a very long run view had to be taken on attracting, training and retaining exceptionally qualified community members to play this instrumental and very skill intensive role.

Humble Beginnings

The project began in late 2018 with three people working distributed at Jsgenesis, some funding, a few years of experience as builders in the space and a big vision. We found ourselves at the tail-end of a difficult bear market at the time, not so different from today.

As we started to design the architecture of the system, we quickly understood that we would need our own standalone blockchain in order to have full control over our block space, fee system and execution environment, and be able to select a decentralisation, performance and security tradeoff ideal for our use case. We proof-of-concepts launching our augmented Ethereum fork, Cosmos SDK and Substrate, and quickly found that the latter was the best alternative for us because it

• Control: gave us full control of our own chain and even consensus mechanism (e.g. Cosmos commits you to Tendermint).
• Maintainers: was maintained by an experienced and well funded team.
• Rust: allowed us to write our business logic in Rust.
• Upgradeability: had forkless upgradability, without smart contracts.
• Interoperability: was going to have trust-minimized interoperability natively.
• Shared-Security: gave us a free option of being a parachain for greater security.

After this very early and pivotal decision we raced ahead with three major priorities in mind

1. Hire additional great engineers and product designers.
2. Iterating on our system design.
3. Building our community.

A Marathon of Testnets

We knew we were going to be building a large system for a long time, and we had to find some way to learn and get feedback while building, not only to manage the execution risk that came from the inevitable planning and design failures, but also to make room for our growing community to continuously learn how the system worked, and how to work with each other. With this goal in mind, we took inspiration from the Ethereum protocol upgrade model of naming distinct upgrades, and the Cosmos incentivised testnet model for training validators on testnet, and started running incentivesed testnets. Each network had a well defined and coherent goal in terms of technological iteration and/or community development.

*The upgrade to Babylon caused a chain split which was remedied by upgrading to a new version of Substrate, and Antioch was effectively identical to Babylon in every other way.

Founding Member Program

Once the chain had technically matured to a level where there was something interesting and substantial for a prospective community to try their hand at, we started to think about how to provide sufficient encouragement for people to give it a try. We started out very simply paying out contributors, such as validators and council members, in early 2019. In mid 2020 we had a bigger community, and the on-chain governance model and range of different roles available had expanded substantially. We kept iterating on our testnet incentive model, attempting to limit the difference between the testnet and future mainnet, but so far we had not started actively distributing mainnet tokens to the community.

As a governance-heavy system, we knew that a key determinant of success would be the extent to which community members would be able to accumulate robust public reputations which they would have an incentive to protect and cultivate, in order to access key platform roles and resources, by limiting abusive behaviour and investing in their own Joystream specific knowledge and relationships. This was for example one of the main reasons we knew we had to have distinct actor identifiers, in the form of memberships, as distinct from raw accounts. It was with this backdrop we decided to launch our Founding Member Program in early 2021. In this program, we would not only establish a scheme for non-US community members to acquire mainnet tokens, but also define a distinct, and highly selective, status for a subset of memberships who were able to earn a sufficiently high amount of tokens, namely Founding Members. Such a status would also be celebrated by the creation of a unique avatar in the style of the Joystream brand identity, and also a special on-chain decoration transaction providing a scarce immutable mark for these members. We have been delighted to see the community embrace these stylish avatars, and Pioneer already gives a special display style for memberships with this mark.

Importantly, the founding member status was later taken to include anyone who has worked directly in association with Jsgenesis, and depending on the context the term Founding Member may or may not include such Jsgenesis persons, which may be a bit confusing.

What we built

A lot has been built, and today Joystream is pretty much a self-contained and vertically integrated technology platform spanning everything from content-delivery and governance to content publishing and NFT auctions. It is a monolithic system optimised for the singular use case of being a video publishing, delivery and monetisation system. This allows us to sidestep the considerable UX, execution and operational costs of attempting to cobble together a web3 technology stack which is still very much in motion. Here is a brief overview of each of the major components that make up the technical side of Joystream, and of course, it's all 100% open-source.

• Blockchain: At the base of the tech stack sits the Joystream blockchain, which is written in Rust, based on Substrate, and has broken into two major parts: the node and the runtime. The latter, which is most interesting, is further composed of what are called pallets, which are like comparable to singleton smart contracts. While the whole runtime is upgradable in flight, since the Substrate has WebAssembly as its execution environment, this is a global operation triggered through governance, and individual new pallets cannot be introduced by users ad-hoc, as contracts can be deployed in a smart contract chain. While Joystream does use some off-the-shelf pallets, for example for the base currency and for consensus and staking, most pallets relate to our domain specific business logic. Here is an overview
• Memberships: Almost all activities, such as making proposals or publishing content, requires a membership, which is distinct personae, with associated authentication and profile information. A really powerful onboarding feature we expect to be used heavily is the ability to invite someone to make a membership, with some pre-specified amount of funds credited to their accounts, which cannot be used for anything except core features. Read more here.
• Council & Elections: The Joystream DAO is, unlike most other DAOs in existence today, a governance structure where only a small number of stakeholders are required to weigh in on decisions on a day to day basis. The primary set of such stakeholders are the participants in the council, in which currently there are 3 seats. They are tasked with the biggest decisions, which they come to agreement on through the proposal system, described below. They are rewarded for this role, and have to compete to retain it, and finally, all important proposals have to pass multiple councils, to allow room for blocking disastrous ideas. Elections are the process by which seats in the council are filled. This happens on a regularly basis, in fact every 16 days, with 9 days for announcing candidacy, 3 days for secret voting, 3 days for revealing votes and a final idle day before next election starts. Any member can stand as a candidate to be elected, any account can vote, and accounts already used for staking in certain other activities, say nomination, validation or working groups, can still vote. Read more here.
• Proposals: There is a proposal system with 23 distinct proposal types, each with its own unique quorum and threshold constraints, as well as how many councils must do uninterrupted ratification, called constitutionality. Only council members vote on proposals, but any member can propose them, and anyone can participate in the proposal specific discussion, all happening on-chain. Proposals cover things such as runtime upgrades, spending funds and managing budgets, managing working groups, setting prices, signalling and so on. The most important feature of this system is that distinct proposals have distinct constraints, this allows calibrating barrier for passing to the inherent risks and urgencies associated with a given proposal, while most other proposal systems have no such introspection. This for example allows the chain to for example require a threshold in a spending proposal which relates to the magnitude of spending being contemplated. Read more here.
• Working Groups: As already mentioned, having delegation and domain specific expertise brought to bear on narrow technical and organisational questions is essential for the DAO to be effective, and working groups are a solution to this problem. They are groups of actors, with their own budget, salaries and leadership, accountable to the council, which have some domains specific responsibility. Membership in some groups yields some domain specific privilege in a corresponding subsystem, for example workers in the curator working group can act as curators in the content directory, while other working groups are purely operational, such as the builders working group Read more here.
• Forum: Effective community governance is only feasible if there is a public space within which information, analysis and perspectives can be shared and deliberated over, and this exchange must itself be neutral, trustworthy and long-lasting, and for this reason Joystream has an on-chain threaded and moderated forum for members. Read more here.
• Bounties: The last missing piece of allowing the community to organise around producing public resources, like software, research, standards and art, without having to get the council to provide their resources and judgement on the activity. The council has limited knowledge and bandwidth, hence having a separate public goods financing and production venue is very important. For this purpose there is an on-chain crowdfunding based bounty system, which even allows for so-called Dominant Assurance Contracts to make certain project financings incentive compatible Read more here.
• Content Directory: The content directory is the on-chain index of all channels and content in the system, and their associated moderation, permission and asset information, both digital and off-chain data assets. It has been designed to be maximally flexible, hence all metadata is purely ledger data not processed by the chain, but instead by an off-chain indexing layer, so as to allow people to define their own content semantics around consumption, publishing, access control, attribution and social interactions. There is a rich on-chain moderation system which allows content directory working group workers to intervene in the index when someone is using it in a way which is out of the policy space of the system. Read more here.
• Content NFTs: For content in the content directory, which in many cases will be videos or playlists - but as mentioned above can be anything, can have 1-of-1 NFTs minted for them. These NFTs can be auction off, with on-chain royalties, using English or Open auctions, with or without instant buy prices, or just sold peer-to-peer. Read more here.
• Channel Tokens: For channels in the content directory, the creator can issue a fungible token. This token is meant as a mix between a financing, monetisation and marketing/alignment tool for the creator. The token can hook into the revenue that the creator generates through NFT sales or revenue from the council, and distribute a share of this revenue to token holders. Tokens can be distributed for free, through a public sale or through a bonding curve based market maker providing some basic liquidity, and the creator also generates fees from this trading. (Documentation forthcoming).
• Data Directory: A separate index exist of what heavy off-chain storage assets, like video, images and pictures for example, exist, and what storage and content delivery operators are responsible for servicing which assets. There is also basic metadata around the assets. This index is a source of truth for the data infrastructure, and in the future would allow for adding automated on-chain auditing of service providers if needed. Read more here.
• Pioneer: The canonical governance application for the Joystream system, allows you to get started creating a membership, often funded by a faucet, and from there you can start posting on the forums or creating proposals or applying for a role. A hosted version may be available here. Read more here.
• Atlas: The canonical publishing, consumption and digital asset product for the content side of the platform. Importantly, this is a white label product built to be customised by anyone looking to start their own video community or product on to of the Joystream, and it has extensive documentation to make this possible. The goal of this product is to make it easy for people to get started building products on Joystream. Read more here.
• YT-synch: An infrastructure service which can be integrated into Atlas, which allows creators from YouTube to automatically sign up to have their content replicated from YouTube to Joystream on an ongoing basis. This is meant to lower the bar for creators who already have a presence on YouTube to start using both platforms, without extra hassle. Read more here
• Hydra: This is our in-house generalised Substrate indexing and query framework, inspired by The Graph, it is a framework, hence it can be used with any Substrate chain, and it won the HACKUSAMA hackathon back in the day, and later the team behind this framework went on to found Subsquid, to which we have started migrating. Read more here.
• Query Node: This is all of the schemas, metadata standards and processing logic that powers the indexing layer when used with Hydra. Read more here.
• Colossus: This is the replicated storage layer which accepts uploads from users, and replicates assets from peers, as well as services requests from the content deliver nodes. Read more here.
• Argus: This is the content delivery node which caches and stores content, replicated from the storage nodes, on demand. Read more here.
• Orion: This is the backend for Atlas, which serves as private data layer for one application instances, powering things like recommendations, filtering, search, etc. Read more here.
• CLI: This is the primary tool for low level interaction with he blockchain, for example for certain advanced on-chain features, or for automated tasks. Read more here.
• Network Tests: Lastly we have an extensive suite of end-to-end regression tests that run a wide range of scenarios across all of our nodes to make sure the network works properly while new features are under development. Read more here.

Audits

Two major reviews have been conducted of the Joystream node and runtime code, one performed by SRLabs and one by Quarkslab, industry leading auditing partners for projects based on the Substrate, such as Polkadot and Kusama. The audits were focused on the blockchain primarily, and they are available publicly.

Genesis Block and Membership Migration

In the end the Genesis block has the following breakdown in terms of share and vesting for various allocation purposes.

Notice that there is a new, not previously mentioned, membership airdrop pool which was used to fund a subset of the 4347 memberships that were migrated over from Carthage which did not have a controller with funds allocated due to some other reason.

The Founding Member Program Ends

This program evolved through many stages, with lots complications, but now as of mainnet launch, the program is over.  For a full history of the program, please read this. Here are some interesting statistics worth considering.

• Number of Candidate Founding Members: 1,103
• Number of Founding Members: 163
• Total Founding Members Allocation: 21.2189609 %

Here is an exhaustive list of members.

Validation & Nomination

The most important activity to get right at this early stage is to develop a vibrant validation and nomination sub-community within the project. This is actually an activity we, in relative terms, underinvested in as part of our testnets.

We already have a solid pool of full nodes running, but at this stage only the Jsgensis nodes participate in validation. We have transitioned to the Thawn stage at this time, hence the validator is now open, but generalised functionality is still be restricted. The most eager validators have been preparing for weeks, and one can find some operational information about them on our Meet Your Validators page. Many are already signalling their intent to validate, and nominators can stake in favour of validators already at this time. For anyone interested in validating, we refer them to our validation guide.

We encourage all stakeholders who hold $JOY to consider nomination, both for private returns but also the security of the network. Also remember that tokens subject to vesting can be used in such nomination, and also simultaneously in voting during council elections. Read our nomination guide to get started.

Get Involved

There are plenty of ways to get involved in Joystream, both near-term and long-term. Near-term, participating in validation and nomination, as described above, are most useful. Using the broader functionality of the system, such as balances transfers, voting or publishing, will not be possible until we are in the Supervised phase, which currently is likely to happen some time this week. It's only at this point the governance application Pioneer becomes usable, and the first council can get elected. From this point on, there is a very broad range of activities people can jump into. The best place to get acquainted with these roles it to check out the Opportunities section of our handbook, but here is at least a list of titles to peak your interest:

1.Council Member
2.Content curator
​3.Content Curator Lead
​4.Builder
5.Builders Lead
​6.Human Resources
​7.Human Resources Lead
​8.Marketer
​9.Marketer Lead
​10.Storage Provider
​11.Storage Provider Lead
​12.Distributor
13.Distributor Lead
​14.Validator

Disclaimer

All forward looking statements, estimates and commitments found in this blog post should be understood to be highly uncertain, not binding and for which no guarantees of accuracy or reliability can be provided. To the fullest extent permitted by law, in no event shall Joystream, Jsgenesis or our affiliates, or any of our directors, employees, contractors, service providers or agents have any liability whatsoever to any person for any direct or indirect loss, liability, cost, claim, expense or damage of any kind, whether in contract or in tort, including negligence, or otherwise, arising out of or related to the use of all or part of this post, or any links to third party websites.