Saga's architecture enables high throughput and low latency, essential for real-time gaming experiences. Developers can scale their chains as needed to accommodate growing user bases without facing the same congestion issues seen on some other blockchains.

Games often have specific rules and mechanics that don't fit neatly into the one-size-fits-all model of traditional blockchains. Saga allows developers to customize their chains to meet the exact needs of their games, from consensus mechanisms to tokenomics.

High gas fees on general-purpose rollups can eat into the profits of game developers and make certain gaming experiences financially unsustainable. Saga's cost-effective infrastructure ensures that developers can create and operate their games without breaking the bank.

Web3 games thrive on community involvement, and Saga's developer-friendly environment encourages engagement. Developers can implement novel monetization strategies, such as ad-based or freemium models, without burdening users with high transaction costs.

Saga's design allows for interoperability with other blockchain ecosystems, opening up opportunities for cross-chain gaming experiences and asset transfers.

Saga has partnered with the DA services and rollup infrastructure provider Celestia and became the base infrastructure for their upcoming RaaS platform. The solution will enable applications to automatically launch Celestia rollups with decentralized sequencers on Saga. It will combine the Saga protocol’s ability to orchestrate and scale dedicated chains using interchain security and Celestia’s Rollmint rollup technology.

Saga boasts an impressive ecosystem of 100+ builders building innovative solutions on top of Saga even before the mainnet launch and we believe the number will grow significantly post the mainnet launch.

Because dApps compete with each other for blockspace on the same network, it is often the case that one popular dApp consumes a disproportionate amount of resources, which increases transaction costs and latency for users of other dApps (e.g. Polygon and Arbitrum).

AppChains offers projects the ability to keep transaction costs & latency low & predictable, which results in better UX for end users.

As dApp grows in popularity, developers need to continue optimizing their applications for their end users.

Larger applications will want to make certain design choice trade-offs, such as throughput, finality, security level, permissions, composability, and ecosystem alignment, amongst others. For example, validators can have high-performance hardware requirements (e.g. running an SGX or FPGAs for generating zero-knowledge proofs).

For traditional organizations, AppChains offer a way to dip their toes into Web3 without going fully permissionless from day one; for example, companies could require KYC’d validators, prescreen developers who want to build on their network, and select which chains they want to bridge assets to/from.

While generalized scalability solutions lowered transaction costs while preserving security and developer experience, they offered few monetization opportunities for developers.

On the other hand, there is a strong business case for AppChains because applications are able to fork existing protocols and monetize them within their ecosystem (e.g. trading fees from an enshrined AMM or NFT marketplace).

In addition, their token benefits from additional token sinks from being used as the security model (i.e. staking token or gas token), as well as a market repricing of that token to something closer to an L2 or L1 token.

Furthermore, an application is able to capture MEV by running its own sequencers or validators, which can create opportunities for new crypto native business models; for example, dYdX validators, who will likely be market makers, can offer low or no fees for users but give them slightly worst execution prices, similar to the payment-for-order-flow model that Robinhood uses.

As another example, many successful games have tons of mods, extensions, skins, etc., and actively try to be as moddable as possible. But most of the time, modding is done by hobbyist gamers who struggle to monetize; if that game were an AppChain then mods can extend that IP on top of a rollup and monetize through the use of that blockspace.

Launching and maintaining a blockchain network can be a highly complex and resource-intensive endeavor, often requiring deep technical expertise.

Security is a paramount concern for blockchain networks. Ensuring that a blockchain is secure, especially for application-specific blockchains, can be a daunting task.

Many blockchain networks face scalability issues as they grow in popularity and usage. Scaling solutions are in high demand to handle increasing transaction volumes.

Managing validators, especially at scale, can be challenging. Validators must adhere to service-level agreements, maintain uptime, and avoid double signing, among other responsibilities.

Seamless interoperability between different blockchain ecosystems is a significant challenge, particularly for decentralized applications (dApps) that rely on multiple blockchains.

