Parano1d v2.0.3

v2.0.3 fixes excessive database growth in nodes and GUI wallets. This patch is recommended for all v2.0.x users.

v2 activates at block 210,537. Nodes and GUI wallets must run v2.0.1 or newer before activation.

Storage fix

MDBX could extend mdbx.dat even when pruning had already freed substantial space inside it. The allocator stopped searching before reaching suitable older free extents. This patch gives that search a bounded time budget so those extents can be reused.

The fix applies automatically when the node or GUI wallet opens an existing or newly created database. Durable writes, database format, consensus rules and network protocols are unchanged.

Updating

Install v2.0.3 and start normally. The fix stops the excessive growth caused by this allocator cutoff. An already oversized file may remain large, but its free pages can be reused for subsequent writes. Normal growth of live State and permanent header indexes still uses disk space.

To reclaim the space already accumulated, you can optionally stop the node or GUI wallet completely, delete only mdbx.dat and mdbx.lck from its data directory, and then start v2.0.3. It will recreate the chain database and synchronize from peers.

Keep the rest of the data directory, including wallet keys, receipts and contract evidence. Do not delete the entire data directory.

Parano1d v2.0.2

v2 activates at block 210,537. The estimated activation time is October 10, 2026 at 11:59 PM PDT (October 11 at 06:59 UTC). Block height determines activation; the actual time depends on block production.

Nodes and GUI wallets must upgrade to v2.0.1 or newer before activation.

New in v2.0.2

• Faster State sync: upgraded peers compress and batch small State segments within strict limits, reducing request count and data transfer. Each segment is still verified separately.
• Less work on repeat syncs: the client verifies matching State segments already on disk and reuses them instead of downloading them again.
• More reliable wallet sends and consolidation: wallets select output slots from live State segments with enough free space, reducing collisions when transactions compete for the last holes in an almost full segment.
• Compatibility with older nodes: peers automatically negotiate /sync/segment/6 or the existing /sync/segment/5 transport. Upgraded seeds continue serving older clients, and upgraded clients can synchronize from older peers. Both transports remain available before and after v2 activation.

State transfer speed depends on peer versions and network conditions.

V2 features

Proof-native smart contracts

From live value to live rights. Contracts add programmable spending rights to live State. Each transition is checked inside the shared recursive block proof, allowing validators to authenticate the current result without retaining or replaying the full interaction history.

• A shared integer core supports checked arithmetic, conditions, inclusion height and persistent counters: up to 16 instructions, two persistent u64 counters and two scratch registers. Applications use this core without generating a separate matrix for each program.
• Six ready-made templates cover payment with refund, timelocked vault, allowance wallet, period budget, recurring payment and gradual unlock. Custom programs are available through the editor, CLI and API. Scheduled policies execute when an authorized participant submits a call.
• The GUI adds F7 Contracts, with Create, My Contracts and Open File workflows; Settings moves to F8. Fourteen contract RPC methods and CLI commands cover terms, funding, balances, reviewed calls, receipts and recovery. Funding and calls become available at v2 activation.
• The journal displays saved interactions from either party. Importing receipts and contract updates merges evidence while preserving local records. Keep public terms and receipts with wallet backups: shared files carry terms and an optional receipt, and wallets discover locally known successor states after calls and reorgs.

Capacity and consensus

The target block interval changes from 20 to 30 seconds. ASERT uses a six-block reference epoch and a 180-second half-life, with height-aware timing across the fork. The earlier v1 → v1.1 transition remains unchanged.

V2 class	Matrix	User pages	Live inputs	Contract calls	Production
Small	m23	63	504	63	Default
Large	m24	206	504	63	Server opt-in

Pages, inputs and calls share the same block budget. A call consumes one page and one input. Small holds up to 63 one-page payments or 63 calls; Large holds up to 206 one-page payments, or 63 calls plus 143 one-page payments, within the 504-input limit. The primary coinbase is separate; an additional mandatory system page consumes one of the listed pages.

Large production requires --v2-large-blocks on the producing server. This permits fee-based selection of Large blocks; all nodes verify both classes. The GUI has no Large-production toggle.

