Ce que c'est
CORP-PRIVATE-STD est la configuration standard de société privée dCorps pour des équipes multi-propriétaires. Elle crée un profil public de société, l'ensemble des portefeuilles principaux et des liaisons de rôles qui séparent l'autorité admin, trésorerie et approbation. Plusieurs propriétaires co-signent les actions protégées afin qu'aucun portefeuille ne contrôle tout, tandis que la vue publique reste claire et facile à vérifier sur la blockchain.
Code du modèle
Code du modèle : CORP-PRIVATE-STD. Ce libellé garde le modèle cohérent entre les applications, les liens et les vues publiques.
Contrôle partagé
Un identifiant d'entité avec plusieurs portefeuilles propriétaires partageant l'autorité. Les actions protégées exigent des co-signatures.
Unités partagées
Les unités de propriété sont réparties entre les détenteurs et les transferts suivent des règles d'approbation par conception.
Types de portefeuilles standard
Les types de portefeuilles standard séparent revenus, dépenses et réserves, tandis que les portefeuilles d'autorité signent les approbations de trésorerie.
Flux étiquetés
Les paiements portent des étiquettes qui expliquent pourquoi l'argent a bougé et quel circuit d'approbation a été utilisé.
Position du modèle
CORP-PRIVATE-STD se situe entre le modèle solo et les modèles de gouvernance avancée. Il ajoute des approbations partagées et la séparation des rôles tout en gardant une structure simple. Passez au modèle solo lorsque le contrôle se concentre sur un seul propriétaire, ou évoluez vers venture ou complex private lorsque la gouvernance s'élargit.
Modèle solo
Revenez à CORP-SOLO lorsqu'un propriétaire contrôle les approbations et qu'une co-signature n'est plus nécessaire.
Modèle Venture
Passez à CORP-VENTURE pour une gouvernance de conseil, des tours investisseurs et des unités multi-classes.
Privé complexe
Passez à CORP-COMPLEX-PRIVATE pour des comités, sujets protégés ou holdings multi-entités.
Meilleur cas d'usage
CORP-PRIVATE-STD convient aux sociétés privées avec deux propriétaires ou plus et des dépenses opérationnelles récurrentes. Il convient aux équipes fondatrices, studios et entreprises familiales qui veulent des rôles clairs, des approbations de routine et des paiements en stablecoins. Le travail quotidien peut avancer vite tandis que les actions à fort impact exigent une co-signature.
Approbations partagées
Les actions protégées exigent au moins deux signataires afin que les décisions soient partagées et responsables.
Natif en stablecoins
Les flux entrants et sortants passent par des stablecoins plutôt que par des rails bancaires, ce qui maintient le flux sur la blockchain.
Séparation des rôles
Les rôles admin et trésorerie sont séparés afin qu'un portefeuille ne puisse pas créer et approuver la même action.
Équipes opérationnelles
Conçu pour des équipes avec dépenses récurrentes et approbations qui veulent des rôles clairs sans lourde structure.
Pas adapté
Ce modèle ne convient pas aux configurations à propriétaire unique sans approbations, ni à la gouvernance de conseil de type venture, ni aux structures à unités multi-classes. Il suppose un contrôle partagé avec des approbations de routine, donc une gouvernance très complexe doit utiliser des modèles avancés. Les organisations axées sur les dons s'alignent avec les modèles NONPROFIT-* conçus pour la collecte et le décaissement.
Simplicité solo
CORP-SOLO convient lorsque un seul portefeuille contrôle tout et que les approbations ne font pas partie de la configuration.
Structure venture
Les tours de financement avec conseil ou les structures à unités multi-classes s'alignent avec CORP-VENTURE.
Modèle associatif
Les organisations à but non lucratif suivent des parcours de dons et d'allocation et s'alignent avec les modèles NONPROFIT-* conçus pour la collecte.
Propriété et unités
Gardez les pourcentages clairs entre plusieurs détenteurs en exprimant les parts en unités de base. Les transferts et émissions d'unités passent par des actions d'approbation, ce qui maintient les changements de propriété contrôlés et visibles. Des unités supplémentaires peuvent être ajoutées plus tard pour la précision sans modifier les pourcentages existants.
Unités de base par défaut
Commence avec 10 000 unités de base afin que les parts restent lisibles entre plusieurs détenteurs.
Une unité, un vote
Le vote suit la propriété des unités par défaut, donc les votes de chaque détenteur reflètent sa part sauf modification par la gouvernance.
Extension de la précision
Ajoutez des unités de base plus tard pour augmenter la précision tout en conservant le pourcentage de chaque détenteur.
Autorité et gouvernance
Séparez les rôles admin, trésorier et approbateur afin qu'aucun portefeuille ne puisse créer et approuver la même action. Les actions protégées exigent des co-signatures et laissent une trace visible pour chaque décision. Les changements de rôles et la rotation des clés sont journalisés sur la blockchain afin que l'autorité actuelle reste claire.
Séparation des rôles
Les rôles admin, trésorier et approbateur sont répartis entre plusieurs portefeuilles afin de séparer contrôle et exécution.
Couche d'approbation
Les rôles d'approbation co-signent les actions de trésorerie et de politique pour une responsabilité partagée.
Rotation des clés
Les clés peuvent être changées via des actions de gouvernance afin que les changements d'accès restent publics et traçables.
Actions protégées
Les actions sensibles exigent plusieurs approbations avant qu'un transfert ne soit effectué ou qu'une politique ne change.
Portefeuilles de rôles d'employés
Déléguez le travail tout en gardant les approbations chez les approbateurs désignés grâce aux portefeuilles de rôles. Les opérateurs peuvent préparer des factures, étiqueter des paiements ou préparer des décaissements, et les approbateurs signent avant que les fonds ne bougent. Le travail avance tandis que la responsabilité reste partagée.
Types de rôles
Les portefeuilles de rôles peuvent être définis pour les opérateurs, comptables, approbateurs ou exécutants de paiements au sein de l'équipe.
Permissions limitées
Les permissions peuvent autoriser la facturation, l'étiquetage ou la préparation des décaissements tout en bloquant l'exécution tant que les approbations requises ne sont pas signées.
Séparation des bénéficiaires
Les portefeuilles bénéficiaires reçoivent les fonds, tandis que les portefeuilles de rôles gèrent l'autorité sauf si la société lie explicitement les deux.
Limites de délégation et d'approbation
Définissez des limites d'approbation pour préciser ce qui peut s'exécuter automatiquement et ce qui doit être co-signé. Des seuils de double contrôle maintiennent les transferts importants en attente de signatures d'approbateurs, tandis que les paiements de routine passent rapidement. Les limites peuvent varier par portefeuille ou catégorie afin que différentes équipes suivent leurs garde-fous.
Périmètre des rôles
Chaque rôle inclut un périmètre clair qui liste les actions qu'il peut préparer, approuver ou exécuter.
Seuils d'approbation
Les seuils définissent le montant ou le niveau de risque qui déclenche une approbation en co-signature.
Limites par portefeuille et catégorie
Les limites peuvent être ajustées par type de portefeuille ou catégorie de dépense afin que les activités suivent leurs garde-fous.
Structure des portefeuilles
Séparez l'argent par usage afin que l'activité soit facile à suivre. Un portefeuille reçoit les paiements clients, un autre gère les dépenses opérationnelles, et un portefeuille de réserve peut conserver des épargnes. Les portefeuilles d'autorité signent les approbations, tandis que les portefeuilles de paiement reçoivent et envoient les fonds. Cela sépare le contrôle de la trésorerie afin que l'activité reste facile à vérifier.
Portefeuille marchand
Le type de portefeuille MERCHANT est le portefeuille de paiement public où atterrissent les revenus clients.
Trésorerie opérationnelle
Le type de portefeuille OPERATING_TREASURY gère les dépenses courantes et les paiements sortants vers fournisseurs et prestataires.
Portefeuille de réserve
Le type de portefeuille RESERVES conserve des marges de sécurité ou des fonds de long terme si vous choisissez d'en mettre de côté.
Séparation de l'autorité
Les portefeuilles d'autorité peuvent inclure plusieurs signataires propriétaires pour les approbations, tandis que les portefeuilles de paiement reçoivent et envoient les fonds afin que le contrôle reste séparé de la trésorerie.
Actifs opérationnels
Les totaux de reporting sont affichés en USDC afin que les valeurs restent stables et faciles à comparer. Les portefeuilles de trésorerie peuvent aussi détenir du DCHUB pour le gas ou une exposition de long terme si vous le souhaitez. Ces avoirs sont étiquetés afin que les synthèses restent claires et ne se mélangent pas avec la trésorerie opérationnelle.
Unité de reporting
Tout le reporting en v0.1 utilise des totaux en USDC afin que les vues restent stables dans le temps et entre outils.
Avoirs de trésorerie
Les portefeuilles de trésorerie et de réserve peuvent détenir du DCHUB en plus des stablecoins lorsque vous souhaitez une exposition au réseau.
Actifs étiquetés
Les soldes DCHUB doivent porter asset_tag et BAL_DCHUB afin que les explorateurs les séparent de la trésorerie opérationnelle.
Paiements de gas
Les frais de transaction sont payés en DCHUB par le portefeuille signataire à chaque transaction soumise.
Commerce et modes de paiement
CORP-PRIVATE-STD prend en charge les paiements directs et les factures, afin que les clients puissent payer comme cela leur convient. Les plans récurrents couvrent la facturation par abonnement avec des paiements planifiés sur la blockchain. Chaque facture porte un statut afin que l'équipe voie d'un coup d'oeil ce qui est ouvert, payé ou annulé.
Paiements directs
Les clients peuvent payer directement vers le portefeuille marchand lorsque le montant est connu à l'avance.
Demandes de facture
Les factures sont des demandes de paiement sur la blockchain liées à l'entité, avec montant, échéance et référence payeur.
Plans récurrents
Les plans récurrents planifient une facturation répétée afin que les abonnements ou forfaits fonctionnent sans saisie manuelle.
Mises à jour de statut
Chaque facture met à jour son statut en passant de ouverte à payée ou annulée, afin que le suivi soit clair.
Articles du catalogue
Définissez ce que vous vendez une fois pour que les factures et paiements restent organisés à mesure que l'activité grandit. Chaque article a un nom, un prix et un identifiant réutilisable dans les factures et les étiquettes. Cela crée une vue cohérente des ventes sans ressaisir les détails à chaque fois.
Référence d'article
Créez un item_id avec un libellé clair et un prix afin que chaque produit ou service soit réutilisable.
Base de coût
Ajoutez une base de coût optionnelle afin de pouvoir estimer les marges plus tard sans estimation rétroactive.
Liaison aux factures
Utilisez item_id sur les factures et étiquettes afin de relier l'activité commerciale aux totaux et aux vues.
Flux de paie et de prestataires
Étiquetez la paie et les décaissements de prestataires afin que la rémunération reste visible sans se mélanger aux rôles d'autorité. Les portefeuilles bénéficiaires reçoivent les fonds, tandis que les rôles d'approbation contrôlent les sorties. Les applications peuvent planifier ou regrouper les décaissements pour s'aligner sur les cycles de paie.
Portefeuilles bénéficiaires
Les portefeuilles bénéficiaires reçoivent directement les salaires ou paiements de prestataires, séparés des rôles d'autorité.
Décaissements étiquetés
Les décaissements portent des étiquettes de paie ou de prestataire afin que la rémunération soit facile à identifier dans les synthèses.
Calendriers optionnels
Les applications ou SDKs peuvent planifier ou regrouper les décaissements lorsque vous voulez des paiements récurrents ou groupés.
Étiquettes et preuves
Les étiquettes sont des libellés simples ajoutés à chaque paiement afin que l'activité reste compréhensible dans le temps. Pour les transactions importantes, vous pouvez attacher une preuve en ancrant une référence sécurisée à une facture, un reçu ou un accord. Cela crée une trace claire sans publier de fichiers privés.
Requis de base
Ces étiquettes sont requises sur chaque flux afin que les vues restent cohérentes. Associez reference_type et reference_id.
Contexte opérationnel
Les étiquettes optionnelles ventilent l'activité par équipe, produit, projet ou canal pour un suivi plus clair.
Contexte d'actionnariat
Ces étiquettes ne s'appliquent que si des parcours liés à l'actionnariat sont ajoutés plus tard, comme des classes, des pools ou de l'acquisition (vesting).
Ancrages de preuves
Les ancrages relient les factures, reçus ou accords sans publier le document lui-même.
Seuil de matérialité
Définissez un seuil de matérialité pour que les éléments plus importants exigent une preuve, avec 1 000 USDC par défaut.
Répertoire des contreparties et confidentialité
Les clients ou fournisseurs récurrents peuvent être étiquetés avec des surnoms privés plutôt que leurs noms réels. La correspondance avec le monde réel reste hors chaîne sous votre contrôle, ce qui protège les données sensibles. Les vues publiques n'affichent que l'étiquette et le portefeuille, pas l'identité sous-jacente. Vous obtenez un historique cohérent de qui paie et qui est payé sans exposer les identités.
Identifiants pseudonymes
Utilisez counterparty_tag pour étiqueter des clients ou fournisseurs récurrents sans exposer leurs noms légaux sur la blockchain.
Correspondance hors chaîne
Conservez la correspondance des noms réels hors chaîne afin que seule votre équipe puisse la consulter.
Contreparties récurrentes
Suivez les contreparties récurrentes sur les factures et paiements sans publier de détails personnels ou commerciaux.
Flux opérationnel
Passez de la configuration à l'activité en suivant une séquence simple. La configuration démarre avec plusieurs portefeuilles propriétaires, un nom d'entité et des seuils d'approbation pour les actions protégées. Vous enregistrez l'entité, connectez les portefeuilles, encaissez les paiements et étiquetez ce qui se passe afin que les vues restent cohérentes. Chaque étape écrit dans l'historique sur la blockchain, ce qui garde les opérations claires pour l'équipe et pour toute personne qui vérifie.
Enregistrer et lier les propriétaires
Enregistrer l'entité et lier les portefeuilles propriétaires ainsi que les rôles admin, trésorier et approbateur.
Définir portefeuilles et seuils
Connecter les portefeuilles standard et définir des seuils d'approbation afin que les actions de trésorerie exigent des co-signatures au-dessus des limites.
Déléguer des rôles
Ajouter des portefeuilles de rôles employés et des portefeuilles bénéficiaires afin que les équipes puissent préparer le travail sans signer.
Encaisser les revenus
Émettre des factures ou accepter des paiements directs afin que les revenus atterrissent dans le portefeuille marchand.
Étiqueter et ancrer
Étiqueter les entrées et sorties et ancrer des preuves pour les éléments importants qui exigent une justification.
Revoir et clôturer
Revoir les vues en direct, puis clôturer une période si vous voulez un instantané fixe pour comparaison ultérieure.
Vues sur la blockchain en direct
Les explorateurs affichent des synthèses en direct à partir des transactions étiquetées sans attendre des exports manuels. Vous pouvez voir les soldes, l'activité récente et la couverture des étiquettes au fil de l'eau. Les autres peuvent vérifier les mêmes chiffres, ce qui maintient la visibilité publique alignée.
Soldes des portefeuilles
Les soldes des portefeuilles se mettent à jour à mesure que les transactions sont confirmées sur la blockchain, afin que les chiffres restent actuels.
Vues par période
Les vues par période résument l'activité sur un intervalle sans attendre une clôture manuelle.
Taux de couverture
Les taux de couverture montrent quels flux sont entièrement étiquetés et lesquels nécessitent encore du contexte.
Exports de données
Les exports sont optionnels pour l'analyse hors ligne ou les sauvegardes lorsque vous voulez des fichiers en dehors de la chaîne.
Registre, logs et preuves
Utilisez le registre et le journal de gouvernance pour vérifier l'identité, le statut, les portefeuilles officiels, les approbations, les co-signatures et les changements de rôles. Chaque entrée d'approbation indique qui a signé et quand, ce qui crée une trace décisionnelle claire. Les ancrages horodatent les documents lorsque des preuves sont requises, afin que l'historique reste durable et vérifiable.
Entrée du registre
Le registre liste l'identité, le statut et les liaisons de portefeuilles officiels afin que chacun puisse vérifier la configuration actuelle.
Journal de gouvernance
Le journal de gouvernance montre les approbations, co-signatures et changements de rôles dans l'ordre temporel pour une responsabilité claire.
Preuve ancrée
Les ancrages horodatent les reçus et contrats afin que leur existence puisse être vérifiée plus tard sans publier les fichiers.
Cycle de vie et statut
Les signaux indiquent si une société est active, en pause ou clôturée, afin que les paiements passent ou non. Les applications peuvent afficher automatiquement le statut comme repère de sécurité. Cela réduit la confusion et évite que des fonds soient envoyés à des entités inactives.
États du statut
Les libellés de statut indiquent si l'entité est active et sûre pour les paiements, avec un code couleur cohérent.
Endpoints de paiement
Les endpoints de paiement se déduisent de l'identifiant d'entité et du type de portefeuille, afin que les utilisateurs ne copient pas d'adresses brutes.
Alertes d'interface
Les interfaces peuvent avertir lorsqu'une entité est suspendue ou dissoute afin que les payeurs évitent d'envoyer des fonds.
Chemins d'évolution
À mesure que la société grandit ou se simplifie, elle peut passer à un autre modèle sans perdre la continuité. Les évolutions ajoutent des parcours de conseil, des termes investisseurs ou une gouvernance complexe, tandis que la simplification peut revenir à une configuration à propriétaire unique. Le même historique d'entité reste intact à travers les transitions.
Modèle Venture
Le code CORP-VENTURE ajoute des approbations de conseil, des termes investisseurs et de l'étiquetage lié à l'actionnariat pour les structures financées.
Privé complexe
Le code CORP-COMPLEX-PRIVATE prend en charge des comités, sujets protégés et holdings multi-entités pour une gouvernance avancée.
Modèle solo
Le code CORP-SOLO convient lorsque la propriété se concentre sur un seul décideur et que les approbations sont minimisées.
Où opérer et vérifier
L'application officielle gère les actions quotidiennes comme l'enregistrement, la facturation et les approbations. Les outils publics, registre, explorateur et indexer officiel, permettent à chacun de vérifier l'identité, le statut et les liaisons de portefeuilles. Cela garde ce que vous faites et ce que les autres voient aligné sur le réseau.
Application officielle
L'application officielle est l'endroit où vous enregistrez, émettez des factures, étiquetez les paiements et approuvez les actions.
Le registre
Le registre confirme l'identité, le statut et les portefeuilles officiels afin que les contreparties sachent à qui elles paient.
L'explorateur
L'explorateur, alimenté par l'indexer officiel, affiche les transactions, les soldes et l'historique public dans une seule vue.
Indexer officiel
Service de données de référence qui alimente les synthèses de l'explorateur et les vues de reporting pour une visibilité publique cohérente.
dApps et SDKs
Les dApps et SDKs tiers permettent de construire des flux personnalisés ou d'intégrer les paiements dans vos produits.
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.