Existing blockchain platforms often require end users to pay transaction fees directly in the native platform token, creating complexity for users and developers alike.

The volatility of cryptocurrency prices can make it difficult for developers to predict and manage their project costs effectively.

Developers seek cost-effective solutions for deploying and maintaining their applications on blockchains, and finding the right pricing model can be a challenge.

Staking mechanisms and maintaining the economic security of a blockchain can be complex and require careful design.

Saga simplifies the process of deploying application-specific blockchains and Ethereum rollups, making it as easy as deploying a smart contract. This streamlines the development and launch of custom blockchains for various use cases.

Saga employs a shared security model, similar to the Cosmos Hub's interchain staking, to ensure the security of each Chainlet. This removes the complexity of gathering validators and securing individual chains, making blockchain deployment more accessible.

Saga offers validator orchestration tools to automate the management of thousands of independent Chainlets, ensuring they meet uptime requirements and other service-level agreements (SLAs).

Saga's use of the Inter-Blockchain Communication (IBC) protocol enables seamless interoperability between Chainlets and other blockchain ecosystems, enhancing the overall connectivity of the blockchain landscape.

Saga's front-end token model allows developers to abstract network fees away from end users. Developers can explore various monetization models, including subscriptions, ad-based models, and fee collection in different tokens.

Saga provides developers with creative solutions for spam prevention and transaction ordering, including whitelisted accounts, stake-based priorities, rate limiting, and more.

Developers can implement transaction fees in any token of their choice, whether it's stablecoins, Saga tokens, or their native token. This fee collection goes directly to the developer's wallet, allowing for flexible monetization.

To provision a Chainlet, developers subscribe to a fee deposit, guaranteeing compute capacity for a specific duration. This model prevents the existence of idle and unused Chainlets.

Saga uses a Musical Chairs mechanism to determine Chainlet prices for each epoch, ensuring competitive rates for developers and incentivizing validators to offer competitive prices.

The Chainlet Scheduler allows for the reduction of active validators per Chainlet, lowering the cost for developers. It also ensures that every Chainlet benefits from the full security of the Saga Mainnet.

Saga offers partnership models that enable ecosystems to scale while accruing value to their tokens and communities. This includes horizontal scalability solutions and revenue-sharing arrangements.

Saga employs a staking inflation schedule to maintain economic security. It ensures that validators post a consistent commission rate, simplifying the validator selection process for delegators

In Saga, smart contract developers interact with the Saga Mainnet to request a Saga Chainlet. A Saga Chainlet is an application-specific blockchain secured using Cosmos Interchain Security (ICS), with the Saga Mainnet validators providing the security. The validators for the Chainlets are the same as those for Saga’s Mainnet, and they produce blocks while checking to make sure that the other validators are following a predetermined service-level agreement (SLA). The provisions of this SLA include uptime requirements, running relayers and services, and validating properly without double signing. When a validator violates the SLA for a Chainlet, the evidence is relayed by the other validators via Inter Blockchain Communication (IBC) back to the Saga Mainnet. The network then slashes the staked SAGA tokens of the validator who violated the SLA. Using ICS, every Chainlet automatically inherits the security of Saga’s Mainnet without the need for a native and individual staking token.

In Saga, a Chainlet can be configured to use various Cosmos SDK modules, including virtual machines (i.e. EVM, Cosmwasm, SolanaVM, MoveVM) as well as different flavors of each (i.e. Juno’s version of Cosmwasm, Osmosis’s version of Cosmwasm, the Aptos MoveVM). Every Chainlet has a dedicated VM that has been deployed onto an individual chain. To deploy, a developer simply requests a Chainlet launch from Saga Mainnet. Once the request is received on the Saga Mainnet, the Saga validators provision the requested Chainlet. Once the provisioning is complete, the developer is free to deploy the smart contracts they have developed onto their Chainlet.

