# Token design

Two native digital cryptographically-secured utility tokens of the Marlin network, MPOND (non-transferrable) and POND (transferrable), each have certain defined functions specified in the protocol/code of the Marlin network, and have a major role in the functioning of the ecosystem on the Marlin network. They are intended to be used solely as the primary utility tokens on the network.

## Token flow

Three major sub-flows: 1. Spam prevention 2. Rewards 3. Staking

## Spam prevention

• Tokens are staked by block producers as collateral against any spam that they might send
• Optionally, they may outsource this to an attester in exchange for a fee
• The deposit entitles a producer to send a given amount of data through the network
• Any data exceeding this limit is simply dropped, acting as a rate limit to ensure the slashing mechanism isn't overwhelmed
• After propagation through the network, spam checkers verify that the message is not spam
• If they determine it to be spam, they submit a proof to the deposit contract and trigger the slashing mechanism
• The more data (and people) that needs to be sent through the network, the more stake is locked up as deposits

## Rewards

• Receivers of data are required to pay into a monthly subscription fee pool (may be any mix of tokens/coins supported on Ethereum)
• A subsidy pool is provisioned to bootstrap the network in the initial stages (with Marlin native token, POND)
• Attested blocks flow from the producer through the relayers to the receivers
• Receivers send tickets to (a subset of) relayers to confirm timely block delivery
• Relayers submit tickets to the subscription and inflation pools in exchange for fees and rewards
• The more people that need to receive data from the network, the more tokens that are locked up in the fee pool on a monthly recurring basis**

## Staking

• Stakers and delegators stake tokens in a staking pool of their choice
• They can of course choose to stake in their own personal "pool"
• Staking pools redelegate the stake towards different relayers in exchange for rewards
• As indicated above, relayers can set up personal pools and delegate towards themselves
• Rewards are modified by the Cobb-Douglas utility function before they are received by the relayers
• Of the form $(r/R)^\alpha * (s/S)^{1-\alpha}$ where
• $r$ = Relayer rewards
• $R$ = Total rewards
• $s$ = Relayer stake
• $S$ = Total stake
• $\alpha$ = System parameter
• Rewards are maximized when the ratio $r/s$ is a constant depending only on $\alpha$
• This ensures that people are incentivized to stake in proportion to their rewards and vice versa, run nodes in proportion to the stake delegated to them which is crucial for security
• Another way of looking at it is people have a fixed amount of resources they are willing to put towards the Marlin network, the above function incentivizes them to split the resources optimally between participating (by running nodes) and securing (by staking), both of which are critical for long term viability
• Positive feedback loop encouraging sustainable network growth
• If relayers are delegated more stake, they are incentivized to run more nodes to increase tickets
• If more people start using the network and relayers receive more tickets, they are incentivized to stake more (or attract more delegations)
• Some nice things about the function:
• Stable equilibrium ratio between activity and security
• Optimal strategy is individual, not collective
• i.e. even if other people don't stake in the optimal ratio, rewards are maximized for an individual when he does it optimally
• No coordination needed
• This also means people don't need to periodically rebalance their resources just because other people started running more nodes or staking
• Equilibrium is stable from an individual perspective as well
• The more bandwidth capacity used by the network (both in terms of unique data as well as receiver numbers), the more stake is locked up towards relayers

## Remarks

• The roles given above aren't exclusive
• Relayer would almost always also be a staker/delegator
• Receiver would almost always also be a spam checker
• Etc
• Implementation details which don't affect the system a lot are omitted for brevity

## The network tokens

Marlin uses POND and MPOND tokens as part its token economy.

### POND

POND is a standard ERC-20 token contract with a total supply of 10 billion.

All network rewards via the subsidy pool for work done by relayers as mentioned above are distributed in POND. POND provides the economic incentives which will be consumed to encourage participants to contribute and maintain the ecosystem on the Marlin network. POND is an integral and indispensable part of the Marlin network, because without POND, there would be no incentive for users to expend resources to provide services for the benefit of the entire ecosystem on the Marlin network. Computational resources are required for various tasks in maintaining the Marlin blockchain, thus providers of these resources would require payment for the consumption of these resources (i.e. "mining" on the Marlin network) to maintain network integrity, and POND will be used as the medium of exchange to quantify and pay the costs of the consumed computational resources.

Conversely, POND also functions as the deterrent for ensuring that nodes perform up to pre-set performance standards. The Marlin network would generally require nodes to first put up a stake of POND before being entitled to participate in the ecosystem, and failure to meet performance standards would result in deduction of such stake.

POND may delegated to relayers and subject to slashing penalties if the relayer its delegated to doesn't follow the protocol.

