Seeking Clarity on the Fold Token’s Value Proposition, Team’s Involvement, and Revenue Distribution

🕋♟️General
, , ,
1

I appreciate Sam’s suggestion to bring questions here for transparency and community discussion, so I’d like to delve into a few important points regarding the Fold token.

  1. Value Proposition: Could you provide a straightforward explanation of the value proposition for the Fold token? This would help the community better understand its purpose and long-term potential.

  2. Team Staking & Incentives: Years ago, Manifold planned on deriving income from staking alongside the community. Has this approach changed? Specifically:

• Are team-held tokens currently staked to the LP, and are they accruing incentives just like community members who have staked?

• If not, is there a timeline or plan to implement this strategy?

  1. Revenue Transparency: Transparency is key to fostering trust. Could you provide more details on what revenue has been generated so far and how those funds have been allocated? If there are plans for future revenue distribution, a clear outline would be greatly appreciated as well as any insights into the accounting practices.

As a follow-up, Sam mentioned that in a 30-day period at the end of last year, the block builder made 9 ETH. Where did that revenue go, and why was it not distributed to Fold stakers? Additionally, didn’t Sam also mention that there was revenue from MEVETH?

  1. Understood Revenue Streams: Some of the current and upcoming revenue-generating components of the Manifold system include:

• Blockbuilding

• ManifoldBoost / AVSBoost

• XGA (potential sequencing fees and constraint market)

• MEVETH

• MEV Protect (possibly launching in January)

• Captive Insurance Fee

• Protocol-owned liquidity? Does this generate fees that can be considered another source of revenue for stakers?

• Protocol-owned validators? Are these still planned, and could they provide another source of revenue for Fold stakers? Is this part of MEVETH protocol or Manifold?

Could you clarify where this revenue will end up? Also, could you provide a timeline or roadmap for when each of these revenue streams will become active and how the generated revenue will be utilized?

  1. Governance Considerations: This morning, Sam shared the following regarding governance:

“There are design decisions that were made that I would not agree with today, for example governance ability for the token. Governance capability can be seen as providing a floor price based off of treasury holdings. This is literally the exact opposite of what was originally planned.

ie if price of token is below treasury holdings value / token supply you could a: buyback token, b: let market bid it back up (potential raid of treasury if the mechanics of actual voting are not sufficiently well defined to prevent a low participation vote to pass).”

Could you elaborate on these statements and provide clarity on what the current approach is regarding governance and how it impacts the Fold token and its holders? These messages confused me more than they enlightened me.

  1. Community FAQ: One last suggestion—could a FAQ page be maintained either as a Telegram subchannel or on the Forum? This is something community members could help with and would go a long way in keeping everyone informed.

Addressing these questions and suggestions can ensure a more transparent and informed community, strengthening trust and collaboration. Thank you for taking the time to provide clarity.

2

Outside the existing revenue models from block building the captive insurance pool has multiple streams. I am providing this response to get feedback so it is not entirely complete but should answer your questions.

First lets define some parameters for modeling the tokenomics, then define the value propositions vis a vie the services that generate revenue. Then we can define KPI’s and draw some derived values from the defined service model.

Parameter Definitions

Service Unit

Measure of the requirement to access the service of the defined value proposition.

Growth Parameter Unit

Measure of the growth of the value proposition.

Adoption Unit

Measure of the adoption of the value proposition by number.

Value Proposition

Volumetric relationship between the main KPI and users. Assume a 1:1 ratio.

Overview of the Proposed System

1.1 Captive Insurance

The Captive Insurance pool is able to provide coverage for service disruption risk. This means that we can underwrite at least two such policies, namely slashing risk and outage risk.

1.2 Slashing Risk

  1. Provide liquid staking services for Ethereum validators. i.e. mevETH.
  2. Collect a protocol fee (e.g., 10% of staking rewards).
  3. Distribute that fee to token holders (stakers of the insurance token), who backstop slashing risk.
  4. Maintain an insurance guarantee that if slashing occurs, payouts are made to the affected stakeholders from the insurance pool.

Key Value Propositions

  • Slashing Protection: The protocol’s insurance component protects stakers (the mevETH LSD token holders) against slashing losses.
  • Token Yield: $FOLD (the “insurance token” or “protocol token”) accrues a share of the protocol fees.

1.2 Participants & Roles

  1. ETH Stakers: Deposit ETH into the protocol, which spins up validators. They receive a liquid staking derivative (mevETH token).
  2. Validators (Operated by the Protocol or Partners): Manage infrastructure for staking.
  3. Insurance Token Holders: Stake $FOLD to underwrite slashing risk; earn fees (in ETH or LSD tokens) in return.

1.3 Basic Flow of Funds

  1. User stakes ETH → The system mints LSD tokens at a 1:1 ratio (minus any small friction if set).
  2. Validators earn block rewards + priority fees → The protocol aggregates them.
  3. Protocol Fee = 10% of the earned staking rewards.
  4. 100% of this Protocol Fee → Goes to the insurance token stakers.
    • In the event of no slashing, they receive the entire fee.
    • If slashing occurs, the insurance pool is partially drained to compensate LSD holders for lost ETH.

1.4 Protocol Fee as a Flat Management Fee

  1. Service Parameter

    • Name: Flat Annual Management Fee
    • Unit: e.g., 0.3 ETH/year per mevETH minted (or a fixed USD amount)
    • Definition: Each participant (re: mevETH issuance) pays a fixed annual fee, regardless of their aggregated staked amount.

  2. Growth Parameter

    • Name: Total Users (i.e. total mevETH minted)
    • Unit: Number of Users
    • Definition: Growth is measured by how many unique users hold or mint mevETH.

  3. Adoption Parameter

    • Name: 1 (i.e. KPI is “Users”)
    • Unit: 1 (i.e., each mevETH issuance is one unit of the main KPI)
    • Definition: If the primary KPI is the aggregated supply minted of mevETH count itself, thus the relationship is simply 1:1.
  • Time Period
  • Number of Users (Growth Parameter)
  • Management Fee (fixed)
  • Revenue = # of users × management fee

2.0 Restaking Fee as a Percentage of Additional Yield

  1. Service Parameter

    • Name: Restaking Fee Rate
    • Unit: “% of restaking yield”
    • Definition: The protocol charges a fraction of the extra yield earned by restaking.

  2. Growth Parameter

    • Name: Total Restaked ETH
    • Unit: ETH (or USD)
    • Definition: The amount of ETH that gets restaked for secondary security or services.

  3. Adoption Parameter

    • Name: Average Restaked ETH per Validator
    • Unit: ETH/validator
    • Definition: If the main KPI is total restaked ETH, you tie it to the number of validators.
  • Time Period
  • # of Validators Participating
  • Avg. Restaked ETH per Validator
  • Total Restaked ETH = # of validators × avg. restaked ETH
  • Restaking Yield (assumption)
  • Fee Rate = service parameter
  • Protocol Revenue = total restaked ETH × restaking yield × fee rate