Dienste Investieren Masternode-Statistik PIRATE tauschen Block-Explorer FAQ Spenden now
Technische Dokumentation PirateCash L1 · geplante L2

PirateCash-Protokoll

Ein technischer Überblick über das Peer-to-Peer-Zahlungsnetzwerk PIRATE: sein UTXO-Ledger, Proof-of-Stake-Konsens, deterministische Masterknoten, LLMQs, Emissionsmodell und die geplante Tenderdash-basierte Layer-2-Plattform.

Revision 1.1 · Juli 2026
Zielblockzeit
120 Sekunden
Konsens
PoS + LLMQ
Maximales Angebot
≈105M PIRATE
Core-Lizenz
MIT open source
01
Zusammenfassung

Protokollübersicht

PirateCash ist ein dezentrales Open-Source-Zahlungsnetzwerk, dessen natives Asset PIRATE ist.

Das Netzwerk unterhält ein öffentliches UTXO-Ledger ohne zentralen Emittenten oder Abwicklungsbetreiber. Unabhängige Knoten validieren jede Transaktion und blockieren sie anhand derselben Konsensregeln. Staker erstellen Blöcke, während eine besicherte Masternode-Schicht Quorum-basierte Dienste und dezentrale Governance bereitstellt.

Unabhängige Validierung

Jeder vollständige Knoten überprüft Transaktionssignaturen, nicht ausgegebene Ausgaben, Blockstruktur, Einsatznachweise und Belohnungslimits, bevor er den Status akzeptiert.

Pfahlbasierte Sicherheit

Nach der Bootstrap-Phase verwendet die Blockproduktion Proof of Stake anstelle einer kontinuierlichen Wettbewerbs-Hash-Berechnung.

Zweistufiges Netzwerk

Deterministische Masterknoten bilden Quoren für Transaktionssperren, Blocksperren und Governance, ohne die vollständige Knotenvalidierung zu ersetzen.

Protokollerbe

PirateCash Core ist ein Fork von Dash Core und behält dessen von Bitcoin abgeleitetes UTXO-Modell, Peer-to-Peer-Netzwerk und Service-Node-Architektur bei. PirateCash ändert Netzwerkidentität, monetäre Parameter und Konsens durch die Aktivierung von PoS bei Block 100.000.

Öffnen Sie das Upstream-Repository Dash Core
02
Systemmodell

Netzwerkarchitektur

PirateCash trennt die lokale Schlüsselverwaltung, die Konsensvalidierung und die Quorumspflichten der Serviceschicht. Durch diese Trennung wird der Wallet-Besitz von der Blockproduktion und dem Masternode-Betrieb getrennt.

Vollständiger Knoten

Lädt die Kette herunter, verwaltet den UTXO-Satz und setzt unabhängig alle Konsensregeln durch. Ein Full Node muss kein Masternode sein.

Staker

Führt ein synchronisiertes Wallet mit berechtigten PIRATE-Ausgaben aus und signiert einen gültigen PoS-Block, wenn eine Ausgabe einen Stake-Kernel findet.

Masternode

Sperrt die erforderlichen Sicherheiten, registriert sich in der deterministischen Liste und nimmt bei Auswahl an Service-Quoren teil.

Wallet oder Integration

Erstellt und signiert Transaktionen, verfolgt Bestätigungen und fragt einen vertrauenswürdigen lokalen Knoten oder einen separat gesicherten Dienst ab.

03
Proof of Stake

Proof-of-Stake-Konsens

PoS wurde im PirateCash-Mainnet seit Block 100.000 durchgesetzt. Es macht den Besitz eines geeigneten UTXO zur Ressource, die zum Vorschlagen eines Blocks verwendet wird, und nicht die rohe Hashing-Leistung.

Das Zielintervall beträgt 120 Sekunden und der Schwierigkeitsgrad wird kontinuierlich angepasst. Die Blockentdeckung bleibt probabilistisch: Das Halten eines geeigneten Einsatzes erhöht die erwartete Chance, einen Block zu produzieren, schafft jedoch keine feste oder garantierte Rendite.

  1. 01

    Wählen Sie geeignete Ausgänge aus

    Das Stake Wallet berücksichtigt nicht ausgegebene PIRATE-Ausgaben, die den Bestätigungsregeln entsprechen und seit mindestens 28.800 Sekunden vorhanden sind. Masternode-Sicherheiten sind standardmäßig vor dem Abstecken geschützt.

  2. 02

    Testen Sie den Stake-Kernel

    Der Knoten testet geeignete Ausgaben und zulässige Zeitstempel anhand des aktuellen PoS-Ziels. Ein höherer infrage kommender Wert erhöht die erwartete Auswahlwahrscheinlichkeit.

  3. 03

    Konstruieren und unterschreiben

    Wenn ein Kernel das Ziel erreicht, erstellt das Wallet die Block-Stake-Transaktion, schließt gültige Mempool-Transaktionen ein und signiert den Block mit dem Schlüssel, der die ausgewählte Ausgabe steuert.

  4. 04

    Validieren und verbreiten

    Peers überprüfen, ob die Ausgabe unverbraucht und ausgereift ist, der Kernel und die Zeitstempel das Ziel erfüllen, die Signaturen gültig sind und die beanspruchte Belohnung die Konsensgrenzen nicht überschreitet.