Users of the Marlin network and/or holders of POND which did not actively participate will not receive any POND incentives. POND are designed to be consumed/utilised, and that is the goal of the POND token distribution. In fact, the project to develop the Marlin network would fail if all POND holders simply held onto their POND and did nothing with it.

### MPOND

MPOND is Marlin's governance and staking token. It can used to create and vote on proposals. It is also required to run a Marlin node - every Marlin node requires a certain amount of MPOND staked or delegated.

For the avoidance of doubt, the governance feature is restricted solely to voting on features of the Marlin network; the governance feature does not entitle MPOND holders to vote on the operation and management of the Company or its affiliates, or their assets, and does not constitute any equity interest in the Company or its affiliates.

#### Properties

• Total supply of MPOND is 10,000.
• Every cluster is cumulatively required to have atleast 0.5 MPOND staked or delegated.
• MPOND can be used to vote and create proposals, where 1 MPOND tokens = 1 vote (votes are fungible as tokens).
• MPOND tokens delegated to other users will be locked.
• Direct MPOND transfers will be locked except for whitelisted addresses (like the bridge and stakedrop contracts). Until universal transfers are enabled, only transfers to/from whitelisted addresses are possible.
• MPOND can be converted to POND via the bridge.
• If delegated or staked, users will first have to unlock the tokens before being able to make a transfer.

### Bridge

A bridge contract is used to convert between MPOND and POND. 1 MPOND can exchanged for 1 million POND tokens and vice-versa via the bridge.

#### POND to MPOND

