Niveaux du système
L’architecture décrit comment la chaîne Hub exécute les transactions et enregistre l’état canonique des entités. Le Hub fonctionne sur dCorps Chain, un rollup Arbitrum Orbit en mode Rollup qui se règle sur Ethereum. L'ensemble s’étend de l’exécution et du règlement du rollup jusqu’aux contrats du noyau, aux adaptateurs optionnels et aux interfaces en aval.
Exécution du rollup
Le rollup Arbitrum Orbit exécute les transactions. DCHUB alimente le gas, la gouvernance et les frais au niveau du protocole.
Modules noyau
Les modules centraux stockent l’identité, les rôles, les décisions, les portefeuilles et l’historique des événements.
Adaptateurs optionnels
Des adaptateurs optionnels ajoutent un contexte de juridiction, de secteur ou de conformité sans modifier l’état du noyau.
Interfaces et indexers
Les indexers et les applications lisent la chaîne. Ils affichent des vues qui ne font pas autorité.
Modules centraux du noyau
Chaque entité repose sur un ensemble minimal de modules centraux qui définissent le registre canonique. Ils restent minimaux pour que la gouvernance puisse évoluer sans changer le standard.
Registre des entités
Identité, type d’entité et statut de cycle de vie pour référencer et vérifier les entités.
Rôles et autorité
Les attributions de rôles et permissions définissent qui peut proposer, approuver ou dépenser.
Actions de gouvernance
Propositions, votes et résolutions enregistrés comme historique officiel des décisions.
Portefeuilles et événements
Portefeuilles officiels et événements d’entrées et sorties étiquetés pour suivre la trésorerie.
Ancrages de documents
Les hachages de documents ancrent les preuves pour permettre une vérification ultérieure.
Signaux de divulgation et de cycle de vie
L’architecture enregistre le mode de divulgation et le statut de cycle de vie dans le registre canonique pour que les interfaces affichent ce qui est public, ce qui est agrégé et si une entité est active.
Mode A · Tout public
Vérifiabilité maximale à partir des données brutes de la chaîne.
Mode B · Structure publique, reporting agrégé
Des agrégats et des preuves remplacent les lignes sensibles.
Mode C · Exécution privée, ancrages publics
Des zones privées ou des sous-chaînes ancrent des résumés au Hub.
brouillon
Créé, pas encore actif pour les contreparties.
actif
En activité et visible dans le registre.
suspendu
Mis en pause par la gouvernance ou des déclencheurs de politique.
dissous
Clos et plus actif.
Modules et adaptateurs optionnels
Ajoutez un contexte optionnel via des modules et des adaptateurs qui interprètent l’état du noyau sans le redéfinir. Ils peuvent être ajoutés ou retirés selon les besoins. Ils peuvent ajouter du contexte de juridiction, de secteur ou d’assurance.
Workflows de juridiction
Workflows optionnels pour aligner les entités sur les exigences de reconnaissance locales.
Cadres sectoriels
Couches de gouvernance sectorielles ou structures de reporting construites sur le noyau.
Attestations
Attestations ou audits externes qui référencent les registres noyau sans les réécrire.
Couches de reporting
Modèles de divulgation et sorties générées à partir d’événements standardisés.
Canonique vs dérivé
L’état sur la blockchain est ordonné dans le temps et infalsifiable. Les vues dérivées sont hors chaîne et ne font pas autorité. N’importe qui peut les reconstruire à partir de la chaîne.
Canonique (sur la blockchain)
État des modules, paramètres et historique des événements sécurisés par le consensus.
Dérivé (hors chaîne)
Vues d’indexer, tableaux de bord et exports recréés à partir des données canoniques.
Mécanismes d’enregistrement
Les événements sont enregistrés de manière déterministe, en stablecoins (USDC). Ils sont ordonnés dans le temps et peuvent inclure des ancrages de preuves. Aucun rail fiat ni garde n’est requis.
Enregistrement
Créer des entités et mettre à jour leur statut de cycle de vie dans une séquence vérifiable.
Gouvernance
Soumettre des propositions et enregistrer des approbations qui mettent à jour l’état canonique.
Événements de trésorerie
Enregistrer des entrées, sorties et transferts USDC étiquetés depuis les portefeuilles officiels.
Ancrages
Ancrer les documents et les preuves avec des hachages vérifiables ultérieurement.
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.