Geek’s Guide to the Larvanet’s Economics

Marlin is a layer-0 scaling protocol. This means that blockchains and dapps, irrespective of the consensus algorithm they use, can leverage Marlin to improve performance.

As integrations with different blockchains and DeFi protocols continue to be developed, it is important for the decentralized network to provide quantifiable economic security to the protocols that use it. 

In our post describing the projected evolution of the network, we had earmarked the introduction of a token economy upon the transition from the Eggnet to the Larvanet. Being a stake-based permissionless network, the economic model involves two key components:

1. Requiring nodes in the network to stake Marlin tokens
2. Rewarding nodes for the work done

This post dives deeper into the design and math behind the staking mechanism.

Contract design

The Marlin staking contracts used in the Larvanet have two primary modules:

1. The cluster registry
2. Delegation mappings

Cluster registry

Cluster operators are required to register their cluster in the Registry where an Operator address (generated using a normal ETH key pair) is used to manage on-chain records such as commission, reward address and a client key (another ETH key pair) which correlates the Operator address with receipts signed by the cluster’s constituent nodes in the network. Thus, the Operator address could be considered as the Controller address used by other networks. 

Delegation mapping

The Operator account is not required to have any POND or MPond tokens apart from gas (ETH) required for smart contract operations. Instead, POND or MPond may be delegated to the Operator address from separate addresses holding such tokens. As a result, there’s no difference between tokens delegated by the Operator itself or by others. Such delegations are recorded in the mapping contracts via Stashes. 

Stash

Any account can create an unbounded number of Stashes. POND, MPond or LP tokens (described tokens) can be moved to a Stash. Each Stash can be delegated to only one Operator. However, different stashes may be delegated to different Operators. 

Tokens may be added to an existing stash at any time. The additional tokens are automatically delegated to the Operator the Stash was delegated to. However, withdrawing tokens from a stash requires the Stash to undelegate first.

Unbonding Period

Stash undelegation involves a unbonding period which is initially set to 30 days. This period can be updated via governance. Partial undelegation of tokens requires separate stashes to be created during delegation. Once a stash is delegated, all tokens in it are undelegated in entirety.

Redelegation

A stash may be redelegated to another Operator without necessitating undelegation and going through an unbonding period. Rather, a redelation delay of 6 hours applies. This delay can again be updated via governance.

Steps to register a cluster and make delegations directly via smart contract calls are already available. An easy-to-use frontend for the same is in works and close to completion.

Network design

Background

Clients (Marlin gateways) find closest nodes of the different clusters in Marlin via a standard P2P discovery process. Using the client key, they check whether the cluster receives more than 0.5 MPond in delegations (eligible clusters) and appropriately adds them to their local whitelist.

Say, there are n eligible clusters registered in the network at a given point of time. Every time a block producer generates a block, it sends blocks to m randomly chosen clusters. The m clusters chosen may vary with every block. They are chosen using a probability distribution described in the next subsection. 

The cluster with a node closest to the block producer ideally receives the block first. The block is then internally propagated to other nodes in the cluster which forward it to receivers (gateways run by other block producers and full nodes). Receivers sign receipts which lead to rewards with certain probability when submitted onchain (probabilistic micropayments).

Data sent to the m clusters is, in fact, erasure coded and the receiver gateways can reconstruct data using chunks received from only x of the m clusters. They, thus, sign receipts for the first y clusters that send them the chunks such that x < y < m < n. Intuitively speaking, this ensures that more clusters (y) than what's required to reconstruct data (x) are incentivized to participate while the fact that more clusters were sent data (m) ensures that there's incentive to provide lowest latency possible.

Larvanet Implementation

In the Larvanet, m is initially set to 5 and y to 3. Clusters are chosen with a probability proportional to square root of the sum of delegations they receive.

In conclusion, higher the delegations, higher the chances of the cluster being chosen amongst the 5 chosen every block interval. Lower the latency, higher the chances of being in the top 3 to receive receipts. Parameters 3 and 5 are expected to be tuned through the course of the Larvanet. 

Token design

As mentioned above, there’s no difference between self-staking or external delegations in Marlin. Therefore, every cluster only receives delegations from holders of eligible tokens.

