La documentation officielle décrit POKT Network comme un protocole ouvert et décentralisé de livraison de données. La réponse à « what is pokt network » concerne donc la coordination, l'enregistrement et la vérification d'une demande : un relay transporte la demande, une session définit une attribution temporaire, un supplier fournit des données, et un claim avec un proof relie le travail hors chaîne au règlement du protocole. Il s'agit d'une explication du système, non d'un guide d'interaction avec un service ni d'une affirmation sur un déploiement actif.
Qu'est-ce que POKT Network ?
POKT Network est un modèle de protocole destiné à la livraison de données. Les documents officiels le présentent comme un réseau ouvert et décentralisé de livraison de données, en citant les requêtes blockchain RPC comme cas courant. L'idée principale n'est pas que toutes les sources de données se comportent de la même manière, mais que le protocole peut coordonner des rôles distincts autour d'une demande sans qu'un opérateur unique définisse tout le parcours.
Dans le modèle documenté, une application a besoin d'information, un gateway peut orienter la demande et un supplier renvoie une réponse issue d'un service pris en charge. Il s'agit de responsabilités séparées. Elles ne permettent pas de conclure que toutes les applications, tous les gateways ou tous les suppliers ont les mêmes logiciels, permissions, fiabilité ou disponibilité actuelle.
Relay est le terme du protocole pour une demande de données et sa réponse correspondante. Cette définition garde l'explication concrète : le réseau concerne la livraison de données et sa comptabilisation. Elle ne promet pas un résultat de données déterminé, une interface ou l'état d'un système externe.
Le protocole décrit ici s'appelle Shannon, et ce nom marque une rupture avec ce qui précédait. La page officielle de questions sur la mise à niveau de Pocket Network indique que le hard fork vers le réseau principal Shannon a été exécuté le 3 juin 2025, que l'ancienne chaîne Morse a été archivée pour consultation puis abandonnée, ses paramètres réseau mis à zéro et le trafic redirigé vers Shannon, et que la mise à niveau a fait passer le réseau aux clés secp256k1 et fait de Pocket une chaîne Cosmos pleinement native. La documentation actuelle énonce la portée tout aussi clairement : Pocket est surtout connu pour l'accès aux RPC de chaînes de blocs, mais le protocole Shannon est décrit comme indifférent au type de données et comme relayant toute forme de données, y compris des requêtes d'inférence de modèles d'intelligence artificielle et d'autres types de services enregistrés en chaîne. Décrire le projet comme un simple réseau RPC décentralisé reviendrait donc à minorer ce qu'affirment aujourd'hui les documents officiels.
Quel problème POKT Network cherche-t-il à traiter ?
De nombreuses applications blockchain doivent obtenir des données de chaîne ou envoyer une requête à un service lié à ces données. Si cet accès dépend d'un chemin de livraison étroit, une interruption, un changement de règle ou une difficulté technique sur ce chemin peut affecter les applications dépendantes. La documentation de POKT Network présente la livraison décentralisée de données comme une manière de coordonner cette dépendance au moyen de rôles de protocole et de règles enregistrables.
La conception distingue celui qui demande les données, celui qui les fournit et la couche qui oriente la demande. Cette distinction est importante pour l'analyse : le rôle de routage d'un gateway diffère du rôle de fourniture d'un supplier, et les deux diffèrent des fonctions d'enregistrement et de vérification du protocole. Décrire ces fonctions séparément est plus exact que de traiter la décentralisation comme une propriété unique.
Les matériaux du projet évoquent aussi des services de données au-delà d'un seul contexte blockchain. C'est une indication de périmètre, non une prévision selon laquelle un service précis serait disponible maintenant ou adapté à une tâche donnée. Lorsqu'elles comptent, les définitions de services, les implémentations et les conditions actuelles doivent être vérifiées dans des sources officielles à jour.
Comment POKT Network livre-t-il des données ?
À un niveau général, un relay commence lorsqu'une application a besoin des données d'un service défini. Un gateway peut orienter ce relay vers les suppliers attribués à la session pertinente, puis un supplier renvoie la réponse. Le rôle du protocole est de rendre l'attribution et la comptabilisation ultérieure compréhensibles par des règles, plutôt que de les confier à un répartiteur central.
Une session est un contexte limité dans le temps qui relie une application, un service et un ensemble de suppliers. La documentation technique officielle décrit cette attribution comme déterminée par les entrées pertinentes du protocole. Cela explique pourquoi la composition d'une session peut être confrontée à l'état du protocole, mais ne prouve pas la qualité ni la signification des données renvoyées par un supplier donné.
Le flux documenté sépare également la livraison immédiate des données du règlement ultérieur. Pendant une session, un supplier peut conserver des enregistrements cryptographiques liés aux relays servis ; ils deviennent pertinents lorsque le travail est représenté auprès du protocole. Ce texte décrit seulement le mécanisme, sans étapes de configuration, d'exploitation ou de soumission.
Quel est le rôle de POKT dans le système ?
POKT est le ticker que la documentation officielle du projet utilise pour le jeton natif du protocole. Dans le système documenté, POKT est lié à la comptabilisation et au règlement du protocole entre des rôles définis. C'est une description fonctionnelle d'un composant du protocole, non une affirmation au sujet d'une étiquette externe, d'un enregistrement d'actif particulier ou d'une décision personnelle.
Il faut distinguer le rôle systémique documenté du jeton d'un paramètre numérique actuel. Les matériaux officiels décrivent le règlement après des claims et proofs valides, mais les proportions, répartitions et autres paramètres concrets peuvent changer. Ce profil ne donne volontairement ni chiffre d'offre, ni facteur de règlement, ni montant de frais, ni autre quantité variable dans le temps.
Le ticker seul n'identifie pas non plus une adresse de contrat. Des étiquettes similaires peuvent apparaître dans des contextes sans lien, et le nom d'un projet n'authentifie pas une page tierce. Lorsqu'un enregistrement propre à un réseau est important, la source officielle pertinente et l'enregistrement correspondant dans la chaîne doivent concorder avant que l'étiquette soit considérée comme confirmée.
La documentation officielle de tokenomics expose la mécanique de règlement de façon concrète, sans la laisser abstraite. Le travail de service est tarifé en unités de calcul indexées sur le dollar américain et non sur le jeton, de sorte que le coût d'une requête ne bouge pas avec le jeton. L'émission est décrite comme pilotée par la demande et non par le temps : il n'y a pas de récompense de bloc fixe, et la quantité émise est proportionnelle au volume de relay servis. Chaque claim réglé brûle des POKT sur le dépôt de l'application et en réémet une quantité moindre, car le paramètre de ratio d'émission est documenté à 0,975 dans le cadre de la proposition PIP-41 : pour 100 POKT brûlés, 97,5 POKT sont émis et les 2,5 POKT restants sont retirés définitivement. Ce qui est émis est ensuite réparti entre les suppliers, les validateurs, la trésorerie de la DAO et le propriétaire de la définition de service, la part documentée des suppliers étant la plus élevée. Les mêmes pages donnent un stake minimal de supplier de 59,500 POKT, une période de déblocage de 21 jours et une offre totale d'environ 2,05 milliards de POKT lue en direct depuis la chaîne. Ce sont les paramètres Shannon actuels, fixés par la gouvernance ; les chiffres publiés pour la chaîne Morse retirée ne décrivent plus ce système.
Écosystème POKT Network et usages documentés
L'écosystème POKT Network peut être compris comme l'ensemble des rôles et enregistrements nommés dans les matériaux du protocole : applications qui demandent un service, gateways qui peuvent coordonner le routage, suppliers qui livrent des données, définitions de services et contributeurs du protocole. Il s'agit d'un périmètre architectural, non d'une mesure d'adoption ni d'une approbation d'une intégration précise.
L'usage documenté le plus familier est la livraison de données blockchain RPC, mais la description officielle traite l'architecture plus largement comme orientée données. Cela explique le vocabulaire du projet, sans constituer un guide de configuration. La prise en charge, la configuration et les limites actuelles d'un service déterminé doivent être vérifiées séparément.
Le mot écosystème ne doit pas effacer les frontières entre des participants indépendants. Gateway, supplier, application et définition de service peuvent avoir des codes, une gouvernance et des conditions d'exploitation différents. Le protocole décrit comment ils peuvent se relier dans un flux de données, mais n'accorde pas à tous les participants une posture de sécurité identique ni une garantie commune.
En quoi relays, sessions, claims et proofs diffèrent-ils ?
Un relay est un événement de livraison de données : la demande et la réponse associée. Une session est un contexte de protocole limité dans le temps qui relie une application et un service à des suppliers choisis. Un claim est la déclaration structurée d'un supplier concernant le travail de cette session, tandis qu'un proof est une preuve cryptographique liée à cette déclaration que le protocole peut évaluer.
Ces termes interviennent à des étapes différentes. Les relays concernent la livraison, les sessions apportent le contexte d'attribution, les claims résument le travail après ce contexte et les proofs soutiennent la vérification avant le règlement. Conserver cette séquence évite une exagération : un claim n'est pas une vérification achevée, et un mécanisme de proof n'est pas une garantie générale pour tous les composants hors chaîne.
Les matériaux techniques décrivent la relation entre un claim enregistré et un proof ultérieur comme un schéma commit-and-reveal. Cela explique pourquoi le protocole peut contrôler des preuves sans enregistrer chaque événement de données directement dans la chaîne. Une conclusion sur un déploiement particulier exige néanmoins la version, les paramètres et les limites actuels de ce mécanisme.
Risques et limites
Le premier risque est l'extrapolation conceptuelle. La livraison décentralisée de données décrit une conception de protocole, mais ne promet pas que chaque réponse est exacte, rapide, confidentielle ou continuellement disponible. Sources de données, gateways, suppliers, code client, définitions de services et versions de protocole peuvent introduire des conditions qu'un aperçu général ne résout pas.
Il existe aussi des risques d'implémentation et de gouvernance. Les règles de session, les détails de sélection du proof, les paramètres économiques, les règles d'accès, les versions logicielles et l'ensemble des services pris en charge peuvent changer. Une phrase décrivant précisément une version de documentation peut devenir incomplète après une évolution du protocole ou d'un déploiement associé ; la date et le périmètre sont donc essentiels à la vérification.
Les risques de correspondance entre identité et enregistrement comptent également. Un nom ou un ticker ne prouve pas qu'une interface externe, un enregistrement de contrat ou une chaîne est officiel. Lorsqu'un enregistrement précis est nécessaire, comparez le contexte officiel actuel, le nom du réseau et l'information technique en lecture seule. En cas de divergence, la conclusion prudente est que l'affirmation n'est pas encore vérifiée.
Un protocole reconstruit apporte ses propres limites. Le ratio d'émission, les parts de répartition, le stake minimal et le taux de conversion des unités de calcul sont des paramètres pilotés par la gouvernance : tout chiffre cité depuis la documentation est donc un relevé daté et non une propriété fixe. Les documents officiels décrivent la participation sans permission ainsi : enregistrer un service ou faire tourner un nœud supplier ne suppose ni liste blanche ni étape d'approbation, ce qui signifie aussi que personne ne contrôle ce qui est enregistré. La documentation elle-même note que le module d'émission inflationniste a besoin d'une protection contre un opérateur qui contrôlerait à la fois une application et un supplier et fabriquerait du trafic, et que cette protection consiste à surfacturer puis à rembourser uniquement les acteurs qui s'identifient auprès de la fondation. Qui lit des documents plus anciens doit aussi en vérifier la date, car des guides écrits pour la chaîne retirée circulent encore, et leurs paramètres de staking et de récompense ne s'appliquent plus.
Comment vérifier POKT Network
Commencez par la documentation officielle et comparez la présentation générale du projet aux pages sur les sessions, claims, proofs, la tokenomics et la terminologie. Vérifiez le domaine, le contexte de la page et si le texte décrit un mécanisme actuel, un paramètre configurable ou un changement historique. Cela permet de distinguer une source primaire d'une reprise non vérifiée ou d'un résumé ancien.
Confirmez que les matériaux officiels actuels utilisent toujours POKT pour le rôle de protocole concerné. Ne déduisez pas une adresse de contrat d'une étiquette, d'un résultat de recherche ou d'une publication sociale. Si une source officielle identifie un enregistrement propre à un réseau, comparez-le en lecture seule avec l'explorateur de blocs approprié, y compris le contexte du réseau et toute relation d'implémentation divulguée.
Pour une affirmation technique, reliez chaque phrase à la source de soutien la plus étroite. La présentation du projet soutient la description des rôles, tandis que les matériaux sur sessions et proofs soutiennent l'explication du cycle. Une différence de version, de réseau, de date de page ou de terminologie est une raison de s'arrêter et d'obtenir une clarification actuelle, plutôt que de combler l'écart par une hypothèse.
Une distinction mérite d'être emportée dans chaque résultat de recherche que vous trouverez. La documentation officielle tient une page sur les lieux où POKT est coté, datée d'avril 2026 sur la page elle-même, qui cite Upbit et Bithumb parmi les plateformes centralisées, et elle comporte une section distincte expliquant pourquoi les plateformes suspendent parfois les dépôts et les retraits : lors de mises à niveau majeures du protocole, une plateforme arrête les transferts le temps de mettre à jour ses propres nœuds, de vérifier la compatibilité des portefeuilles et de rapprocher ses règlements ; la documentation précise qu'une telle pause est le signe que la plateforme agit avec prudence, et non le signe que quelque chose a mal tourné. Une suspension des dépôts et retraits n'est donc pas un retrait de cotation. Devant un avis, lisez la formulation sur la page d'annonces de la plateforme elle-même, vérifiez si une reprise est annoncée, et confirmez les paramètres actuels du protocole en interrogeant la chaîne plutôt qu'en vous fiant à un résumé.
Conclusion
POKT Network se comprend le mieux comme un protocole documenté de livraison décentralisée de données. Son vocabulaire sépare le relay comme événement de données de la session qui apporte le contexte d'attribution, du claim qui représente le travail et du proof utilisé lors de la vérification. Cette séparation explique la conception, mais ne garantit pas un service actif.
POKT est le ticker documenté du jeton natif du projet et joue un rôle systémique dans la comptabilisation du protocole. Les paramètres actuels, le périmètre des services, l'état logiciel et les enregistrements propres au réseau peuvent changer. Toute affirmation allant au-delà de cet aperçu architectural doit être vérifiée de nouveau avec la source officielle actuelle exacte et l'enregistrement technique correspondant en lecture seule.
Pages de marché associées
Pages Bitbase pour les jetons cités dans cet article :
- POKT : Voir le prix
Articles associés
Autres articles Bitbase sur ce sujet :
- OriginTrail, un graphe de connaissances décentralisé
- Comment évaluer les projets DePIN et leurs métriques : un cadre demande réelle contre émission
Avertissement : Cet article est un contenu pédagogique de Bitbase Academy, fourni à titre d'information uniquement. Il explique ce que fait un projet et quel rôle son jeton joue dans ce système ; il ne constitue pas un conseil en investissement, en trading, en fiscalité ou en finance, et il ne vaut ni recommandation ni approbation d'un projet ou d'un jeton. Bitbase n'a pas effectué de diligence raisonnable sur le projet décrit ici, et le mentionner ne signifie pas que Bitbase référence ou prend en charge cet actif. Les cryptoactifs comportent un risque important, notamment la volatilité des prix, une liquidité faible, la défaillance des contrats intelligents, l'incertitude réglementaire et la perte possible de toute leur valeur. Rédigé en août 2026 ; le statut d'un projet, sa tokenomics, son équipe et ses contrats peuvent changer à tout moment. Vérifiez tout par vous-même via les canaux officiels, l'adresse du contrat et un explorateur de blocs, et méfiez-vous des sites imitant le projet et des liens d'hameçonnage.
Sources
[1] Pocket Network Documentation (official) docs.pocket.network
[2] About Pocket Network (official documentation) docs.pocket.network
[3] Sessions, Claims & Proofs (official documentation) docs.pocket.network
[4] POKT Tokenomics (official documentation) docs.pocket.network
[5] Token overview (official documentation) docs.pocket.network
[6] Glossary (official documentation) docs.pocket.network
[7] Shannon Upgrade FAQ (official) pocket.network
[8] Welcome, Shannon: the new era of permissionless access is here (official) pocket.network
[9] POKT on Exchanges (official documentation) docs.pocket.network
