Services Investir Statistiques des masternodes Échanger COSA Explorateur de blocs FAQ Faire un don maintenant
Documentation technique Cosanta L1 · prévu L2

Protocole Cosanta

Un aperçu technique du réseau de paiement peer-to-peer COSA : son grand livre UTXO, son consensus Proof-of-Stake, ses masternodes déterministes, ses LLMQ, son modèle d'émission et sa plateforme de couche 2 basée sur Tenderdash.

Révision 1.1 · juillet 2026
Temps de bloc cible
150 secondes
Consensus
PoS + LLMQ
Offre maximale
≈56.04M COSA
Licence Core
MIT open source
01
Résumé

Aperçu du protocole

Cosanta est un réseau de paiement décentralisé open source dont l'actif natif est COSA.

Le réseau tient un grand livre public UTXO sans émetteur central ni opérateur de règlement. Des nœuds indépendants valident chaque transaction et bloquent selon les mêmes règles de consensus. Les Stakers créent des blocs, tandis qu'une couche de masternode garantie fournit des services basés sur le quorum et une gouvernance décentralisée.

Validation indépendante

Chaque nœud complet vérifie les signatures de transaction, les sorties non dépensées, la structure des blocs, les preuves de mise et les limites de récompense avant d'accepter l'état.

Sécurité basée sur les enjeux

Après la phase d'amorçage, la production de blocs utilise la preuve de participation au lieu d'un calcul de hachage compétitif continu.

Réseau à deux niveaux

Les masternodes déterministes forment des quorums pour les verrous de transactions, les verrous de blocs et la gouvernance sans remplacer la validation complète des nœuds.

Patrimoine protocolaire

Cosanta Core est un fork de Dash Core et conserve son modèle UTXO dérivé de Bitcoin, sa mise en réseau peer-to-peer et son architecture de nœud de service. Cosanta modifie l'identité du réseau, les paramètres monétaires et le consensus en activant PoS au bloc 100 000.

Ouvrez le référentiel Dash Core en amont
02
Modèle de système

Architecture réseau

Cosanta sépare la gestion des clés locales, la validation du consensus et les tâches de quorum de la couche de service. Cette séparation maintient la propriété du portefeuille distincte de la production de blocs et de l'exploitation du masternode.

Nœud complet

Télécharge la chaîne, gère l'ensemble UTXO et applique indépendamment toutes les règles de consensus. Un nœud complet n’a pas besoin d’être un masternode.

Jalonneur

Exécute un portefeuille synchronisé avec les sorties COSA éligibles et signe un bloc PoS valide lorsqu'une sortie trouve un noyau de mise.

Noeud maître

Verrouille les garanties requises, s'inscrit sur la liste déterministe et participe aux quorums de service une fois sélectionné.

Portefeuille ou intégration

Crée et signe des transactions, suit les confirmations et interroge un nœud local de confiance ou un service sécurisé séparément.

03
Proof of Stake

Consensus sur la preuve de participation

PoS est appliqué sur le réseau principal Cosanta depuis le bloc 100 000. Cela fait de la propriété d'un UTXO éligible, plutôt que de la puissance de hachage brute, la ressource utilisée pour proposer un bloc.

L'intervalle cible est de 150 secondes et la difficulté est ajustée en continu. La découverte de blocs reste probabiliste : détenir une participation éligible augmente les chances attendues de produire un bloc mais ne crée pas de rendement fixe ou garanti.

  1. 01

    Sélectionnez les résultats éligibles

    Le portefeuille de jalonnement prend en compte les sorties COSA non dépensées qui répondent aux règles de confirmation et existent depuis au moins 86 400 secondes. La garantie du masternode est protégée contre le jalonnement par défaut.

  2. 02

    Tester le noyau de mise

    Le nœud teste les sorties éligibles et les horodatages autorisés par rapport à la cible PoS actuelle. Une valeur plus éligible augmente la probabilité de sélection attendue.

  3. 03

    Construire et signer

    Lorsqu'un noyau atteint l'objectif, le portefeuille construit la transaction de mise en bloc, inclut les transactions mempool valides et signe le bloc avec la clé contrôlant la sortie sélectionnée.

  4. 04

    Valider et propager

    Les pairs vérifient que la sortie n'est pas dépensée et est mature, que le noyau et les horodatages satisfont la cible, que les signatures sont valides et que la récompense réclamée ne dépasse pas les limites du consensus.

Probabilité conceptuelle P(bloc) ∝ participation éligible ÷ difficulté de réseau

Cette relation explique uniquement la sélection attendue ; la mise en œuvre évalue des noyaux d'enjeux discrets, et les résultats à court terme peuvent différer considérablement de la moyenne.

