Idea Proposal: Community Custom Indices on Pyth Pro

Ideas Bank
1

Off-chain creator indices published as native Pyth Pro feeds

Status: Idea for discussion with Pyth / Douro Labs / Community Council

1. Executive Summary

Pyth already delivers the highest-quality multi-asset price feeds and has successfully launched official Indices.

This idea is to let the community (especially Crypto Twitter and influencers) create their own custom indices. These indices would be:

  1. Defined by the creator (basket of existing Pyth feeds + weights + methodology)
  2. Aggregated / computed off-chain or by Pyth
  3. Published as feeds on Pyth Pro
  4. Consumable by trading venues (Hyperliquid, TradeXYZ, and others) exactly like any other Pyth Pro feed

Key requirement: Creators must stake PYTH to create and maintain an index. This adds skin-in-the-game, improves quality control, reduces spam, and creates structural demand for the PYTH token.

Additional capabilities:

  • Controlled ability to add/remove assets or adjust weights on demand (with safeguards for continuity and quality).
  • Staking or burning as the ongoing mechanism to keep an index live.

This turns influencer conviction into tradeable markets while generating new revenue for creators and the Pyth DAO.

2. Problem & Opportunity

  • Influencers and community members constantly share multi-asset conviction portfolios (crypto + equities + metals + FX, etc.).
  • There is currently no clean, high-quality way to turn those views into continuous indices that trading venues can use.
  • Official Pyth Indices are excellent but permissioned and institutional-focused.
  • Hyperliquid and TradeXYZ already rely heavily on Pyth Pro and Pyth Indices for their RWA/macro markets. Adding community-created indices would give them more unique products and increase Pyth usage.

A permissionless (but staked) “Creator Indices” layer would increase Pyth Pro adoption, create new revenue streams, and deepen community engagement.

3. Proposed Solution

Core flow:

  1. Creator stakes the required amount of PYTH.
  2. Creator defines the index (selects Pyth feeds, sets weights, chooses methodology, adds a thesis/description).
  3. The index is calculated either by Pyth or by a third-party service.
  4. The index is published as a new feed on Pyth Pro (clearly labeled “Community Index” with public methodology).
  5. Any venue (Hyperliquid, TradeXYZ, etc.) can pull the feed via the standard Pyth Pro API and list markets against it.
  6. Creator can later add/remove assets or adjust weights under controlled rules (see Section 6).
  7. Stake remains locked to keep the index live (see Section 4).

4. PYTH Staking Requirement

To create and keep an index live, the creator must stake PYTH.

Why stake ?:

  • Creates ongoing skin-in-the-game and long-term alignment.
  • Allows the stake to be returned (after cooldown) if the index is cleanly delisted.
  • Generates structural demand for PYTH without permanently destroying supply in a way that may discourage participation.
  • Burn can be considered later as an optional “premium” or permanent commitment path if desired, but staking is the primary and recommended mechanism for now.

Suggested parameters (open for discussion):

  • Minimum stake to create an index (e.g. 10,000 – 50,000 PYTH)
  • Stake remains locked while the index is active
  • Possible tiered system (higher stake → higher visibility, more complex indices, or higher rebalancing frequency)
  • Unstaking possible after a cooldown period or after the index is delisted

Benefits of the staking requirement:

  • Filters low-effort or spam indices
  • Gives creators real skin-in-the-game
  • Creates structural buy & hold demand for PYTH
  • Aligns creators with the long-term success of the Pyth network

5. Technical Architecture

Data Source

All underlying price data comes from existing Pyth Pro feeds.

Two Possible Approaches for Calculation & Serving

  1. User defines the index → Pyth Pro backend calculates it in real-time (Preferred)
    • Creator hand-picks the underlying feeds and sets the weights/methodology through a UI.
    • Pyth’s own infrastructure then continuously calculates and serves the index as a native feed on Pyth Pro.
    • Highest reliability, lowest operational burden, and seamless consumption by venues such as Hyperliquid and TradeXYZ.
    • This path requires Pyth to enable support for community-defined derived indices.
    • Best suited for supporting controlled real-time composition changes.
  2. Third-party backend does everything
    • A separate backend continuously queries individual Pyth Pro feeds, calculates the weighted index, stores the data, and serves it via its own API.
    • Higher workload and full operational responsibility on the community/third party.
    • This is the path that can be built immediately without changes from Pyth.

Smart contracts

Only needed for the PYTH staking / locking mechanism. No smart contracts are required for index calculation in the MVP.

6. Index Calculation Methodology & Dynamic Composition

Start simple and fully transparent:

  • Equal-weighted (default one-click option)
  • Custom fixed weights (creator chooses the exact percentages)

The index level is calculated from the weighted average of percentage returns (starting from a base of 100 or 1000).

Every index must publicly display:

  • Exact list of underlying feeds
  • Current weights
  • Full methodology description

Adding / removing assets or adjusting weights on demand (controlled real-time rebalancing)

To keep indices relevant and useful without sacrificing reliability or continuity:

  • Creators can add or remove assets and change weights, but under deliberate constraints rather than unrestricted real-time changes.
  • Required safeguards:
    • Public notice period (e.g. 24–72 hours) before any change takes effect.
    • Mandatory public announcement of the exact change + updated methodology.
    • Frequency limits (e.g. max N changes per month; higher stake tiers unlock more frequent rebalancing).
    • Hard limits on number of constituents and minimum weight per asset.
    • Major composition changes could be treated as a new “version” of the index (or require a higher stake tier) so historical data remains clean and continuous for traders/venues.