Konzeptionelle Wahrscheinlichkeit P(Block) ∝ zulässiger Anteil ÷ Netzwerkschwierigkeit

Diese Beziehung erklärt nur die erwartete Auswahl; Die Implementierung bewertet diskrete Stake-Kernel und kurzfristige Ergebnisse können erheblich vom Durchschnitt abweichen.

PoS-Aktivierung #100,000
Mindestalter für den Einsatz 28,800 s
Zielabstand 120 s
Schwierigkeiten beim Retargeting Jeder Block

Staking erfordert einen vollständig synchronisierten Knoten und sicheren Zugriff auf den Signaturschlüssel. Verschlüsseln Sie das Wallet, bewahren Sie Offline-Backups auf und entsperren Sie es nur für das Staking, sofern dies unterstützt wird. Die Poolrendite hängt von den tatsächlich erzielten Staking-Belohnungen und vom Glück des Pools beim Finden von Blöcken ab. Wrapped PIRATE stellt eine Verpflichtung des Betreibers gegenüber dem Nutzer dar — der Dienst nimmt native PIRATE entgegen und gibt dafür BEP-20-Token aus. Ihr Marktpreis und ihre Handelbarkeit werden durch die auf PancakeSwap bereitgestellte Liquidität unterstützt.

04
Service layer

Masternodes und Quoren

Eine deterministische Masternode-Liste verankert eine zweite Netzwerkebene. Sicherheiten beweisen ein langlebiges wirtschaftliches Engagement; es gewährt keine Erlaubnis, Konsensregeln zu ändern. Vollständige Knoten überprüfen weiterhin die resultierenden Transaktionen, Blöcke und Quorumsignaturen.

Regelmäßige Masternode-Sicherheiten 10,000 PIRATE
Evo-Masternode-Sicherheiten 40,000 PIRATE

Die Sicherheit bleibt unter dem Schlüssel des Eigentümers, darf aber nicht ausgegeben werden, solange der Masternode registriert und aktiv ist.

IS

InstantSend

Sperrt Transaktionseingaben durch eine LLMQ-Signatur, sodass widersprüchliche Ausgaben abgelehnt werden können, bevor sich die normale Blocktiefe ansammelt.

CL

ChainLocks

Signiert den ersten gültigen Block, der in der Höhe beobachtet wird, wodurch tiefgreifende Reorganisationen erheblich erschwert werden, sobald das Netzwerk die Sperre akzeptiert.

DAO

Regierungsführung

Aktive Masternode-Betreiber stimmen über Vorschläge ab; Genehmigte Zahlungen können über den Superblock-Budgetmechanismus des Protokolls abgewickelt werden.

C
PIP-0001 · PIRATECASH CORE v19

Corsa

PirateCash-Masternodes betreiben außerdem Corsa, einen dezentralen Messenger für grenzenlose Kommunikation mit Ende-zu-Ende-Verschlüsselung. So bleiben Gespräche privat, ohne von einem zentralen Dienst abhängig zu sein.

corsa-chat-Anforderung für PirateCash Core v19
Ab PirateCash Core v19 muss eine Masternode zusätzlich eine lokale corsa-chat/Corsa-Node auf demselben Server ausführen. Die automatische Einrichtung im masternode-Repository konfiguriert PirateCash Core und corsa-chat zusammen. Die Anforderung ist in PIP-0001 beschrieben.
github.com/piratecash/corsa
Mainnet-Quorum-Profile in PirateCash Core
Service Quorum-Profil Protokollrolle
ChainLocks LLMQ_400_60 Schwellenwertsignatur für Blocksperren
InstantSend LLMQ_60_75 Rotierendes Quorum für deterministische Transaktionssperren
Platform LLMQ_100_67 Quorum-Profil für Plattformdienste reserviert
05
Planned Layer 2

PirateCash-Plattform: geplanter Layer 2

Architekturstatus Geplant · nicht im Mainnet aktiv

