Protocolo PirateCash
Una descripción técnica de la red de pagos peer-to-peer PIRATE: 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
- 120 artículos de segunda clase
- Consenso
- PoS + LLMQ
- Oferta máxima
- ≈105M PIRATE
- Licencia Core
- MIT open source
Descripción general del protocolo
PirateCash es una red de pago descentralizada de código abierto cuyo activo nativo es PIRATE.
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.
PirateCash 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. PirateCash 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
PirateCash 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 PIRATE 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 PirateCash 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 120 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 PIRATE no gastadas que cumplen con las reglas de confirmación y han existido durante al menos 28,800 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 PIRATE representa una obligación del operador frente al usuario — el servicio recibe PIRATE 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.
Corsa
Los masternodes de PirateCash también impulsan Corsa, un mensajero descentralizado para comunicarse sin fronteras con cifrado end-to-end, manteniendo las conversaciones privadas sin depender de un único servicio central.
A partir de PirateCash Core v19, un masternode también debe ejecutar un nodo local corsa-chat/Corsa en el mismo servidor. La configuración automática del repositorio masternode configura PirateCash Core y corsa-chat juntos. El requisito se describe en PIP-0001.
| 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 PirateCash: Capa 2 planificada
La red de Capa 2 aún no procesa el estado del usuario y no forma parte del consenso activo PirateCash. El diseño a continuación describe la dirección de desarrollo prevista, no un producto actualmente en funcionamiento.
PirateCash 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 PirateCash, estos componentes están destinados a integrarse con la cadena PoS de Capa 1 y la lista determinista de masternodos PirateCash.
PirateCash Core
Los pagos nativos PIRATE, UTXO, la emisión, la prueba de participación, los masternodes y la finalidad de la capa 1 permanecen en la cadena primaria.
PirateCash 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 PirateCash Core, PoS y el modelo de masternode.
consensus.MN_RRHeight = 1910840;
En el bloque 1.910.840 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 PirateCash Platform.
Pruebe DKG, rotación del validador, detenciones por pérdida de quórum, estado determinista, DAPI y actualizaciones de protocolo en condiciones adversas.
PirateCash 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.910.840 no es la altura de lanzamiento de Platform.
El perfil LLMQ_100_67 ya existe en los parámetros PirateCash 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
PIRATE 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 PIRATE.
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
PIRATE tiene una curva de emisión definida por protocolo con un suministro máximo aproximado de 105 millones de monedas.
La red utilizó Proof of Work hasta el bloque 100.000; después, Proof of Stake pasó a ser el mecanismo de producción de bloques. El subsidio base comenzó en 50 PIRATE y se reduce a la mitad cada 1.048.576 alturas del bloque anterior. Los pagos deterministas a masternodes empiezan en el bloque 1.266.000, el presupuesto DAO en 1.899.666 y la financiación del credit pool mediante MN_RR en 1.910.840. Las comisiones se añaden a la recompensa permitida y no crean emisión adicional por sí mismas.
Lanzado sin premine
La red principal de PirateCash se lanzó públicamente el 3 de noviembre de 2018 sin una reserva precreada de PIRATE 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 PIRATE
- 0 PIRATE
- Lanzamiento público
- 2018-11-03
- Recompensa de bloque inicial
- 50 PIRATE
La declaración de no premineración se aplica a la moneda nativa PIRATE 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 | 50 PIRATE | Fase inicial PoW |
| 100,000–1,048,575 | 50 PIRATE | PoS con subsidio base completo |
| 1,048,576–1,265,999 | 25 PIRATE | PoS con asignación progresiva de masternode |
| 1,266,000–1,899,665 | 25 PIRATE | Pagos deterministas a masternodes activos |
| 1,899,666–2,097,151 | 25 PIRATE | Presupuesto DAO; MN_RR sigue en el bloque 1.910.840 |
| 2,097,152+ | 12,5 PIRATE y después reducción a la mitad cada 1.048.576 bloques | Emisión finita 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.
PIRATE envuelto en BNB Smart Chain
PIRATE envuelto es un token BEP-20 que conecta la red nativa PirateCash a un grupo de participación y al ecosistema BNB Smart Chain. Un usuario puede depositar PIRATE nativo en el grupo y recibir PIRATE envuelto según las reglas del servicio. El grupo agrega depósitos y utiliza monedas nativas para apostar en la red PirateCash, mientras que el token permanece disponible en la billetera compatible del usuario.
El PIRATE nativo y el PIRATE envuelto se registran en libros de contabilidad separados: el primero en la cadena de bloques PirateCash 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 PirateCash.
Cómo obtener PIRATE envuelto
Obtener wrapped PIRATE mediante @piratecash_bot
El cambio se realiza mediante @piratecash_bot — deposite PIRATE nativo y solicite el retiro de wrapped PIRATE a su dirección de BNB Smart Chain (BEP-20).
Abrir @piratecash_bot ↗Comprar en PancakeSwap
El PIRATE 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 ↗0xaFCC12e4040615E7Afe9fb4330eB3D9120acAC05
BscScan ↗
Suministro fijo: 105.000.000 PIRATE · 8 decimales · el suministro completo se acuñó cuando se implementó el contrato
Wrapped PIRATE y la operación del pool de staking están fuera del consenso de la red principal de PirateCash. 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 PIRATE ↔ wrapped PIRATE 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 PirateCash.
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 PirateCash 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 PirateCash 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
- PIRATE
- Lugares decimales
- 8
- Puerto P2P de red principal
- 63636
- Prefijo de dirección pública
- P
- tiempo de génesis
- 2018-11-02 23:45 UTC
- Hash del bloque Génesis
33422d3f8e94bae7cd2544e737d64ff8ec3ee140cc3fdc4db3d14656f9a60912