Hello Saganauts!
The launch of the Saga protocol V1 is imminent! A new protocol launch is exciting but often difficult to execute smoothly. In addition, the Saga protocol is a very complex piece of software that requires multiple major components to function properly. To best ensure a successful launch, Saga will be dividing up the launch into a progressive schedule.
The full launch communications will be divided into four different blog posts:
- Part 1: Technical launch process description and high level tokenomics (this post)
- Part 2: Innovator participation details
- Part 3: Community participation details
- Part 4: Full Saga Tokenomics
In this post, we will break down the major questions:
- What will be launched at each phase
- When each phase will occur
- How each phase will be launched
- Why they are being launched in this fashion and
- High-level tokenomics and distribution of the $SAGA tokens
This post does NOT include a detailed breakdown of our tokenomics or how to participate in our airdrops. Those topics will be more thoroughly explained in separate posts in the future (shortly 🙂).
Here we go!
What is Launched?
Earlier this year, we unveiled Saga Realms, the technical manifestation of the Saga Multiverse. Saga Realms allow developers to launch customizable chains on Saga with different features and services such as technology stack, security source and various obligations. Under the framework of Realms, the standard Saga Chainlet became one Realm of many that will be supported in the near future, including those for our partners at Polygon, Avalanche, Celestia, XPLA and many others. To support configurable Realms out of the gate, the Saga launch will be divided into three components: security chain, platform chain and Chainlet.
For purposes of clarification, the security chain and platform chain together constitute the Saga Mainnet.
Let’s dive deeper into each.
Security Chain
The security chain is the first security source for the Saga protocol. This is where the $SAGA token is minted, staked and ultimately slashed if there is validator misbehavior. Saga’s security chain is built using the Cosmos-SDK.
Platform chain
The platform chain is where the developer launches and maintains their Chainlets. The platform chain aggregates security from multiple security chains and forwards that security to the launched Chainlets. Aggregation and forwarding of security is done through Cross-chain Validation (CCV). CCV is an innovation pioneered by Cosmos, and Saga uses a modified version of Cosmos CCV. Any misbehaviors relayed by Chainlets are ultimately forwarded back to the security chain, where slashing will ultimately occur. The first security chain that the platform chain will aggregate security from will be the Saga security chain. However, in the future, the Saga platform chain will derive security from other sources such as our partners at Ethereum, Polygon, Avalanche and other stakers and validators. The platform chain is built using the Cosmos-SDK.
Chainlet
The Chainlet is where all computation actually happens. The end user interacts with one or more Chainlets. The platform chain forwards security from the security chain to the Chainlets. Any misbehavior in Chainlets are first relayed back to the platform chain. The first supported chainlets are built using the Cosmos-SDK but there will be other types including Avalanche Subnets and Polygon Supernets.
Progressive Launch Roadmap
To ensure a successful launch of the full Saga protocol V1, the launch will be divided into six progressive phases. Each phase builds on top of the previous, and the full-featured Saga protocol V1 will have completed launch at the end of phase six. The full progressive launch schedule is shown below.
Let’s go through each phase.
Phase 1
The most significant effort in Phase 1 is the launch of the security chain. During this phase, the platform chain and Chainlets launched from the platform chain will be operated by foundation validators (not the security chain validators). The security chain validators will be external and decentralized, and will almost inevitably have participated in our Incentivized Testnet. Cross-chain validation (CCV) will not be supported from the security chain to the platform chain and to the Chainlets.
- Developers can begin launching Chainlets that will persist through all the phases. In other words, their applications and smart contracts will be live in a production environment that users can interact with. Upgrading to successive Mainnet phases will be done automatically on the backend, so developers will not need to worry about manually upgrading.
Developers will still need to request test tokens from the foundation to launch Chainlets (Controlled Permissioned Access). Our Innovators will be provisioned with keys to have test tokens automatically fauceted to their wallets for funding their Chainlets.
- Stakers can start staking assets to secure the network and earn inflation rewards.
- Validators need to launch and maintain the security chain only. External validators will not be running the platform chain and Chainlets.
- End Users can begin using launched Chainlets.
Phase 2
Phase 2 introduces basic CCV from the security chain to the platform chain. The platform chain will be secured using CCV with a hardcoded foundation key. This is the first step in converting the platform chain into a security aggregator. This phase will also test drive whether validators are able to successfully upgrade the security chain.
- Developers (No Changes)
- Stakers (No Changes)
- Validators need to upgrade the security chain.
- End Users (No Changes)
Phase 3
Phase 3 then shares the aggregated platform chain security to the individual Chainlets. In other words, each Chainlet will now inherit the security of the platform chain. In this instance, the relayed security is still only a hardcorded foundation key. However, the subsequent phases will introduce more and more security into the platform chain. This phase will also test drive upgrading a production Chainlet and platform chain.
- Developers (No Changes)
- Stakers (No Changes)
- Validators need to upgrade the security chain.
- End Users (No Changes)
Phase 4
Up until now, the platform chain and Chainlets were not operated by external validators. Phase 4 is where we begin onboarding validators in the security chain to start operating the platform chain. Running the platform chain means these validators will also need to run every chainlet launched by the platform chain. A proof of authority set of validators from our security chain will start operating the additional infrastructure. The platform chain will now be secured using CCV with the PoA validator keys.
- Developers (No Changes)
- Stakers (No Changes)
- Validators: External validators will need to start running the platform chain and all Chainlets.
- End Users (No Changes)
Phase 5
Once the PoA platform chains and Chainlets are stable, we can onboard the entire set of security chain validators to run the platform chain and Chainlet infrastructure. At this point, the full security chain security is aggregated on the platform chain, which gets forwarded automatically to all Chainlets.
- Developers (No Changes)
- Stakers (No Changes)
- Validators (all) will need to start running the platform chain and all Chainlets
- End Users (No Changes)
Phase 6
Finally, we can enable slashing on the security chain. Any misbehavior on any Chainlet is forwarded back to the platform chain, which relays it to the security chain. This is the point where audits will be finalized, and the $SAGA token will begin to be used for provisioning Chainlets. The developer portal will now be permissionless and no longer be controlled access.
This will complete the progressive launch of the Saga protocol V1.
- Developers will need to begin paying for Chainlets using $SAGA tokens instead of Testnet tokens. The developer UX will now be permissionless and no longer be controlled access. Up to this point, the incremental changes between the phases have been largely on the backend, and there would have been little to no noticeable change for the developers or their end users.
Now, however, there will be fast interoperability between the Chainlets and bridging out to other ecosystems, which will enable any assets to be transferred in and out of Chainlets at the speed of settlement allowed on the chain receiving the assets. This also means Chainlets are now fully elastically scalable and can have the same level of flexibility as typical cloud instances.
- Stakers (No Changes)
- Validators (No changes)
- End Users (No Changes)
Why is the launch structured this way?
The progressive nature of this launch means that we can incrementally test out each major component to isolate issues along the way. This kind of agile launch ultimately means a faster and more secure path to achieving the full launch status. Carefully planning each step means that every stakeholder can experience a much smoother ramp up to the complete Saga protocol launch.
Benefits for validators
The onboarding experience for validators is progressive. Phase 1 requires the validators to test out the launch of a singular chain. Then, a few upgrade cycles later, certain validators will need to launch a second chain (platform chain) and make sure their infrastructure is ready to spin multiple Chainlets on demand. Finally, the whole validator set will be running the platform chain.
Keep in mind that the launch process for a decentralized proof-of-stake chain on Saga is entirely permissionless and automated. We are taking a process that was previously painful and cumbersome for even one chain and allowing developers to access a completely streamlined version as many times as they want. Our engineering team has spent most of their time making sure we have the validator tooling to make this a manageable burden on our validator sets, but we are doing something entirely new. The best way to guide the validators through launch is through a phased approach.
Benefits for developers
The Saga progressive launch is designed such that Chainlets are fully production ready at Phase 1. This is the earliest possible point at which we can deliver a secure chain-to-launch-chains to developers so that their applications can go live and welcome user activity. Additional features will be added throughout the launch phases to enhance functionality, and these features will be clearly communicated to developers so they can in turn let their communities know.
However, any Chainlet launched during the progressive launch process will have security automatically migrated between phases. The goal is to have minimal to no disruption to the developers’ Chainlets as the launch phases are completed.
Benefits for stakers and hodlers
The stakers and hodlers have access to the $SAGA tokens immediately at Phase 1. Saganauts can begin securing Saga before the platform chain is fully decentralized. The progressive launch significantly de-risks the stakers’ and hodlers’ assets.
Benefits for end users of our dapps
The end users of Saga can start using and interacting with their favorite Chainlet applications as soon as Phase 1 is complete.
High-level Tokenomics
At Phase 1, the $SAGA token is live on the Saga security chain. The total supply of Saga at TGE will be one billion tokens distributed as below:
Core Contributors (20%)
The OG Saganauts part of the core team who have been (and will be) working tirelessly to bring Saga into existence. Tokens subject to a 3 year lockup with a 1 year cliff starting at TGE.
Fundraising (20%)
The investors who shared in our vision of Saga. 10% has been allocated so far, and the remaining 10% will be held for future fundraising rounds. Tokens subject to a 3 year lockup with a 1 year cliff starting at TGE.
Ecosystem and Development (30%)
The Ecosystem and Development bucket is designed to expand the Saga ecosystem post-launch. These tokens will be used to fund communities and developers that augment and improve the Saga experience.
Foundation Reserve (10%)
Reserve for the foundation for use cases outside of fundraising, development and ecosystem expansion.
Airdrops (20%)
$SAGA tokens will be distributed to builders, stakers, hodlers and general end users that exhibit helpful behaviors for the Saga ecosystem. The 20% allocation will be distributed over multiple stages:
- 6% of total supply of tokens will be airdropped at Phase 1, our initial TGE drop (60,000,000 tokens)
- 4% of total supply of tokens will be airdropped from Phases 2–6 (40,000,000 tokens)
- 10% of total supply of tokens will be airdropped post Phase 6 through multiple retroactive airdrop events
Conclusion
We’re hoping you are just as excited about the launch of the Saga protocol as we are! Information on how Saganauts can participate in this launch will be published shortly!
For further information, follow us on Twitter, join our Discord and Telegram and subscribe to our Medium.