In essence, a Saga Chainlet is a sovereign blockchain with a VM module running a single smart contract.

Because each Chainlet contains only the smart contracts a developer or team would like to deploy on a single chain, the developer has a flexible and usable development environment

For the developer, the deployment of Chainlet is as easy as deploying a smart contract

Chainlet blockspace is not shared with any other application, leading to predictable fees

Saga is meant to be VM agnostic, which means developers can bring their own VM module to plug into their Chainlet. The first kind of VM Saga will support is the EVM Chainlet components such as VM module, SDK, and Tendermint Core can be upgraded independently from other applications, and Saga Mainnet

Saga supports other technology stacks besides Cosmos SDK and Tendermint, including Polygon Edge

Saga enables developers to manually “shard” various workflows into multiple Chainlets to leverage horizontal scaling. Deploying a Uniswap-like AMM smart contract into its own application-specific Chainlet will already offer significant scalability improvements. However, once the demand for the smart contract starts exceeding the limitations of current blockchain technology, the developer could deploy multiple instances of the same smart contract focused on particular subsets of activity. In the AMM example, the developer could deploy a smart contract instance for each asset pair. The Chainlet architecture enables near limitless scalability, as long as these Chainlets can be secured properly.

One of the challenges of deploying a Cosmos-based application-specific chain is the complexity around securing the chain. Each application chain requires gathering validators, distributing staking tokens, and designing a token mechanism that helps secure the chain. Saga uses shared security to remove this barrier to entry. Every Saga Chainlet is secured by the Saga Mainnet validators using shared security.

There are many flavors of shared security. Saga uses a model similar to the Cosmos Hub’s version 1 interchain staking called Optimistic Coordination to ensure the security of each of the Chainlets.

Every validator on the Saga Mainnet is required to validate every Chainlet provisioned

Validators agree on a set of SLA for Chainlet provisioning and maintenance such as timely deployments, guaranteed compute capacity, minimum uptime, honest consensus participation, and inter-blockchain communication relaying

An auditor monitors the Chainlet and creates a governance case in the event that a validator fails to meet service obligations

Saga Mainnet enforces any consequences needed for validators violating SLA

With Optimistic Coordination, Chainlets automatically inherit the security of the Saga Mainnet. However, to make provisioning Chainlets as simple as possible, Saga requires a suite of tools to facilitate Chainlet orchestration for validators.

Deploying a smart contract and provisioning a Chainlet on Saga is intended to be a fully automated process. We can expect thousands of independent Chainlets to be running at the same time. This means that Saga validators will need to be able to automatically manage thousands of independent processes on their servers and keep up with the resources needed to maintain them. To facilitate this orchestration, Saga will develop validator orchestration tools that will simplify the process of placement, scheduling, releasing, installing, and upgrading:

Automatically spin up new processes and server environments for each Chainlet

Automatically schedule binaries to be executed based on Chainlet subscription SLAs

Facilitate deployment of new Chainlets on multiple compute resources

Monitoring tools for validators to ensure sufficient resources are available for provisioning new Chainlets

One of the more difficult tasks for validators will be predicting the required hardware necessary to service the utilization needs of all Chainlet applications. On the one hand, having too much excess computing resources is wasteful. However, not having enough resources may result in slashing due to computer SLA violations. Therefore, Saga’s validator orchestration tools will need to help validators predict when new hardware resources will be necessary.

Splitting out applications into one or more Chainlets means that composability will be more difficult to achieve on Saga. Validators will be required to relay IBC messages between any two pairs of Chainlets, including the Saga Mainnet. Our IBC will additionally be more performant, by virtue of all our Chainlets being co-located in each validator's datacenter. However, more tools and development will be needed to make the IBC user experience as seamless as possible.

