SQD Revenue Pools Explained (FAQs)

mojo

05 Jan 2026 • 10 min read

Over the last few days we’ve announced the SQD Revenue Pool rollout (beta) – an optional participation layer where SQD holders can lock SQD behind Portals that are funded by real AI and DeFi data demand.

This post gives a simplified overview and then answers the main questions from the community.

30-Second Summary

SQD used to be mostly emissions rewards for nodes.
With Portal / Revenue Pools, data consumers pay in fiat or stablecoins for access to Portals.
SQD holders may lock SQD into independently operated Portal pools to support capacity.
A portion of Portal fees may be distributed in stablecoins to participants who lock SQD for the benefit of the network; the rest is intended to support node rewards and long-term supply management (including possible buyback and burns).
Over time, this is intended to gradually reduce reliance on emissions and rebalance node incentives around real network usage.

In other words: we’re starting to move from inflation-only rewards to revenue-linked protocol rewards.

How The New Model Works

Under the new design:

Clients (data consumers) – including leading AI, DeFi and RWA protocols with over $16B in TVL – subscribe to a Portal and pay their monthly fees in USDT or fiat (or other supported payment methods).
Behind each Portal sits a capped “crowdfund” pool of locked SQD, supplied by SQD holders:
- SQD holders lock SQD into a capped Portal pool (1M SQD in the initial rollout, with planned expansions to 5M and 10M).
Up to 50% of the USDT fees generated by a Portal may be allocated to independently operated Portal pools and distributed to participating SQD holders that lock SQD for the benefit of clients, subject to pool parameters and operational conditions.
The remaining portion of Portal fees is intended to support the SQD network by funding:
- SQD-denominated incentives for node operators and delegators, and
- a smaller portion allocated to automated long-term supply management (including burns) to support a healthy SQD environment.

This creates a loop:

Stronger demand for data → more Portals → more fees → more SQD locked and SQD-denominated rewards bought with Portal fees → better supply management → a stronger value balance of SQD → more data in the SQD Network → more consumers.

Why This Matters

Portal / Revenue Pools are intended to introduce several important dynamics for SQD:

Demand-driven token usage, as SQD is locked to support live services.
Reduced effective circulating supply, via temporary locking and protocol-driven supply management (including possible buybacks and burns).
Customer-funded operations, helping to reduce reliance on ongoing token issuance.
A clearer link between enterprise adoption and underlying network activity.

Over time, these dynamics are intended to strengthen the relationship between SQD network usage and the role of the SQD token within that ecosystem; however, no assurance is made regarding future token performance.

Community FAQs

1. “So what actually changed?”

SQD used to be mostly emissions rewards for nodes.

Now we’re moving to:

Portals paying real fees (in stables) for data
SQD holders may lock into Portals to sit in front of that fee stream
Emissions tapering down as fee revenue ramps up

In other words: from inflation to to revenue-backed yield.

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

There are two sides here.

Builders / protocols

They can pay in USDT/fiat or other supported tokens.
That’s for UX – “web2-friendly billing”.

SQD holders

Portals need SQD locked behind them.
SQD providers buy and lock SQD to supply Portal capacity.
Fees paid by builders are streamed back to those SQD lockers and workers, and partly used for healthy automated supply management (including burns).

So no, SQD isn’t “removed from the loop”.

It becomes the collateral that captures the USDT/fiat flow:

Builders pay in stables/fiat.
SQD holders that lock get the stablecoin rewards.

3. “Is this bullish?”

Bullish.

First time you can earn stablecoin from SQD instead of only more SQD.
Yield is backed by real demand from protocols actually using the data.
Portal capacity is capped (1M → 5M → 10M SQD), so not everyone can sit in front of these revenues.
Target is 10%+ of supply locked in Portals alone over time.
Emissions for nodes taper down as fee + buyback flows ramp up.

4. “What does this mean for dilution?”

In the near term, total node rewards stay similar – treasury + early Portal fees.
As Portal revenues grow, they replace more and more of what the treasury used to pay.
Only once fees cover a meaningful chunk of rewards does APR start to step down – on a timetable, not randomly.

