Modèle de société solo

Ce que c'est

CORP-SOLO est la configuration la plus simple pour une société dCorps à propriétaire unique. Elle crée un profil public de société, les portefeuilles principaux pour recevoir et payer, et un rôle de propriétaire qui contrôle les approbations. Vous gardez le contrôle tandis que chacun peut vérifier la structure et l'activité sur la blockchain.

Code du modèle

Code du modèle : CORP-SOLO. Ce libellé garde le modèle cohérent entre les applications, les liens et les vues publiques.

Contrôle unique

Un identifiant d'entité avec un portefeuille propriétaire principal unique détenant l'autorité finale.

Modèle d'unités par défaut

La propriété est découpée en unités de base afin que les pourcentages soient simples et cohérents entre applications et explorateurs.

Types de portefeuilles standard

Les types de portefeuilles standard séparent les revenus, les dépenses et les réserves afin que les flux d'argent soient faciles à suivre.

Flux étiquetés

Les paiements portent des étiquettes qui expliquent pourquoi l'argent a bougé, afin que l'activité reste claire sans notes manuelles.

Meilleur cas d'usage

CORP-SOLO convient aux opérateurs solo qui veulent une configuration simple et transparente, opérationnelle immédiatement. Il convient aux freelances, petits studios et startups naissantes qui veulent des portefeuilles et des approbations clairs sans processus lourd. Les tâches courantes peuvent être déléguées tandis que le propriétaire garde le contrôle final.

Décideur unique

Un seul propriétaire prend les décisions finales, tandis que des aides peuvent préparer des tâches sans prendre le contrôle.

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.

Adapté aux débuts

Conçu pour les fondateurs solo, consultants et premiers opérateurs qui veulent de la structure sans surcoûts.

Chemin de migration

Une étape claire des tableurs vers une vue partagée sur la blockchain que les clients peuvent vérifier.

Pas adapté

Ce modèle n'est pas destiné aux équipes qui exigent des approbations partagées, des votes de conseil ou des contrôles investisseurs formels. Il est conçu pour un seul propriétaire avec une autorité à point unique, pas pour une gouvernance multi-signataire. Les groupes axés sur les dons doivent utiliser les modèles pour organisations à but non lucratif conçus pour la collecte et le décaissement.

Gouvernance multi-signataire

Non adapté lorsque plusieurs personnes doivent co-signer des décisions, voter des changements ou approuver des dépenses.

Contraintes investisseurs

Ne couvre pas les termes investisseurs complexes, les règles d'acquisition (vesting) ou les limites de transfert requises par les structures capital-risque.

Modèle associatif

Les organisations à but non lucratif exigent des parcours de dons et d'allocation. Utilisez les modèles NONPROFIT-* pour la collecte.

Propriété et unités

Gardez les pourcentages évidents en exprimant les parts en petites unités faciles à lire. Le nombre d'unités par défaut garde les calculs simples, comme diviser 100 pour cent en petites parts. Si vous souhaitez plus de précision plus tard, vous pouvez ajouter des unités sans changer la part de chacun.

Unités de base par défaut

Commence avec 10 000 unités de base, donc 1 unité équivaut à 0,01 % de propriété et reste facile à lire.

Une unité, un vote

Le vote suit la propriété des unités par défaut, une unité égalant un vote 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 propriétaire.

Autorité et gouvernance

Liez les rôles sur la blockchain afin que chacun puisse voir qui est autorisé à agir. Les approbations et changements de rôles laissent une trace visible, ce qui rend les décisions plus faciles à expliquer ensuite. Si les clés changent, l'autorité actuelle reste claire car l'historique des rôles demeure public.

Rôles liés au propriétaire

Les rôles admin, conseil et trésorier sont liés par défaut au portefeuille du propriétaire dans CORP-SOLO.

Signatures d'autorité

Le portefeuille d'autorité signe les approbations et les actions de gouvernance, créant une responsabilité claire des décisions.

Rotation des clés

Les clés peuvent être changées via une action de gouvernance afin que les modifications d'accès soient publiques et traçables.

Actions protégées

Les actions sensibles peuvent exiger une approbation explicite, même dans une configuration à propriétaire unique, pour un contrôle plus sûr.

Portefeuilles de rôles d'employés

Déléguez des tâches sans perdre le contrôle total en utilisant des portefeuilles de rôles. Les membres de l'équipe peuvent préparer des factures, étiqueter des paiements ou préparer des décaissements tandis que le propriétaire approuve l'étape finale. Le travail avance, la responsabilité reste claire.

Types de rôles

Les portefeuilles de rôles peuvent être définis pour les opérateurs, comptables, approbateurs ou exécutants de paiements selon l'équipe.

Permissions limitées

Les permissions peuvent autoriser la facturation, l'étiquetage ou la préparation de décaissements tout en bloquant l'exécution jusqu'à l'approbation du propriétaire.

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 vous liez explicitement les deux.

Limites de délégation et d'approbation

Définissez des limites d'approbation pour préciser ce qui passe automatiquement et ce qui doit être revu. Les petits paiements courants peuvent être validés rapidement, tandis que les transferts importants attendent la signature du propriétaire. Les limites peuvent varier par portefeuille ou catégorie afin que les règles correspondent au fonctionnement de l'entreprise.

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 étape d'approbation avant qu'un paiement ne parte.

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 des garde-fous différents.

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é approuvent les actions, 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-SOLO 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 pour voir 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.

category_code counterparty_type reference_id reference_type

Contexte opérationnel

Les étiquettes optionnelles ventilent l'activité par équipe, produit, projet ou canal pour un suivi plus clair.

business_unit_tag department_tag cost_center_tag project_tag product_tag item_id channel_tag region_tag counterparty_tag

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).

equity_class_tag vesting_schedule_tag option_pool_tag

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 le portefeuille du propriétaire, un nom d'entité et les premiers rattachements de portefeuilles. 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 vous et pour toute personne qui vérifie.

Enregistrer et lier

Enregistrer l'entité et lier les rôles d'autorité afin que le propriétaire soit clairement associé aux approbations.

Définir portefeuilles et limites

Connecter les portefeuilles standard et définir des limites d'approbation pour que les dépenses suivent vos règles.

Déléguer des rôles

Ajouter des portefeuilles de rôles employés et des portefeuilles bénéficiaires lorsque vous souhaitez que d'autres préparent le travail.

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 et les changements de rôles. Si un document doit être prouvé plus tard, vous pouvez ancrer une référence sécurisée avec un horodatage. Ensemble, ces sources créent un historique durable difficile à réécrire.

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, votes 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.

brouillon actif suspendu dissous

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 l'entreprise grandit, vous pouvez passer à un modèle plus riche sans perdre la continuité. Les évolutions ajoutent des rôles, des approbations et des niveaux de gouvernance tout en conservant le même identifiant d'entité et l'historique. Vous commencez simplement et vous étendez lorsque la complexité apparaît.

Privé standard

Le code CORP-PRIVATE-STD ajoute un contrôle multi-signataire et un deuxième niveau d'approbation pour les équipes en croissance.

Modèle Venture

Le code CORP-VENTURE ajoute des termes investisseurs, des parcours de conseil et de l'étiquetage lié à l'actionnariat pour les structures financées.

Privé complexe

Le code CORP-COMPLEX-PRIVATE prend en charge des structures complexes, des comités et des sujets protégés pour une gouvernance avancée.

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 manifeste

Nicolas 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.

En anglais uniquement

Testnet

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.

Demander l’accès à la testnet

Accès contrôlé. Approbation requise.

Testnet En anglais uniquement