Das Layer-2-Netzwerk verarbeitet den Benutzerstatus noch nicht und ist nicht Teil des aktiven PirateCash-Konsenses. Das folgende Design beschreibt die beabsichtigte Entwicklungsrichtung, nicht ein derzeit in Betrieb befindliches Produkt.

PirateCash plant den Aufbau einer eigenen Layer-2-Plattform als Fork und Adaption des Open-Source-Plattformstapels Dash, wobei Tenderdash als BFT-Konsens-Engine verwendet wird.

Tenderdash ist ein Tendermint-Fork, der für dynamische Masternode-Quoren und BLS-Schwellenwertsignaturen angepasst ist. Es ist die Konsenskomponente der Plattform; Zustandsspeicher, Datenprotokoll und Entwicklerschnittstellen bilden separate Schichten. In der PirateCash-Version sind diese Komponenten für die Integration in die Schicht-1-PoS-Kette und die deterministische Masterknotenliste PirateCash vorgesehen.

BFT Endgültigkeit

Ein Block wird nach Zustimmung von mehr als zwei Dritteln des aktiven Validatorsatzes festgeschrieben. Wenn kein Quorum erreicht werden kann, sollte die Finalisierung gestoppt werden, um die Konsistenz des Staates zu wahren.

LLMQ und BLS

Tenderdash ersetzt einen statischen Validatorsatz durch rotierende Masterknoten-Teilsätze. Eine BLS-Schwellenwertsignatur stellt die Quorumsentscheidung als eine kompakte Signatur dar.

Ausführung im selben Block

Das Zieldesign erbt die Ausführung im selben Block: Der in einem Blockheader festgeschriebene AppHash stellt den Zustand dar, nachdem die enthaltenen Übergänge ausgeführt wurden.

Datenverträge, nicht EVM

Die geplante Plattform zielt auf Identitäten, Dokumente und schemagesteuerte Daten mit signierten Zustandsübergängen ab. Dies impliziert keine EVM-Kompatibilität oder willkürliche Solidity-Verträge.

Implementierungsphasen

01
Gabel und Anpassung

Wählen Sie eine kompatible Tenderdash/Plattform-Basislinie aus, ersetzen Sie Netzwerkidentitäten und integrieren Sie sie mit PirateCash, Core, PoS und dem Masterknotenmodell.

02
Finanzierung des Credit Pools consensus.MN_RRHeight = 1910840;

Bei Mainnet-Block 1.910.840 wird MN_RR aktiviert: Das Protokoll beginnt, den Platform-Anteil der Masternode-Belohnung dem Credit Pool zuzuweisen. Damit beginnt die Finanzierung des Pools; PirateCash Platform wird dadurch weder gestartet noch aktiviert.

03
Devnet und Testnet

Testen Sie DKG, Validatorrotation, Quorum-Loss-Stopps, deterministischen Zustand, DAPI und Protokoll-Upgrades unter schwierigen Bedingungen.

04
Separater Platform-Start

PirateCash Platform wird später durch einen separaten Aktivierungsprozess gestartet, nachdem Devnet und Testnet validiert sowie öffentliche Spezifikationen, Audits und Betreibersoftware vorbereitet wurden. Block 1.910.840 ist nicht die Starthöhe der Platform.

Das Profil LLMQ_100_67 ist bereits in den Parametern PirateCash Bis zu einer separaten Aktivierung bleiben Leistung, Gebühren, Anwendungsfunktionen und Plattformökonomie Designziele.

06
UTXO ledger

Transaktionen und das UTXO-Ledger

PIRATE wird als nicht ausgegebene Transaktionsausgaben verbucht. Eine Transaktion verbraucht vorhandene Ausgaben und erstellt neue Ausgaben, deren Ausgabebedingungen durch Skripte und kryptografische Schlüssel definiert werden.

Kein Kontostand im Konsens

Ein angezeigtes Wallet-Guthaben ist die Summe der auszugebenden UTXOs, die von seinen Schlüsseln gesteuert werden. Das Wechselgeld einer Zahlung wird normalerweise als neu erstellte Ausgabe zurückgegeben.

Gebühren

Die Differenz zwischen den gesamten Inputs und Outputs ist die Transaktionsgebühr. Knoten wenden Relay- und Mempool-Richtlinien zusätzlich zu Konsensprüfungen auf Blockebene an.

Schlüsseleigentum

Das Protokoll erkennt gültige Signaturen, keine Identitäten oder Supportanfragen. Der Verlust eines privaten Schlüssels oder einer Wiederherstellungsphrase bedeutet im Allgemeinen, dass die Kontrolle über das PIRATE verloren geht.

