Objectif et couverture
La validation ici signifie des contrôles d'intégration, pas des approbations. Elle définit comment les équipes confirment que les actions, étiquettes et vues dérivées restent cohérents entre SDKs, indexers et explorateurs sur le testnet. La couverture se concentre sur des sorties répétables, la parité entre outils, la détection précoce des écarts et des rapports de conformité avec hachages de preuve.
Alignement de schéma
Les payloads d'action suivent les types du bundle en cours pour une validation cohérente.
Couverture des étiquettes
Les flux portent les étiquettes requises afin que les vues classent l'activité sans interprétation manuelle.
Cohérence des vues
Les vues dérivées correspondent aux sorties d'indexer pour des totaux identiques.
Parité des outils
Les outils officiels et tiers s'alignent sur les mêmes entrées, sorties et logiques d'étiquetage.
Surfaces de conformité
Les contrôles de validation s'appliquent aux surfaces du noyau qui pilotent le comportement du Hub : transactions, événements, dérivation des vues et sortie de l'explorateur. Chaque surface a des schémas attendus et des conventions d'étiquetage pour aligner les sorties. La couverture s'étend à chaque cycle testnet, avec des ajouts progressifs.
Sortie transaction
Les actions signées émettent les événements et mises à jour attendus dans les paramètres actifs.
Flux d'événements
Les flux d'événements publient des payloads cohérents pour parsing et indexation.
Dérivation des vues
La logique d'indexer correspond aux calculs de référence pour soldes et ratios.
Affichage explorateur
Les vues explorateur reflètent les résultats de l'indexer avec étiquettes et métadonnées cohérents.
Signaux de validation
Des contrôles légers indiquent si les sorties correspondent au bundle en cours. Ils incluent comparaisons de fixtures, complétude des étiquettes et parité indexer afin de détecter les écarts tôt. Ils sont informatifs et guident l'intégration, pas des approbations ou certifications.
Fixtures de référence
Les fixtures comparent les sorties attendues aux réponses live du testnet pour détecter les dérives.
Contrôles de diff
Les diffs automatisés comparent les sorties d'indexer entre environnements.
Complétude des étiquettes
Les contrôles de couverture signalent les étiquettes manquantes avant partage des résultats.
Signaux d'erreur
Les erreurs sont journalisées avec des IDs d'action pour tracer vite les échecs.
Rapports de conformité
Publiez des rapports avec versions ciblées, résumé des résultats et hachages de preuve.
Flux de validation
Utilisez ce flux pour aligner votre intégration avec la surface testnet actuelle. Il garde l'installation cohérente entre équipes et souligne les écarts tôt. Répétez le flux après les resets ou mises à jour de bundle pour maintenir votre base alignée.
Revoir le bundle
Récupérez le dernier bundle et confirmez versions de schéma, endpoints et chain ID.
Exécuter des actions tests
Soumettez un petit ensemble d'actions test pour portefeuilles, rôles et étiquettes.
Vérifier la couverture des étiquettes
Vérifiez les étiquettes pour chaque action et corrigez les valeurs manquantes.
Comparer les vues
Comparez explorateur et indexer pour confirmer totaux et classifications.
Tracer et relancer
Documentez les écarts, ajustez l'intégration et relancez les contrôles.
Publier le rapport
Publiez un rapport de conformité avec versions ciblées et hachages de preuve.
Limites du testnet
Le travail de validation se fait sur le testnet et hérite de ses contraintes. Les resets, changements de paramètres et couverture partielle sont normaux pendant le développement actif. Traitez les résultats comme des signaux d'intégration et vérifiez à nouveau quand le bundle change.
Cycles de reset
Des resets peuvent survenir, gardez fixtures et configs portables.
Changements de paramètres
Les paramètres peuvent évoluer, alignez la validation sur le dernier bundle.
Couverture partielle
Certains modules peuvent rester incomplets pendant des itérations testnet.
Manifeste
"Mon objectif est simple : permettre à chacun, partout, de créer une entité capable d’opérer avec crédibilité, continuité et de véritables infrastructures financières, conçues pour fonctionner en stablecoins."
Lire le manifesteNicolas Turcotte
Fondateur et ingénieur principal
Contribuez maintenant
La testnet est destinée aux constructeurs, opérateurs et responsables qui veulent valider le Hub en public.
Ingénieurs de protocole
Travail sur les définitions du kernel, le périmètre des messages et les invariants.
Ingénieurs d’indexation et de données
Définition des schémas d’événements et des entrées reproductibles pour les vues.
Opérateurs précoces
Test du séquenceur, de la publication des lots et du périmètre opérationnel sous règles de testnet.
Investisseurs alignés sur l’infrastructure
Suivi du périmètre, des risques et des progrès (sans promesse de rendement).
Conseil juridique
Révision des limites, du périmètre non custodial et de l’ordre de la pile documentaire.
Responsables de gouvernance
Définition de la séparation kernel/adaptateurs et de la posture de mise à jour.
Accès à la testnet
Demandez l’accès pour explorer le Hub, tester les interfaces de référence et valider le comportement du protocole de bout en bout sur la testnet de développement. Tout le monde peut en faire la demande ; l’accès opérateur local/dev est examiné plus strictement.
Accès contrôlé. Approbation requise.
Testnet En anglais uniquement
Accès à la testnet
Demandez l’accès pour explorer le Hub, tester les interfaces de référence et valider le protocole sur la testnet de développement. L’accès local/dev des opérateurs est examiné plus strictement.
Demander l’accès à la testnetBulletin En anglais uniquement
Restez informé
Mises à jour concises sur la préparation de la testnet, les lancements et les jalons de gouvernance.