• Preserve the 1,100,000-byte terminal transport limit for both classes. Admission and block construction enforce the selected class's page, input and call limits together.
• Retain the 144-block transaction epoch, 18-block finality boundary and 17-block maximum reorg. At the new target, the epoch is about 72 minutes and finality is about nine minutes. Body and undo retention remain 42 and 36 blocks.
• Bind the first v2 proof to the last pre-v2 block through an authenticated fork origin. Cold synchronization and reorg handling verify this transition. The transition release includes old and new matrix material; verified retirement certificates enable later builds to omit the old matrices.

Tokenomics

V2 replaces State-triggered reward reductions with an explicit height schedule. The exact gross block subsidy starts at 16 NOID at the fork and follows:

16 → 11.30 → 8 → 5.65 → 4 → 2.83 → 2 → 1.41 → 1 NOID

Each step lasts 1,051,200 blocks from activation, nominally one year at 30 seconds per block. After eight reductions, the permanent tail is 1 NOID per block. Existing balances are unchanged.

Early mainnet operation showed why the original monetary clock needed to change: live State occupancy measures outstanding outputs, and can stay low while payments and contract interactions reuse slots. Tying reductions solely to State expansion left their timing unpredictable. Height now gives issuance a visible schedule.

State efficiency still has an economic incentive. Occupancy raises the fee for net-new live slots, and that growth component is burned. Consolidation frees slots and avoids the growth charge.

Other improvements since v1.1.0

• Fork difficulty: starting at the v2 fork, a block derives its difficulty target from its parent header, so competing blocks with the same parent have the same target regardless of their own timestamps.
• State processing: cache authenticated segments within a bounded memory budget and update only changed Merkle paths, reducing repeated hashing and copying across segments during synchronization, block application and proving.
• Proof implementation: reuse matrix-column weights, reduce temporary folding buffers and cache exact previously verified carried matrix claims. This reduces repeated verification work, including on Small blocks following a Large block.
• RPC and receipt recovery: expose retained block bodies after recursive suffix synchronization even when a block has no standalone proof bundle. Block RPCs and startup receipt recovery use those retained bodies.
• Wallet reliability and storage: preserve reviewed calls and successor terms across submission failures; store identical proof bytes once across local contract receipts while keeping exported receipts self-contained.
• Mining tools: align template refresh with fork timing, report active capacity, add configurable external-worker RPC timeouts with a 180-second default, and support finite mining runs through --blocks.
• Proof accounting: correct response-cost accounting and extend the source-linked analysis to v2, historical ancestry and matrix retirement.
• Documentation: update the README and English, Russian and Chinese documentation, including the contract core, API, GUI walkthroughs, receipts, network economics and an archive of earlier protocol profiles.

Parano1d v2.0.1

Mandatory release. Upgrade before mainnet block 210,537.

V2.0.1 supersedes v2.0.0. Starting at the v2 fork, a block derives its difficulty target from its parent header, so competing blocks with the same parent have the same target regardless of their own timestamps. The activation height is unchanged. If you installed v2.0.0, update to v2.0.1 before the fork. No reset or wallet migration is needed.

This patch also adds read-only RPC fields for contract indexers: contract_opening_hex in getMempoolEntry and call or close classification in getBlockDetails. The v2 proof matrices and contract rules are unchanged.

Update nodes, GUI wallets, block-producing pool nodes and exchange infrastructure before activation. Updated software switches rules automatically at that height; v1.1 cannot validate v2 blocks. The existing genesis, live balances and wallet secrets are preserved.

The estimated activation time is October 10, 2026 at 11:59 PM PDT (October 11 at 06:59 UTC). Block height determines activation; the actual time depends on block production.

1. Proof-native smart contracts

From live value to live rights. Contracts add programmable spending rights to live State. Each transition is checked inside the shared recursive block proof, allowing validators to authenticate the current result without retaining or replaying the full interaction history.