Bestätigung und Sperren

Eine Blockbestätigung ordnet die Transaktion in der PoS-Kette an. InstantSend und ChainLocks bieten Quorum-signierten Schutz vor widersprüchlichen Ausgaben und Reorganisationen.

07
PIRATE economics

Emission und Verteilung

PIRATE verfügt über eine protokolldefinierte Emissionskurve mit einem ungefähren maximalen Vorrat von 105 Millionen Münzen.

Bis Block 100.000 nutzte das Netzwerk Proof of Work; danach wurde Proof of Stake zum Mechanismus der Blockerzeugung. Die Basissubvention startete bei 50 PIRATE und halbiert sich alle 1.048.576 Höhen des vorherigen Blocks. Deterministische Masternode-Zahlungen beginnen bei Block 1.266.000, das DAO-Budget bei 1.899.666 und die MN_RR-Finanzierung des Credit Pools bei 1.910.840. Transaktionsgebühren werden zur zulässigen Belohnung addiert und erzeugen selbst keine zusätzliche Emission.

Fairer Start

Ohne Premine gestartet

Das PirateCash-Mainnet wurde am 3. November 2018 öffentlich gestartet, ohne dass vor dem Start der Kette eine vorab erstellte Reserve an nativem PIRATE zugewiesen wurde. Münzen gelangten durch protokolldefinierte Belohnungen für Blöcke, die von Netzwerkteilnehmern produziert wurden, in Umlauf.

Native PIRATE-Premine
0 PIRATE
Öffentlicher Start
2018-11-03
Erste Blockbelohnung
50 PIRATE

Die No-Premine-Erklärung gilt für die native PIRATE-Münze und den Layer-1-Start. Die spätere Vertragsdarstellung BEP-20 auf der BNB Smart Chain verfügt über eine separate Liefer- und Vertriebshistorie.

Verkürzter Mainnet-Subventionsplan
Blockbereich Grundzuschuss Protokollphase
0–99,999 50 PIRATE PoW-Startphase
100,000–1,048,575 50 PIRATE PoS mit voller Basissubvention
1,048,576–1,265,999 25 PIRATE PoS mit progressiver Masternode-Zuweisung
1,266,000–1,899,665 25 PIRATE Deterministische Masternode-Zahlungen aktiv
1,899,666–2,097,151 25 PIRATE DAO-Budget; MN_RR folgt bei Block 1.910.840
2,097,152+ 12,5 PIRATE, danach Halbierung alle 1.048.576 Blöcke Langfristig begrenzte Emission
Finanzministerium

Nach der Höhe des Budgetstarts reserviert das Protokoll einen Subventionsanteil für genehmigte Governance-Zahlungen durch Superblocks.

Service-Belohnungen

Der Masternode-Anteil beginnt bei 0,1 % und wird schrittweise in Richtung des in Core definierten langfristigen Ziels von 60 % umverteilt.

Angebotsobergrenze

Das Maximum ist ein Emissionsplanergebnis, keine frei prägbare Token-Einstellung. Der Konsens lehnt Belohnungen ab, die über den zulässigen Zuschuss hinausgehen.

Liquid Staking

Wrapped PIRATE auf BNB Smart Chain

BNB Smart Chain BEP-20

Wrapped PIRATE ist ein BEP-20-Token, der das native PirateCash-Netzwerk mit einem Staking-Pool und dem BNB Smart Chain-Ökosystem verbindet. Ein Benutzer kann gemäß den Serviceregeln natives PIRATE in den Pool einzahlen und verpacktes PIRATE erhalten. Der Pool aggregiert Einzahlungen und verwendet die nativen Münzen zum Abstecken im PirateCash-Netzwerk, während der Token im kompatiblen Wallet des Benutzers verfügbar bleibt.

Natives PIRATE und verpacktes PIRATE werden in separaten Ledgern erfasst: Ersteres auf der PirateCash UTXO-Blockchain, Letzteres durch einen BEP-20-Vertrag auf der BNB Smart Chain. Der verpackte Token erzeugt auf der PirateCash-Protokollebene keine zusätzliche Emission nativer Münzen.

01 Natives PIRATE Münzen existieren im primären PirateCash UTXO-Netzwerk.
02 Poolkaution Der Benutzer sendet PIRATE an die Adresse des Absteckpool-Dienstes.
03 Gepoolter Einsatz Der Pool sammelt native Münzen und beteiligt sich an der Blockerstellung.
04 Eingewickelt PIRATE Der Pool überträgt BEP-20-Tokens aus seiner vorhandenen Reserve an den Benutzer.

So erhalten Sie verpacktes PIRATE

