PirateCash protocol
A technical overview of the PIRATE peer-to-peer payment network: its UTXO ledger, Proof-of-Stake consensus, deterministic masternodes, LLMQs, emission model and planned Tenderdash-based Layer 2 platform.
Revision 1.1 · July 2026- Target block time
- 120 seconds
- Consensus
- PoS + LLMQ
- Maximum supply
- ≈105M PIRATE
- Core license
- MIT open source
Protocol overview
PirateCash is an open-source, decentralized payment network whose native asset is PIRATE.
The network maintains a public UTXO ledger without a central issuer or settlement operator. Independent nodes validate every transaction and block against the same consensus rules. Stakers create blocks, while a collateralized masternode layer provides quorum-based services and decentralized governance.
Independent validation
Every full node checks transaction signatures, unspent outputs, block structure, stake proofs and reward limits before accepting state.
Stake-based security
After the bootstrap phase, block production uses Proof of Stake instead of continuous competitive hash computation.
Two-tier network
Deterministic masternodes form quorums for transaction locks, block locks and governance without replacing full-node validation.
PirateCash Core is a fork of Dash Core and retains its Bitcoin-derived UTXO model, peer-to-peer networking and service-node architecture. PirateCash changes network identity, monetary parameters and consensus by activating PoS at block 100,000.
Open the upstream Dash Core repositoryNetwork architecture
PirateCash separates local key management, consensus validation and service-layer quorum duties. This separation keeps wallet ownership distinct from block production and masternode operation.
Full node
Downloads the chain, maintains the UTXO set and independently enforces all consensus rules. A full node does not need to be a masternode.
Staker
Runs a synced wallet with eligible PIRATE outputs and signs a valid PoS block when an output finds a stake kernel.
Masternode
Locks the required collateral, registers on the deterministic list and participates in service quorums when selected.
Wallet or integration
Creates and signs transactions, tracks confirmations and queries a trusted local node or a separately secured service.
Proof-of-Stake consensus
PoS has been enforced on PirateCash mainnet since block 100,000. It makes ownership of an eligible UTXO, rather than raw hashing power, the resource used to propose a block.
The target interval is 120 seconds and difficulty is adjusted continuously. Block discovery remains probabilistic: holding eligible stake increases the expected chance of producing a block but does not create a fixed or guaranteed return.
-
01
Select eligible outputs
The staking wallet considers unspent PIRATE outputs that meet confirmation rules and have existed for at least 28,800 seconds. Masternode collateral is protected from staking by default.
-
02
Test the stake kernel
The node tests eligible outputs and permitted timestamps against the current PoS target. More eligible value increases expected selection probability.
-
03
Construct and sign
When a kernel meets the target, the wallet constructs the block stake transaction, includes valid mempool transactions and signs the block with the key controlling the selected output.
-
04
Validate and propagate
Peers verify that the output is unspent and mature, the kernel and timestamps satisfy the target, signatures are valid and the claimed reward does not exceed consensus limits.
P(block) ∝ eligible stake ÷ network difficulty
This relationship explains expected selection only; the implementation evaluates discrete stake kernels, and short-term results may differ substantially from the average.
Staking requires a fully synchronized node and safe access to the signing key. Encrypt the wallet, keep offline backups and unlock only for staking where supported. Pool yield depends on the staking rewards actually earned and on the pool’s luck in finding blocks. Wrapped PIRATE represents the operator’s obligation to users: the service accepts native PIRATE and issues BEP-20 tokens in return. Their market price and tradability are supported by liquidity provided on PancakeSwap.
Masternodes and quorums
A deterministic masternode list anchors a second network tier. Collateral proves a long-lived economic commitment; it does not grant permission to change consensus rules. Full nodes still verify the resulting transactions, blocks and quorum signatures.
Collateral remains under the owner’s key but must stay unspent while the masternode is registered and active.
InstantSend
Locks transaction inputs through an LLMQ signature so conflicting spends can be rejected before ordinary block depth accumulates.
ChainLocks
Signs the first valid block observed at a height, making deep reorganizations substantially harder once the network accepts the lock.
Governance
Active masternode operators vote on proposals; approved payments can be settled through the protocol’s superblock budget mechanism.
Corsa
PirateCash masternodes also power Corsa, a decentralized messenger for borderless communication with end-to-end encryption, so conversations stay private without relying on a single central service.
Starting with PirateCash Core v19, a masternode must also run a local corsa-chat/Corsa node on the same server. The automatic setup in the masternode repository configures PirateCash Core and corsa-chat together. The requirement is described in PIP-0001.
| Service | Quorum profile | Protocol role |
|---|---|---|
| ChainLocks | LLMQ_400_60 |
Threshold signing for block locks |
| InstantSend | LLMQ_60_75 |
Rotating quorum for deterministic transaction locks |
| Platform | LLMQ_100_67 |
Quorum profile reserved for platform services |
PirateCash Platform: planned Layer 2
The Layer 2 network does not yet process user state and is not part of active PirateCash consensus. The design below describes the intended development direction, not a currently operating product.
PirateCash plans to build its own Layer 2 platform as a fork and adaptation of the open-source Dash Platform stack, using Tenderdash as its BFT consensus engine.
Tenderdash is a Tendermint fork adapted for dynamic masternode quorums and BLS threshold signatures. It is the consensus component of the platform; state storage, the data protocol and developer interfaces form separate layers. In the PirateCash version, these components are intended to integrate with the Layer 1 PoS chain and the PirateCash deterministic masternode list.
PirateCash Core
Native PIRATE, UTXO payments, emission, Proof of Stake, masternodes and Layer 1 finality remain on the primary chain.
PirateCash Platform
A separate state chain for fast confirmation, verifiable data changes and decentralized application services.
BFT finality
A block commits after agreement by more than two thirds of the active validator set. If a quorum cannot be reached, finalization should halt to preserve state consistency.
LLMQ and BLS
Tenderdash replaces a static validator set with rotating masternode subsets. A BLS threshold signature represents the quorum decision as one compact signature.
Same-block execution
The target design inherits same-block execution: the AppHash committed in a block header represents state after the included transitions have executed.
Data contracts, not EVM
The planned platform targets identities, documents and schema-governed data with signed state transitions. It does not imply EVM compatibility or arbitrary Solidity contracts.
Implementation stages
Select a compatible Tenderdash/Platform baseline, replace network identities and integrate it with PirateCash Core, PoS and the masternode model.
consensus.MN_RRHeight = 1910840;
At mainnet block 1,910,840, MN_RR activates and the protocol begins reallocating the Platform share of the masternode reward to the credit pool. This starts funding the pool; it does not launch or activate PirateCash Platform.
Test DKG, validator rotation, quorum-loss halts, deterministic state, DAPI and protocol upgrades under adversarial conditions.
PirateCash Platform will launch later through a separate activation process, after devnet and testnet validation, public specifications, audits and operator software are ready. Block 1,910,840 is not the Platform launch height.
The LLMQ_100_67 profile already exists in PirateCash Core parameters, but this alone does not mean Layer 2 is live. Until a separate activation, performance, fees, application features and platform economics remain design targets.
Transactions and the UTXO ledger
PIRATE is accounted for as unspent transaction outputs. A transaction consumes existing outputs and creates new outputs whose spending conditions are defined by scripts and cryptographic keys.
No account balance in consensus
A displayed wallet balance is the sum of spendable UTXOs controlled by its keys. Change from a payment is normally returned as a newly created output.
Fees
The difference between total inputs and outputs is the transaction fee. Nodes apply relay and mempool policies in addition to block-level consensus checks.
Key ownership
The protocol recognizes valid signatures, not identities or support requests. Losing a private key or recovery phrase generally means losing control of its PIRATE.
Confirmation and locks
A block confirmation orders the transaction in the PoS chain. InstantSend and ChainLocks add quorum-signed protection against conflicting spends and reorganizations.
Emission and distribution
PIRATE has a protocol-defined emission curve with an approximate maximum supply of 105 million coins.
The launch used Proof of Work through block 100,000; Proof of Stake then became the block-production mechanism. The base subsidy started at 50 PIRATE and halves every 1,048,576 previous-block heights. Deterministic masternode payments begin at block 1,266,000, the governance budget at 1,899,666, and MN_RR credit-pool funding at 1,910,840. Transaction fees are added to the permitted reward and do not create supply by themselves.
Launched without a premine
The PirateCash mainnet launched publicly on 3 November 2018 without a pre-created reserve of native PIRATE allocated before the chain started. Coins entered circulation through protocol-defined rewards for blocks produced by network participants.
- Native PIRATE premine
- 0 PIRATE
- Public launch
- 2018-11-03
- Initial block reward
- 50 PIRATE
The no-premine statement applies to the native PIRATE coin and the Layer 1 launch. The later BEP-20 contract representation on BNB Smart Chain has a separate supply and distribution history.
| Block range | Base subsidy | Protocol phase |
|---|---|---|
| 0–99,999 | 50 PIRATE | PoW bootstrap |
| 100,000–1,048,575 | 50 PIRATE | PoS active at full subsidy |
| 1,048,576–1,265,999 | 25 PIRATE | PoS with progressive masternode allocation |
| 1,266,000–1,899,665 | 25 PIRATE | Deterministic masternode payments active |
| 1,899,666–2,097,151 | 25 PIRATE | Governance budget; MN_RR follows at block 1,910,840 |
| 2,097,152+ | 12.5 PIRATE, then halved every 1,048,576 blocks | Long-term finite emission |
After the budget start height, the protocol reserves a subsidy share for approved governance payments through superblocks.
The masternode share begins at 0.1% and is progressively reallocated toward the long-term 60% target defined in Core.
The maximum is an emission-schedule result, not a freely mintable token setting. Consensus rejects rewards above the permitted subsidy.
Wrapped PIRATE on BNB Smart Chain
Wrapped PIRATE is a BEP-20 token connecting the native PirateCash network to a staking pool and the BNB Smart Chain ecosystem. A user can deposit native PIRATE into the pool and receive wrapped PIRATE under the service rules. The pool aggregates deposits and uses the native coins for staking on the PirateCash network, while the token remains available in the user’s compatible wallet.
Native PIRATE and wrapped PIRATE are recorded on separate ledgers: the former on the PirateCash UTXO blockchain, the latter by a BEP-20 contract on BNB Smart Chain. The wrapped token does not create additional native-coin emission at the PirateCash protocol level.
How to obtain wrapped PIRATE
Obtain wrapped PIRATE through @piratecash_bot
The exchange is performed through @piratecash_bot: deposit native PIRATE and request a withdrawal of wrapped PIRATE to your BNB Smart Chain (BEP-20) address.
Open @piratecash_bot ↗Buy on PancakeSwap
Wrapped PIRATE can also be acquired directly from an available liquidity pool with a BNB Smart Chain-compatible self-custody wallet.
Open PancakeSwap ↗0xaFCC12e4040615E7Afe9fb4330eB3D9120acAC05
BscScan ↗
Fixed supply: 105,000,000 PIRATE · 8 decimals · the full supply was minted when the contract was deployed
Wrapped PIRATE and staking-pool operation are outside the PirateCash mainnet consensus. The contract does not mint tokens automatically on deposit and does not implement a native trustless bridge: cross-network conversion is operated by the project gateway from the existing supply. The project gateway available through @piratecash_bot guarantees native PIRATE ↔ wrapped PIRATE exchange in both directions. Before depositing or swapping, verify the contract address, distribution and redemption rules, fees and custody terms for native coins. DEX price, yield and liquidity are not guaranteed by the PirateCash protocol.
Bidirectional exchange gateway @piratecash_bot ↗Security and trust boundaries
Security is layered: signatures protect ownership, PoS orders valid state transitions, full nodes enforce consensus, and LLMQ signatures add fast protection against transaction conflicts and chain reorganizations.
Conflicting transactions
Nodes reject spends of already consumed outputs, while InstantSend can lock inputs before normal confirmation depth is reached.
InstantSend · UTXOChain reorganizations
ChainLocks bind quorum agreement to a block at a given height and reduce the practical scope for reorganizing accepted history.
ChainLocks · LLMQInvalid stake or reward
Every node verifies stake eligibility, kernel target, block signature, transaction validity and maximum reward independently.
PoS · validationWallet compromise
Consensus cannot restore stolen keys. Encryption, recovery-phrase backups, system hardening and separation of operator keys remain user responsibilities.
signatures · backupsThis document describes the protocol; it is not an audit, investment promise or guarantee of uninterrupted operation. The executable PirateCash Core consensus code is authoritative if this overview and an active software release differ.
Integration reference
Production integrations should run a compatible PirateCash Core node, validate the reported network and genesis block, wait for the confirmation or lock policy appropriate to their risk model, and test upgrades before deployment.
- Native symbol
- PIRATE
- Decimal places
- 8
- Mainnet P2P port
- 63636
- Public address prefix
- P
- Genesis time
- 2018-11-02 23:45 UTC
- Genesis block hash
33422d3f8e94bae7cd2544e737d64ff8ec3ee140cc3fdc4db3d14656f9a60912