Saga’s token mechanisms rely heavily on seamless cross-chain composability. Manually transferring assets between Chainlets and other Cosmos chains through IBC is a poor user experience for the end user. Ultimately, we want assets to seamlessly transfer between blockchains without the end user initiating IBC transactions. In addition to creating validator orchestration tools around IBC, Saga will work with the broader Cosmos ecosystem to augment features to automate and abstract the IBC experience away from end users.

They split the token economics into two conceptual components: the front end and the back end. The front end is the portion of the token flow between the Chainlet end users and the Chainlet developers. The back end is the portion of the token flow between the Chainlet developers and the Saga chain. Splitting up the token mechanism into two independent parts allows for interesting usability benefits and value accrual for developers and our partner chains.

Imagine a scenario where Uber hosts their mobile apps on Amazon’s servers. The expected user interaction flow is as follows: end users pay Uber then Uber pays Amazon for hosting their applications. It is unusual to expect end users to pay Amazon directly. However, this is the norm in most smart contract platforms today. The fees from the underlying network are paid by end users, not application developers. This results in end users needing to custody enough tokens to pay for the fees and prevents developers from exploring interesting business models such as ad-based or freemium models.

This front-end model enables developers to explore interesting monetization models that were previously not possible. End users are abstracted away from network fees and the developers can implement more flexible monetization methods:

The developer can still implement fees per transaction. However, this model enables those fees to be paid in whatever tokens the developer wants. The fee tokens gathered by the developer can be any external tokens (like stablecoins), Saga tokens, or tokens created by the developer. This fee will accumulate in a wallet controlled by the developer

The developer may implement a subscription service where only whitelisted users may use the smart contracts

The developer can also choose to make their product free for end users with monetization coming from other sources like advertisements. In this scenario, the developer will need to set up some spam prevention mechanisms to prevent malicious users from utilizing the Chainlet capacity purchased by the developer. However, this can also be solved via whitelisted accounts

On Saga, end users of each application interact only with the Chainlet, and all fees for provisioning Chainlets are paid by the app developers. We will discuss the token flows for how this Chainlet provisioning happens in the back-end section.

If there are no end-user fees, how does Saga deal with transaction spam and transaction ordering? Saga gives the flexibility to the developer to solve spam and transaction ordering in more creative ways. Some methods include:

Whitelisted accounts maintained by the developer
Stake-based or holdings-based transaction priority for any asset on any chain
Wallet and UI-based rate limiting
Other fees (such as swap fees or other interaction flows in the system)
NFTs that give access to a certain amount of transactions
Other developer-specified ordering using ABCI++

Of course, the developer can also choose to implement traditional gas-based transaction fees in their Chainlets. However, since the network is not directly charging these fees, the developer can decide to denominate the fees in any token (i.e. USDC, ATOM, ETH, their native token, or SAGA). Also, unlike other blockchains, if a developer opts to charge transaction fees, those fees will not go to Saga. The fees generated by Chainlets accumulate in a wallet controlled by the developer, allowing a developer to realize the full value of the applications they have deployed.

In Saga, the developer pays for provisioning the Chainlet. The interaction flow is designed to be similar to how an Amazon EC2 instance is provisioned for web developers. In order for a developer to deploy a Chainlet, a developer must subscribe to a fee deposit, which guarantees a specified level of compute capacity for a specified amount of time for the provided Chainlet. The cost increases for higher capacity subscriptions, and there will be discounts offered based on the duration of commitment.

Once the subscription is selected, the developer needs to post the necessary bond in Saga tokens to provision the Chainlet. In essence, the fee bond is a pre-pay account to provision Chainlets and will be drawn down over time. At the outset, the network will provision “free credits” akin to trial accounts offered by services like AWS and Google Cloud to allow developers to freely set up testnets or experimental chains, but these free credits will only allow for a limited amount of Chainlet capacity for a limited time.

Once the Chainlet is provisioned, the end user can directly interact with the Chainlet. The maximum utilization of the Chainlet will be restricted based on the subscription tier selected by the developer.

