Back to blog
January 5, 2026 · 10 min · SQD Team

SQD Revenue Pools Explained (FAQs)

Tokenomics Revenue Pools FAQ
SQD Revenue Pools Explained (FAQs)

SQD recently announced a Revenue Pool rollout (beta), an optional participation layer where SQD token holders can lock their tokens into Portals funded by genuine AI and DeFi data demand.

30-Second Summary

  • SQD previously offered primarily emissions-based rewards for node operators
  • With Portals/Revenue Pools, data consumers now pay in fiat or stablecoins for access
  • SQD holders may lock tokens into independently operated Portal pools to support capacity
  • A portion of Portal fees may distribute as stablecoins to participating SQD lockers; remaining fees support node rewards and supply management
  • The system aims to gradually reduce reliance on emissions and rebalance incentives around actual network usage

Key shift: Moving from inflation-only rewards to revenue-linked protocol rewards.

How The New Model Works

The mechanism operates in four steps:

  1. Data consumers (including protocols with over $16B TVL) subscribe to Portals and pay monthly fees in USDT or fiat

  2. Portal backing structure: Each Portal is supported by a capped crowdfund pool of locked SQD supplied by holders

    • Initial cap: 1M SQD
    • Planned expansions to 5M and 10M
  3. Fee allocation: Up to 50% of Portal USDT fees may go to independently operated pools and distribute to participating SQD lockers

  4. Remaining fees support:

    • SQD-denominated incentives for node operators and delegators
    • Automated long-term supply management (burns)

The intended loop: Stronger demand for data → more Portals → more fees → more SQD locked and SQD-denominated rewards bought with Portal fees → better supply management → stronger value balance of SQD.

Why This Matters

Portal/Revenue Pools introduce several intended dynamics:

  • Demand-driven token usage as SQD locks to support live services
  • Reduced circulating supply through temporary locking and protocol-driven supply management
  • Customer-funded operations reducing reliance on token issuance
  • Clearer enterprise adoption-to-network activity connection

These dynamics are intended to strengthen relationships between SQD network usage and the token’s ecosystem role, though no assurances regarding future token performance exist.

Community FAQs

1. “So what actually changed?”

Before: SQD functioned mostly as emissions rewards for node operators.

Now:

  • Portals collect real fees in stablecoins from data consumers
  • SQD holders may lock tokens into Portals to access fee streams
  • Emissions taper as fee revenue increases

The transition moves from inflation to revenue-backed yield.

2. “Do builders still need SQD, or is it all USDT/fiat now?”

For builders/protocols: They can pay in USDT/fiat or other supported tokens for web2-friendly billing.

For SQD holders: Portals require locked SQD behind them. SQD providers must acquire and lock tokens to supply Portal capacity. Fees stream back to lockers and partially fund supply management including burns.

SQD doesn’t leave the ecosystem — it becomes the collateral that captures the USDT/fiat flow: Builders pay in stables; SQD lockers receive stablecoin rewards.

3. “Is this bullish?”

Affirmative indicators include:

  • First opportunity to earn stablecoin from SQD instead of only more SQD
  • Yields backed by genuine protocol demand for data
  • Capped Portal capacity (1M → 5M → 10M SQD) creates scarcity
  • Target of 10%+ of supply locked in Portals alone over time
  • Node emissions taper as fee and buyback flows increase

4. “What does this mean for dilution?”

The progression:

  • Near term: Node rewards stay similar (treasury + early Portal fees)
  • Growth phase: Portal revenues replace treasury-funded payments
  • Maturity: APR steps down gradually once fees meaningfully cover rewards — on scheduled timeline, not randomly

Long-term stakers should view this as receiving payment from real usage, not just dilution.

5. “Where’s the buy pressure if users don’t pay in SQD?”

Buy pressure emerges supply-side:

  • Portals require locked SQD backing → SQD providers must purchase and hold tokens for capacity
  • Limited Portal slots (1M → 5M → 10M) create competitive pressure
  • Revenue portions fund automated supply management (burns/rewards)

Rather than forcing builders to constantly market-buy SQD, the system lets them pay in stables while forcing capital allocation to accumulate locked SQD for fee access.

6. “Isn’t this just for whales? What about small holders?”

Portal capacity is intentionally limited to maintain value — by design.

However:

  • Delegation to workers remains open to all holders
  • You don’t need Portal participation to support the network or earn
  • More Portal capacity opens over time (5M → 10M) if demand justifies
  • Future “retail pool” mechanisms could further improve accessibility

Portals are open but limited. Not every SQD will sit in front of fees — that’s exactly why the spots matter.

7. “What’s this fee switch thing — is it a tax button?”

The fee switch is a future tuning lever, not a secret rug switch.

Current state: Switched to zero; has no effect.

Future design:

  • Governance could activate small protocol fees on Portal usage
  • Caps would apply
  • Changes only via transparent governance with clear notice

8. “Is the yield guaranteed? Are you promising X%?”

No guarantees exist. Portals are independent with no Subsquid obligation.

Yield sources include:

  • Portal fees (stablecoins)
  • Emissions (while available)
  • Automated supply management parameters

