 |
August 02, 2026, 04:22:49 PM |
|
Paqus Core Final Design Note
This document records the final design direction for the current Paqus Core metadata layer. In this context, "final design" means the core blockchain model is considered stable and no significant consensus-model changes are planned for the items described here.
Chain Metadata
Paqus Core keeps consensus-critical metadata compact, deterministic, and easy to verify from canonical bytes. The chain is driven by block height, canonical serialized block weight, authenticated account state, and proof-of-work commitments.
The design intentionally removes human wall-clock assumptions from core consensus. Nodes may still use local time for networking, mempool policy, logging, and operations, but block validity does not depend on a human timestamp field.
Newly Implemented in Paqus Core
AccountStatement
AccountStatement is the canonical sender-side state anchor for an account. Every outgoing account action must extend the signer's current active statement. This keeps signer-owned actions sequential and prevents stale actions from being replayed after the account has moved forward.
An AccountStatement commits to:
- account address;
- account balance;
- account authorization state;
- account credits;
- authorized transaction hash;
- authorization proof hash;
- previous AccountStatement.
Incoming transfers update the receiver balance and credits, but they do not advance the receiver AccountStatement. Only self-authorized outgoing account actions advance that account's statement.
When a statement is produced at height H, it becomes eligible as `last_state` after the account-statement activation delay. The current delay is one block, so a statement produced at height H can be used from height H + 1.
WBDA
Weight-Based Difficulty Adjustment (WBDA) is the Paqus difficulty and subsidy adjustment algorithm. It is weight based, not time based. Every completed epoch of 2,048 blocks is measured by canonical serialized block weight, then the result is applied to the next epoch.
The utilization formula is:
utilization = average block weight / 5 MiB its means total epoch block weight / 10 GiB
-Below 30% | Diff Target +1 | Subsidy +1 |
-30% trought 70% | Diff Target unchanged | Subsidy unchanged |
-Above 70% | Diff Target -1 | Subsidy -1 |
The 30% and 70% boundaries are included in the unchanged zone. Difficulty is clamped so it cannot fall below `1`. The subsidy is clamped to `1..=20 XPQ`.
Base Reward : 10 XPQ
The first epoch is blocks `1..=2,048`. Its measured utilization determines the difficulty and subsidy beginning at block `2,049`.
Dual Authorization
Dual Authorization binds each spendable account to an ordered owner/auth public-key pair. Both signatures are required for outgoing account actions.
The first outgoing transaction from an account carries both public keys. After successful validation, the ledger stores them in AccountAuthorization. Subsequent transactions carry only the two signatures. The node resolves the stored public keys from authenticated account state.
Receiving XPQ does not require prior authorization registration. An address can receive funds before its authorization keys are present in state; those keys are registered when the account spends for the first time.
Removed from Paqus Core
Paqus Core no longer uses a human timestamp field as a consensus input for block time. Consensus progression is height based, and WBDA adjusts from block weight instead of elapsed wall-clock time.
This keeps the core chain independent from clock drift, local timezone handling, and timestamp manipulation as a difficulty signal.
Core Fee Field
Paqus Core no longer has a dedicated consensus fee field. Fees are represented outside the core transaction format as node, relay, mempool, and miner policy.
If a transaction wants to pay the block producer directly, it can use a normal transfer output to the block miner target. That output is ordinary consensus state, not a separate fee field.
QCash File Naming
QCash file names are also updated to make the denomination and asset type easier to read at a glance.
Previous format:
Denomination_ShortID.XPQ
New format:
DenominationXPQ_ShortID.QCash
Example:
10XPQ_ab12cd34.QCash
The new format keeps the denomination attached to `XPQ`, keeps the shortidentifier separated by an underscore, and uses the `.QCash` extension to make the file type explicit.
Design Boundary
- AccountStatement orders signer-owned account actions.
- WBDA controls epoch difficulty and block subsidy from canonical block weight.
- Dual Authorization requires owner/auth approval for outgoing actions.
- QCash files use the `DenominationXPQ_ShortID.QCash` naming format.
- Human block time and a dedicated core fee field are not part of the core consensus model.
|