The subscription model prevents idle, unused Chainlets from existing forever. The only requirement for maintaining the Chainlet is the payment of the subscription fees. As the protocol depletes the fee bond balance, the developer must maintain a sufficient balance to pay for the subscription.

They may also allow developers to stake the fee bond tokens. Provided the developer has enough Saga tokens staked in the fee bond, this could allow developers to automatically pay for Chainlet subscriptions from the staking rewards.

Low deposit balances can be replenished by developers or broader community incentives, but once depleted, validators may halt the chain and after a predetermined grace period, remove the unused binary and underlying data.

The fee generated from developers is intended to pay for the validators’ infrastructure cost of maintaining Chainlets. Saga incentivizes validators to offer the most competitive rates to developers through our validator selection mechanism.

In Saga, time is split into discrete epochs (i.e. 1 day). Developers pay for Chainlets on an epoch-by-epoch basis. Every validator in the Saga Mainnet publicly posts the price they would like to charge a developer to run a Chainlet for one epoch. Sometime before the beginning of the next epoch, the validators’ bids are locked for the epoch, and a session of Musical Chairs begins to determine a universal price for running a Chainlet for the epoch. The validators’ bids are set for all future epochs until the validators indicate they would like to change their bids.

Musical Chairs terms and definitions:

Total Set: The set of validators interested in being validators in the network. Anyone interested is able to join the total set.
Player Set: The set of validators who get to participate in the musical chair session. Player Set Count (p): The number of validators in the Player Set. Musical Chairs Price: The resulting price from the Musical Chairs auction. Used to set the Chainlet price of the next epoch. Winning Set: The set of validators whose bid is less than or equal to the Musical Chair Price. Winning Set Count (w): The number of validators in the Winning Set. Losing Set: The set of validators whose bid is greater than the Musical Chairs Price. Losing Set Count (l) The number of validators in the Losing Set and l = p - w. Active Set: The set of validators who get to validate Chainlets in the next epoch.

Step 1: Player Selection

The first step of Musical Chairs is to determine which validators participate in the game from the Total Set. The number of validators who are included in the Player Set is determined by the network as a parameter p. The validators in the Player Set are the top p validators by delegator stake weight. Our assumption in the Musical Chairs auction is that Saga may support a very large number of validators in the Player Set.

Step 2: Musical Chairs

The validators in the Player Set play a round of musical chairs to determine the Winning Set and the Losing Set. The parameter of the Chainlet price that the validator has configured for their validator will be pulled in for the current Musical Chairs session. The number of validators in the Winning Set is set as a parameter w. Saga sorts the validators in the Player Set by their auction bid. The cheapest w validators get included in the Winning Set. The remaining validators with the highest prices get included in the Losing Set.

Step 3: Price Setting

The price for the epoch is set by the most expensive validator in the Winning Set. This guarantees that every validator in the Winning Set receives Chainlets fees that are greater than or equal to the amount they bid.

Let’s go through an example system where p=10 and w=8. In the following example, there are 12 validators in the total set. Each validator’s price bid is denoted as dollar figures in the box. First, the Player Set is determined by rank ordering by stake weight: Validators 11 and 12 (the two validators with the least amount of stake) are excluded because p=10. Then, the Winning Set is determined by choosing the cheapest w validators in the Player Set. In the example, validators 2 and 7 are included in the Losing Set because their prices are the highest two bids from the player set. The Winning Set for the next epoch will be validators 1, 3, 4, 5, 6, 8, 9 and 10. Finally, the Chainlet price for the next epoch will be max(Winning Set), which is $5 in this example.

The final step of Musical Chairs is to reward the Winning Set and punish the Losing Set. The Saga team is evaluating a number of methods to reward and punish these validators to incentivize the validators and delegators while keeping the security assumptions of the network intact. Here is one way:

The Active Set of the network in the next epoch is the Player Set. (Validators in both the Winning and Losing Set are included.)