• A shared integer core supports checked arithmetic, conditions, inclusion height and persistent counters: up to 16 instructions, two persistent u64 counters and two scratch registers. Applications use this core without generating a separate matrix for each program.
• Six ready-made templates cover payment with refund, timelocked vault, allowance wallet, period budget, recurring payment and gradual unlock. Custom programs are available through the editor, CLI and API. Scheduled policies execute when an authorized participant submits a call.
• The GUI adds F7 Contracts, with Create, My Contracts and Open File workflows; Settings moves to F8. Fourteen contract RPC methods and CLI commands cover terms, funding, balances, reviewed calls, receipts and recovery. Funding and calls become available at v2 activation.
• The journal displays saved interactions from either party. Importing receipts and contract updates merges evidence while preserving local records. Keep public terms and receipts with wallet backups: shared files carry terms and an optional receipt, and wallets discover locally known successor states after calls and reorgs.

2. Capacity and consensus

The target block interval changes from 20 to 30 seconds. ASERT uses a six-block reference epoch and a 180-second half-life, with height-aware timing across the fork. The earlier v1 → v1.1 transition remains unchanged.

V2 class	Matrix	User pages	Live inputs	Contract calls	Production
Small	m23	63	504	63	Default
Large	m24	206	504	63	Server opt-in

Pages, inputs and calls share the same block budget. A call consumes one page and one input. Small holds up to 63 one-page payments or 63 calls; Large holds up to 206 one-page payments, or 63 calls plus 143 one-page payments, within the 504-input limit. The primary coinbase is separate; an additional mandatory system page consumes one of the listed pages.

Large production requires --v2-large-blocks on the producing server. This permits fee-based selection of Large blocks; all nodes verify both classes. The GUI has no Large-production toggle.

• Preserve the 1,100,000-byte terminal transport limit for both classes. Admission and block construction enforce the selected class's page, input and call limits together.
• Retain the 144-block transaction epoch, 18-block finality boundary and 17-block maximum reorg. At the new target, the epoch is about 72 minutes and finality is about nine minutes. Body and undo retention remain 42 and 36 blocks.
• Bind the first v2 proof to the last pre-v2 block through an authenticated fork origin. Cold synchronization and reorg handling verify this transition. The transition release includes old and new matrix material; verified retirement certificates enable later builds to omit the old matrices.

3. Tokenomics

V2 replaces State-triggered reward reductions with an explicit height schedule. The exact gross block subsidy starts at 16 NOID at the fork and follows:

16 → 11.30 → 8 → 5.65 → 4 → 2.83 → 2 → 1.41 → 1 NOID

Each step lasts 1,051,200 blocks from activation, nominally one year at 30 seconds per block. After eight reductions, the permanent tail is 1 NOID per block. Existing balances are unchanged.

Early mainnet operation showed why the original monetary clock needed to change: live State occupancy measures outstanding outputs, and can stay low while payments and contract interactions reuse slots. Tying reductions solely to State expansion left their timing unpredictable. Height now gives issuance a visible schedule.

State efficiency still has an economic incentive. Occupancy raises the fee for net-new live slots, and that growth component is burned. Consolidation frees slots and avoids the growth charge.

Other improvements since v1.1.0

• State processing: cache authenticated segments within a bounded memory budget and update only changed Merkle paths, reducing repeated hashing and copying across segments during synchronization, block application and proving.
• Proof implementation: reuse matrix-column weights, reduce temporary folding buffers and cache exact previously verified carried matrix claims. This reduces repeated verification work, including on Small blocks following a Large block.
• RPC and receipt recovery: expose retained block bodies after recursive suffix synchronization even when a block has no standalone proof bundle. Block RPCs and startup receipt recovery use those retained bodies.
• Wallet reliability and storage: preserve reviewed calls and successor terms across submission failures; store identical proof bytes once across local contract receipts while keeping exported receipts self-contained.
• Mining tools: align template refresh with fork timing, report active capacity, add configurable external-worker RPC timeouts with a 180-second default, and support finite mining runs through --blocks.
• Proof accounting: correct response-cost accounting and extend the source-linked analysis to v2, historical ancestry and matrix retirement.
• Documentation: update the README and English, Russian and Chinese documentation, including the contract core, API, GUI walkthroughs, receipts, network economics and an archive of earlier protocol profiles.

