[RFC-11] Hub-First Expansion: A Spot, Self-Governing Altcoin Index on Neverland

[RFC-11] Hub-First Expansion: A Spot, Self-Governing Altcoin Index on Neverland


Summary

This RFC proposes a simple product for people who want to buy strong altcoins, hold them, and let them quietly grow, without managing a dozen protocols across a dozen chains.

The idea is to bring yield-bearing versions of strong assets from other networks (such as staked HYPE, LINK and PENDLE) to Monad, and to offer rules-based baskets built from them. Think of an S&P 500 ETF, not a hedge fund: real spot assets, native staking only, fixed rules, no leverage, no trading for profit, no fund manager.

Neverland’s role can be as light as listing these tokens as collateral, exactly as it did with XAUt0 and hMON. In return, Neverland gets a new category of quality collateral, a natural borrowing product, and liquidity that stays on Monad.

This RFC does not request funds, parameter changes or a specific listing. It asks governance to signal support for the direction and for the Neverland team to assess feasibility, as a complement to deployments on other chains.

Problem Statement

Who this is for

Most long-term crypto holders keep the bulk of their portfolio in BTC and ETH and want a smaller, deliberate allocation to a handful of strong altcoins. They are not farmers or traders. They put aside part of their salary every month and want to accumulate and hold.

For this person, today’s DeFi is hostile. My own portfolio illustrates it: staked HYPE on HyperLend (HyperEVM), cbXRP on Moonwell (Base), LINK in a curated Morpho vault, PENDLE staked on Pendle. Four protocols, several chains, several gas tokens, different bridges and stablecoin routes, and a different risk profile for each position. Rebalancing to a target allocation means doing the math by hand. Borrowing against the whole portfolio is impossible.

A holder in this situation typically wants three things:

  • Simple spot exposure: buy in target proportions and hold.
  • Safe yield where it exists: native staking, not strategies.
  • Optionally, liquidity without selling: borrow stablecoins against the whole allocation in one place.

What exists today and where it falls short

No existing product delivers all three.

Option What it does well Why it doesn’t fit a spot holder
Do it yourself across chains Full control Many chains, gas tokens and bridges; manual rebalancing; no way to borrow against everything at once
Curated yield vaults (e.g. curated Morpho vaults) Higher yield, hands-off A curator actively allocates funds; you carry their decision risk; the goal is yield, not exposure
Synthetic yield assets (e.g. Ethena) Attractive yield Built on derivatives and basis trading; a synthetic dollar, not spot exposure to the assets you chose
On-chain index tokens (Reserve DTFs, CMC20, Index Coop) Fungible, transparent, rules-based Mostly single-chain, generally no native staking yield, rarely usable as collateral
CEX auto-invest and earn Very simple Custodial; opaque yield sources; nothing usable on-chain
Crypto ETPs and ETFs Regulated wrapper Brokerage-only; relatively high annual fees for baskets; limited altcoin coverage; no DeFi use
Wallet portfolio automation (e.g. Glider) Non-custodial, automated rebalancing Positions stay in your wallet as separate tokens; no single composable asset; not collateral

Why this matters for Neverland

Monad still has a limited set of high-quality, yield-bearing collateral. At the same time, expanding only by deploying Neverland on other chains means separate liquidity, oracles, risk operations and incentives on each chain, and direct competition with lenders already established there. DUST incentives spread across several markets risk becoming too thin to build sticky liquidity in any of them.

Bringing the strongest assets of other ecosystems to Monad addresses both problems: it gives holders a product that doesn’t exist today, and gives Neverland collateral, borrowing demand and liquidity that stay on Monad.

Low Level Details

Proposed model

The model has two layers.

Layer 1: one yield-bearing token per asset. For each supported asset there is one token on Monad, for example yHYPE, yLINK, yPENDLE. Each is backed by the real asset held in native staking or an established liquid staking token on its home chain (for example kHYPE for HYPE). Tokens are accumulating: staking rewards are reinvested, so each token represents slightly more of the underlying asset over time, and its price follows the asset. No claiming, no separate reward balances. Layer 1 needs no management at all: the asset is simply staked.