Route A · Gateway
Wrapped PIRATE über @piratecash_bot erhalten

Der Umtausch erfolgt über @piratecash_bot — zahlen Sie native PIRATE ein und veranlassen Sie die Auszahlung von wrapped PIRATE an Ihre BNB-Smart-Chain-Adresse (BEP-20).

@piratecash_bot öffnen
Route B · tauschen
Kaufen Sie auf PancakeSwap

Wrapped PIRATE kann auch direkt aus einem verfügbaren Liquiditätspool mit einer BNB Smart Chain-kompatiblen Self-Custody-Wallet erworben werden.

Öffnen Sie PancakeSwap
Offiziell verpackter PIRATE-Vertrag · BNB Smart Chain 0xaFCC12e4040615E7Afe9fb4330eB3D9120acAC05 BscScan ↗ Fester Vorrat: 105.000.000 PIRATE · 8 Dezimalstellen · Der volle Vorrat wurde geprägt, als der Vertrag in Kraft trat
Vertrauen Sie Grenzen und Risiken

Wrapped PIRATE und der Staking-Pool liegen außerhalb des PirateCash-Mainnet-Konsenses. Der Vertrag prägt bei einer Einzahlung nicht automatisch Token und implementiert keine native Trustless Bridge: Die netzwerkübergreifende Konvertierung wird vom Projekt-Gateway aus dem vorhandenen Token-Angebot ausgeführt. Das Gateway über @piratecash_bot garantiert den Umtausch native PIRATE ↔ wrapped PIRATE in beide Richtungen. Prüfen Sie vor einer Einzahlung oder einem Tausch die Vertragsadresse, Ausgabe- und Rücknahmeregeln, Gebühren und Verwahrungsbedingungen für native Coins. DEX-Preis, Rendite und Liquidität werden nicht durch das PirateCash-Protokoll garantiert.

Bidirektionales Exchange-Gateway @piratecash_bot ↗
09
Trust model

Sicherheits- und Vertrauensgrenzen

Die Sicherheit ist mehrschichtig: Signaturen schützen das Eigentum, PoS ordnet gültige Zustandsübergänge an, vollständige Knoten erzwingen den Konsens und LLMQ-Signaturen bieten schnellen Schutz vor Transaktionskonflikten und Kettenreorganisationen.

Widersprüchliche Transaktionen

Knoten lehnen Ausgaben bereits verbrauchter Ausgaben ab, während InstantSend Eingaben sperren kann, bevor die normale Bestätigungstiefe erreicht ist.

InstantSend · UTXO

Kettenumstrukturierungen

ChainLocks bindet die Quorumsvereinbarung an einen Block auf einer bestimmten Höhe und verringert den praktischen Spielraum für die Neuorganisation des akzeptierten Verlaufs.

ChainLocks · LLMQ

Ungültiger Einsatz oder Belohnung

Jeder Knoten überprüft unabhängig die Stake-Berechtigung, das Kernel-Ziel, die Blocksignatur, die Transaktionsgültigkeit und die maximale Belohnung.

PoS · validation

Kompromiss beim Geldbeutel

Consensus kann gestohlene Schlüssel nicht wiederherstellen. Verschlüsselung, Sicherung der Wiederherstellungsphrase, Systemhärtung und Trennung der Betreiberschlüssel bleiben weiterhin in der Verantwortung des Benutzers.

signatures · backups

Dieses Dokument beschreibt das Protokoll; Es handelt sich nicht um eine Prüfung, ein Investitionsversprechen oder eine Garantie für einen unterbrechungsfreien Betrieb. Der ausführbare Konsenscode PirateCash Core ist maßgeblich, wenn diese Übersicht und ein aktives Software-Release abweichen.

10
Reference

Integrationsreferenz

Produktionsintegrationen sollten einen kompatiblen PirateCash Core-Knoten ausführen, das gemeldete Netzwerk und den Genesis-Block validieren, auf die Bestätigung oder Sperrrichtlinie warten, die ihrem Risikomodell entspricht, und Upgrades vor der Bereitstellung testen.

Einheimisches Symbol
PIRATE
Dezimalstellen
8
Mainnet-P2P-Port
63636
Präfix für öffentliche Adressen
P
Genesis-Zeit
2018-11-02 23:45 UTC
Genesis-Block-Hash
33422d3f8e94bae7cd2544e737d64ff8ec3ee140cc3fdc4db3d14656f9a60912

Dieses Webdokument wird auf der PirateCash-Website verwaltet. Konsensverändernde Werte müssen vor der Implementierung anhand der aktiven Version PirateCash Core überprüft werden.

Revision 1.1 · Juli 2026