Skip to content

Choosing Your M0 Extension Model

M0 provides powerful, pre-built templates to get you to market faster. These models are audited, battle-tested starting points for the most common use cases. Each one offers a different approach to handling the underlying $M yield, giving you the flexibility to build the exact product you need.

Three Core Models

M0 offers three distinct extension models, each available on both EVM and SVM chains. While the implementation details differ between EVM smart contracts and SVM programs, the core yield distribution logic and use cases remain consistent.

Model TypeYield DistributionBest ForEVM ImplementationSVM Implementation
Treasury Model100% of yield captured by protocol adminProtocol treasuries, ecosystem funds, centralized yield managementMYieldToOneNoYield
User Yield ModelYield distributed to all token holders (optional admin fee)DeFi protocols, consumer wallets, yield-bearing stablecoinsMYieldFeeScaledUi
Institutional ModelPermissioned yield distribution with delegated management and custom feesInstitutional platforms, B2B services, prime brokeragesMEarnerManagerCrank

Model 1: Treasury Model

Core Concept: All accrued yield from the underlying $M is captured by the protocol administrator. Token holders receive a stable, non-rebasing token with 1:1 backing.

When to Use:
  • Protocol-owned stablecoins where yield funds protocol development
  • Ecosystem development funds or grants programs
  • Corporate treasuries requiring centralized revenue management
  • Simple business models where all yield goes to one entity

EVM Implementation: MYieldToOne

Creates an ERC-20 token that wraps $M 1:1. All yield is claimed by calling claimYield(), which mints new tokens to a single designated recipient.

  • Yield Claiming: Anyone can call claimYield() to mint accumulated yield to the configured recipient
  • Access Control: Role-based permissions for managing the recipient address and freezing accounts
  • Source Code: MYieldToOne.sol

» Deep Dive on MYieldToOne (EVM)

SVM Implementation: NoYield

Creates a token that wraps $M 1:1. The admin claims all accumulated yield via the claim_fees instruction.

  • Yield Claiming: Only the admin can call claim_fees to mint accumulated yield to a chosen recipient
  • Token Standard: Uses Token-2022 (or legacy Token Program for compatibility)
  • Source Code: solana-m-extensions

» Deep Dive on NoYield (SVM)

Model 2: User Yield Model

Core Concept: Yield is automatically distributed to all token holders, creating a yield-bearing stablecoin. An optional protocol fee can be configured to capture a percentage for the admin.

When to Use:
  • DeFi protocols offering yield-bearing stablecoins to users
  • Consumer wallets with built-in savings accounts
  • GameFi economies where users are rewarded for holding
  • Applications prioritizing user incentives while optionally capturing protocol revenue

EVM Implementation: MYieldFee

User balances automatically increase as yield accrues. You can configure a fee (0-100%) to redirect a portion of yield to your protocol.

  • Automatic Yield: User balances grow automatically—no claiming required
  • Optional Fee: Configure what percentage of yield goes to users vs. your protocol treasury
  • Source Code: MYieldFee.sol

» Deep Dive on MYieldFee (EVM)

SVM Implementation: ScaledUi

User balances automatically increase as yield accrues. Anyone can call sync() to update the yield rate for all holders at once.

  • Automatic Yield: User balances grow automatically—no claiming required
  • Permissionless Updates: Anyone can call sync() to update yield (not just admin)
  • Optional Fee: Support for protocol fee (typically set to 0 for full pass-through)
  • Source Code: solana-m-extensions

» Deep Dive on ScaledUi (SVM)

Model 3: Institutional Model

Core Concept: Three-tier permissioned architecture where an admin delegates authority to Earn Managers, who manage their own sets of earners with custom fee arrangements.

When to Use:
  • Institutional platforms serving multiple client organizations
  • B2B services requiring bespoke yield-sharing agreements
  • Prime brokerages with per-client fee structures
  • Platforms needing granular control over who can hold and earn yield

EVM Implementation: MEarnerManager

Only whitelisted addresses can hold tokens and earn yield. Each earner has a customizable fee rate that determines their yield share.

  • Permissioned Holding: Only approved addresses can hold, transfer, or earn yield
  • Custom Fees: Set individual fee rates for each earner (e.g., VIP client gets 95% yield, standard gets 80%)
  • Source Code: MEarnerManager.sol

» Deep Dive on MEarnerManager (EVM)

SVM Implementation: Crank

Three-tier hierarchy: Admin authorizes Earn Managers, who each manage their own set of earners with custom fees. Used by Wrapped M ($wM).

  • Delegated Management: Earn Managers can independently manage their earners and set fees
  • Yield Distribution: Automated bot calculates yield offchain and distributes it onchain
  • Source Code: solana-m-extensions

» Deep Dive on Crank (SVM)

Choosing Your Path

  1. Choose your model type based on your yield distribution needs:

    • Treasury Model if you want centralized yield capture
    • User Yield Model if you want to share yield with token holders
    • Institutional Model if you need granular permissioning and custom fees
  2. Choose your chain based on your ecosystem:

    • EVM chains for traditional smart contract platforms (Ethereum, Base, etc.)
    • SVM chains for Solana, Fogo, or other SVM-compatible networks
  3. Review implementation details by reading the deep-dive documentation for your chosen implementation

Ready to build? Check out our Implementation Guides to get started.