Activation PoS #100,000
Âge minimum de mise 86,400 s
Espacement des cibles 150 s
Difficulté à recibler Chaque bloc

Le staking nécessite un nœud entièrement synchronisé et un accès sécurisé à la clé de signature. Chiffrez le portefeuille, conservez des sauvegardes hors ligne et ne le déverrouillez que pour le staking lorsque cette fonction est prise en charge. Le rendement du pool dépend des récompenses de staking effectivement obtenues et de la chance du pool à trouver des blocs. Wrapped COSA représente une obligation de l’opérateur envers l’utilisateur — le service reçoit des COSA natifs et remet en échange des jetons BEP-20. Leur prix de marché et leur négociabilité reposent sur la liquidité créée sur PancakeSwap.

04
Service layer

Masternodes et quorums

Une liste déterministe de masternodes ancre un deuxième niveau de réseau. La garantie prouve un engagement économique à long terme ; il n'accorde pas la permission de modifier les règles de consensus. Les nœuds complets vérifient toujours les transactions, les blocs et les signatures de quorum résultants.

Garantie de masternode régulière 10,000 COSA
Garantie du masternode Evo 40,000 COSA

La garantie reste sous la clé du propriétaire mais ne doit pas être dépensée pendant que le masternode est enregistré et actif.

IS

InstantSend

Verrouille les entrées de transaction via une signature LLMQ afin que les dépenses conflictuelles puissent être rejetées avant que la profondeur de bloc ordinaire ne s'accumule.

CL

ChainLocks

Signe le premier bloc valide observé en hauteur, ce qui rend les réorganisations profondes beaucoup plus difficiles une fois que le réseau accepte le verrou.

DAO

Gouvernance

Les opérateurs de masternodes actifs votent sur les propositions ; les paiements approuvés peuvent être réglés via le mécanisme budgétaire de superbloc du protocole.

Profils de quorum du réseau principal dans Cosanta Core
Service Profil du quorum Rôle du protocole
ChainLocks LLMQ_400_60 Signature de seuil pour les verrous de bloc
InstantSend LLMQ_60_75 Quorum tournant pour les verrous de transaction déterministes
Platform LLMQ_100_67 Profil de quorum réservé aux services de plateforme
05
Planned Layer 2

Plateforme Cosanta : couche 2 prévue

Statut de l'architecture Prévu · non actif sur le réseau principal

Le réseau de couche 2 ne traite pas encore l’état de l’utilisateur et ne fait pas partie du consensus actif Cosanta. La conception ci-dessous décrit l'orientation de développement prévue, et non un produit actuellement opérationnel.

Cosanta prévoit de créer sa propre plate-forme de couche 2 en tant que fork et adaptation de la pile de plate-forme open source Dash, en utilisant Tenderdash comme moteur de consensus BFT.

Tenderdash est un fork Tendermint adapté aux quorums de masternodes dynamiques et aux signatures de seuil BLS. C'est la composante consensus de la plateforme ; le stockage d'état, le protocole de données et les interfaces de développement forment des couches distinctes. Dans la version Cosanta, ces composants sont destinés à s'intégrer à la chaîne Layer 1 PoS et à la liste de masternodes déterministes Cosanta.

BFT finalité

Un bloc est validé après accord de plus des deux tiers de l’ensemble des validateurs actifs. Si le quorum ne peut être atteint, la finalisation doit être interrompue pour préserver la cohérence de l'état.

LLMQ et BLS

Tenderdash remplace un ensemble de validateurs statiques par des sous-ensembles de masternodes rotatifs. Une signature de seuil BLS représente la décision de quorum sous la forme d'une signature compacte.

Exécution dans le même bloc

La conception cible hérite de l'exécution du même bloc : le AppHash validé dans un en-tête de bloc représente l'état après l'exécution des transitions incluses.

Contrats de données, pas EVM

La plate-forme prévue cible les identités, les documents et les données régies par des schémas avec des transitions d'état signées. Cela n'implique pas la compatibilité EVM ou les contrats Solidity arbitraires.

Étapes de mise en œuvre

01
Fourchette et adaptation

Sélectionnez une base de référence Tenderdash/Platform compatible, remplacez les identités réseau et intégrez-la avec Cosanta Core, PoS et le modèle de masternode.

02
Alimentation du credit pool consensus.MN_RRHeight = 1013576;

Au bloc 1 013 576 du réseau principal, MN_RR est activé : le protocole commence à réaffecter au credit pool la part de la récompense des masternodes destinée à Platform. Cette étape commence à alimenter le pool, mais ne lance ni n'active Cosanta Platform.

03
Devnet et testnet

