SQD token : comment fonctionne le système de récompenses ?

Les récompenses du token SQD visent un objectif précis : aligner le rendement du staking sur les besoins réels de calcul et d’indexation du réseau Subsquid, sans supervision centralisée.

Le protocole ajuste le taux en fonction de l’usage, avec une base projetée autour de 20 % à l’équilibre, et des pointes qui atteignent 70 % lorsque le réseau manque de workers.

Le dispositif s’appuie sur un pool initial représentant 10 % de l’offre totale sur trois ans, avec une contrainte interne qui limite la dépense à 90 % de ce pool.

Le protocole calcule ces rewards par epoch quotidienne.

Passons au rôle de Subsquid Network et de SQD dans cet ensemble.

Qu’est-ce que Subsquid Network et le token SQD ?

Subsquid Network fonctionne comme un moteur de requêtes décentralisé dédié à l’extraction de données on-chain à grande échelle, afin de servir des usages analytiques, des indexeurs et des applications.

Le réseau interroge plus de 100 chaînes compatibles EVM et Substrate, ce qui réduit la dépendance à des fournisseurs de données fermés.

Le token SQD ancre la sécurité économique du réseau et rémunère les opérateurs qui apportent du calcul et de la disponibilité.

Cette architecture vise aussi un coût bas d’extraction de données, avec un ordre de grandeur rare dans l’indexation on-chain.

• Plus de 100 réseaux EVM et Substrate couverts.
• Offre totale de 1,337 milliard de SQD.
• Token déployé sur Ethereum et Arbitrum.
• Coût d’extraction indicatif de 1 To : 1 à 5 $.

Le token, lancé mi-mai après un testnet CoinList qui a réuni 20 000 participants, s’inscrit dans une feuille de route marquée par un mainnet data lake annoncé en juin, ce qui éclaire directement la logique de rewards.

D’où proviennent les récompenses SQD ?

Le système de rewards s’alimente, sur les trois premières années, via un rewards pool dédié.

Subsquid Labs a réservé 10 % de l’offre totale de SQD pour financer cette émission incitative dans le temps.

Le protocole applique un plafond de distribution par epoch afin d’éviter une dérive du rendement lorsque le montant total staké baisse.

Une règle d’économie interne borne la consommation à 90 % du pool sur la période, ce qui structure la durabilité du programme.

Paramètre	Valeur
Rewards pool (exemple)	1 000 000 SQD.
Total staké (exemple)	10 000 000 SQD.
APR_CAP (exemple)	(0,3 × 1 000 000) / 10 000 000 = 3 %.
Durée d’une epoch	1 jour.

Le cap par epoch impose une discipline d’émission : le rendement affiché ne dépasse pas la limite compatible avec l’enveloppe sur trois ans.

La structure protège le pool contre un épuisement prématuré et rend le mécanisme lisible pour les stakers.

Comment le taux de récompense est-il calculé ?

Le protocole combine deux mécanismes : un taux ajusté par l’utilisation et la capacité cible du réseau (rAPR), puis un plafond APR_CAP qui dépend du total staké.

Le taux effectif correspond au minimum entre le rAPR issu de l’usage et ce plafond lié au pool.

Les sections suivantes découpent les variables qui pilotent ce rAPR et la contrainte APR_CAP.

Elles clarifient aussi le passage d’un taux annuel à une distribution par epoch quotidienne.

Utilisation du réseau et capacité cible

L’utilisation représente l’écart entre une capacité cible, définie comme le niveau optimal pour servir les requêtes sans friction, et la capacité réellement disponible.

Le protocole exprime cette utilisation comme (capacité cible – capacité actuelle) / capacité cible, ce qui transforme une tension opérationnelle en signal économique.

Quand le réseau converge vers son équilibre, le base APR projeté se situe autour de 20 %, ce qui sert de repère de long terme.

Le protocole compare ensuite ce base APR au plafond APR_CAP pour obtenir le rAPR retenu.

La distribution quotidienne s’obtient en annualisant à rebours, selon rAPR/365 appliqué au total staké, qui additionne bonded et delegated.

• L’utilisation suit la formule : (capacité cible – capacité actuelle) / capacité cible.
• La capacité cible désigne le point d’optimum pour des requêtes fluides.
• Le base APR projeté vise 20 % à l’équilibre du réseau.
• Le taux quotidien s’appuie sur : (rAPR/365) × total staked (bonded + delegated).

Limite APR_CAP et total staked

Le plafond APR_CAP relie directement le rendement maximal au volume global staké, ce qui crée un effet mécanique de dilution lorsque davantage d’acteurs participent.

Le protocole le formule ainsi : APR_CAP = (0,3 × pool initial) / SQD staked.