“Beginning of the end for emissions.
Similar rewards for now → more of it funded by real revenues → then a gradual, sustainable decline in APR as fees dominate.”

So long-term stakers shouldn’t be thinking “I’m getting wrecked”, they should be thinking:

“I’m getting paid from real usage, not just dilution.”

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

Buy pressure comes from the supply side, not front-end billing:

Portals must be backed by locked SQD → SQD providers need to buy and hold SQD to supply capacity.
Limited Portal slots (1M → 5M → 10M) mean there’s competition to sit in front of fees.
A portion of the revenue is used for automated supply-management (including burn / SQD-side rewards as parameters evolve).

So instead of forcing builders to market-buy SQD every time they send requests, you:

Let them pay in stables/fiat (good UX), and
Force capital (SQD holders) to accumulate and lock SQD to get a cut of the fees.

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

Portal capacity is intentionally limited. That’s by design: it makes those slots valuable as demand is real.

But:

Delegating to workers stays open to everyone; you don’t have to be in Portals to support the network or earn.
Over time, more Portal capacity (5M → 10M SQD, etc.) opens up if demand justifies it.

“Portals are open but limited. Not every SQD will sit in front of fees – that’s exactly why the spots matter. Small holders can still delegate to workers; big, sticky capital fights for Portal capacity.”

If you later add any “retail pool” / minimum allocation, that just turbo-charges this answer.

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

Short answer: it’s a future tuning lever, not a secret rug switch.

Right now, fee switch = 0. It does nothing.
In future, governance can turn on a small protocol fee on Portal usage (taken from locked SQD / fee flows).

The intention is to:

cap it,
make it transparent, and
only touch it via governance, with a clear process and notice.

“There is a fee switch, but it starts at 0 and can’t just be randomly turned on. If we ever use it, it will be with caps and governance – and you’ll see it coming.”

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

No. Absolutely not – Portals are independent and there is no promise or obligation of Subsquid itself.

Yield for SQD stakers will come from:

Portal fees (in stables)
Emissions (while they still exist)
Automated supply management, depending on parameters

Actual % depends on:

How much SQD is locked
How many Portals are live
How much those Portals are paying

“There is no fixed or guaranteed APR. As more real customers use the network, more fees flow to SQD holders. As emissions taper, the mix shifts from inflation to usage.”

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

Difference vs fake “real yield”:

Fees are from data requests by protocols that actually need on-chain data.
You’re not recycling your own token; you’re routing external value (USDT etc.) into the system.
The network already serves huge usage – multi-chain data lake, petabytes of queries, big protocols plugged in.

So yes, if nobody uses the data, yield goes down. This is tied to product-market fit.

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

You have options:

Do nothing → stay pure liquid, speculate on price only.
Delegate to workers → help secure the network, earn SQD emissions (and later a share of fee-tops). Good for any size.
Lock into Portals (when live) → allocate SQD to Portal capacity and sit directly in front of stablecoin fee flows + automated supply management. Limited capacity, 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 and getting paid in stables.”

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

While we cannot make any promises, the idea is to have data demand drive token scarcity:

More SQD locked in Portals + nodes → less liquid supply.
A slice of Portal revenues used for automated supply management → net reduction in supply over time, driven by usage.
Yield shifting from emissions → fees → less constant sell pressure from farmers dumping rewards.

So the flywheel to visualise:

More Portals → more fees → more SQD locked + better automated supply management → stronger position for long-term holders.

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

The first beta pool is deliberately simple and capped:

A special smart contract acts as a crowd-pool for the first Portal.
The current target cap is 1.2M SQD locked in that contract.
For this initial pool, 1,000 USDT per 30 days is scheduled to be distributed to participants.
That amount is split pro-rata across all SQD in the pool (e.g. locking 100k SQD would entitle you to the same fraction of that 1,000 USDT as your share of the 1.2M pool, subject to pool conditions).
The team reserves the right to change parameters for beta as things evolve, but changes are announced and documented.

Unlocks:

You can request to unlock; the current design foresees an unlock period of around a couple of days, with smaller positions able to exit proportionally faster than full positions.
Exact timings and mechanics will be documented with the 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 (e.g. Deutsche Telekom, DeFi protocols, etc.) pay subscription fees to the operating entity that runs the data service (for the first pool, this is Subsquid Labs).