Testez DKG, la rotation du validateur, les arrêts de perte de quorum, l'état déterministe, DAPI et les mises à niveau de protocole dans des conditions contradictoires.

04
Lancement distinct de Platform

Cosanta Platform sera lancée ultérieurement par une activation distincte, après validation du devnet et du testnet et préparation des spécifications publiques, audits et logiciels opérateurs. Le bloc 1 013 576 n'est pas la hauteur de lancement de Platform.

Le profil LLMQ_100_67 existe déjà dans les paramètres Cosanta Core, mais cela ne signifie pas à lui seul que la couche 2 est active. Jusqu'à une activation distincte, les performances, les frais, les fonctionnalités des applications et l'économie de la plate-forme restent des objectifs de conception.

06
UTXO ledger

Transactions et grand livre UTXO

COSA est comptabilisé comme sortie de transaction non dépensée. Une transaction consomme les sorties existantes et crée de nouvelles sorties dont les conditions de dépense sont définies par des scripts et des clés cryptographiques.

Pas de solde de compte consensuel

Le solde d'un portefeuille affiché est la somme des UTXO dépensables contrôlés par ses clés. La modification d'un paiement est normalement renvoyée sous la forme d'une sortie nouvellement créée.

Frais

La différence entre le total des entrées et des sorties correspond aux frais de transaction. Les nœuds appliquent des politiques de relais et de pool de mémoire en plus des vérifications de consensus au niveau des blocs.

Propriété des clés

Le protocole reconnaît les signatures valides, pas les identités ou les demandes d'assistance. Perdre une clé privée ou une phrase de récupération signifie généralement perdre le contrôle de son COSA.

Confirmation et verrouillages

Une confirmation de bloc ordonne la transaction dans la chaîne PoS. InstantSend et ChainLocks ajoutent une protection signée par quorum contre les dépenses et les réorganisations conflictuelles.

07
COSA economics

Émission et distribution

COSA a une courbe d'émission définie par un protocole avec une offre maximale approximative de 56,04 millions de pièces.

Le lancement a utilisé un bootstrap PoW à faible récompense. PoS a été activé au bloc 100 000, les paiements des masternodes ont commencé plus tard et la subvention de base augmente par étapes programmées avant d'être réduite de moitié à long terme. Les frais de transaction sont ajoutés à la récompense globale autorisée et ne créent pas en eux-mêmes une offre supplémentaire.

Lancement équitable

Lancé sans prémine

Le réseau principal Cosanta a été lancé publiquement le 16 juillet 2021 sans réserve pré-créée de COSA natif allouée avant le démarrage de la chaîne. Les pièces sont entrées en circulation grâce à des récompenses définies par le protocole pour les blocs produits par les participants au réseau.

Prémine native COSA
0 COSA
Lancement public
2021-07-16
Récompense de bloc initiale
0.01 COSA

La déclaration sans prémine s'applique à la monnaie native COSA et au lancement de la couche 1. La représentation contractuelle BEP-20 ajoutée ultérieurement sur BNB Smart Chain possède un historique d'offre et de distribution distinct.

Calendrier condensé des subventions du réseau principal
Plage de blocs Subvention de base Phase protocolaire
0–99,999 0.01 → 0.09 COSA PoW bootstrap et protection de monopole
100,000–525,251 0.10 → 0.50 COSA PoS actif ; rampe de subvention progressive
525,252–999,999 0.50 → 45 COSA PoS avec allocation progressive de masternodes
1,000,000–≈1,048,576 50 COSA Subvention de base de pointe et activation du budget
≈1,048,576–≈2,097,152 25 COSA Première réduction de moitié programmée
≈2,097,152+ 12,5 COSA, puis réduit de moitié à intervalles programmés Émission finie à long terme
Trésorerie

Après le début du budget, le protocole réserve une part de subvention aux paiements de gouvernance approuvés via des superblocs.

Récompenses de service

La part du masternode commence à 0,1 % et est progressivement réaffectée vers l'objectif à long terme de 60 % défini dans Core.

Plafond d'approvisionnement

Le maximum est un résultat du calendrier d'émission, et non un paramètre de jeton librement modifiable. Le consensus rejette les récompenses supérieures à la subvention autorisée.

Staking liquide

Wrapped COSA sur BNB Smart Chain

BNB Smart Chain BEP-20

Wrapped COSA est un jeton BEP-20 connectant le réseau natif Cosanta à un pool de jalonnement et à l'écosystème BNB Smart Chain. Un utilisateur peut déposer du COSA natif dans le pool et recevoir du COSA enveloppé conformément aux règles de service. Le pool regroupe les dépôts et utilise les pièces natives pour le jalonnement sur le réseau Cosanta, tandis que le jeton reste disponible dans le portefeuille compatible de l'utilisateur.

