Zensia — Satoshi's Vision for Today's Bitcoin

Zensia — Satoshi's Vision for Today's Bitcoin
A peer-to-peer electronic cash system designed from first principles to address the centralizing pressures observed in mature Proof-of-Work networks.
Learn More
Join the community
Executive Summary
Zensia is a peer-to-peer electronic cash system designed from first principles to address the centralizing pressures observed in mature Proof-of-Work networks. The protocol is a direct response to the divergence of contemporary Bitcoin from its original mission, where high fees have relegated its base layer to a settlement network and specialized hardware has supplanted its egalitarian security model. Zensia restores the "one-CPU-one-vote" principle and establishes a credibly fixed, minimalist rule set resistant to capture and ossification.
The design is predicated on a small set of robust and non-negotiable rules. First, it employs RandomX, a CPU-oriented Proof-of-Work algorithm, to bind network security to the globally distributed and highly competitive market for general-purpose CPUs, thereby neutralizing the centralizing advantage of specialized ASIC hardware. Second, it implements ASERT, a rapid per-block difficulty adjustment algorithm, to ensure stable block production and immediate responsiveness to hashrate fluctuations, preventing the timing attacks and fee market instability that plague systems with slow-moving adjustments. Third, a novel coinbase smoothing rule is introduced at the protocol level, distributing the block subsidy among the last N=144 block finders. This mechanism drastically reduces payout variance, making solo and small-pool mining economically viable and directly weakening the primary incentive for miners to congregate in dominant, centralized pools.
Zensia is specified as a complete system, committed to a fair, pre-mine-free launch and the subsequent ossification of its core parameters. This approach ensures credible neutrality and long-term predictability, removing the need for contentious governance or upgrade rituals. By re-aligning economic incentives with the goal of decentralization, Zensia presents a rigorous, falsifiable implementation of Bitcoin's founding principles under modern technological and adversarial conditions.
At-a-Glance Parameter Table
Problem Statement & Critique Map
The foundational premise of Bitcoin was to create a "peer-to-peer electronic cash system" that allows payments "without going through a financial institution". However, over fifteen years of evolution, the protocol's incentive structure has been outmaneuvered by emergent economies of scale. This has led to a system that, while immensely valuable and secure, exhibits centralizing tendencies that conflict with its original purpose. The development of Application-Specific Integrated Circuits (ASICs) concentrated manufacturing power, leading to a hardware monoculture. The high capital cost and payout variance of ASIC mining then created an inexorable pull toward mining pools, which re-introduce trusted intermediaries responsible for block construction and censorship. Concurrently, the use of blockspace for non-financial data has driven transaction fees to levels that preclude its use as cash, pushing users toward custodial solutions like ETFs, which reconstruct the very financial intermediaries Bitcoin was meant to obsolete.
These issues are not independent failures but interconnected symptoms of an incentive cascade. Specialized hardware incentivizes pooling; pooling centralizes block construction; high fees incentivize custodial ownership. Zensia is not a series of patches for these symptoms but a unified redesign of the underlying incentives to favor a decentralized equilibrium. The following table maps the specific critiques of Bitcoin as of 2025 to Zensia's direct, protocol-level responses.
Hardware Centralization
Bitcoin's SHA-256 algorithm has led to specialized ASIC manufacturing controlled by a few entities, undermining "one-CPU-one-vote".
Zensia's Response: RandomX Proof-of-Work algorithm optimized for general-purpose CPUs, binding security to the global CPU market.
Mining Pool Dominance
High variance in solo mining rewards drives miners to centralized pools that control transaction selection and censorship.
Zensia's Response: Protocol-level coinbase smoothing distributes rewards among the last 144 block finders, making solo mining economically viable.
Fee Market Volatility
Slow difficulty adjustments create unstable block times and unpredictable fee markets, harming user experience.
Zensia's Response: ASERT difficulty adjustment algorithm provides per-block responsiveness to hashrate changes.
Zensia Consensus Specification (Normative)
This section provides a complete, unambiguous, and normative definition of the Zensia consensus rules, sufficient for an independent team to create a compatible client implementation.
The Zensia protocol is built on three core pillars that work in concert to create a decentralized equilibrium:
CPU-Friendly Mining
RandomX algorithm ensures anyone with a general-purpose computer can participate in network security
Responsive Difficulty
ASERT provides immediate, per-block difficulty adjustments to maintain stable block times
Reward Distribution
Coinbase smoothing distributes rewards among recent miners, reducing variance and pool incentives
Proof-of-Work: RandomX
Justification: The protocol must resist centralization at the hardware level. Bitcoin's use of SHA-256 has led to an industry dominated by a few specialized ASIC manufacturers, undermining the "one-CPU-one-vote" ideal. Zensia adopts RandomX, a Proof-of-Work algorithm optimized for general-purpose CPUs. This choice binds the security of the network to the vast, globally distributed, and highly competitive commodity CPU manufacturing ecosystem (e.g., Intel, AMD, ARM). This market is far too deep and liquid to be captured by a single entity, thus restoring a practical and resilient foundation for decentralized hashpower production.
Specification:
Algorithm
RandomX, as specified in the reference implementation documentation. Modes: Miners MUST use "fast mode" (requiring ~2 GB RAM). Verifying nodes SHOULD use "light mode" (requiring ~256 MB RAM) for efficiency.
Key (K)
The K parameter for the RandomX virtual machine is derived from blockchain data to prevent miner-selectable optimizations. For a block at height h, the key K is the block hash of the block at height h_{key} = h - (h \pmod{2048}). This provides a new, unpredictable key approximately every 2048 blocks (~14 days).
Input (H)
The input to the RandomX hash function is the 80-byte block header, serialized as standard.
Attacker Cost Model
An attack on Zensia is not a hardware manufacturing problem but a capital expenditure problem. An attacker cannot secretly design a more efficient ASIC. Instead, they must acquire a dominant share of the global CPU hashrate, likely by renting massive capacity from cloud providers or assembling large botnets. While possible, this shifts the attack surface to a more transparent and far larger market, significantly raising the practical cost and logistical complexity of a sustained 51% attack compared to specialized hardware environments.
Block and Transaction Parameters
Target Block Interval
600 seconds (10 minutes). This is a conservative choice with a long history of stability and provides ample time for global block propagation.
Subsidy Schedule
The initial block subsidy is 50 ZNS. The subsidy halves every 210,000 blocks (~4 years), creating a total capped supply of 21,000,000 ZNS. This monetary policy is chosen for its predictability and historical precedent.
Max Block Weight
4,000,000 Weight Units (WU). This maintains compatibility with existing tooling and analysis while providing a hard cap on block size to combat the chain bloat identified as a key risk.
Script and Signature Policy
The protocol adopts Bitcoin's script system as it existed prior to the activation of Segregated Witness and Taproot. Valid script types include P2PK, P2PKH, P2SH, and standard OP_CHECKMULTISIG. Witness programs (SegWit v0, v1+) and Taproot scripts are explicitly non-standard and invalid.
This is a deliberate "negative design choice." The analysis of modern Bitcoin shows that the unintended consequence of advanced scripting features was their use for large-scale, non-financial data storage, which congests the network and prices out monetary users. By reverting to a simpler, more constrained script system, Zensia removes the primary vector for this activity at the consensus level, reinforcing its role as an electronic cash system without resorting to complex, policy-based transaction filtering.
Difficulty Adjustment Algorithm: ASERT (aserti3-2d)
Justification: Bitcoin's 2016-block difficulty adjustment period is too slow to react to modern hashrate volatility, creating opportunities for manipulation and causing instability in block times and fees. A responsive, per-block algorithm is required. Zensia adopts ASERT (Absolutely Scheduled Exponentially Rising Targets), specifically the aserti3-2d variant. ASERT is chosen for its stability, mathematical elegance, and "history-agnostic" property. Unlike moving-average-based algorithms, ASERT's calculation depends only on the current block's data and a fixed "anchor block" (the genesis block), making it computationally simple and highly resistant to timestamp manipulation attacks.
Mathematical Specification:
The ideal target calculation is an exponential function based on the deviation from a perfect schedule. The target for the block at height h+1 is calculated as:

