Protocolo Cosanta
Una descripción técnica de la red de pagos peer-to-peer COSA: su libro de contabilidad UTXO, consenso de prueba de participación, masternodes deterministas, LLMQ, modelo de emisión y plataforma de Capa 2 planificada basada en Tenderdash.
Revisión 1.1 · Julio 2026- Tiempo objetivo de bloque
- 150 artículos de segunda clase
- Consenso
- PoS + LLMQ
- Oferta máxima
- ≈56.04M COSA
- Licencia Core
- MIT open source
Descripción general del protocolo
Cosanta es una red de pago descentralizada de código abierto cuyo activo nativo es COSA.
La red mantiene un libro de contabilidad público UTXO sin un emisor central ni un operador de liquidación. Los nodos independientes validan cada transacción y bloquean según las mismas reglas de consenso. Los participantes crean bloques, mientras que una capa de masternode garantizada proporciona servicios basados en quórum y gobernanza descentralizada.
Validación independiente
Cada nodo completo verifica las firmas de las transacciones, los resultados no gastados, la estructura del bloque, las pruebas de participación y los límites de recompensa antes de aceptar el estado.
Seguridad basada en apuestas
Después de la fase de arranque, la producción de bloques utiliza Prueba de participación en lugar de un cálculo de hash competitivo continuo.
Red de dos niveles
Los masternodes deterministas forman quórums para bloqueos de transacciones, bloqueos de bloques y gobernanza sin reemplazar la validación de nodo completo.
Cosanta Core es una bifurcación de Dash Core y conserva su modelo UTXO derivado de Bitcoin, su red de igual a igual y su arquitectura de nodo de servicio. Cosanta cambia la identidad de la red, los parámetros monetarios y el consenso activando PoS en el bloque 100.000.
Abra el repositorio Dash Core ascendenteArquitectura de red
Cosanta separa la gestión de claves local, la validación de consenso y las tareas de quórum de la capa de servicio. Esta separación mantiene la propiedad de la billetera distinta de la producción de bloques y la operación de masternode.
Nodo completo
Descarga la cadena, mantiene el conjunto UTXO y aplica de forma independiente todas las reglas de consenso. Un nodo completo no necesita ser un masternode.
apostador
Ejecuta una billetera sincronizada con salidas COSA elegibles y firma un bloque PoS válido cuando una salida encuentra un núcleo de participación.
nodo maestro
Bloquea la garantía requerida, se registra en la lista determinista y participa en quórums de servicio cuando es seleccionado.
Monedero o integración
Crea y firma transacciones, rastrea confirmaciones y consulta un nodo local confiable o un servicio seguro por separado.
Consenso de prueba de participación
PoS se ha aplicado en la red principal Cosanta desde el bloque 100.000. Hace que la propiedad de un UTXO elegible, en lugar del poder de hash bruto, sea el recurso utilizado para proponer un bloque.
El intervalo objetivo es de 150 segundos y la dificultad se ajusta continuamente. El descubrimiento de bloques sigue siendo probabilístico: tener una participación elegible aumenta la posibilidad esperada de producir un bloque, pero no crea un rendimiento fijo o garantizado.
-
01
Seleccionar productos elegibles
La billetera de apuestas considera salidas COSA no gastadas que cumplen con las reglas de confirmación y han existido durante al menos 86,400 segundos. La garantía de Masternode está protegida contra apuestas de forma predeterminada.
-
02
Pruebe el núcleo de la apuesta
El nodo prueba las salidas elegibles y las marcas de tiempo permitidas con respecto al objetivo PoS actual. Un valor más elegible aumenta la probabilidad de selección esperada.
-
03
Construir y firmar
Cuando un kernel cumple con el objetivo, la billetera construye la transacción de participación del bloque, incluye transacciones de mempool válidas y firma el bloque con la clave que controla la salida seleccionada.
-
04
Validar y propagar
Los pares verifican que la salida no se haya gastado y esté madura, que el kernel y las marcas de tiempo cumplan con el objetivo, que las firmas sean válidas y que la recompensa reclamada no exceda los límites de consenso.
P(bloquear) ∝ participación elegible ÷ dificultad de la red
Esta relación explica únicamente la selección esperada; la implementación evalúa núcleos de interés discretos y los resultados a corto plazo pueden diferir sustancialmente del promedio.
El staking requiere un nodo completamente sincronizado y acceso seguro a la clave de firma. Cifre el monedero, conserve copias de seguridad fuera de línea y desbloquéelo únicamente para staking cuando esta función sea compatible. El rendimiento del pool depende de las recompensas de staking obtenidas realmente y de la suerte del pool al encontrar bloques. Wrapped COSA representa una obligación del operador frente al usuario — el servicio recibe COSA nativo y entrega a cambio tokens BEP-20. Su precio de mercado y su negociabilidad se apoyan en la liquidez creada en PancakeSwap.
Masternodos y quórums
Una lista determinista de masternodes ancla un segundo nivel de red. La garantía demuestra un compromiso económico de larga duración; no otorga permiso para cambiar las reglas de consenso. Los nodos completos aún verifican las transacciones, los bloques y las firmas de quórum resultantes.
La garantía permanece bajo la clave del propietario, pero no debe gastarse mientras el masternode esté registrado y activo.
InstantSend
Bloquea las entradas de transacciones a través de una firma LLMQ para que los gastos conflictivos puedan rechazarse antes de que se acumule la profundidad del bloque normal.
ChainLocks
Firma el primer bloque válido observado en una altura, lo que dificulta sustancialmente las reorganizaciones profundas una vez que la red acepta el bloqueo.
Gobernancia
Los operadores activos de masternodes votan las propuestas; los pagos aprobados pueden liquidarse a través del mecanismo presupuestario de superbloque del protocolo.
| Servicio | Perfil de quórum | Rol de protocolo |
|---|---|---|
| ChainLocks | LLMQ_400_60 |
Firma de umbral para bloqueos de bloque |
| InstantSend | LLMQ_60_75 |
Quórum rotativo para bloqueos de transacciones deterministas |
| Platform | LLMQ_100_67 |
Perfil de quórum reservado para servicios de plataforma |
Plataforma Cosanta: Capa 2 planificada
La red de Capa 2 aún no procesa el estado del usuario y no forma parte del consenso activo Cosanta. El diseño a continuación describe la dirección de desarrollo prevista, no un producto actualmente en funcionamiento.
Cosanta planea construir su propia plataforma de Capa 2 como una bifurcación y adaptación de la pila de plataforma Dash de código abierto, utilizando Tenderdash como su motor de consenso BFT.
Tenderdash es una bifurcación Tendermint adaptada para quórumes dinámicos de masternode y firmas de umbral BLS. Es el componente de consenso de la plataforma; El almacenamiento de estado, el protocolo de datos y las interfaces del desarrollador forman capas separadas. En la versión Cosanta, estos componentes están destinados a integrarse con la cadena PoS de Capa 1 y la lista determinista de masternodos Cosanta.
Cosanta Core
Los pagos nativos COSA, UTXO, la emisión, la prueba de participación, los masternodes y la finalidad de la capa 1 permanecen en la cadena primaria.
Cosanta Platform
Una cadena estatal separada para una confirmación rápida, cambios de datos verificables y servicios de aplicaciones descentralizados.
BFT finalidad
Un bloque se confirma después del acuerdo de más de dos tercios del conjunto de validadores activos. Si no se puede alcanzar un quórum, la finalización debe detenerse para preservar la coherencia estatal.
LLMQ y BLS
Tenderdash reemplaza un conjunto de validadores estáticos con subconjuntos de masternodos rotativos. Una firma de umbral BLS representa la decisión de quórum como una firma compacta.
Ejecución en el mismo bloque
El diseño de destino hereda la ejecución del mismo bloque: el AppHash confirmado en un encabezado de bloque representa el estado después de que se hayan ejecutado las transiciones incluidas.
Contratos de datos, no EVM
La plataforma planificada apunta a identidades, documentos y datos gobernados por esquemas con transiciones de estado firmadas. No implica compatibilidad con EVM ni contratos Solidity arbitrarios.
Etapas de implementación
Seleccione una línea base Tenderdash/Plataforma compatible, reemplace las identidades de red e intégrela con Cosanta Core, PoS y el modelo de masternode.
consensus.MN_RRHeight = 1013576;
En el bloque 1.013.576 de la red principal se activa MN_RR: el protocolo comienza a reasignar al credit pool la parte de la recompensa de los masternodes destinada a Platform. Esto inicia la financiación del pool, pero no lanza ni activa Cosanta Platform.
Pruebe DKG, rotación del validador, detenciones por pérdida de quórum, estado determinista, DAPI y actualizaciones de protocolo en condiciones adversas.
Cosanta Platform se lanzará más adelante mediante una activación independiente, después de validar devnet y testnet y de preparar las especificaciones públicas, auditorías y software de operadores. El bloque 1.013.576 no es la altura de lanzamiento de Platform.
El perfil LLMQ_100_67 ya existe en los parámetros Cosanta Core, pero esto por sí solo no significa que la Capa 2 esté activa. Hasta que se realice una activación separada, el rendimiento, las tarifas, las características de la aplicación y la economía de la plataforma seguirán siendo objetivos de diseño.
Transacciones y el libro mayor UTXO
COSA se contabiliza como salidas de transacciones no gastadas. Una transacción consume resultados existentes y crea nuevos resultados cuyas condiciones de gasto están definidas por scripts y claves criptográficas.
Sin saldo de cuenta en consenso
El saldo de una billetera mostrado es la suma de los UTXO gastables controlados por sus claves. El cambio de un pago normalmente se devuelve como una salida recién creada.
Honorarios
La diferencia entre los insumos y los productos totales es la tarifa de transacción. Los nodos aplican políticas de retransmisión y mempool además de comprobaciones de consenso a nivel de bloque.
Propiedad clave
El protocolo reconoce firmas válidas, no identidades ni solicitudes de soporte. Perder una clave privada o una frase de recuperación generalmente significa perder el control de su COSA.
Confirmación y bloqueos
Una confirmación de bloque ordena la transacción en la cadena PoS. InstantSend y ChainLocks agregan protección firmada por quórum contra reorganizaciones y gastos conflictivos.
Emisión y distribución
COSA tiene una curva de emisión definida por protocolo con un suministro máximo aproximado de 56,04 millones de monedas.
El lanzamiento utilizó un arranque PoW de baja recompensa. PoS se activó en el bloque 100.000, los pagos del masternode comenzaron más tarde y el subsidio base aumenta en pasos programados antes de entrar en reducciones a la mitad a largo plazo. Las tarifas de transacción se agregan a la recompensa en bloque permitida y no crean oferta adicional por sí mismas.
Lanzado sin premine
La red principal de Cosanta se lanzó públicamente el 16 de julio de 2021 sin una reserva precreada de COSA nativo asignada antes del inicio de la cadena. Las monedas entraron en circulación mediante recompensas definidas por el protocolo para los bloques producidos por los participantes de la red.
- Preminado nativo COSA
- 0 COSA
- Lanzamiento público
- 2021-07-16
- Recompensa de bloque inicial
- 0.01 COSA
La declaración de no premineración se aplica a la moneda nativa COSA y al lanzamiento de Capa 1. La representación del contrato BEP-20 posterior en BNB Smart Chain tiene un historial de suministro y distribución separado.
| rango de bloques | Subvención básica | Fase de protocolo |
|---|---|---|
| 0–99,999 | 0.01 → 0.09 COSA | PoW arranque y protección de monopolio |
| 100,000–525,251 | 0.10 → 0.50 COSA | PoS activo; rampa gradual de subsidios |
| 525,252–999,999 | 0.50 → 45 COSA | PoS con asignación progresiva de masternode |
| 1,000,000–≈1,048,576 | 50 COSA | Subvención base pico y activación presupuestaria |
| ≈1,048,576–≈2,097,152 | 25 COSA | Primera reducción a la mitad programada |
| ≈2,097,152+ | 12.5 COSA, luego reducido a la mitad a intervalos programados | Emisiones finitas a largo plazo |
Después del pico inicial del presupuesto, el protocolo reserva una parte del subsidio para los pagos de gobernanza aprobados a través de supermanzanas.
La participación del masternode comienza en el 0,1 % y se reasigna progresivamente hacia el objetivo a largo plazo del 60 % definido en Core.
El máximo es un resultado del cronograma de emisiones, no una configuración de token que se puede acuñar libremente. El consenso rechaza recompensas por encima del subsidio permitido.
COSA envuelto en BNB Smart Chain
COSA envuelto es un token BEP-20 que conecta la red nativa Cosanta a un grupo de participación y al ecosistema BNB Smart Chain. Un usuario puede depositar COSA nativo en el grupo y recibir COSA envuelto según las reglas del servicio. El grupo agrega depósitos y utiliza monedas nativas para apostar en la red Cosanta, mientras que el token permanece disponible en la billetera compatible del usuario.
El COSA nativo y el COSA envuelto se registran en libros de contabilidad separados: el primero en la cadena de bloques Cosanta UTXO, el segundo mediante un contrato BEP-20 en BNB Smart Chain. El token envuelto no crea una emisión adicional de moneda nativa en el nivel del protocolo Cosanta.
Cómo obtener COSA envuelto
Obtener wrapped COSA mediante @piratecash_bot
El cambio se realiza mediante @piratecash_bot — deposite COSA nativo y solicite el retiro de wrapped COSA a su dirección de BNB Smart Chain (BEP-20).
Abrir @piratecash_bot ↗Comprar en PancakeSwap
El COSA envuelto también se puede adquirir directamente desde un fondo de liquidez disponible con una billetera de autocustodia compatible con BNB Smart Chain.
Abrir PancakeSwap ↗0x5f980533b994c93631a639deda7892fc49995839
BscScan ↗
Suministro fijo: 64.000.000 COSA · 8 decimales · el suministro completo se acuñó cuando se implementó el contrato
Wrapped COSA y la operación del pool de staking están fuera del consenso de la red principal de Cosanta. El contrato no acuña tokens automáticamente al depositar ni implementa un puente trustless nativo: la conversión entre redes la realiza la pasarela del proyecto a partir del suministro existente. La pasarela disponible mediante @piratecash_bot garantiza el cambio native COSA ↔ wrapped COSA en ambos sentidos. Antes de depositar o intercambiar, verifique la dirección del contrato, las reglas de distribución y canje, las comisiones y las condiciones de custodia de las monedas nativas. El precio en DEX, el rendimiento y la liquidez no están garantizados por el protocolo Cosanta.
Pasarela de cambio bidireccional @piratecash_bot ↗Límites de seguridad y confianza
La seguridad tiene capas: las firmas protegen la propiedad, PoS ordena transiciones de estado válidas, los nodos completos imponen el consenso y las firmas LLMQ agregan protección rápida contra conflictos de transacciones y reorganizaciones de cadenas.
Transacciones conflictivas
Los nodos rechazan gastos de salidas ya consumidas, mientras que InstantSend puede bloquear entradas antes de que se alcance la profundidad de confirmación normal.
InstantSend · UTXOReorganizaciones de cadena
ChainLocks vincula el acuerdo de quórum a un bloque a una altura determinada y reduce el alcance práctico para reorganizar el historial aceptado.
ChainLocks · LLMQApuesta o recompensa no válida
Cada nodo verifica la elegibilidad de participación, el objetivo del kernel, la firma del bloque, la validez de la transacción y la recompensa máxima de forma independiente.
PoS · validationCompromiso de billetera
El consenso no puede restaurar las claves robadas. El cifrado, las copias de seguridad de las frases de recuperación, el refuerzo del sistema y la separación de las claves del operador siguen siendo responsabilidad del usuario.
signatures · backupsEste documento describe el protocolo; no es una auditoría, promesa de inversión o garantía de funcionamiento ininterrumpido. El código de consenso ejecutable Cosanta Core tiene autoridad si esta descripción general y una versión de software activa difieren.
Referencia de integración
Las integraciones de producción deben ejecutar un nodo Cosanta Core compatible, validar la red informada y el bloque de génesis, esperar la confirmación o la política de bloqueo adecuada a su modelo de riesgo y probar las actualizaciones antes de la implementación.
- Símbolo nativo
- COSA
- Lugares decimales
- 8
- Puerto P2P de red principal
- 60606
- Prefijo de dirección pública
- C
- tiempo de génesis
- 2021-07-16 13:32 UTC
- Hash del bloque Génesis
00000216af2a362c1833a0a608408bcdc69d23b276e47d7510a776e3b0bb1fce