Layer 2: baskets. A small number of standard basket tokens (for example “HYPE / LINK / PENDLE”), each made of Layer 1 tokens and rebalanced by fixed rules. Users who want their own mix can hold Layer 1 tokens directly in chosen proportions, with automatic rebalancing.

Exits. Like stETH, there are two ways out: sell instantly on a DEX at market price, or redeem at full value after the home chain’s unstaking period (for example about seven days for HYPE).

“Isn’t this just another vault?”

Technically, yes: it is a pool of assets with a share token. The difference is the mandate, meaning what the pool is allowed to do.

A hedge fund and an S&P 500 index ETF are both pooled funds. In the first, a manager makes discretionary decisions to maximise returns. The second simply follows a published methodology. This proposal is the second kind.

Typical yield vault This model
Goal Maximise yield Exposure to chosen assets; convenient accumulation
Who decides Curator or manager, at their discretion Rules written in advance
Allowed actions Moving funds between markets, leverage, loops, derivatives Buy, stake natively, rebalance by rule. Nothing else
Source of risk Market risk plus strategy and manager risk Market risk of the assets plus staking risk
Role of yield The product A bonus from native staking only

It is also the opposite of a synthetic yield product. There is no synthetic dollar, no basis trade, no derivatives. The holder owns a claim on real assets that sit where they can be staked safely.

No fund manager needed: how the model runs itself

A passive index does not need a portfolio manager. S&P 500 funds don’t have a stock picker; they follow a methodology. The same methodology can be enforced by smart contracts and limited governance:

  • Methodology in the contract. Inclusion criteria (market capitalisation, liquidity, oracle coverage, available native staking), weighting rule (for example capped market-cap weighting or equal weights) and rebalancing schedule (for example monthly, or when drift exceeds a set band) are fixed in advance.
  • Automatic execution. Keepers trigger rebalancing on schedule; trades are executed through auctions or competing solvers. No person decides when or at what price to trade.
  • One staking source per asset. Chosen once by governance, not switched to chase yield.
  • Minimal governance. Governance only approves changes to the asset list, infrequently (monthly or quarterly), against objective criteria and behind a timelock. Changes can be optimistic: they pass unless vetoed. Governance can never move funds.
  • Narrow guardian. A guardian can only pause, or trigger an emergency delisting under predefined conditions (depeg, oracle failure, exploit of the staking source). Several of these conditions can be monitored automatically.

This is already practised on-chain: Reserve’s baskets use governance and auction-based rebalancing, and CMC20 rebalances monthly under fixed rules. Nothing here requires inventing new machinery or hiring a portfolio manager.

What a holder gets

Example: a user sets aside $300 each month for altcoins.

Today: bridge to several chains, keep gas on each, buy on different venues, choose where to stake each asset, track weights in a spreadsheet, rebalance by hand. Borrowing against the combined position is not possible.

With this model: deposit USDC on Monad, choose a basket once, and the allocation is bought, staked and kept in proportion automatically. The user sees one balance that follows the assets and grows with staking rewards, can exit instantly or redeem at full value, and can borrow stablecoins against the whole basket on Neverland if needed.

In short, the holder gets:

  • Spot exposure to the assets they chose, not a synthetic
  • Native staking yield by default, with no strategy risk
  • No manager discretion: transparent, fixed rules
  • One chain, one balance, one interface
  • Automatic rebalancing
  • The ability to borrow against a diversified altcoin allocation in one place

What Neverland gets

  • A new category of collateral, bringing the strongest assets of other ecosystems to the canonical pool.
  • A natural lending product. “Borrow against your whole altcoin portfolio” is a clear, differentiated offer that fits a lending market better than any other venue.
  • Liquidity and revenue that stay on Monad, rather than being split across chains where Aave, Morpho and local lenders are already established.
  • Focused DUST incentives, if governance chooses to support liquidity for these assets, instead of spreading them across several markets.
  • Low operational burden. Neverland does not need to build or manage the index. Its minimal role is listing the tokens as collateral under conservative parameters.