Everyone in the Active Set receives Chainlet fees for the Chainlets they are validating.

However, the price is set by only the winning validators. Therefore, validators in the Losing Set are receiving less than their requested price.

Delegators to the validators in the Losing Set receive zero inflation from the network for the epoch. This directly incentivizes the validator to bid lower in the next epoch or risk their delegators re-delegating to other validators.

Another way the network could configure the rewards and punishment is:

The Active Set of the network in the next epoch is the Winning Set.
Validators in the Losing Set get kicked out of validating the next epoch.
Delegators to the validators in the Losing Set receive zero inflation from the network for the epoch. This directly incentivizes the validator to bid lower in the next epoch or risk their delegators re-delegating to other validators.

In the first scenario, the validators in the Losing Set still validate Chainlets but receive less reward than they would have wanted. A validator who is in the Losing Set consistently will lose delegation because the delegators are not receiving any inflation rewards, which will eventually push the validator out of the Player Set.

In the second scenario, the punishment is more strict. Validators in the Losing Set are immediately kicked out of the Active Set and receive zero rewards and inflation. They also are no longer required to validate Chainlets. However, there are some security implications of removing large validators from the Active Set, and the Saga team is researching the best way to design the reward and punishment mechanism to minimize Chainlet costs (Tenet 3) while maintaining the security guarantees of a Proof of Stake network.

The parameters, w and p, and the punishment mechanisms are very important for the incentives of the network. If w is too small, too many validators will be punished. If w is set too high, the economics of commoditizing blockspace won’t function properly.

There are also security implications that we need to consider. A malicious actor can Sybil attack the Saga validator set to attempt to control the network or the outcome of the Musical Chairs process. It is notable that validators can attempt to collude/Sybil attack the Winning Set (bid prices low) or the Losing Set (bid prices high). The parameters need to consider both dynamics.

The Saga team’s current thought is that w needs to be approximately 75-85% of p. This makes w sufficiently large enough to ensure it is difficult to control the Winning Set. At the same time, a Losing Set size of 15-25% ensures that filling the Losing Set with Sybil validators is difficult.

Another lever Saga has to prevent Sybil attacks and collusion is to make the social cost of such attacks very high. Saga can, for example, include in its upcoming Constitution that a Sybil validator will be slashed fully to disincentivize such behavior.

How can the network further lower the prices of Chainlets for developers (Tenet 3)? The Musical Chairs process determines the amount each validator will receive for each Chainlet, but the actual price that the developer pays will be (Musical Chairs Price x number of active validators for their Chainlet). The Musical Chairs Price variable is automatically reduced as validators compete to join the Winning Set, but we can also reduce the active validators per Chainlet to decrease the price that developers pay.

One way to reduce the number of active validators is to reduce the total number of validators participating in the network. However, this has decentralization and security implications that may not be ideal. There may be a way to increase the total number of validators but still reduce the number of active validators per Chainlet. Instead of requiring every validator on the Saga Mainnet to validate every Chainlet, we can relax the SLA requirement for certain validators and have a partial set validate each Chainlet. This can be accomplished using the Chainlet Scheduler.

Imagine the network sets a certain threshold of quorum for each Chainlet. Let’s arbitrarily pick 70% of total staked assets. For each Chainlet prior to the beginning of each epoch, the scheduler randomly selects a set of validators whose stake weight adds up to greater than or equal to the 70% threshold. There are many different ways to randomly select this set, but an easy way to do this is to keep picking individual validators randomly based on their stake weight until the set has greater than or equal to 70% stake weight. Let’s define the validators selected as s and those not selected as n. There will be a different set of {s,n} for each Chainlet per epoch. Only those in s are required to validate the Chainlet. Conversely, the SLA for the n validators are loosened to allow those validators to not validate the Chainlet.