Parano1d v2.0.0

Historical source release only. v2.0.0 was superseded before activation, and its downloadable release assets have been removed. Install Parano1d v2.0.2 before mainnet block 210,537. Nodes and GUI wallets require v2.0.1 or newer. The activation height has not changed.

Mainnet v2 activates at block 210,537.

Update nodes, GUI wallets, block-producing pool nodes and exchange infrastructure before activation. Updated software switches rules automatically at that height; v1.1 cannot validate v2 blocks. The existing genesis, live balances and wallet secrets are preserved.

The estimated activation time is October 10, 2026 at 11:59 PM PDT (October 11 at 06:59 UTC). Block height determines activation; the actual time depends on block production.

1. Proof-native smart contracts

From live value to live rights. Contracts add programmable spending rights to live State. Each transition is checked inside the shared recursive block proof, allowing validators to authenticate the current result without retaining or replaying the full interaction history.

• A shared integer core supports checked arithmetic, conditions, inclusion height and persistent counters: up to 16 instructions, two persistent u64 counters and two scratch registers. Applications use this core without generating a separate matrix for each program.
• Six ready-made templates cover payment with refund, timelocked vault, allowance wallet, period budget, recurring payment and gradual unlock. Custom programs are available through the editor, CLI and API. Scheduled policies execute when an authorized participant submits a call.
• The GUI adds F7 Contracts, with Create, My Contracts and Open File workflows; Settings moves to F8. Fourteen contract RPC methods and CLI commands cover terms, funding, balances, reviewed calls, receipts and recovery. Funding and calls become available at v2 activation.
• The journal displays saved interactions from either party. Importing receipts and contract updates merges evidence while preserving local records. Keep public terms and receipts with wallet backups: shared files carry terms and an optional receipt, and wallets discover locally known successor states after calls and reorgs.

2. Capacity and consensus

The target block interval changes from 20 to 30 seconds. ASERT uses a six-block reference epoch and a 180-second half-life, with height-aware timing across the fork. The earlier v1 → v1.1 transition remains unchanged.

V2 class	Matrix	User pages	Live inputs	Contract calls	Production
Small	m23	63	504	63	Default
Large	m24	206	504	63	Server opt-in

Pages, inputs and calls share the same block budget. A call consumes one page and one input. Small holds up to 63 one-page payments or 63 calls; Large holds up to 206 one-page payments, or 63 calls plus 143 one-page payments, within the 504-input limit. The primary coinbase is separate; an additional mandatory system page consumes one of the listed pages.

Large production requires --v2-large-blocks on the producing server. This permits fee-based selection of Large blocks; all nodes verify both classes. The GUI has no Large-production toggle.

• Preserve the 1,100,000-byte terminal transport limit for both classes. Admission and block construction enforce the selected class's page, input and call limits together.
• Retain the 144-block transaction epoch, 18-block finality boundary and 17-block maximum reorg. At the new target, the epoch is about 72 minutes and finality is about nine minutes. Body and undo retention remain 42 and 36 blocks.
• Bind the first v2 proof to the last pre-v2 block through an authenticated fork origin. Cold synchronization and reorg handling verify this transition. The transition release includes old and new matrix material; verified retirement certificates enable later builds to omit the old matrices.

3. Tokenomics

V2 replaces State-triggered reward reductions with an explicit height schedule. The exact gross block subsidy starts at 16 NOID at the fork and follows:

16 → 11.30 → 8 → 5.65 → 4 → 2.83 → 2 → 1.41 → 1 NOID

Each step lasts 1,051,200 blocks from activation, nominally one year at 30 seconds per block. After eight reductions, the permanent tail is 1 NOID per block. Existing balances are unchanged.

Early mainnet operation showed why the original monetary clock needed to change: live State occupancy measures outstanding outputs, and can stay low while payments and contract interactions reuse slots. Tying reductions solely to State expansion left their timing unpredictable. Height now gives issuance a visible schedule.

State efficiency still has an economic incentive. Occupancy raises the fee for net-new live slots, and that growth component is burned. Consolidation frees slots and avoids the growth charge.

Other improvements since v1.1.0