POND can be converted to MPOND by sending POND to the bridge and an equivalent number of MPOND (#POND/1m) is received on the same address while burning the POND tokens sent.

#### MPOND to POND

The bridge also allows conversion of MPOND to an equivalent number of POND (#POND X 1m). However, the conversion is a bit nuanced and not instantaneous as above. The mechanism is described below.

A request can be made on the bridge to convert a certain number of MPOND (say P). After transfer request is made, there is a wait time of W blocks before a conversion can be attempted. During the wait time, MPOND can still be used towards staking and governance. After the wait time, a fraction L of P MPOND can be sent to the bridge for conversion.

Parameters W and L are both controlled by governance. These parameters make sure that there are always enough MPOND locked to ensure that the security of the network and its governance is not compromised. After every W blocks, $L$ of P MPOND requested initially can be sent to the bridge for conversion. That is, if W and $L$ remain constant, the user can convert all the requested MPOND to POND in $\lceil{\frac{100}{L}}\rceil*W$ blocks.

A series of scenarios and expected results of calls made to the Bridge are illustrated in the table below.

Timespan MPOND balance Call Maxima Result Maxima mapping Maxima used mapping Liquidity Effective Liq. (calculated) Call convert Result
Day -1 1000 {-1:0} 0%
Day 0 1000 1100 reject {-1:0} 0%
Day 0 1000 900 accept {0: 900} {0:0} 0%
Day 30 1000 50 accept {0: 900, 30: 50} {0:0, 30:0} 0%
Day 31 1000 100 reject {0: 900, 30: 50}
Day 180 1000 {0: 900, 30: 50} {0:0, 30:0} 0% 950, 0 reject
Day 180 1000 {0: 900, 30: 50} {0:0, 30:0} 10%
Day 180 1000 {0: 900, 30: 50} {0:0, 30:0} 10% 85, 0 accept
Day 180 915 {0: 900, 30: 50} {0:85, 30:0} 10% 10, 0 reject
Day 180 915 {0: 900, 30: 50} {0:85, 30:0} 5% 10, 0 reject
Day 180 915 {0: 900, 30: 50} {0:85, 30:0} 10% 10, 0 reject
Day 180 915 {0: 900, 30: 50} {0:85, 30:0} 10% 2, 0 accept
Day 180 913 {0: 900, 30: 50} {0:87, 30:0} 10%
Day 210 {0: 900, 30: 50} {0:87, 30:0} 10% 10, 30 reject
Day 210 {0: 900, 30: 50} {0:87, 30:0} 20% 10, 30 accept
Day 211 {0: 900, 30: 50} {0:87, 30:10} 20% 100, 0 reject
Day 212 {0: 900, 30: 50} {0:87, 30:10} 20% 20% 93, 0 accept
Day 213 {0: 900, 30: 50} {0:180, 30:10} 20% 20%
Day 360 {0: 900, 30: 50} {0:180, 30:10} 20% 40%
Day 390 {0: 900, 30: 50} {0:180, 30:10} 15% 30%

#### Properties

• POND can be instantly converted into MPOND with 1MPOND yielded against 10^6 POND.
• To convert MPOND to POND, there is a delay of at least W blocks.
• At any point after W, $min(100, liquidityRatio*floor[(time since request)/W])$ % of the total requested amount, including all previous conversions for the request, can be transferred to POND.
• If POND/MPOND are staked/delegated, then they can’t be transferred to the bridge.
• During wait period, MPOND can be used for governance and staking.
• User can partially/fully cancel conversion requests from MPOND to POND at any time, even after wait time is over as long as the conversion is not completed.

#### RISKS

You acknowledge and agree that there are numerous risks associated with purchasing MPOND/POND, holding MPOND/POND, and using MPOND/POND for participation in the Marlin network. In the worst scenario, this could lead to the loss of all or part of the MPOND/POND which had been purchased. IF YOU DECIDE TO PURCHASE MPOND/POND, YOU EXPRESSLY ACKNOWLEDGE, ACCEPT AND ASSUME THE FOLLOWING RISKS:

• Uncertain Regulations and Enforcement Actions: The regulatory status of MPOND/POND and distributed ledger technology is unclear or unsettled in many jurisdictions. The regulation of virtual currencies has become a primary target of regulation in all major countries in the world. It is impossible to predict how, when or whether regulatory agencies may apply existing regulations or create new regulations with respect to such technology and its applications, including MPOND/POND and/or the Marlin network. Regulatory actions could negatively impact MPOND/POND and/or the Marlin network in various ways. The Company, the Distributor (or its affiliates) may cease operations in a jurisdiction in the event that regulatory actions, or changes to law or regulation, make it illegal to operate in such jurisdiction, or commercially undesirable to obtain the necessary regulatory approval(s) to operate in such jurisdiction. After consulting with a wide range of legal advisors and continuous analysis of the development and legal structure of virtual currencies, a cautious approach will be applied towards the sale of MPOND/POND. Therefore, for the token sale, the sale strategy may be constantly adjusted in order to avoid relevant legal risks as much as possible. For the token sale, the Company and the Distributor are working with Bayfront Law LLC, a boutique corporate law firm in Singapore with a good reputation in the blockchain space.

• Inadequate disclosure of information: As at the date hereof, the Marlin network is still under development and its design concepts, consensus mechanisms, algorithms, codes, and other technical details and parameters may be constantly and frequently updated and changed. Although this white paper contains the most current information relating to the Marlin network, it is not absolutely complete and may still be adjusted and updated by the Marlin team from time to time. The Marlin team has no ability and obligation to keep holders of MPOND/POND informed of every detail (including development progress and expected milestones) regarding the project to develop the Marlin network, hence insufficient information disclosure is inevitable and reasonable.

• Competitors: Various types of decentralised applications and networks are emerging at a rapid rate, and the industry is increasingly competitive. It is possible that alternative networks could be established that utilise the same or similar code and protocol underlying MPOND/POND and/or the Marlin network and attempt to re-create similar facilities. The Marlin network may be required to compete with these alternative networks, which could negatively impact MPOND/POND and/or the Marlin network.

• Loss of Talent: The development of the Marlin network greatly depends on the continued co-operation of the existing technical team and expert consultants, who are highly knowledgeable and experienced in their respective sectors. The loss of any member may adversely affect the Marlin network or its future development. Further, stability and cohesion within the team is critical to the overall development of the Marlin network. There is the possibility that conflict within the team and/or departure of core personnel may occur, resulting in negative influence on the project in the future.

• Failure to develop: There is the risk that the development of the Marlin network will not be executed or implemented as planned, for a variety of reasons, including without limitation the event of a decline in the prices of any digital asset, virtual currency or MPOND/POND, unforeseen technical difficulties, and shortage of development funds for activities.

• Security weaknesses: Hackers or other malicious groups or organisations may attempt to interfere with MPOND/POND and/or the Marlin network in a variety of ways, including, but not limited to, malware attacks, denial of service attacks, consensus-based attacks, Sybil attacks, smurfing and spoofing. Furthermore, there is a risk that a third party or a member of the Company, the Distributor or its affiliates may intentionally or unintentionally introduce weaknesses into the core infrastructure of MPOND/POND and/or the Marlin network, which could negatively affect MPOND/POND and/or the Marlin network. Further, the future of cryptography and security innovations are highly unpredictable and advances in cryptography, or technical advances (including without limitation development of quantum computing), could present unknown risks to MPOND/POND and/or the Marlin network by rendering ineffective the cryptographic consensus mechanism that underpins that blockchain protocol.

• Other risks: In addition, the potential risks briefly mentioned above are not exhaustive and there are other risks (as more particularly set out in the Terms and Conditions) associated with your purchase, holding and use of MPOND/POND, including those that the Company or the Distributor cannot anticipate. Such risks may further materialise as unanticipated variations or combinations of the aforementioned risks. You should conduct full due diligence on the Company, the Distributor, its affiliates and the Marlin team, as well as understand the overall framework, mission and vision for the Marlin network prior to purchasing MPOND/POND.