1.1 Crisis

The financial system faces fundamental challenges rooted in mandatory sovereign credit currency and fractional reserve banking. These create cycles of economic crises that disproportionately harm the vulnerable while enriching large capital holders.

The solution requires a currency system with "hard constraints" - one that no institution can easily debase, reducing trust costs while maintaining economic stability.

1.2 The Future of Currency

Currency has evolved through five stages: universal value objects, rare stable objects, trust-based certificates, sovereign credit symbols, and now electronic network systems based on "recognized rules" with "individual credit" as supplements.

Bitcoin's emergence in 2008 provided the foundational direction, but more is needed: a system that achieves scale while maintaining trustlessness and transparency.

1.3 What Do We Need

The blockchain solution is not about decentralization for its own sake, but about trustlessness - reducing structural trust risks. We need hard constraints and minimized trust, a currency system that no one can easily debase without consuming resources to do so.

2.1 Technical Theories

Electronic currency has a fatal flaw: unlimited replication at zero cost. Solution: assign unique numbers to currency units with an announced upper limit, use signatures to indicate ownership. This solves counterfeiting but creates the double-spending problem.

2.2 Principle of Self-Interest

Cooperation systems relying solely on honesty are unsustainable. Bitcoin solved this by combining ledger recording with currency issuance, providing incentives for everyone to maintain honest records through Proof-of-Work.

2.3 Shortcomings

Bitcoin's limitations: (1) High energy consumption in mining, and (2) Low transaction throughput (~7 TPS). The paper argues energy consumption is not truly a drawback - it introduces hard constraints through market forces. However, low throughput is a real limitation for global commerce.

3.1 Fundamental Assumptions

Punitive mechanisms can enforce honesty even in systems with inherent risks. The public ledger should function as arbitration and final clearing, not record every transaction.

3.2 Main Principles

Real-time, no-loss microtransactions through bi-directional settlement channels. Funds settle synchronously across channel chains - all parties receive/disburse simultaneously, preventing any "intermediate state" where one side gains while another loses.

3.3 Technical Implementation

Process flow: (1) Joint channels lock funds, (2) Off-chain settlements between parties, (3) Channel routing finds payment paths through network, (4) Sequential signing ensures atomicity - either all succeed or all fail.

3.4 Channel Closure

When both parties agree on final balance, they sign a closure transaction and broadcast to main network for confirmation. Funds return to both parties immediately after confirmation.

3.5 Arbitration Protection

Unilateral channel termination is possible but penalized: the initiator's account locks for a period (e.g., 1 week). If dishonest parties submit outdated balances, the honest party can seize all funds including the locked balance.

3.6 Balancing Payments

Channel offset settlements allow merchant-node and personal channels to rebalance atomically, improving fund utilization without frequent main network interactions.

3.7 Decentralization

Two key features prevent excessive centralization: (1) Immediate settlement prevents node failures from locking funds, (2) Single-transaction-at-a-time locking deters hub nodes by making large fund lockups unprofitable.

3.8 Fast Channels

For trusted long-term relationships, delayed reconciliation (hourly) increases throughput from ~10 TPS to 2000+ TPS without settlement risks.

3.9 Fund Calculation

With 100 units locked in channels supporting 3 TPS: Daily volume = 4.3M units (best case 8.6M). Fund utilization: 86.4M times daily. With fees at 1/100M: Net annual return ~315%.

4.1 Basic Data Structures

Three-level hierarchy: Blocks >> Transactions >> Actions. Simple, human-readable, compact format for both machine and human verification. Transactions contain: actions (operations), signs (individual signatures), multisigns (multi-signature data).

4.2 Multisignature Addresses

Support for 2/2, 1/2, 2/3, 1/3 configurations and more. Multiple private keys manage single addresses. Up to 200 private keys can manage one multisignature address. No single secret key; security distributed across key holders.

4.3 Hierarchical Equity Control Accounts

Support modern corporate structures with beneficiary and voting rights. Features: jointmanagement, dynamic key changes, changeable voting ratios, different rights per equity, fund protection in extreme cases (collective key loss scenarios).