Actual returns depend on:

  • Locked SQD amounts
  • Active Portal count
  • Portal payment levels

There is no fixed or guaranteed APR. As more real customers use the network, more fees flow to SQD holders.

9. “Isn’t this just ‘real yield’ that dies when the hype dies?”

Key differences from fake “real yield”:

  • Fees originate from data requests by protocols genuinely requiring on-chain information
  • External value (USDT) routes into the system rather than recycling internal tokens
  • The network already serves massive usage (multi-chain data lake, petabytes of queries, major protocols)

Yield would decline if data demand drops — this mechanism ties directly to product-market fit.

10. “So what do I actually do as a holder?”

Holders have three options:

  • Remain liquid: Pure speculation on price without participation
  • Delegate to workers: Support network security, earn SQD emissions and later fee distributions. Works for any holder size.
  • Lock into Portals (when live): Direct Portal capacity allocation, stablecoin fee streams, automated supply management participation. Limited capacity with higher competition.

You’re not just farming emissions and hoping price outruns dilution — you’re plugging your SQD into actual demand from AI/DeFi/RWA protocols.

11. “How does this help price long-term?”

The proposed mechanism links data demand to token scarcity:

  • More locked SQD in Portals/nodes → reduced liquid supply
  • Portal revenue portions funding automated supply management → net supply reduction driven by usage
  • Yield shift from emissions to fees → reduced farmer dumping pressure

The visualized flywheel: More Portals → more fees → more locked SQD plus better supply management → stronger long-term holder position.

12. “What are the parameters of the first beta Portal / Revenue Pool?”

Initial pool specifications:

  • Smart contract functions as crowd-pool for the first Portal
  • Target cap: 1.2M SQD locked
  • Scheduled distribution: 1,000 USDT per 30 days
  • Distribution method: Pro-rata split across all pool SQD
  • Team reserves right to adjust beta parameters with announcements

Unlock mechanics:

  • Unlock requests permitted
  • Current design: around 2-day unlock period
  • Smaller positions exit faster than full positions
  • Exact mechanics documented with live pool

All of this is beta, optional, and not a guarantee of any particular APR.

13. “Who is my counterparty when I join a Portal / Revenue Pool?”

Enterprise customers pay subscription fees to the operating entity running the data service (Subsquid Labs for the first pool).

That entity forwards funds into the Portal/Revenue Pool program per published parameters.

As participant, you don’t enter direct revenue-sharing contracts with enterprises. Rather, you opt into an optional participation mechanism operated by an independent provider, with Subsquid supporting technical and organizational rollout.

Critical points:

  • Pools don’t create legal claims on specific enterprise revenues
  • Participation doesn’t make Subsquid or Rezolve your legal guarantor

14. “What is the lock-up duration? Is it just 14 days like delegation?”

Revenue Pool lock-up operates as a separate parameter from delegation unbonding.

First beta pool intent:

  • Unlock period of a few days
  • Smaller allocations exit proportionally faster

Design philosophy: a genuine commitment window exists without requiring exact delegation period mirroring.

Until live, treat lock-up details as TBD and subject to change.

15. “How are node operators treated in the new model?”

The goal prevents node operators becoming dependent on token speculation.

Design principles:

  • Operators continue receiving sufficient rewards to support the network
  • Funding sources: emissions (temporary) plus Portal fees
  • Revenue Pools make operator rewards more sustainable by shifting from pure emissions to fee-backed income
  • Operators can delegate and potentially join pools, though the design doesn’t require “whale” status

Worker incentives stay in place, and the new mechanism is meant to reduce dilution and strengthen their economics.

16. “Are ‘Revenue Pools’ and ‘Portal Pools’ the same thing?”

Yes — they reference the same concept with different naming contexts:

  • “Portal Pools” = product/technical documentation term
  • “Revenue Pools” = term used in Rezolve or legal contexts highlighting enterprise customer funding

Future design: The framework supports multiple pools operated by different providers competing on parameters to attract SQD.

17. “How transparent will this be around revenue and distributions?”

For the first beta pool:

  • USDT distribution rate (e.g., 1,000 USDT/month) is pre-announced and fixed, but not directly equal to total enterprise revenue
  • As more pools emerge and competition increases, rates expected to move closer to capacity economic value — an evolution, not a promise

On-chain visibility:

  • Locked SQD per pool
  • USDT distributions per period

Off-chain sharing:

  • High-level metrics (Portal count, aggregate data usage)
  • No confidential customer billing disclosures

Important Notice and Disclaimer

This publication provides informational purposes only and doesn’t constitute acquisition, holding, use, or disposal offers under any jurisdiction’s laws.

Key disclaimers:

  • Portal/Revenue Pool rollout is a limited beta and optional participation mechanism
  • Doesn’t modify the SQD token or introduce new token functionality
  • Grants no rights, claims, or reward guarantees
  • Doesn’t create Subsquid obligations or liabilities
  • Fee distributions and supply management are non-binding and subject to change/suspension
  • Constitutes neither investment, financial, legal, nor tax advice
  • Prospective participants must independently assess technical, legal, regulatory, and economic risks

Want to learn more about SQD?