The chart below shows the potential reduction in the number of validators per Chainlet when we apply this kind of scheduler on existing token distributions in the Cosmos ecosystem. A small reduction in quorum threshold and SLA can have a very significant impact on the number of validators.

There are some nice behaviors that result from utilizing this kind of scheduler. First, we can guarantee that every Chainlet will have the full security of the Saga Mainnet. Second, because the number of validators per Chainlet is significantly reduced, the total price for developers will also go down (Tenet 3). By setting a quorum threshold, below 100%, we are able to cut down on the steepest part of the cost curve. Third, the number of Chainlets each validator validates will be proportional to their stake weight. This means the top validators will validate all Chainlets, while validators with little stake weight will be required to validate a very small number of Chainlets. This makes validator requirements for smaller validators significantly less than those for larger validators. We can vary the total threshold level and see how many Chainlets each validator ends up validating. We can see that regardless of the threshold level, there is a much smaller number of Chainlets in the tail-end validators.

There are some complications that may arise with a scheduler.

First, with a lower quorum threshold, the risk of stalling due to a downed validator increases. With a threshold rate of 70%, a validator with 4% of the stake may halt Chainlets if they accidentally go down since a quorum of 66% won’t be possible. In reality, this threshold will likely be set by governance targeting a minimum failure tolerance for validators going down.

Second, a random sampling scheduler may vary the number of validators per Chainlet from one epoch to another. The Saga team has simulated a simple random sampling scheduler and found that the number of validators per Chainlet follows a normal distribution and is kept fairly consistent across epochs. Saga can employ a more sophisticated scheduler to make the distribution tighter, making the cost for developers less lumpy from one epoch to another. Also, in all scenarios, the scheduler reduces the number of validators vs. the whole validator set. Even if there are small variations for developers, the cost will always be less than the price without the scheduler.

Finally, every validator will be validating a different set of Chainlets every epoch. This means that we will need to implement fast-syncing of blockchain data (state and mempool) across validators to make sure there is an automatic transition of validator sets between epochs. One way to solve this problem is to require the top validators to always validate every Chainlet. The number of validators in this set can be parameterized using governance. This way, there is always a consistent set of validators to state sync as the other validators swap between Chainlets to validate.

Saga’s unique and flexible product design enables partnership models with other ecosystems that allow for the accrual of value to these ecosystems’ tokens and communities even when Saga serves as the base chain.

First, Saga could partner with various other layer one blockchain ecosystems to offer horizontal scalability solutions while keeping the economics of the respective tokens intact.

Imagine a scenario where a partner network is expecting a smart contract that will generate too much traffic in the partner network’s mainnet. To prevent their blockspace from being too congested, the partner network could deploy the smart contract on Saga instead. The partner network can post the Chainlet provisioning fee in Saga tokens to get the smart contract provisioned.

The Chainlet can be configured to demand end users to pay fees in the partner network tokens. This way, the end user’s interaction flow is identical to the case in which the smart contract is deployed on the partner mainnet. The fees paid by the end users follow our front-end token model and get distributed to an account owned by the partner network. A portion of these fees can be converted to Saga tokens to pay for the Chainlet subscription. The remaining balance can be configured to be distributed back to the partner’s validators and stakers in the same method as smart contracts deployed on the partner’s mainnet.

Saga’s token mechanism allows for accumulated transaction fees (net of Saga Chainlet fees) to accrue value to partner stakeholders. The partner also keeps their developer and end-user pipeline, maintaining brand loyalty while scaling through Saga.

A second method of partnership is a revenue share between the Saga Mainnet and technology teams across the ecosystem. This structure covers cases in which developers are coming directly to Saga to build their applications. Saga is meant to be a VM-agnostic chain, and numerous VM options will be available to developers who come to Saga looking for an environment to build their applications in. Therefore, Saga will want strong technology partners to support and develop VM technologies on Saga. Saga can always use its Protocol Controlled Reserve to pay and incentivize these developers to continue to maintain and support their respective VM options for Saga.