Precedents in Neverland governance

Neverland has already approved both building blocks this model needs:

  • NGV-07 (XAUt0): listing an asset issued on another network and brought to Monad via the OFT architecture, with explicit treatment of bridge dependency, issuer control and basis risk, under conservative caps.
  • NGV-06 (hMON): listing a yield-bearing token priced through a composed oracle (conversion rate x underlying price). A Layer 1 token would be priced the same way: exchange rate x underlying asset price.

Relation to multi-chain expansion

This is not an alternative to deploying Neverland on other chains. It is a complement: alongside taking Neverland to new networks, Neverland can bring the best assets of those networks to Monad.

Deploy on each chain Hub-first (complement)
Liquidity Split across chains Concentrated on Monad
DUST incentives Spread across markets Focused on one market
Competition Direct, with incumbent lenders New product category
Risk operations Repeated per chain One market, more collateral types
User reach Users on other chains Users must come to Monad

Scope and applicability

  • Protocol behavior changes: none at this stage. This RFC seeks a directional signal and a feasibility assessment only.
  • Funds and incentives: no treasury funds or DUST allocation requested.
  • Migration: not applicable. No existing positions or markets are affected.
  • Implementation: to be determined by the feasibility assessment. The Layer 1 tokens could be built by the Neverland team, a partner, or an independent builder. Any listing would follow the standard listing process through a separate Governance Vote.
  • Suggested rollout if feasible: (1) a single Layer 1 asset, likely staked HYPE, listed with conservative caps; (2) additional assets and a first standard basket; (3) stablecoin borrowing against baskets.

Risk considerations

  • Cross-chain custody: backing assets sit on other chains and depend on bridge or messaging infrastructure, historically the largest source of losses in DeFi. Any implementation requires layered controls (independent verification, rate limits, proof of reserve, pausing) and full audits.
  • Staking risk: exposure to the chosen staking source or liquid staking token, mitigated by using only established, audited providers.
  • Oracle and basis risk: as with XAUt0, oracle freshness alone is not enough; executable liquidity must also be monitored.
  • Liquidation liquidity: new tokens will start with thin liquidity on Monad. Caps must be sized to executable liquidity.
  • Redemption latency: unstaking periods mean full redemption is not instant. Liquidations must rely on DEX liquidity, not redemption.
  • Builder dependency: if the tokens are built by a third party, Neverland takes on their contract and operational risk, to be assessed like any other listing.
  • Onboarding: users must bring assets to Monad; the product has to be simple enough to justify it.

Alternatives Considered

  • Deploying on other chains only. Brings access to new users, but splits liquidity, incentives and risk operations, and competes directly with established lenders. Treated here as complementary rather than competing.
  • Listing plain bridged assets without yield. Simpler, but gives holders no reason to move staked positions to Monad and forfeits the yield that makes collateral attractive.
  • Actively managed yield vaults. Could offer higher returns, but reintroduce manager discretion and strategy risk, which is exactly what spot holders want to avoid, and would require portfolio management resources Neverland does not need to take on.
  • Synthetic exposure (derivatives or basis-trade based assets). Rejected because the target user wants to own the real asset, not a synthetic position.
  • Waiting for third parties to bring these assets to Monad. Possible, but Neverland would lose the chance to shape listing criteria and be the first market for them.

Open Questions

  • Does the Neverland team see this as compatible with its current expansion plans?
  • Which asset is the best first candidate? Staked HYPE seems natural given existing liquid staking infrastructure.
  • Should the tokens be built by the Neverland team, a partner, or an independent builder?
  • Which methodology suits a first basket better: capped market-cap weighting or equal weights?
  • What minimum liquidity and security requirements should apply before listing?
  • Should DUST incentives support liquidity for these assets, and in what proportion?

Closing Statement