That entity then forwards funds into the Portal / Revenue Pool program according to the published parameters (e.g. the 1,000 USDT/month discussed above).

As a pool participant, you are not entering into a direct revenue-sharing contract with those enterprises. You are opting into an optional participation mechanism (a Revenue Pool) operated by an independent provider, with Subsquid supporting the technical and organisational rollout of the framework.

That’s why both the PR and this FAQ stress that:

pools do not create a legal claim on specific enterprise revenues, and
participation does not make Subsquid or Rezolve your guarantor or counterparty in a legal sense.

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

Not exactly.

Lock-up/unbonding for Revenue Pools is a separate parameter from the existing 14-day delegation unbonding.
For the first beta pool, the current intent is an unlock period of a few days, with smaller allocations able to exit proportionally faster.
These details will be confirmed and documented with the live pool contract.

Design intent: there is a real commitment window (so it’s not just instant in-and-out farming), but it doesn’t have to mirror delegation one-to-one.

Until parameters are live, treat lock-ups as TBD and subject to change.

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

The goal is not to make node operators dependent on token price speculation.

Node operators are expected to continue receiving rewards sufficient to support the network, funded by a mix of emissions (while they last) and Portal fees.
The purpose of Revenue Pools is to make those rewards more sustainable long-term by shifting their funding source from pure emissions to fee-backed income.
Node operators can still earn via delegation and may also participate in pools if they choose, but the design doesn’t require them to become “whales” to benefit.

In short: worker incentives stay in place, and the new mechanism is meant to reduce dilution and strengthen the economics around them, not to remove them from the picture.

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

Yes - in practice they refer to the same concept.

“Portal Pools” is the product / technical term in the SQD docs.
“Revenue Pools” is the name often used in Rezolve-facing or legal/PR contexts to highlight that the pools are funded by enterprise customer payments rather than emissions.

The first pool is configured and funded by Subsquid Labs; later, the framework is designed to support multiple pools run by different providers, who can compete on parameters to attract SQD.

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

For the first beta pool:

The USDT distribution rate (e.g. 1,000 USDT/month) is pre-announced and fixed by the pool parameters, but not directly equal to total enterprise revenue.
Over time, as more pools appear and competition increases, it’s expected that these rates move closer to the economic value of the capacity provided, but this is an evolution, not a promise.

On-chain, participants will be able to see:

how much SQD is locked in each pool, and
how much USDT (or other tokens) each pool distributes per period.

Off-chain, the team will continue to share high-level metrics (e.g. number of Portals, aggregate data usage, etc.) without disclosing confidential customer billing data.

Important notice and disclaimer

This publication is provided for informational purposes only and does not constitute an offer, solicitation, or recommendation to acquire, hold, use, or dispose of any crypto-asset within the meaning of any laws, regulations or directives in any jurisdiction.

The Portal/Revenue Pool rollout is a limited beta initiative and represents an optional participation mechanism operated by independent Portal providers. It does not modify the SQD token, does not introduce new token functionality, and does not grant any rights, claims, or guarantees to rewards, returns, income, or value appreciation.

Participation in Portal pools, the receipt of any pool-related distributions, and any automated or supply management mechanisms do not constitute a right, claim, or entitlement by SQD holders against Subsquid, Subsquid Labs GmbH, or any affiliated entity, nor do they create any obligation, liability, or commitment on their part. Subsquid does not act as issuer, operator, counterparty, or guarantor of any Portal pool and is solely supporting the technical and organisational rollout of the Portal framework.

Any references to potential fee-funded distributions, incentives, or supply management measures are purely descriptive, non-binding, and subject to change, suspension, or termination at any time. Such references do not constitute a promise of performance, yield, or economic benefit. Participation is voluntary and subject to applicable terms, conditions, and risks.

Nothing in this publication constitutes investment advice, financial advice, legal advice, or tax advice. Prospective participants are solely responsible for conducting their own independent assessment of the technical, legal, regulatory, and economic risks and for ensuring compliance with all applicable laws and regulations in their respective jurisdictions.