• State processing: cache authenticated segments within a bounded memory budget and update only changed Merkle paths, reducing repeated hashing and copying across segments during synchronization, block application and proving.
• Proof implementation: reuse matrix-column weights, reduce temporary folding buffers and cache exact previously verified carried matrix claims. This reduces repeated verification work, including on Small blocks following a Large block.
• RPC and receipt recovery: expose retained block bodies after recursive suffix synchronization even when a block has no standalone proof bundle. Block RPCs and startup receipt recovery use those retained bodies.
• Wallet reliability and storage: preserve reviewed calls and successor terms across submission failures; store identical proof bytes once across local contract receipts while keeping exported receipts self-contained.
• Mining tools: align template refresh with fork timing, report active capacity, add configurable external-worker RPC timeouts with a 180-second default, and support finite mining runs through --blocks.
• Proof accounting: correct response-cost accounting and extend the source-linked analysis to v2, historical ancestry and matrix retirement.
• Documentation: update the README and English, Russian and Chinese documentation, including the contract core, API, GUI walkthroughs, receipts, network economics and an archive of earlier protocol profiles.

Parano1d v1.1.0

This is a mandatory protocol update. The new rules activate at block 95,125. Upgrade before that height.

Upgrade

v1.1.0 keeps the existing genesis, live State, wallet secrets, transaction format, exported receipts, recursive relation and authenticated matrices. Update nodes, GUI wallets and block-producing pool nodes before the activation height. Old nodes remain compatible before activation but cannot validate blocks under the activated rules. No restart at the activation height itself is needed for an already updated, running node.

Protocol activation

• Correct the ASERT fractional polynomial while preserving the exact legacy difficulty calculation for earlier blocks. The block target stays 20 seconds.
• Encode HistoryStep terminals with canonical shared Merkle paths. Repeated authentication nodes are stored and transmitted once, then the original paths are reconstructed for the unchanged verifier and recursive relation.
• Apply a 1,100,000-byte terminal limit to the canonical compressed encoding. Expanded decoding is also bounded. Before activation the legacy encoding and 1,048,576-byte cap remain in force. The block body has its own limit.
• Allow eligible producers to use B255. Every mining session starts with B25 without a startup benchmark. Its first completed B25 preparation permits B255 for that session only if prepare_time × 4 <= 20 seconds. Ordinary fee-ordered selection determines the actual class within that capacity.
• Apply the existing dynamic mempool fee floor only under real local load. Count or retained bytes reaching 80% enables it; both falling strictly below 50%, or an empty pool, reset it. Consensus State-growth fees are unchanged.

Fixes and implementation improvements

• Complete initial synchronization after an exact, verified commit of the selected tip, without waiting for a redundant probe of a moving chain. Retire disconnected manifest candidates and preserve valid source failover.
• Continue partial mempool recovery in bounded batches. Preserve the 128-intent, 16 MiB response limits, one consumption-paced recovery lane, finite scans and 30-second per-peer request spacing. No idle seed polling is introduced.
• Coalesce byte-identical gossip/direct deliveries without bypassing admission or suppressing required forwarding. Preserve selected bootstrap identity across authenticated reconnects and release replacement seed transports after a stable ordinary-peer handoff.
• Replan Auto fees after a local fee rejection before admission, within the existing three-attempt limit. Explicit fees and accepted transactions are not silently increased. Evict intents that no longer meet the current consensus State-growth minimum, releasing their local reservations.
• Prefer not to place coinbase or mandatory fund payouts in output slots of other pending local transactions. A bounded same-segment search falls back to the previous valid choice, so pending reservations cannot block mining or mandatory payouts. Amounts and recipients are unchanged.
• Reduce repeated hashing, proof-leaf work, state copying and wallet I/O. Add conditional walletUtxoSnapshot polling with legacy RPC fallback. Preserve GUI address labels locally and append wallet artifact changes instead of rewriting entire collections.
• Remove obsolete raw-segment Compact FRI opening code. Refine the wallet Johnson-bound analysis and update the Poseidon2b cryptanalysis audit without changing W65/H133, matrices or cryptographic protocol parameters.