More specifically, the developer chooses a VM environment and deploys a smart contract on Saga. They then post the fee deposit that is needed to provision and maintain the Chainlet. Saga will provision a Chainlet for the developer that uses the native token of the VM for transaction fees.

When an end user uses the application, they call the smart contract directly on the Chainlet and pay transaction fees in the native token of the VM. These fees accumulate in a wallet controlled by the developer. The developer can convert part of the fees to pay for the required bond needed to provision the Chainlet or however, they see fit. Saga can also take a portion of the fees and send them to the network affiliated with the VM technology partner as a revenue share, incentivizing value accrual for the partners’ tokens.

Once the price is set by Musical Chairs, how does a developer actually pay for a Chainlet? To reiterate, the Musical Chairs process determines the amount each validator will receive for each Chainlet, but the actual price that the developer pays will be (Musical Chairs Price x number of active validators for their Chainlet).

When the next epoch begins, each developer’s Chainlet fee deposit is reduced by (Musical Chairs Price x number of active validators for their Chainlet) and distributed to the addresses of the validators in the Active Set. This means each validator receives the Musical Chairs Price amount of SAGA tokens per Chainlet they validate.

Once the fee deposit is collected by the validator, they are on the hook for validating and meeting the SLA requirement for that Chainlet. In the middle of this epoch, another Musical Chairs auction process begins for the subsequent epoch. Unless the validator changes their bid, their current price automatically rolls over to the next epoch. There is significant value for validators (and their delegators) to be included in the Winning Set. Therefore, those validators in the Losing Set will want to lower their bids to get back in the Winning Set for the following epoch, ultimately lowering the price of Chainlets.

There are some further optimizations we can implement to make the developer experience better. We will go into more detail with the following ideas in the future, but we wanted to leave a small glimpse into the future design of the Saga pricing mechanism.

First, the Musical Chair auction mechanism ensures that the price will constantly change from epoch to epoch. One way to reduce volatility is to charge developers a moving average of the price from the last X epochs. This way, epoch by epoch, the price variation only contributes a small movement to the actual price and the developer is able to better predict the price of Chainlets ahead of time.

Secondly, we can denominate Chainlet prices in USD instead of SAGA tokens. By having dollar-denominated Chainlet prices, there will be a much more predictable market for developers. Because the payments will still be made in SAGA tokens, this mechanism will require some form of price oracle system or bonding curve.

Saga depends on stakers for the economic security of the Mainnet and, by extension, the security of each Chainlet. To ensure sufficient economic security for the system, Saga employs a staking inflation schedule very similar to that of the Cosmos Hub. The network targets a specific stake rate by varying the inflation rate. The annual inflation is capped between minimum and maximum rates. If more than ⅔ of SAGA is staked, the block rewards decrease gradually down to a floor of a minimum rate of annualized inflation. If less than ⅔ of SAGA is staked, the block rewards increase gradually up to a ceiling of a maximum annualized inflation.

With the Cosmos Hub, each validator posts a commission that they take from each delegator. With Saga, the network determines a universal commission rate that every validator takes from their delegators. This design is due to the fact that in our system, each validator is already posting their Musical Chair auction price. We do not think asking delegators to choose between a high-cost validator with low commissions and a low-cost validator with high commissions is a productive tradeoff. Saga simplifies the validator selection process by keeping the commission rate consistent across all the validators.

Selecting the right validator will be key to maximizing delegator rewards. As mentioned in the Musical Chairs section, delegators delegated to validators in the Losing Set of Musical Chairs may not earn any inflation rewards. It is important for delegators to redelegate to validators who post the cheapest prices.

Z A commission still exists to ensure that the Saga validators have ways of economically sustaining themselves without any Chainlet activities. Over time, we expect validators to price Chainlets at cost or below cost, and having an inflation commission buffer helps the Chainlet price decrease to such levels.