4.4 Multi-Signature Transactions

Atomic operations requiring multiple signatures. If one action fails, all fail. Prevents fraud in equity investments and complex financial operations where both parties must simultaneously commit.

4.5 Payment Categories

Support for diverse payment types: self-pay, payment requests, delegated payments, and equity operations. Different contract structures for different business scenarios.

4.6 Signature Stripping

Signatures occupy significant block space. After sufficient confirmation (1+ year), signature data can be stripped from historical transactions while maintaining core transaction data, reducing blockchain size dramatically.

4.7 Transaction Fees

Fees collected by miners create economic incentive for participation. Fluctuate based on network congestion. Can be zero or negative (subsidies). Fee payer's signature separated from other participants.

4.8 Field Formats

Standardized formats for transaction data using scientific notation for monetary amounts, ensuring consistency and efficiency across the network.

5.1 Competitive Bookkeeping Rewards

Miners compete through Proof-of-Work (X16RS hash algorithm) to earn right to append blocks. Ensures honest record-keeping without central authority. X16RS resists ASIC dominance through 16-random algorithm combination.

5.2 Public Ledger Fees

Transaction fees paid by users go to miners who maintain the network. Creates immediate economic incentive for participation and network security.

5.3 Channel Service Fees

Nodes operating channels collect small fees for transfer services. Incentivizes network participation and stable service provision from distributed nodes.

5.4 Channel Interest

0.1% compound interest every 34 days (~11% annually) on locked funds in channels. Rewards capital provisioning and liquidity services. Makes channel operation economically attractive.

5.5 Block Diamond

Separate mining process producing "Block Diamonds" - dynamic currency supply units. Adjusts based on network demand and usage. Total possible: 16^6 = 16.7M diamonds. Mining time: ~25 min per diamond. Maximum daily production: ~58 diamonds.

5.6 Data Services

Long-term incentive structures for maintaining historical data and providing archived ledger services to network participants.

6.1 Total Supply and Growth

Phase 1 (Years 0-0.95): Fibonacci sequence: 1, 1, 2, 3, 5, 8 coins per block
Phase 2 (Years 1-10): Decreasing: 8, 5, 3, 2, 1, 1 coins per block
Phase 3 (Year 10+): Stable 1 coin per block indefinitely
Total Supply: 22,000,000 coins
Long-term Annual Issuance: ~0.48% (asymptotically decreasing)

6.2 One-Way Transfer Compatible with Bitcoin

Bitcoin can be permanently transferred to Hacash through "black hole address" mechanism. Equivalent Hacash coins issued with lock-up periods (20 years for first coin, 5 years for second/third, 2.5 years for fourth-seventh) to mitigate volatility and suppress speculation.

6.3 Units and Symbols

Standardized unit definitions and symbols for clarity in transactions and accounting.

6.4 Prohibition of Artificial Monetary Policies

Currency issuance follows algorithmic rules, not discretionary policy. Prevents institutional manipulation and wealth redistribution through inflation.

7.1 Anonymity

Balance privacy with auditability. Without privacy, currency fungibility suffers - different coins have different values based on transaction history.

7.2 Payment Mixing

Fixed-amount payment mixing: groups collectively transfer same amounts, making precise payer-payee matching impossible. More participants = better privacy protection.

7.3 Forward Deferred Payment

Intermediary receives transaction from payer, creates temporary hashed address. Payer funds locked with time-delay release. Intermediary claims after original transaction confirms. If unclaimed after timeout (1 year), funds return to payer.

7.4 Encrypted Settlement Network

Channel transaction data encrypted from broader network visibility while maintaining auditability for authorized parties.

7.5 Channel Reversal

Technical capability to reverse transaction direction in channels for privacy purposes.

8.1 Channel Chain Delayed Signature Attack

Attackers initiate massive small payments to delay signatures and reach lock timeouts. Mitigation: track payer address, cumulative amounts, lock times. Calculate utilization scores - abnormally low scores restrict payment frequency.

8.2 Low-Cost Channel Fraud