Most people in crypto who want altcoin exposure are not looking for the highest APY. They want to own the assets they believe in, hold them safely, earn native staking rewards where possible, and not spend their evenings bridging and rebalancing. Today no product serves them well.

Neverland can be the place where they do. The protocol has already shown, with XAUt0 and hMON, that it can list cross-chain and yield-bearing assets responsibly. This RFC proposes taking the next step: a spot, rules-based, self-governing index built from those kinds of assets, and a lending market that lets holders use it.

If governance and the team see merit in this direction, the next step would be a feasibility assessment and, if positive, a separate Governance Vote for a first asset.

Disclosure: I am a Neverland user with a lending position and 5,000 DUST locked in veDUST. I am not affiliated with any project mentioned. I have prepared a detailed design of the model and I am happy to share it with the Neverland team.


References

Thanks for putting this together. I understand this is intended as a directional signal and a mandate for the Neverland team to assess feasibility, rather than approval of an implementation.

I think the main thing that needs to be clearer is what that mandate actually asks the team to assess and where responsibility is expected to sit if the direction proves feasible. The RFC describes the architecture, but most of the operational ownership is still open, at minimum:

  • Issuer: who builds, deploys and maintains the Layer 1 yield-bearing tokens, and who is accountable for them
  • Custody and staking: who holds the underlying assets on their home chains, which staking providers are used, and who carries that risk
  • Oracles: who provides and maintains pricing for both the wrappers and the baskets
  • Liquidity: how sufficient liquidation liquidity is established and who is responsible for it
  • Rebalancing: who operates and funds the keepers, auctions and solver infrastructure

These don’t necessarily need to be answered at the RFC stage, but I think the distinction should be explicit between what governance is signalling support for now and what the Neverland team is actually being mandated to do next.

If the intent is for these questions to be investigated, with potential operators and partners identified and an executable structure brought back to governance, that makes sense, and I’d expect that work to come from the proposer, with the Neverland team reviewing. If Neverland is expected to assume any of these roles itself, that should be specified before governance is asked to authorize it.

1 Like

Thanks, this is exactly the right question to push on, and I agree the RFC doesn’t currently draw a clear enough line between the direction and the mandate.

To be upfront about my own position: I’m a user and the author of the design, not an operator. I’m not in a position to take on issuance, custody, or infrastructure ownership, and I don’t want to imply otherwise. So to answer your points directly, as I see them:

Issuer. This should not be Neverland. The most realistic path is an existing team already issuing yield-bearing tokens, or an independent builder. Neverland’s role would be the one it already knows: reviewing and listing the result.

Custody and staking. Established liquid staking providers on each home chain, rather than anything new built for this purpose. For HYPE that means an existing LST provider; the staking risk sits with them and is assessed at listing, as with hMON.

Oracles. A composed path, exactly like hMON: exchange rate x underlying price, using existing feed providers. Baskets price from their components.

Liquidity. This is the hardest one and, in my view, the real gating factor. It needs either the issuer, a market maker, or incentives — and it should be sized before any listing, not after.

Rebalancing. Keepers and auction/solver infrastructure that already exists as a service, funded from the product’s own fees, not by Neverland.

On what governance would actually be signalling: I’d narrow it to interest in the direction, with no mandate for the team beyond reviewing a concrete proposal if and when one is brought back with named operators. If that reading works, I’m happy to amend the RFC to state it explicitly.

On what I can contribute: my useful skill here isn’t operational, it’s understanding how an ordinary user thinks. Most of DeFi is designed from inside the crypto mindset. The clearest counter-example is what Robinhood did with its own chain: the pools, the routing, the mechanics were all put under the hood of an app people already knew how to use, and it reached an audience that would never have touched the same thing presented as DeFi. That is what I’d want this to be.

So I can’t be the operator, but I can stay involved on the product and user-experience side, be available in Discord, and help shape it as it develops. I’ve also written up the model in more detail than the RFC covers — mint and exit mechanics, custody controls, oracle and listing rules, and the economics. Nothing exotic, but it’s all in one place, and I’m glad to share it with the team or with whoever ends up building this.