Eligible tokens

The delegation contracts allow delegations from any number of whitelisted token contracts. Initially, the whitelist includes POND and MPond but can be expanded to include Uniswap and Sushi pairs or even a liquid staking wrapper contract if required. 

Minimum requirement

Irrespective of the total tokens delegated, every cluster will be required to have a delegation of at least 0.5 MPond which can be tweaked over time through on-chain governance. Clusters with lower than that amount of MPond delegations will be ignored by clients during the random selection process.

Token distribution

In order to achieve a fair distribution of Marlin tokens and consequently Marlin nodes, tokens were/are being distributed through two schemes

1. Participation in the Eggnet
2. FlowMint: Delegating DOT, ATOM, NEAR etc to validators who install Marlin gateways

POND may also be converted to MPond using the POND-MPond bridge. Delegating any of the eligible tokens to a cluster leads to network rewards in the form of POND. Details of how rewards are calculated is shared in the subsequent section. 

Token allocation

Background: 

The Marlin token economy consists of two tokens POND and MPond. 1 MPond can be minted by locking 1,000,000 POND in a bridge contract. The maximum supply of POND is 10 billion and at any time, a fraction of POND’s supply exists in the form of MPond to provide bare minimum guarantees of economic security. 

Maximum supply of POND = 10 billion

Total allocation: 

As part of the initial distribution, early backers, team and advisors of Marlin all receive MPond whilst POND’s circulating supply is dedicated to ecosystem activities and staking rewards. Totally, 21.8% of POND’s maximum supply, that is, 2,180,000,000 POND tokens are to be distributed amongst validators and delegators in the Marlin network in the form of staking rewards. 

Total allocation towards staking rewards = 21.8% of POND’s maximum supply

Larvanet allocation:

The annual rate of inflation of POND will initially be set to 1.03% of POND’s maximum supply. Since rewards for delegators depend on the number of tokens staked, inflation can be updated to keep staking in Marlin competitive compared to alternative venues. 

Initial rate of annual inflation (iROI): ~1.03% of POND’s maximum supply 

Tokens to be distributed over a year per iROI: ~102,766,667 POND

Tokens to be distributed daily per iROI: ~281,553 POND (102,766,667/365)

Reward distribution

The 281k POND tokens are distributed once every epoch (24 hours). These tokens are allocated amongst clusters in proportion to the number of receipts collected by them on that particular day. There are no withdrawal restrictions on such rewards once distributed. Rewards are initially only enabled for Ethereum, but similar to FlowMint, rewards will be distributed for multiple networks that the Marlin protocol serves eventually. 

Cluster operators set a commission f. Fraction f of rewards the cluster gets every 24 hours is allocated to the operator's reward address. Fraction 1-f is equally distributed (50-50) amongst POND and MPond delegators of that cluster. If say Uniswap POND-USDC LP token is added to the list of Eligible Tokens, then the tokens barring the cluster’s fees will be equally distributed (33-33-33) amongst POND, MPond and Uni LP delegators of the cluster.

Simulations of APRs in steady state can be found here: https://docs.google.com/spreadsheets/d/1Bbfn46MBh-NRLLRyG0mbou7LXEtK91wh86Oo_12Y0cU/edit?usp=sharing

Briefly speaking, APRs for POND could hover around 900% in the beginning and settle between 30-60% depending on the scale of participation.

Corollaries

1) Since the probability of a cluster being chosen is quadratic, there should be a certain tipping point where it's more profitable to operate another cluster.

2) The 50-50 distribution of cluster rewards amongst POND and MPond delegators should ensure a more uniform POND delegation lest the POND APR for highly popular clusters turn uncompetitive.

3) If APRs for POND happen to be significant, it should be a reasonable choice for POND holders to convert to MPond to operate clusters and charge a high commission. Commission is tunable by cluster operators and can be used as a lever to manage APRs for POND and MPond holders by cluster operators (MPond holders) themselves.

Follow us on our official channels to stay up to date on all things Marlin!

Twitter | Telegram Announcements | Telegram Chat | Discord | Website