\text{next\_target} = \text{anchor\_target} \times 2^{\frac{(\text{time\_delta} - \text{ideal\_block\_time} \times \text{height\_delta})}{\text{halflife}}}
Where:
anchor_target is the initial target from the genesis block.
anchor_timestamp is the timestamp of the genesis block.
time_delta is (timestamp_h - anchor_timestamp).
height_delta is (height_h - 0).
ideal_block_time is a constant, 600 seconds.
halflife (τ) is a constant, 172,800 seconds (2 days), controlling the responsiveness.
Implementation (Integer Arithmetic):
To avoid floating-point indeterminacy across different platforms, the calculation must be performed using fixed-point integer arithmetic. The 2^x term is calculated using a precise cubic polynomial approximation. The following pseudocode outlines the required logic.
Coinbase Reward Smoothing (Pay-Last-N-Finders)
Justification: The primary economic driver of mining pool centralization is the need to reduce the high variance of block rewards, especially for smaller miners. The "Pay-Last-N-Finders" rule directly addresses this by building a variance reduction mechanism into the consensus protocol itself. By distributing each block subsidy among the finders of the last N blocks, the system effectively creates a global, trustless, and fee-free PPLNS (Pay Per Last N Shares) payout scheme. This makes solo and small-pool mining far more economically predictable and sustainable, directly weakening the gravitational pull of large, centralized pools.
Formal Definition:
Let h be the current block height being produced. The smoothing window is a constant N = 144 blocks. The number of coinbase recipients, k, is defined as k = min(h + 1, N). The total block subsidy S (initially 50 ZNS) plus any transaction fees F is the total reward R = S + F. This total reward R is divided into k equal shares: share = R / k. Any remainder from integer division is added to the share of the current block's finder (the output at index 0). The recipients are the miners of blocks h (the current finder), h-1, h-2,..., h - k + 1. A recipient is identified by the scriptPubKey of the first output (index 0) of the coinbase transaction in their respective historical block.
Coinbase Transaction Layout:
The coinbase transaction for block h MUST have exactly one input and k outputs.
Output 0: Pays share + (R \pmod k) to the scriptPubKey chosen by the miner of block h.
Output 1: Pays share to the scriptPubKey from output 0 of the coinbase transaction in block h-1.
Output i (for 1 <= i < k): Pays share to the scriptPubKey from output 0 of the coinbase transaction in block h-i.
Size Overhead:
A standard P2PKH output consists of an 8-byte value, a 1-byte scriptPubKey length, and a 25-byte script, totaling 34 bytes.
For N=144, a mature chain will have k=144 outputs. The additional 143 outputs add 143 \times 34 \text{ bytes} = 4862 \text{ bytes} (~4.8 kB) to the coinbase transaction. For a larger N=720, the overhead would be 719 \times 34 \text{ bytes} = 24446 \text{ bytes} (~24.4 kB). This overhead is non-trivial but is considered an acceptable cost for the significant decentralization benefit it provides. It is non-witness data and consumes block weight accordingly.
Consensus Validation Rules
A node must perform the following checks in order to validate a new block. A block is valid if and only if all checks pass.
1
Block Structure
The block must be syntactically correct and its total weight must not exceed 4,000,000 WU.
2
Proof-of-Work
The RandomX hash of the 80-byte block header must be less than or equal to the target value specified in the header.
3
Timestamp
The block's timestamp must be greater than the Median Time Past (MTP) of the previous 11 blocks and must not be more than 2 hours in the future relative to the node's network-adjusted time.
4
Coinbase Transaction
The block must contain exactly one coinbase transaction as its first transaction. This transaction must have k = min(height + 1, N) outputs and the sum of its output values must not exceed the correct block subsidy plus transaction fees. The recipient scripts for outputs 1 to k-1 must correctly match the historical coinbase scripts.
5
Transaction Validity
All other transactions in the block must be valid according to all consensus rules (e.g., script validation, no double-spends, correct signatures).
6
Chain Work
The valid chain is the one with the most accumulated Proof-of-Work. No hard reorg limit is specified; finality is probabilistic and determined by the economic weight of the chain.
Incentive & Security Analysis
This section analyzes the Zensia protocol through a game-theoretic lens, evaluating its robustness against known attack vectors and assessing the intended and unintended consequences of its incentive structure.
Zensia's design creates a fundamentally different incentive landscape compared to traditional Proof-of-Work cryptocurrencies. By addressing the root causes of centralization at the protocol level, it aims to establish a more robust and decentralized equilibrium state.
The following sections examine how these mechanisms interact with miner behavior and analyze their effectiveness against common attack vectors.
Variance Reduction vs. Pool Incentives
The single most powerful incentive for miners to join pools is to reduce the variance of their income. A solo miner with a small fraction of the network's hashrate may go months or years without finding a block, an economically untenable position. The "Pay-Last-N-Finders" rule directly attacks this problem at the protocol level. For a miner controlling a fraction p of the total hashrate, the probability of finding any given block is p. In a winner-take-all system, their income is a series of large, infrequent jackpots. Under the N-rule, their expected income over an N-block window is p \times N \times (R/N) = p \times R. While the long-term expected value is the same, the distribution of payments is dramatically different. Instead of one large payment, the miner receives many small payments from blocks found by others, smoothing their revenue stream into a predictable flow that is directly proportional to their hashrate contribution.
Pool Commoditization Effect
This mechanism effectively commoditizes the primary service offered by mining pools. By providing variance smoothing as a native, trustless feature of the protocol, Zensia fundamentally weakens the economic moat of large pools. Pools can no longer justify high fees solely for this service. While they may still compete by offering secondary services like optimized block template construction or private transaction relay, their core gravitational pull is significantly diminished.
This should foster a more decentralized and competitive ecosystem of smaller pools and make solo mining a rational choice for a much wider range of participants, directly countering the oligopoly observed in modern Bitcoin.
144
Block Smoothing Window
The number of previous blocks whose miners receive a portion of each new block reward
99.3%
Variance Reduction
Theoretical reduction in income variance for a miner with 1% of network hashrate
0%
Protocol Fee
Unlike pools which charge fees, Zensia's protocol-level smoothing is completely free
Analysis of Known Attack Vectors
Selfish Mining
The N-rule and ASERT combine to create a hostile environment for selfish mining attacks. In a standard selfish mining attack, the attacker privately mines a chain and later releases it to orphan the public chain, claiming all rewards from their secret blocks.
In Zensia, this strategy is less profitable for two reasons. First, when the selfish miner releases their chain, the rewards from their withheld blocks are not captured entirely by them; they are split with the miners of the honest blocks that were mined in the N-1 period before their secret chain was revealed. This forces the attacker to share profits with the very miners they are attacking.
Second, while the attacker is withholding blocks, the honest chain's block times will increase. ASERT will respond by rapidly lowering the difficulty on the honest chain, making it harder for the attacker to maintain or extend their private chain's lead. This dual-pronged defense significantly raises the difficulty and lowers the profitability of selfish mining.
Timestamp Manipulation and Time-Warp Attacks
ASERT is exceptionally robust against timestamp manipulation. Because its difficulty calculation is based on the elapsed time and height difference relative to a fixed historical anchor (the genesis block), it establishes an absolute, ideal schedule for block production.
Miners cannot collectively gain by reporting false timestamps, as the difficulty will always correct back toward this absolute schedule. This prevents the "difficulty drift" and feedback oscillations that can be exploited in DAAs that rely on a moving window of recent block times.
Miner Extractable Value (MEV)
Zensia's minimalist, non-Turing-complete script system inherently limits the surface area for complex MEV, such as the front-running and sandwich attacks common on smart contract platforms.
The primary forms of MEV will be transaction ordering within a block and fee-based priority (transaction censorship). These are fundamental properties of any public mempool, and Zensia makes no attempt to solve them with complex in-protocol rules, adhering to a minimalist design philosophy.
DAA Responsiveness and Hashrate Stability
ASERT's design provides a predictable and stable response to hashrate shocks. The halflife parameter of 2 days means that for any deviation from the target block time, the algorithm will correct the difficulty by 50% of the error over a 2-day period.
Hashrate Increase
If network hashrate doubles, block times will temporarily shorten. ASERT will begin increasing the difficulty with every block, smoothly guiding the block interval back towards 10 minutes. This prevents the "hour-one ripping" problem at launch, where early miners can extract a disproportionate number of coins before the first difficulty adjustment.
Hashrate Decrease
(e.g., 51% Attack or Minority Chain scenario): If 50% of the hashrate suddenly leaves the network, block times will temporarily double to 20 minutes. ASERT will immediately begin lowering the difficulty, ensuring the chain remains usable and does not enter a "death spiral" where blocks become too difficult to find. This rapid response is critical for the survival of a minority chain after a contentious fork and mitigates the profitability of "coin-hopping" attacks where mercenary hashrate switches between chains to exploit slow difficulty adjustments.
Network & Operations
This section defines the practical, operational aspects of running Zensia software, ensuring a clear path for miners and node operators to participate in the network.
Download Software
Obtain the reference implementation with built-in solo miner
Verify Integrity
Check binary hashes against published values
Run Node
Connect to the network and begin validating transactions
Start Mining
Contribute CPU power directly to secure the network
Reference Implementation: Node and Solo Miner
A core component of the Zensia project is the provision of a well-maintained, open-source reference implementation. To fully realize the "one-CPU-one-vote" principle, this implementation must include a capable and easy-to-use solo miner.
Reference Solo Miner
A reference CPU miner, based on the high-performance XMRig codebase, will be included directly in the main client repository. It will be configured by default for solo mining against a local node. The configuration will be managed via a simple config.json file with sane defaults for thread count, huge pages, and NUMA node affinity, which are critical for RandomX performance. This lowers the technical barrier for individuals to contribute hashrate directly to the network and participate in transaction selection, rather than ceding this role to a pool operator.
Default Node Configuration
The reference node will use conservative network parameters similar to Bitcoin Core, including default mempool size, transaction relay policies, and peer connection limits, to ensure stability and resilience against DoS attacks.
Reproducible Builds
The project will provide a deterministic build system using a containerized environment (e.g., Docker). This allows any third party to compile the source code and verify that the resulting binaries are identical to the officially released ones, ensuring no hidden code has been introduced.
Technical Requirements
The reference implementation is designed to run on commodity hardware:
CPU: Any x86-64 processor with AES-NI support
RAM: 4GB minimum (8GB recommended)
Storage: 50GB for full blockchain storage
Operating Systems: Linux, Windows, macOS
P2P Network Bootstrapping
A new node must be able to discover its first peers to join the network. A purely decentralized discovery mechanism, such as random IP address probing, is often too slow and unreliable. Zensia adopts a pragmatic, multi-layered approach similar to Bitcoin's to ensure robust and efficient bootstrapping.
DNS Seeds
The primary mechanism is a hardcoded list of several DNS hostnames. When a new node starts, it queries these DNS seeds, which return a list of IP addresses of reliable, active nodes in the network. Using multiple independent seed operators mitigates the risk of a single point of failure or censorship.
Hardcoded Seed Nodes
As a fallback, the client will contain a static, hardcoded list of IP addresses for long-running, stable nodes. This list is used only if all DNS seeds are unreachable, providing a last-resort connection path.
Peer Address Caching
Once connected to its first peer, a node will use the standard getaddr and addr P2P messages to exchange lists of known active peers. The node will maintain a local database of these peers. For all subsequent restarts, the node will first attempt to connect to peers from its local cache, making the network self-sustaining and reducing reliance on the initial seed nodes.
This pragmatic compromise uses a minimal set of trusted introduction points to solve the cold-start problem, after which the network relies on its own decentralized peer discovery.
Fair Launch Specification
The launch process must be transparent, unpredictable, and devoid of any insider advantage to establish credible neutrality from genesis.
Fair Launch Specification
The launch process must be transparent, unpredictable, and devoid of any insider advantage to establish credible neutrality from genesis.
Pre-Launch Protocol
Code Freeze and Publication
A specific git commit hash representing the final 1.0.0 source code will be declared several weeks prior to the potential launch window.
Reproducible Build Verification
The project will publish the source code, deterministic build scripts (Dockerfiles), and the corresponding SHA256 hashes of the binaries for all major platforms (Linux x86-64, Windows x86-64, macOS ARM64/x86-64). A period of public review will allow independent developers to verify that the published binaries are a direct result of the published source code.
Launch Trigger and Genesis Block
The network will begin at a future, unpredictable moment, determined by a publicly verifiable external event. This prevents any single party from knowing the exact start time and gaining a mining advantage.
Trigger Specification
The Zensia network will launch upon the discovery of the first Bitcoin block that meets a specific, arbitrary condition.
Example Trigger: "The Zensia network will activate at the moment of the first Bitcoin block at or after Bitcoin block height H=900,000 whose block hash, when interpreted as a 256-bit little-endian integer, is divisible by the prime number 1009."
Monitoring Script
A simple, auditable script (e.g., Python, Bash) will be provided. This script will monitor a public Bitcoin block explorer API or a local Bitcoin node for the trigger condition. Upon detection, it will automatically construct the genesis block and start the Zensia node and reference solo miner.
Genesis Block Parameters
Timestamp: The timestamp of the triggering Bitcoin block.
Parent Hash: The hash of the triggering Bitcoin block.
Subsidy: 50 ZNS.
Coinbase Output: The 50 ZNS subsidy will be paid to an unspendable OP_RETURN script, effectively burning the first block reward to demonstrate fairness.
Difficulty: The nBits field will be set to the maximum possible target (lowest difficulty).
Post-Launch Guidance & Disclosures
First-Day Guidance: Simple, clear instructions will be provided for early participants: "1. Download the software and verify its hash. 2. Run the provided auto-start script. 3. Your computer will begin solo mining when the trigger condition is met. No pool is required."
Legal and Ethical Disclosure: A formal statement will be included in the project's README and website: "Zensia is a free, open-source software experiment. There has been no pre-mine, founder's reward, Initial Coin Offering (ICO), or sale of any kind. The software is provided 'as is' without warranty. There is no central entity, company, or foundation responsible for this network. All coins are issued exclusively via the Proof-of-Work algorithm described in this document and are available to anyone willing to contribute computational work."
Comparative Appendix: Zensia vs. Bitcoin (2025)
Implementation Appendix: Test Vectors
To ensure compatibility between different client implementations, the following test vectors must be used for validation of critical consensus logic. The vectors will be provided in JSON format in the reference implementation repository.
ASERT Difficulty Calculation
A set of JSON fixtures will be provided, each containing an array of block header states. Each state will include height, timestamp, and the nBits (target) of the previous block. The fixture will specify the correct nBits for the next block. The test suite must cover:
The calculation for the block immediately after genesis.
A sequence of blocks with timestamps exactly 600 seconds apart, demonstrating target stability.
A sequence with a sudden, large positive time jump, showing a rapid increase in difficulty (decrease in target).
A sequence with a sudden, large negative time jump (within MTP limits), showing a rapid decrease in difficulty (increase in target).
A long sequence of blocks with slightly faster-than-target times, demonstrating the smooth, exponential correction back to the target.
Coinbase Smoothing Rule
A set of JSON fixtures will describe a chain state and the expected coinbase transaction for the next block. Each fixture will contain:
The current block height h.
The total subsidy S and fees F.
An array of the scriptPubKeys from the coinbase transactions of blocks h-1 down to h - min(h, N-1).
The expected serialized coinbase transaction for block h, including:
The correct number of outputs, k = min(h+1, N).
The correctly calculated share value for each output.
The correct distribution of the remainder to the first output.
The correct scriptPubKey for each of the k outputs.
Test cases must include h=0 (one output), h < N (e.g., h=10, k=11 outputs), and h >= N (k=N outputs).
Genesis Block
The full, serialized genesis block will be provided in hexadecimal format, along with its corresponding block hash. This serves as the ultimate root of the chain and the anchor for the ASERT algorithm.