farming token model research solana specific

How to assign MRN tokens to mSOL token holders?

• Keep track of all mSOL token addresses

  • assign MRN to mSOL account addresses at specific checkpoint
  • ? create MRN account every time mSOL account is created and link them
    • this way we could just track mSOL addresses and assign MRN to connected MRN address
  • ? how to handle mSOLs transfered to new addresses(not created on deposit)
    • ? would we create new MRN account once new mSOL account is created? -> can we have user pay for this?
  • volnurable to sendwitch attack exploit
    • somebody buys token right before distribution, waits for it receives MRN and then sells mSOLs
  • can we keep this trust minimised? => meaning not dependent on trusted party providing address list, or have this list verified by the program?
    • we need to check mSOL balance on every MRN distribution after every epoch
      • adjusted spl-token contract adjusted for this?
      • ? transfer MRN receiving rights separately?

• Allow users to "prove" (provide blockchain data to the smart contract) that they own mSOL => this could create MRN token account + add user to array

  • ? make MRN tokens claimable => meaning user would interact with governance program in order to claim the tokens
  • "claim" MRN from the smart contract, it checks what is the account balance of the claimer + last miniting event => mints new MRN + updates last mint time
    - features
    - interactive from user side, non-interactive from our side
    - problematic calculation mechanism of MRN rewards, if mSOL in the user account changes due to rewards / transfers, calculation is difficult potentially unbound
  • ? distribute tokens automatically once user has initialized his accont
    • we would need to query the account at every distribution event to check for the account balance of mSOLs

• Create "staking governance program"

  • MRN would be only assigned to mSOLs locked in the contract
    • this would decrease token velocity, since it is uneconomical to keep mSOLs outside this program, creates unwanted dillema for the user, prevents use of the mSOL as collateral in other protocols
    • via this contract people could participate in governance
      • incentive allignment => only people participating in governance would receive farming rewards in MRN
      • ? allow people to also lock in pool LP tokens of SOL/mSOL pool?
        • there would need to be more MRN tokens for LPs to offset the lost opportunity from holding SOL instead of mSOL

mSOL token mechanism - How to do rewards accrual

• variable value token => increasing price of mSOL as rewards accrue
  • current hackaton solution
    • value increases due to increased amount of SOLs in the system
  • variable supply with multiplier. => mSOL == SOLmultiplier => mSOL.totalSupply == SOLmultiplier.totalSupply
    • this is how AMPLE froth and Lido rebases its supply
    • We could have an internal oracle that tracks (1+token rewards) and produces multiplier.
    • This mechanism is tested in the wild, but currently impelented in Solidity but not on solana, we would need to launch our own adjusted spl-token program
• constant value token => mint new tokens to keep mSOL == SOL price
  • benefits
    • better interoperability with other protocols
      • use of standard AMMs without IL
    • better asset for collaterals
      • fixed collateral size
      • getting staking rewards to different account
  • mechanisms
    • mint to accounts after every epochs
      • user would specify receiver address when depositing, we would mint appropriate amount of tokens to this address after every epoch
        • features
          • non-interactive from user side(except when changing receiver address), interactive from our side
          • ? tx size could blow up if there are too many receiver addresses
    • "claim" mSOLs from the smart contract, it checks what is the account balance of the claimer + last miniting event => mints new mSOLs + updates last mint time
      • features
        • interactive from user side, non-interactive from our side

Treasury

• income
  • withdrawal fees
• spending
  • decided by governance => MRN token holders
    • funding of
      • development
      • marketing
    • redistribution of funds to MRN token holders => actual figure based on which we could model token value =>compare value capture with other protocols (sushiswap), possible size of the system => value of the system

Reserve mechanism

definitions

• reserve 0 => R0

  • current hackaton reserve implementation with getInLine() functionality

• reserve 1 => R1

  • reserve with flat fee on swaping out SOLs
    • Features
      • onesided liquidity
      • LP tokens
      • external liquidity providers
      • flat fee not dependent on the reserve size
        • predictable price
        • reserve could get depleted

• reserve 2 => R2

  • two sided AMM solution
    • use of stableswap curve

Proposed solution 1 (Roman's idea, please correct this text if I misunderstood you)
R0 would be the first line of defence, if there is not enough funds here to pay for withdrawal, user would draw funds from R1. Is R2 even necessary in this case?

• Observations

  • R1

    • to have R1 instead of only having R0 makes sense only with having external liquidity providers. This is so, since there is really no reason in separating reserve into R0 and R1 if we do not employ external liquidity. We can have the same fee structure no matter if the system is separated in R0 and R1 or just all excess funds used for paying out users are kept in R0
      • thus if we want to attract external liquidity to R1, this needs to be profitable for the LPs
        • incentives
          • MRN tokens for LPs
            • It is probably not good to rely on rewarding people with MRN indefinitely, it also points to the fact that the mechanism is inefective, if there would be no LPs without it
          • Trading fees
            • this should be the main incentive for LPs to provide liquidty in SOLs. Thus the trading fees cannot be minimal, but must in fact reflect broader market dynamics. LPs can provide their liquidity to any other protocol to earn rewards, thus the fees must be ± on paar with others.
        • ? automatic rebalancing
          • ? is there any incentive for new LPs to provide liquidity once some people have withdrawn from R1?
            • if Yes
              • perfect, could you explain the mechanism / link to explanation?
            • if No
              • We need to replinish it either
                • from R0
                • by unstaking

  • R2

    • features
      • there is price slippage (for stableswap curve this should be really low)
      • automatic rebalancing
        • if people get SOLs from the pool there is an incentive for others to trade SOLs into the pool, since there is a small arbitrage opportunity
          • no need for us to unstake + rebalance the pool under normal conditions

Linear price mechanism

Definitions:

• Reserve (R0)
  the buffer for storing SOL tokens between depositing by user and delegating to validator at the end of epoch. May be used for withdrawals for preventing unnecesarry unstaking and paying wathdrawal immediately.
• Staking total
  total amount of SOL tokens stored in the all stake accounts controlled by instance of marinade.finance program. It includes delegated tokens, waring up and cooling down tokens and stake account rent tokens.
• Total epoch reward value
  0 between epoch start and completion of update process. Total amount of SOL tokens gathered during update process from the stake accounts.
• mSOL token price
  (<staking total> + <reserve amount> - <total epoch reward value> * (<slots per epoch> - <current epoch slot index>)/<slots per epoch>) / <total mSOL supply>

Procedures:

• Delegate reserve
  procedure runned by the admin at the end of each epoch. Moves reserve SOL tokens to the stake accounts and starting delegation process. All moved tokens become warming up stake tokens, thats why delegated amount of SOLs will be added to the staking total value as result of this operation.
• Update
  procedure running by the admin at the begining of each epoch. Collects all staking rewards into reserve for using it in the next delegate reserve process at the end of this epoch or paying withdrawals during this epoch. In result of this operation reserve amount instantly grows by total epoch reward value but stake total remains the same because rewards are not included in the stake total calculation. However update recalculates stake total for handling situations where some validators was punished by the system and some part of SOL tokens was lost from the stake accounts under marinade.finance control. In such case difference between previous stake total and current stake total will be subtructed from the total epoch reward value to compensate staking total loss for the mSOL token price calcuation. If difference will be bigger than total epoch reward value then it will be set to 0 and price of mSOL token imediately becomes lower and remains constant during this epoch.