Le COSA natif et le COSA enveloppé sont enregistrés sur des registres distincts : le premier sur la blockchain Cosanta UTXO, le second par un contrat BEP-20 sur BNB Smart Chain. Le jeton encapsulé ne crée pas d’émission de pièces natives supplémentaire au niveau du protocole Cosanta.

01 Natif COSA Les pièces existent sur le réseau principal Cosanta UTXO.
02 Dépôt de piscine L'utilisateur envoie COSA à l'adresse du service de pool de jalonnement.
03 Jalonnement groupé Le pool regroupe les pièces natives et participe à la création de blocs.
04 Emballé COSA Le pool transfère les jetons BEP-20 de sa réserve existante à l'utilisateur.

Comment obtenir un COSA enveloppé

Itinéraire A · passerelle
Obtenir wrapped COSA via @piratecash_bot

L’échange s’effectue via @piratecash_bot — déposez des COSA natifs et demandez le retrait des wrapped COSA vers votre adresse BNB Smart Chain (BEP-20).

Ouvrir @piratecash_bot
Itinéraire B · échange
Acheter sur PancakeSwap

Le COSA emballé peut également être acquis directement à partir d'un pool de liquidités disponible avec un portefeuille d'auto-conservation compatible BNB Smart Chain.

Ouvrir PancakeSwap
Contrat COSA officiellement conclu · Chaîne intelligente BNB 0x5f980533b994c93631a639deda7892fc49995839 BscScan ↗ Approvisionnement fixe : 64 000 000 COSA · 8 décimales · l'approvisionnement complet a été émis lors du déploiement du contrat
Limites de confiance et risques

Wrapped COSA et le pool de staking se trouvent hors du consensus du réseau principal Cosanta. Le contrat ne crée pas automatiquement de jetons lors du dépôt et ne met pas en œuvre de pont trustless natif : la conversion entre réseaux est assurée par la passerelle du projet à partir de l'offre existante. La passerelle accessible via @piratecash_bot garantit l'échange native COSA ↔ wrapped COSA dans les deux sens. Avant un dépôt ou un échange, vérifiez l'adresse du contrat, les règles d'émission et de rachat, les frais et les conditions de conservation des monnaies natives. Le prix sur DEX, le rendement et la liquidité ne sont pas garantis par le protocole Cosanta.

Passerelle d'échange bidirectionnelle @piratecash_bot ↗
09
Trust model

Limites de sécurité et de confiance

La sécurité est multicouche : les signatures protègent la propriété, PoS ordonne des transitions d'état valides, les nœuds complets imposent le consensus et les signatures LLMQ ajoutent une protection rapide contre les conflits de transactions et les réorganisations de chaîne.

Opérations conflictuelles

Les nœuds rejettent les dépenses liées aux sorties déjà consommées, tandis que InstantSend peut verrouiller les entrées avant que la profondeur de confirmation normale ne soit atteinte.

InstantSend · UTXO

Réorganisations de la chaîne

ChainLocks lie l'accord de quorum à un bloc à une hauteur donnée et réduit la portée pratique de la réorganisation de l'historique accepté.

ChainLocks · LLMQ

Mise ou récompense invalide

Chaque nœud vérifie indépendamment l'éligibilité de la mise, la cible du noyau, la signature de bloc, la validité de la transaction et la récompense maximale.

PoS · validation

Compromis du portefeuille

Consensus ne peut pas restaurer les clés volées. Le cryptage, les sauvegardes des phrases de récupération, le renforcement du système et la séparation des clés des opérateurs restent la responsabilité de l'utilisateur.

signatures · backups

Ce document décrit le protocole ; il ne s'agit pas d'un audit, d'une promesse d'investissement ou d'une garantie de fonctionnement ininterrompu. Le code consensus exécutable Cosanta Core fait autorité si cette présentation et une version logicielle active diffèrent.

10
Reference

Référence d'intégration

Les intégrations de production doivent exécuter un nœud Cosanta Core compatible, valider le réseau signalé et le bloc Genesis, attendre la confirmation ou la politique de verrouillage appropriée à leur modèle de risque et tester les mises à niveau avant le déploiement.

Symbole natif
COSA
Décimales
8
Port P2P du réseau principal
60606
Préfixe de sonorisation publique
C
Temps de la Genèse
2021-07-16 13:32 UTC
Hachage du bloc Genesis
00000216af2a362c1833a0a608408bcdc69d23b276e47d7510a776e3b0bb1fce

Ce document Web est géré avec le site Web Cosanta. Les valeurs qui changent par consensus doivent être vérifiées par rapport à la version active Cosanta Core avant la mise en œuvre.

Révision 1.1 · juillet 2026