Cette relation soutient l’objectif de dépense limitée à 90 % du pool en trois ans, puisque le cap se réajuste quand le total staké varie.

Le total staké agrège les SQD bonded des workers et les SQD delegated des délégateurs, sans distinction comptable dans le calcul du plafond.

Le protocole débloque les rewards à chaque epoch sur la base de (rAPR/365) × total staked.

• APR_CAP : (0,3 × pool initial) / SQD staked.
• Total staked : delegated + bonded.
• Rewards par epoch : (rAPR/365) × total staked.

Comment les rewards sont-ils répartis entre workers et délégateurs ?

Le réseau distingue deux profils : les workers, qui opèrent l’infrastructure et traitent les requêtes, et les délégateurs, qui fournissent du capital staké.

La répartition sert à comparer des incentives de nature différente, entre rendement d’exploitation et rendement passif.

Le protocole lie une partie des rewards à la contribution et à la performance côté worker.

Calcul pour les workers

Le protocole rémunère un worker à partir de trois briques : sa part de stake, sa contribution compute, puis des discounts liés à la disponibilité et à la tenue dans le temps.

La part de stake s’exprime par s[i] = S[i] / sum(S), ce qui mesure le poids relatif du worker dans l’ensemble des stakers.

La contribution compute s’appuie sur T[i] = sqrt(t_scanned[i] × t_e[i]), qui combine les chunks scannés et la taille des réponses servies.

Deux rabais modulent la rémunération : D_liveness, basé sur le temps en ligne auto-déclaré, et D_tenure, qui reflète la consistance de cette présence.

La formule de rewards worker agrège le bonded et une composante liée au stake : r[i] × b[i] + 0,5 × r[i] × s[i], avec b[i] défini comme le bonded.

Élément	Définition ou formule
Contribution de stake s[i]	S[i] / sum(S).
Contribution compute T[i]	sqrt(t_scanned[i] × t_e[i]).
t_scanned[i]	Chunks scannés.
t_e[i]	Taille des réponses servies.
Discount D_liveness	Pourcentage online auto-déclaré.
Discount D_tenure	Consistance de la présence online.

Avec un rate de 25 %, 1 million de SQD bonded et 1 million de SQD stakés, le calcul d’exemple conduit à 500 000 SQD de rewards.

Le réseau vise un ordre de grandeur de 20 à 30 % pour la part des workers à l’équilibre.

Récompenses pour les délégateurs

Le délégateur vise un rendement passif, puisque le worker exécute l’activité et porte la responsabilité opérationnelle.

Le protocole attribue la part délégateur via 0,5 × r[i] × s[i], en prenant s[i] comme le montant delegated.

Le rendement observé autour de l’équilibre du réseau se situe autour de 10 % sur les SQD delegated, selon les paramètres d’usage et de cap.

La vérification des rates par worker passe par l’app Subsquid Network, ce qui permet d’identifier les opérateurs dont la performance sert le mieux la distribution.

• La formule délégateur suit : 0,5 × r[i] × s[i] (avec s[i] en delegated).
• Le repère de rendement à l’équilibre tourne autour de 10 % sur les SQD delegated.
• Les rates se consultent dans l’app Subsquid Network, le worker restant responsable de la performance.

Comment maximiser ses rewards SQD ?

L’optimisation des rewards dépend surtout du choix des bons opérateurs et de l’état du réseau, sans lien avec une promesse de rendement fixe.

Un délégateur recherche des workers actifs, visibles comme live, et exposés à du trafic, car l’usage pilote le rAPR.

Un worker, lui, améliore sa rémunération en maintenant une présence en ligne et en traitant des requêtes, puisque la disponibilité et le compute pèsent dans la formule.

• Déléguez via l’app Subsquid Network vers des workers live avec un trafic élevé.
• Comparez les rates et la régularité des opérateurs avant de déléguer.
• Côté worker, maintenez l’uptime et traitez le trafic pour renforcer la contribution compute.
• Surveillez les phases de sous-capacité, car le base APR grimpe jusqu’à 70 % lorsque le réseau manque de workers.
• Explorez les opportunités de staking et de DeFi autour de SQD via des plateformes comme Criffy et via des exchanges.
• Intégrez les signaux périphériques du marché, comme l’airdrop passé de Binance à 500 SQD, pour contextualiser la distribution et l’attention portée au token.

Quand le réseau sort de la sous-capacité, le rendement se normalise autour de son équilibre, ce qui recompose la hiérarchie entre stratégies.

Quand l’activité se tend, le mécanisme favorise l’apport de compute et redistribue l’incitation vers l’infrastructure.