More advanced methods can be added later based on demand.

7. Revenue Sharing Model

Aligned with Pyth’s existing commercial model:

  • Listing / usage revenue from the feed on Pyth Pro
  • Suggested split example:
    • 40–60% → Creator
    • 20–30% → Pyth DAO
    • Remainder → any platform/operator (if applicable)

Additional upside: Creators can earn referral commissions when their audience subscribes to Pyth Pro via tracked links.

8. Addressing Key Concerns

Downtime & Reliability

A community-run server cannot match institutional-grade uptime.

→ Strong preference for Approach 1 (Pyth Pro backend calculates the index in real-time).

Quality & Brand Safety

  • Mandatory PYTH staking acts as the primary spam filter
  • Clear “Community Index” labeling (never mixed with official Pyth Indices)
  • Public methodology required
  • Easy process to pause or delist low-quality or abandoned indices
  • Minimum standards before a feed is published on Pro
  • Controlled rebalancing rules prevent sudden manipulative or low-quality composition changes

Technical Difficulty of Creating a Feed on Pyth Pro

This is currently the biggest blocker.

Today it is not possible for a community member to freely create or publish a new feed on Pyth Pro.

  • Publishing is restricted to approved first-party data providers only.
  • Official indices are created internally by Pyth + MarketVector.

Conclusion on Technical Path

Up to discussion

9. Benefits

For Pyth

  • New high-quality feeds on Pro
  • Increased Pro subscriptions and data usage
  • New revenue stream shared with the DAO
  • Stronger token utility through mandatory staking
  • More markets on Hyperliquid, TradeXYZ, and other venues

For Creators / Influencers

  • Turn market views into real, tradeable products
  • Ability to evolve the index over time under clear rules
  • Direct monetization and stronger follower engagement

For Venues (Hyperliquid, TradeXYZ, etc.)

  • More unique markets with trusted, low-latency Pyth pricing

For Traders & Token Holders

  • Ability to trade influencer conviction indices that can stay relevant
  • Increased demand and utility for PYTH

10. Feedback requested on:

  • Suitable minimum stake amount and locking rules
  • Preferred revenue-share structure
  • Quality standards and delisting process
  • Exact parameters for controlled asset addition/removal (notice period, frequency limits, versioning)
  • Confirmation that staking or burning is the preferred ongoing maintenance mechanism
  • Technical path to be decided

Thank you for considering this idea.
Also thanks to @arguer for his review.

From SCP with Love

5 Likes
2

I think thats brilliant idea to bring the X people in by creating their own indicies and blow some steam in the twitter

Cant wait to see where this goes.

As i said love ya brain SCP

3

very nice idea, ser!
Would be cool to see how people can actually implement their conviction in a tradable tool!

4

I really like the proposal (overall), more utility, flexibility, and scaling opportunities are always a win. However, a few key questions come to mind:

How do we prevent manipulations, cheating during rebalancing notices, or creators dumping tokens on their followers?

Maybe we need a slashing and a higher staking requirement , 10k–50k $PYTH feels too low.

Adding a review by the DAO, Community Council, or Douro Labs for index verification could help maintain quality and safety.

It would be great to poll potential influencers first to validate actual demand and interest.

On the revenue-share structure
Keep the baseline structure simple or implement volume-based tiers (higher trading volume = higher percentage for the creator) to strongly incentivize active promotion and market generation.

1 Like
5

Love the idea and would really love to see something along these lines ship.

My initial thoughts..

Staking:

My biggest concern is what can happen to people holding positions. If the stake can be pulled, the index can be wound down, and anyone with an open trade on Hyperliquid or wherever gets forced out at a price and time they never picked.

Unstaking basically becomes a delisting event and traders could be forced to close at a loss they may not have normally taken.

I would suggest creating a proper wind down process. This should aim to protect traders as much as possible first and foremost.

Burns instead of, or alongside staking and long term unstaking periods are other things I would suggest for consideration.

Getting the barrier right

If we set upfront cost too low we end up with endless spam and copycat indices similar to what happens with memecoins. If we set it too high we will stunt creativity and participation.

A recurring maintenance fee that gets burned handles this better than one big upfront lock. Cheap to create, ongoing cost to stay alive. Dead indices die off on their own, good ones pay for themselves out of their own revenue, and the burn scales with adoption instead of sitting there flat.

No manual controls once it’s live

This is one of my stronger concerns. Building on what @Mersault said, any discretionary change to composition is a manipulation vector. Creator adds a token, shills the index, moves the weights around their own bag. Notice periods and frequency caps slow that down but the incentive is still sitting there, and if it goes wrong it’s reputational risk for Pyth.

Instead, rules should be set at creation and then just execute automatically. Rebalancing schedule, weighting, and what happens in the edge cases all defined upfront.

If creators want to change the identity of their index they can simply create a new one with its own set of rules.

This is also a safety mechanism to protect traders from manipulation and bad actors as well as safeguard to Pyth’s reputation.

Revenue split

40 to 60% to the creator feels steep. If we go with automated rules and no manual controls then the creator does the work once at launch and collects passively from there. I’d weight it more toward the DAO and the platform offering the index, this could always be adjusted as things evolve over time too.

1 Like