MIMD 0012 Staking

[Dodecahedr0x]

MIMD 0012 Staking

Abstract

MagicBlock validators have nothing at stake, preventing them from being malicious.

This proposal aims to introduce a staking mechanism that gives an incentive to the validators to perform correctly on several criteria:

• Performance: Validators are rewarded for performing well on the network.
• Security: Validators are punished for performing poorly on the network.

To achieve this, the proposal introduces a two-tier system:

• A non-slashable Consumer Stake that rewards the best performing validators and stakers with protocol revenues and inflation.
• An slashable Security Stake that punishes malicious validators caught trying to steal user funds.

The system is designed to utilize a custom Restaking program to avoid paying the 4% fee on rewards and 0.1% withdrawal fee associated with [Jito's Restaking Program] (https://docs.restaking.jito.network/). Regardless of the option chosen, we will refer to it as the Restaking Program (RS).

Economic model

All revenues are generated from users paying SOL for the service of validators on ephemeral rollups. These fees are split: 90% go to the operator, 10% to the protocol.

We introduce two tokens used in the system: magicSOL (a wrapped version of jitoSOL that accrues additional yield from the MagicBlock protocol) and BLOCK (the protocol token):

• Operators must lock some amount of both in order to become active validators.
• magicSOL is obtained by staking jitoSOL to earn protocol revenues on top of Solana staking yield and fee revenues.
• BLOCK can be staked to receive protocol revenues and some BLOCK inflation
• BLOCK inflation is also distributed to operators.

Finally, a share of protocol revenues also goes to Verifiers, nodes that check that other peers are not committing fraud. This creates an additional incentive for verifiers, in addition to earning a share of the slashed tokens.

Since protocol revenue is denominated in SOL, it needs to be swapped into the corresponding token before distribution. This requires that there are available liquidity pools for each pair.

Inflation

At each time step, a BLOCK inflation budget is defined based on the percentage of BLOCK staked. For example, if the base_budget is 100 BLOCK every second, this will actually be 50 BLOCK per second if only half of the BLOCK supply is staked. This incentivizes staking, as unstaked tokens will be diluted more quickly.

Moreover, inflation is distributed among operators proportionally to the revenues they generate: an operator generating 50% of protocol fees would earn 50% of the operator's inflation budget.

Alternatives considered

• Simpler inflation: not adjusting the inflation to the percent of tokens staked is simpler but gives fewer incentives to stakers.
• Subscription fee for operators: operators would have to pay a recurrent BLOCK fee to remain active operators. This creates demand for BLOCK tokens that scales with demand for MagicBlock. It can be burned or redistributed to stakers.

Architecture

flowchart TB
  %% Direction
  %% Core actors
  U[Users] -->|pay SOL for validator service| F(SOL Fees)
  F -->|90%| OpRev[Operator Revenue]
  F -->|10%| ProtRev[Protocol Revenue]

  %% Two-tier stake system
  subgraph Staking
    direction LR
    BSTK[BLOCK Staker]
    SSTK[magicSOL Staker]
  end

  %% Rewards from revenues
  ProtRev --> SSTK
  ProtRev --> BSTK
  ProtRev --> V

  %% Verifiers and fraud detection
  subgraph Verifier Network
    V[Verifiers]:::info -->|monitor peers / detect fraud| Detected{Fraud Detected?}
  end
  Detected -- Yes --> Slash[Slash Security Stake]
  Slash -->|slashed tokens shared| V

  %% Validator activation
  OP[Operators]
  OP -->|lock mSOL + BLOCK| Slash

  %% BLOCK inflation mechanism
  subgraph BLOCK Inflation
    direction LR
    Base[Base Inflation Budget per time step] --> Adj[Adjust by % of BLOCK staked]
    Adj -->|Inflation Budget t| SplitInfl[Distribute]
    SplitInfl -->|proportional to fees generated| OP
    SplitInfl --> BSTK
  end

  %% Styles
  classDef good fill:#eaffea,stroke:#47a447,stroke-width:1px;
  classDef warn fill:#fff4e5,stroke:#f0ad4e,stroke-width:1px;
  classDef info fill:#e8f1ff,stroke:#5bc0de,stroke-width:1px;

Loading

Implementation plan

Implementing this system depends on several other tasks:

• Creating the BLOCK and deploying capital in liquidity pools.
• Fraud proofs need to be implemented for the Security Stake to happen.

Taking this into consideration, the following implementation plan is proposed:

1. Implement magicSOL staking and the base work to redistribute protocol revenues.
2. When BLOCK is available:
   a. Reuse the previous mechanism and combine it with the inflation rewards to create BLOCK staking
   b. Implement revenue-weighted distribution of inflation to operators
3. When Fraud proofs are available, implement the Security Stake and distribute a share of protocol revenues to verifiers