Skip to content

Design new UX for MFS changes #802

Open
Task
#837
Open
Design new UX for MFS changes#802
Task
#837
Assignees
thebeyondr
Milestone
SPE II - Milestone 1: Define Livepeer 2.0 delegation UX & establish baseline

Description

@ECWireless
ECWireless
opened on Sep 8, 2026

Notes

  • Based on research done in Research how MFS changes delegation #801
  • MFS is now explicitly defined as:
    reward % = min(fee % of network, stake % of network)
  • Delegators are expected to actively move stake toward high-fee, under-staked nodes to unlock more rewards.
  • Research should determine how Explorer can clearly show:
    • fee share vs. stake share
    • where a node is reward-capped
    • where moving stake could improve delegator returns
  • Account for the tension with the proposed 21-round unbonding / transfer delay, which may limit how “active” delegation can realistically be.
  • No wireframes or 2.0 contract upgrades exist at this point

Deliverables

  • Design mock-up, whether in Figma, a branch preview, or any other appropriate design surface
  • Rationale write-up within this ticket

Acceptance Criteria

This ticket will be considered complete when a design (whether in Figma, a branch preview, or any other appropriate design surface) and rationale write-up are posted below, and fully approved by @ECWireless .

Activity

  1. ECWireless
    added this to the SPE II - Milestone 1: Define Livepeer 2.0 delegation UX & establish baseline milestone on Sep 8, 2026
  2. ECWireless
    added the
    Task
    issue type on Sep 8, 2026
  3. ECWireless
    added this to SPE II - Delegator Trackon Sep 14, 2026
  4. github-project-automation
    moved this to Todo in SPE II - Delegator Trackon Sep 14, 2026
  5. ECWireless
    assigned
    thebeyondr
    on Oct 7, 2026

  6. ECWireless commented on Oct 7, 2026

    @ECWireless
    ECWireless
    on Oct 7, 2026
    CollaboratorAuthor

    TODO:

    • Figure out how subgraph schemas will likely change
    • What should the hierarchy of importance be?
    • Should this be displayed on the orchestrator page, or in the delegator page?

  7. ECWireless commented on Oct 9, 2026

    @ECWireless
    ECWireless
    on Oct 9, 2026
    CollaboratorAuthor

    @thebeyondr to the above questions:

    1. Where should this detail be displayed? Definitely on the Orchestrator page. I can see it being useful on "My Account" so delegators can see the fee share of the orchestrator they delegated to. And can potentially even see adding some text along the lines of saying the orchestrator is "stake-capped" currently or "fee-capped". On My Account, we should also consider how this plays with Design new reward-history view #803
    2. What should the hierarchy of importance be? We mainly want to push people to know where opportunity is, and push them to move to that opportunity. So if a node has high fees and low stake, we want to make sure the user understands that this may be a better place to park their stake.
    3. What subgraph schemas will most likely change? This is just a guess, since the contracts have not been updated yet:
    type Pool @entity {
  id: ID!
  round: Round!
  delegate: Transcoder!

  # LIKELY CHANGE:
  # Fees move from ETH-denominated accounting to USDC.
  fees: BigDecimal!

  rewardTokens: BigDecimal
  totalStake: BigDecimal!
  rewardCut: BigInt!
  feeShare: BigInt!

  # POSSIBLE ADDITIONS:
  # These could also be derived in Explorer from Pool + Round data
  # rather than indexed directly.
  feePercentOfNetwork: BigDecimal
  stakePercentOfNetwork: BigDecimal
  mfsRewardPercent: BigDecimal
}

type Transcoder @entity {
  id: ID!

  # LIKELY SEMANTIC CHANGE:
  # "Transcoder" effectively becomes the broader permissionless
  # Node Operator role described in Livepeer 2.0.
  active: Boolean!
  status: TranscoderStatus!

  rewardCut: BigInt!
  feeShare: BigInt!
  totalStake: BigDecimal!

  # LIKELY CHANGE:
  # Fee-volume accounting becomes USDC-based.
  totalVolumeUSDC: BigDecimal
  thirtyDayVolumeUSDC: BigDecimal
  sixtyDayVolumeUSDC: BigDecimal
  ninetyDayVolumeUSDC: BigDecimal

  # POSSIBLE ADDITIONS:
  # Useful as current-state convenience fields for Explorer,
  # though these may instead be derived from the latest Pool/Round.
  currentFeePercent: BigDecimal
  currentStakePercent: BigDecimal
  currentMFSRewardPercent: BigDecimal

  pools: [Pool!] @derivedFrom(field: "delegate")
  delegators: [Delegator!] @derivedFrom(field: "delegate")
}

type Round @entity {
  id: ID!

  pools: [Pool!] @derivedFrom(field: "round")

  mintableTokens: BigDecimal!

  # LIKELY CHANGE:
  # Network fee volume moves from ETH to USDC.
  volumeUSDC: BigDecimal!

  totalActiveStake: BigDecimal!
  totalSupply: BigDecimal!

  movedStake: BigDecimal!
  newStake: BigDecimal!

  # LIKELY REMOVED OR REDEFINED:
  # 2.0 removes the fixed active-Orchestrator cap and allows
  # permissionless node registration.
  numActiveTranscoders: BigInt!
  activeTranscoderCount: BigInt!
}
    1. New question: How should MFS opportunities be surfaced given that the proposed 21-round transfer delay may make stake movement significantly slower than it is today?

  8. thebeyondr commented on Oct 9, 2026

    @thebeyondr
    thebeyondr
    on Oct 9, 2026
    Collaborator

    Thanks, I thought about it and came up with basically the same answers so I've been able to get started in alignment. 🫡

  9. thebeyondr
    linked a pull request that will close this issuedocs: MFS delegation UX mocks for #802 #837on Oct 12, 2026
  10. thebeyondr
    added a commit that references this issue on Oct 12, 2026

    docs: add MFS UX preview and Explorer agent design rules

    22f6aff
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

Task

Projects

Milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions