Preview: Introducing Delegation Pools - A New Way to Delegate

SubQuery Foundation
1

Hey everyone,

We’ve been working on a new feature that we’re excited to share with you all for early feedback and discussion: Delegation Pools .

The goal here is to explore new ways for delegators to participate in the network, particularly for those who might not have the time or expertise to actively manage their own indexer selection strategy. Think of it as a “set-and-forget” or managed fund approach to delegation.

This is a work in progress, and we’d love to hear your thoughts on the concept and design.

The Core Idea

A Delegation Pool is a smart contract that acts as a single, collective delegator. Instead of you delegating directly to an indexer, you delegate your SQT to a pool. In return, you receive pool shares (as ERC-20 tokens) that represent your stake.

A designated Pool Manager (which could be a DAO, a seasoned delegator, or a team) is then responsible for deploying the pool’s total SQT to a set of indexers based on their own strategy.

Key Concept: The entire experience for the user—from delegation to the undelegation lock period—should feel and be as secure as delegating directly, just with an added management layer.

How We See It Working

  1. User Delegates to Pool: You delegate your SQT to a Delegation Pool contract.
  2. You Receive Shares: You get pool tokens proving your stake and share of the pool.
  3. Manager Delegates to Indexers: The Pool Manager uses the aggregated SQT to delegate to their chosen indexers (they can delegate, undelegate, and even redelegate).
  4. Claiming & Auto-Compounding: The Manager can claim rewards from all indexers. An option for auto-compounding (automatically re-staking rewards) is also part of the design.
  5. User Undelegates: You decide to undelegate. Your pool shares are burned, and a withdrawal request is initiated, following the same unbonding period as the network.
  6. User Withdraws: After the lock period, you can withdraw your proportional share of the SQT and rewards from the pool.

Some Open Questions We’re Pondering

This is where we’d really value community input:

  • For Delegators: Does the concept of a “managed pool” appeal to you? What kind of information would you need to see to trust a Pool Manager (e.g., historical performance, transparency reports)?
  • For Potential Managers: Does this model seem feasible? The current design allows for a rewardFee . What other tools or data would you need to effectively manage a pool?
  • Fee Structure: The current thought is a simple reward fee taken when rewards are claimed or upon user withdrawal. Are there other fee models we should consider?
  • Risks: What potential risks do you see with this pooled approach that we might not have considered? How can we mitigate them in the design?

A Note on Technical Details

The contract is designed to be non-custodial and transparent. The manager cannot withdraw your original SQT; they can only move it between indexers or through the standard undelegation process. Your ownership is always represented by your pool shares.

This is just a preliminary look. A more detailed technical specification will follow once we incorporate feedback from this discussion.

So, what do you think? We’re opening the floor for questions, concerns, and ideas. Please let us know your thoughts below!

2

We don’t need Delegation Pools. There are only a few operators with a normal APY. It’s not difficult to come and delegate.

You’d be better off reducing the withdrawal time for coins from delegation to one week! Two weeks is a long time in 2025. People’s investments are locked in for two weeks. Life happens, and we don’t need those two weeks. This will only benefit us, because people won’t be afraid to delegate, knowing they’ll have their coins in their hands for one week at most.