Token Mechanism and Economics

This section offers a brief overview of Saga's Token Mechanism and Incentives. For a more detailed description, please check out our first token paper.

We split the token economics into two conceptual components: the front end and 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.

Front End: End User to Developer

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.

Spam Prevention and Transaction Ordering

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.

Back End: Developer to Saga Mainnet

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.

We 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.