Risk when one party doesn't monitor channels. Mitigations: (1) Risk deposit per account across multiple channels as fraud insurance, (2) Nodes disclose channel lists and identities, (3) Breach terminates all channel cooperation.

8.3 Channel Credit Currency Creation and Default

Fast channels allow temporary negative balances during delayed reconciliation. Risks limited by: micro-payment amount restrictions and frequent reconciliation requirements.

8.4 Centralization of Hash Power, 51% Attacks, and Guerrilla Mining

X16RS Algorithm: 16-random hash combination resists ASIC and FPGA dominance.
Historical Witness Path Selection: Wealthy accounts sign block broadcasts creating "witness value." Attacker's secret chain cannot surpass transparent fork's witness value, making attacks fail.
Fork Selection by Vote: Users with locked channel funds gain voting rights. During attacks, voting transactions accumulate. When threshold reached, miners switch to honest chain.

8.5 Extreme Price Fluctuations

Addressed through proper currency issuance design, algorithmic supply adjustments via Block Diamonds, and Bitcoin integration lock-up periods that suppress speculative behavior.

9.1 Simplicity and Intuitiveness

Human-readable, understandable protocols. No smart contracts with hidden vulnerabilities. Users without technical background must understand contract terms. Financial systems cannot tolerate software vulnerabilities.

9.2 Compact Data and Efficient Execution

Balance generality with performance. Save every byte and CPU cycle where possible. Efficiency in core critical parts takes priority over module elegance.

9.3 Controllable Scale of Public Ledger Data

Block size and frequency must remain compatible with mid-range consumer hardware. Prevents centralization of ledger data among well-funded institutions. Maintains true decentralization capability.

9.4 Signature Stripping and Data Compression

After ~1 year, blocks cannot rollback. Strip signature data (significant portion of block) and compress transaction data. Create state snapshots monthly/yearly for historical reference without signature bloat.

Hacash represents a complete cryptocurrency system designed specifically for large-scale real-world payments and instant settlement. By combining channel chain technology with Bitcoin-style security, hierarchical transaction support, and carefully designed economic incentives, it achieves:

• Infinite Scalability: Through channel chains, not network bloat
• Hard Constraints: Algorithmic rules, no policy discretion
• Trustlessness: Punitive mechanisms ensure honesty
• Privacy: Balancing anonymity with auditability
• Enterprise Ready: Complex transaction types for corporate structures
• Self-Sustaining: Multiple incentive mechanisms ensure participation

The system addresses cryptocurrency's fundamental challenge: creating a currency that is simultaneously secure, scalable, and trustless - suitable for the next generation of global commerce.

Three-level Hierarchy: Blocks >> Transactions >> Actions

Block Structure:

• Block Header: Version, previous hash, merkle root, timestamp, difficulty, nonce
• Transactions: Ordered list of transaction data

Transaction Structure:

• Actions: Payment instructions and operations
• Signs: Individual signatures
• Multisigns: Multi-signature data for joint accounts

Designed for compact storage while maintaining human readability for auditability. Signature stripping supported for historical data after sufficient confirmation time.

X16RS Hash Algorithm

Evolution of X16R combining 16 different hashing algorithms randomly. Each step randomizes the algorithm selection, preventing ASIC/FPGA efficiency gains. Maintains broader mining participation.

Block Reward Calculation

Phase 1 (0-0.95 years): Fibonacci: 1, 1, 2, 3, 5, 8
Phase 2 (1-10 years): Decreasing: 8, 5, 3, 2, 1, 1
Phase 3 (10+ years): Stable: 1 per block
Total Supply: 22,000,000 coins
Annual Issuance (Long-term): ~0.48% (decreasing asymptotically)

Block Diamond Production

Formula: hash256((genesis_block_hash || prev_diamond_block_hash) + belong_user_public_key + nonce_number)
Compression: 4-bit to character mapping (0WTYUIAHXVMEKBSZN)
Valid Diamond Criteria: First 10+ characters as "0", no trailing zeros
Total Possible: 16^6 = 16,777,216
Maximum Daily: ~58 diamonds (~21,000/year)