POSITRONIC

Executive Summary

Positronic (ASF) is the world's first Layer-1 blockchain that embeds artificial intelligence directly into its consensus mechanism. Unlike projects that merely deploy AI as decentralized applications on top of existing chains, ASF integrates four specialized neural network models into the block validation pipeline itself, creating a novel consensus paradigm called Proof of Neural Consensus (PoNC).

The Positronic blockchain combines the security guarantees of Delegated Proof of Stake (DPoS) with real-time AI transaction scoring, enabling the network to detect and quarantine fraudulent transactions, MEV attacks, smart contract exploits, and economic instabilities before they are committed to the chain. This proactive defense model represents a fundamental departure from traditional blockchains that rely solely on cryptographic and economic incentives.

Key Innovations

Key Metrics

Core Architecture

The Positronic blockchain is built as an account-based state machine (similar to Ethereum) with SHA-512 cryptographic hashing, providing 512-bit security output compared to Bitcoin's SHA-256. The architecture prioritizes modularity, allowing each subsystem (AI validation, consensus, token management, identity) to operate independently while integrating seamlessly through the core blockchain orchestrator.

2.1 SHA-512 Hashing

ASF employs SHA-512 as its primary hashing algorithm, providing 256-bit collision resistance and 512-bit preimage resistance. This choice offers several advantages over the SHA-256 used by Bitcoin and most other blockchains:

2.2 Block Structure

Each block in the ASF chain contains a header with metadata and a list of validated transactions:

2.3 Transaction Types

2.4 Architecture Overview

2.5 State Model

ASF uses an account-based state model where each account maintains a balance, nonce, optional contract code, storage, and a TRUST reputation score. The global state is organized as a Merkle Patricia Trie, enabling efficient state proofs for light clients and cross-chain verification.

Proof of Neural Consensus (PoNC)

Proof of Neural Consensus is ASF's signature innovation: a consensus mechanism that augments traditional DPoS with a multi-model AI ensemble that scores every transaction for risk before it enters the block. This creates a proactive defense layer that can detect and quarantine malicious activity in real-time, something no existing blockchain offers at the consensus level.

3.1 The Four AI Models

The PoNC ensemble consists of four specialized neural network models, each targeting a different class of threats:

3.2 Tiered Scoring System

To optimize performance without sacrificing security, PoNC uses a tiered scoring approach. Not every transaction needs all four models:

3.3 Decision Thresholds

The weighted ensemble produces a composite risk score, immediately quantized to integer basis points (0–10,000). Classification uses integer comparison with a ±50bp dead zone for cross-platform determinism (see §3.6):

3.4 Dynamic Adjustments

After quantization to integer basis points, the score is adjusted using integer-only arithmetic (_apply_adjustments_q) to maintain cross-platform determinism:

• Reputation Bonus: score_q = score_q * 80 // 100 for trusted senders (reputation > 9,000bp, nonce > 50)
• New Account Penalty: score_q += 500 for accounts with nonce = 0
• Large Value Scrutiny: score_q += 1000 when sender_balance_ratio > 8,000bp

3.5 Safety Mechanisms

3.6 Cold Start Calibration

New networks face a cold start problem: freshly trained AI models lack sufficient data to distinguish unusual-but-legitimate transactions from actual anomalies, causing excessive false positives. The ColdStartManager solves this with a three-phase graduated threshold system based on block height:

False positive reports are rate-limited (10 per hour per reporter) to prevent manipulation. Phase B thresholds interpolate linearly so the network gradually transitions from permissive to strict without sudden behavioral changes.

3.7 Deterministic Scoring

A critical requirement for consensus is that all validator nodes must produce identical AI classification decisions for the same transaction, regardless of hardware (Intel, AMD, ARM). Two problems must be solved: random seed consistency and floating-point divergence.

3.7.1 Seed Determinism

All random operations within the neural models are seeded identically via DeterministicContext(seed=AI_CONSENSUS_SEED). This ensures model weight initialization and stochastic operations produce the same values on every node.

3.7.2 Integer Basis-Point Scoring (IEEE 754 Mitigation)

IEEE 754 floating-point arithmetic is not deterministic across CPU architectures. The same multiply-accumulate sequence can produce different results on Intel (x87/SSE) vs AMD vs ARM due to different rounding modes, FMA fusion, and intermediate precision. For example, one node might compute a score of 0.8499 (ACCEPT) while another computes 0.8501 (QUARANTINE) — a consensus fork.

To eliminate this, ASF converts all AI scores to integer basis points (0–10,000) immediately after the ensemble weighted average, and all subsequent comparisons use integer arithmetic only:

Quantization formula: score_q = min(int(float_score * 10000 + 0.5), 10000)

3.7.3 Dead Zone Classification

Even after quantization, two nodes might produce scores that differ by 1 basis point due to intermediate float rounding before quantization. The dead zone of ±50 basis points around each threshold ensures these borderline cases are always classified conservatively:

DPoS Consensus Engine

After transactions pass the AI validation gate, they enter the DPoS consensus layer where a set of elected validators propose and finalize blocks. ASF's DPoS implementation features Byzantine Fault Tolerant (BFT) finality, slot-based block production, and a comprehensive slashing mechanism to discourage misbehavior.

4.1 Consensus Parameters

4.2 Core Components

4.3 Validator Lifecycle

Validators go through a defined lifecycle: Register (32 ASF minimum stake) → Activated (all eligible validators join the active set) → Propose & Attest (21 producers selected by weighted-random per epoch; all active validators attest on blocks for pro-rata rewards) → Miss/Double-Sign (penalties triggered) → Jailed (temporarily excluded) → Unjail (re-enter election after timeout).

4.4 Epoch Transitions

At each epoch boundary, the system derives a new epoch seed from the previous block hash, runs a validator election that activates ALL eligible validators (no top-N cap), selects 21 block producers via stake-weighted random, processes pending unjail requests, and resets the finality tracker. Epoch-0 uses a deterministic genesis seed.

4.5 Slashing & Penalties

4.6 Fee Distribution (Consensus v2 — Three-Layer)

Bitcoin-Style Tokenomics

ASF adopts a Bitcoin-inspired economic model with a fixed total supply, mining-based distribution, predictable halving schedule, and zero founder pre-mine. This design ensures fair distribution while creating sustainable deflationary pressure through fee burning.

5.1 Supply Distribution

5.2 Block Reward & Halving Schedule

The initial block reward is 24 ASF, halving approximately once per year (~2.6 million blocks at 12-second intervals). The 12-second block time (aligned with Ethereum) creates a controlled emission schedule that makes ASF significantly scarcer than fast-block chains, driving long-term value through supply discipline.

5.3 Fee Burn Mechanism

20% of all transaction fees are permanently burned (calculated as the remainder after other shares to prevent rounding dust loss), reducing the circulating supply over time. This creates sustained deflationary pressure, especially as network usage grows. The remaining fees are distributed to block producers (25%), attesters pro-rata by stake (25%), node operators / community pool (20%), and AI treasury (10%).

TRUST — Soulbound Reputation Token

TRUST is ASF's non-transferable reputation token, permanently bound to each address. Unlike transferable tokens, TRUST cannot be bought, sold, or moved between accounts. It must be earned through consistent positive behavior on the network and can be lost through malicious activity. This creates a genuine meritocratic system where reputation directly impacts mining rewards.

6.1 Trust Levels

6.2 Score Rewards

6.3 Score Penalties

6.4 Inactivity Decay

To prevent abandoned accounts from retaining high trust scores indefinitely, a decay mechanism reduces the score by 1 point per 30 days of inactivity. The score floor is 0 and cannot go negative. This ensures that only actively participating members maintain their reputation benefits.

For example, a LEGEND-level miner with a 2.0x multiplier earns 48 ASF per block in Year 1 (instead of the standard 24 ASF), creating a strong incentive for long-term positive participation.

Token Standards: PRC-20 & PRC-721

ASF provides native token standards that allow anyone to create fungible tokens (PRC-20) and non-fungible tokens (PRC-721) directly on the blockchain. These standards are modeled after Ethereum's ERC-20 and ERC-721 but include ASF-specific enhancements such as AI verification for NFTs.

7.1 PRC-20: Fungible Token Standard

PRC-20 is the standard for creating custom fungible tokens on the Positronic blockchain. Each token contract tracks balances, allowances, and supply metrics.

State Tracking: balances (per address), allowances (owner-spender pairs), total_supply, decimals (configurable), holder_count, transfer_count, total_burned.

7.2 PRC-721: Non-Fungible Token Standard

PRC-721 extends the traditional NFT standard with two unique features: dynamic metadata (NFTs whose properties can evolve over time) and AI verification (each NFT receives an authenticity score from the AI validation system).

AI Verification

Each PRC-721 NFT includes an ai_verified boolean and an ai_score (0.0 to 1.0). The AI system analyzes NFT metadata and associated content to detect plagiarism, verify originality, and assess quality. This provides buyers with an objective authenticity measure directly on-chain.

Dynamic NFTs

When the dynamic flag is set during minting, the NFT's metadata can be updated over time. This enables evolving game characters, real-time data NFTs, and progressive artwork that changes based on on-chain events.

7.3 Token Registry

All created tokens and NFT collections are registered in the global TokenRegistry, providing a unified catalog for discovery, search, and verification. Token creation incurs a fee that is burned, preventing spam.

Gasless Transactions (Paymaster System)

One of the biggest barriers to blockchain adoption is the requirement for new users to acquire native tokens before they can perform any action. ASF solves this with its Paymaster System, which allows sponsors (such as game developers, dApp operators, or enterprises) to pay transaction fees on behalf of their users.

8.1 How It Works

A Paymaster is an on-chain entity that pre-deposits ASF coins into a sponsorship pool. When a user submits a transaction that qualifies for sponsorship, the gas fee is deducted from the Paymaster's balance instead of the user's account. This enables zero-friction onboarding for new users.

8.2 PaymasterConfig

8.3 Anti-Spam Protection

Additional protections include per-transaction gas limits, daily aggregate limits, and the ability for Paymasters to restrict sponsorship to specific contract addresses.

8.4 24-Hour Reset

The daily_used counter automatically resets to zero after 86,400 seconds (24 hours), ensuring that the daily budget refreshes for the next day.

Smart Wallet & Account Abstraction

ASF's Smart Wallet system implements account abstraction, providing users with programmable wallets that support temporary session keys, social recovery, daily spending limits, and emergency locking — all without requiring users to manage seed phrases.

9.1 Session Keys

Session keys are temporary cryptographic keys with limited permissions and automatic expiration. They are ideal for gaming sessions where a user wants to authorize game actions without approving each transaction individually.

9.2 Social Recovery

Instead of seed phrases, Smart Wallets use a guardian-based recovery system. Users designate trusted addresses as recovery guardians and set a threshold (default: 2). If access is lost, the required number of guardians can collectively authorize wallet recovery to a new key.

9.3 Spending Limits

Each Smart Wallet can set a daily_spending_limit that restricts the total value that can be sent within a 24-hour period. The can_spend(amount) method validates against this limit before authorizing any transaction. Setting the limit to 0 disables the restriction.

9.4 Emergency Lock

The is_locked flag provides an emergency freeze mechanism. When activated, no outgoing transactions are permitted regardless of session keys or guardian approvals. Only the primary owner key can unlock the wallet.

Game Bridge Platform

Positronic does not host games directly. Instead, it provides a Game Bridge SDK that allows external games — mobile, PC, console, or web — to connect to the ASF blockchain. Game developers integrate the SDK to enable Play-to-Mine rewards, on-chain assets (NFTs), and gasless transactions for their players.

10.1 Architecture

The game runs on the developer's own infrastructure. Only reward claims, asset ownership, and session proofs are recorded on-chain, keeping the blockchain lean while giving players real ownership of their in-game achievements.

10.2 SDK Features

10.3 Integration Flow

1. Register Game: Developer registers their game on-chain (one-time fee: 100 ASF) and receives a Game ID and API key
2. Create Game Economy: Game creates custom PRC-20 tokens and NFT collections via the Game Token Bridge
3. Start Session: Player connects wallet; SDK creates a signed game session
4. Play: Game runs on developer's servers; session key authorizes actions without per-TX approval
5. Mint Items: Game mints NFTs to players for achievements, loot drops, or crafted items
6. Submit Results: At session end, the game submits a score proof to the blockchain
7. Claim Rewards: AI validates the session; if approved, ASF and custom token rewards are distributed to the player

10.4 Reward Calculation

Each game defines its own base_reward and difficulty_factor. The player's TRUST score determines the multiplier (1.0x to 2.0x). ASF rewards draw from the 200M ASF Play-to-Mine allocation. A 5% emission tax is applied to daily Play-to-Mine emissions and directed to the team wallet to fund ongoing development. Games can also distribute their own custom PRC-20 tokens as additional rewards. All rewards are subject to AI anti-cheat verification and 4-layer emission control (global → per-game → per-player → per-session).

10.5 Available SDKs

10.6 Game Token Bridge

The Game Token Bridge is an orchestration layer that allows registered games to create and manage their own on-chain economies:

AI Agents On-Chain

ASF provides a native framework for registering and managing autonomous AI agents on the blockchain. Each agent has a unique identity, defined permissions, and a trust score that evolves based on its performance history.

11.1 Agent Types

11.2 Agent Identity & Trust

Each agent receives a unique agent_id derived from SHA-256 hashing. The agent's trust score starts at 0 and adjusts based on actions: +1 per successful action, -5 per failure. The success rate is calculated as executed / (executed + failed).

11.3 Permission System

Agents operate within a defined permission set that specifies which actions they are allowed to perform. Owners can pause, resume, or ban their agents at any time. The action history (last 50 actions) is logged with timestamps, data hashes, and success/failure status for full auditability.

11.4 Agent Status Lifecycle

ACTIVE (0) → can execute actions  |  PAUSED (1) → temporarily suspended  |  BANNED (2) → permanently disabled

Privacy & Commitment System

ASF's privacy system uses hash commitments and Schnorr sigma protocols to allow users to prove statements about their data without revealing the underlying information. This is critical for financial privacy, identity verification, and confidential evidence handling in legal proceedings.

12.1 Supported Proof Types

12.2 Cryptographic Protocol

ASF uses a SHA-512-based commitment scheme (simplified for efficiency):

12.3 ZKProof Structure

12.4 Confidential Evidence

The hash commitment system integrates with ASF's forensic evidence system through ConfidentialEvidence, which combines encrypted evidence data with a hash commitment proof of authenticity. Only authorized viewers (e.g., judges, investigators) can decrypt the content, while the proof ensures that the evidence has not been tampered with.

Cross-Chain Bridge

ASF's cross-chain bridge enables interoperability with major blockchain networks through hash anchoring — posting ASF state hashes onto external chains for additional security guarantees, and verifying proofs from external chains on ASF.

Implementation Note: The bridge currently provides a cross-chain abstraction layer with hash anchoring interfaces. Live connectivity to Ethereum, Bitcoin, Polygon, and BSC networks requires external relayer deployment (not yet operational).

13.1 Supported Chains

13.2 Hash Anchoring

Critical ASF data (evidence hashes, state roots, checkpoint hashes) can be anchored on external chains. The AnchoredHash structure tracks the anchor lifecycle:

13.3 External Proof Verification

Proofs submitted from external chains are verified on ASF through the submit_external_proof and verify_external_proof functions, enabling trustless cross-chain state verification.

DePIN — Decentralized Physical Infrastructure

DePIN (Decentralized Physical Infrastructure Networks) allows real-world hardware devices to register on the Positronic blockchain, submit data, and earn rewards for their contributions. This bridges the gap between the physical world and the blockchain.

14.1 Device Types

14.2 Device Lifecycle

REGISTERED (0) → ACTIVE (1) → OFFLINE (2) or BANNED (3)

Devices must send a heartbeat() at least every 10 minutes to remain active. The heartbeat also transitions newly registered devices to ACTIVE status.

14.3 Data Submission & Rewards

Active devices call submit_data(data_hash) to submit evidence of their work. Each valid submission earns 1 reward unit. The DePIN registry tracks cumulative stats per device: uptime_hours, data_submitted, and rewards_earned.

14.4 Location Tracking

Each device registers with geographic coordinates (latitude/longitude), enabling location-based queries and regional infrastructure mapping.

Post-Quantum Cryptography

Quantum computers pose an existential threat to the elliptic curve cryptography (Ed25519, ECDSA) that secures nearly all blockchains today. ASF proactively addresses this through a dual-signature system that pairs traditional Ed25519 signatures with quantum-resistant CRYSTALS-Dilithium2 signatures.

15.1 The Quantum Threat

Shor's algorithm, when run on a sufficiently large quantum computer, can break the discrete logarithm problem underlying Ed25519 and ECDSA in polynomial time. While large-scale quantum computers do not yet exist, the blockchain's immutable record means that transactions signed today could be forged by quantum computers in the future ("harvest now, decrypt later" attacks).

15.2 CRYSTALS-Dilithium2

ASF implements real CRYSTALS-Dilithium2 (ML-DSA-44, FIPS 204) via the pqcrypto library, which wraps the NIST-standardized reference C implementation. The lattice-based signature scheme provides NIST Level 2 (~128-bit) post-quantum security using Module-LWE / Module-SIS hardness assumptions.

15.3 Dual Signature System

The DualSignature structure carries both an Ed25519 signature and a post-quantum signature. The is_quantum_safe property returns true when the PQ signature is present.

15.4 Key Management

The PostQuantumManager maintains a registry of PQ public keys mapped to addresses. Functions include: register_pq_key, has_pq_key, get_pq_key, and verify_dual_signature.

Decentralized Identity (DID)

ASF implements a W3C-compatible Decentralized Identifier (DID) system that gives users self-sovereign identity on the blockchain. Users can create identities, issue verifiable credentials, and manage their digital presence without relying on centralized identity providers.

16.1 DID Format

Each DID is derived from the user's blockchain address and follows the W3C DID specification.

16.2 Verifiable Credentials

16.3 DID Operations

16.4 Use Cases

• Academic Credentials: Universities issue verifiable diplomas on-chain
• Professional Certification: Industry bodies issue skill certifications
• KYC without Data Exposure: Prove identity verification without revealing personal data (combined with hash commitments)
• Cross-Platform Identity: Single DID works across multiple ASF dApps

Neural Immune System

Beyond the AI Validation Gate, ASF operates a Neural Immune System that provides continuous, real-time threat monitoring and automated response. This system acts as the blockchain's immune defense, identifying and neutralizing threats before they can cause damage.

17.1 Threat Detection

The Neural Immune System monitors for multiple categories of threats: Sybil attacks (fake identity proliferation), DDoS patterns (transaction flooding), spam transactions, double-spend attempts, and economic manipulation.

17.2 AI Rank System

Neural Validator Nodes (NVN) earn military-style ranks based on their performance through the AIRankManager. Higher ranks receive greater fee shares and voting power in AI model governance decisions.

17.3 Quarantine Pool & Appeal

Transactions flagged by the AI gate (integer score 8,500–9,499 bp; see §3.6) are placed in the quarantine pool. Two release paths exist:

1. Automatic re-evaluation — every QUARANTINE_REVIEW_INTERVAL (100 blocks) the AI gate rescores each quarantined TX. If the score drops below 8,500 bp, the TX is released into the mempool.
2. Governance appeal — any staker can vote on a quarantined TX via vote_appeal(tx_hash, vote_for, voter_id). A supermajority (>2:1 for/against) releases the TX immediately.

Transactions not released within MAX_QUARANTINE_TIME (1,000 blocks) expire and are discarded. Users may file an appeal with a deposit of IMMUNE_APPEAL_DEPOSIT (10 ASF), refunded on successful appeal.

17.4 Automated Response

When persistent threats are detected, the system can automatically ban offending addresses, increase AI scrutiny levels for related transactions, alert the validator set, and trigger emergency governance proposals if the threat is systemic.

17.5 Token Governance (DAO)

Before any new token can be deployed on the Positronic network, it must pass through a dual-gate governance process: first an AI risk assessment, then a council vote. This prevents scam tokens, rug-pulls, and low-quality projects from launching on the network.

Governance Flow:

17.6 AI Model Governance

Changes to the AI validation models (weights, thresholds, versions) are governed through an on-chain supermajority vote. This includes a kill switch for emergency situations and treasury spending control.

Model Governance Proposal Types:

Compliance & Forensic Evidence System

Positronic includes a built-in compliance and forensic evidence system purpose-built for legal admissibility. Every on-chain event can be collected, verified, cryptographically signed, anchored to immutable storage, and exported as a court-ready document — making Positronic the first blockchain designed from the ground up to produce evidence packages that meet the evidentiary standards of modern legal proceedings.

18.1 Wallet Registry & Traceability

The WalletRegistry provides AI-verified address tracking for compliance. Unlike traditional KYC systems, wallet verification is performed by the network’s AI engine, which analyzes on-chain behavior, source type, and historical patterns to assign a trust score. Users retain pseudonymous usage by default; identity association is opt-in and requires user consent.

Wallet Status Lifecycle

Wallet Trust Tiers

Each registered wallet is assigned a trust tier based on AI analysis of on-chain history, transaction volume, and behavior patterns. Tiers determine transaction limits and access levels:

The AI trust score is a continuous value from 0.0 to 1.0, computed from wallet age, transaction patterns, flagged count, and source type (wallet app, exchange, contract, etc.). Tier promotion and demotion are automatic based on this score.

18.2 Forensic Reporter

The ForensicReporter generates detailed, structured forensic reports for legal and regulatory use. Each report collects on-chain evidence items, computes findings, and produces a tamper-proof document sealed with Ed25519 digital signatures and SHA-512 cryptographic hashing.

Report Types

Evidence Collection

Each piece of forensic evidence (ForensicEvidence) contains the following verified fields:

Digital Signatures & Tamper Detection

Every forensic report is cryptographically sealed using a three-step integrity process:

The SHA-512 hash covers all report fields (report ID, type, creation timestamp, subject address, evidence list, findings, and risk score). The Ed25519 signature binds the hash to the signer’s public key. Anyone can verify the report signature using the signer’s public key without needing access to the original data — providing non-repudiation and tamper detection suitable for court proceedings.

18.3 Court Evidence Pipeline

The CourtReportGenerator transforms forensic reports into complete, court-ready evidence packages. The pipeline follows a five-stage process designed for legal admissibility:

Evidence Exhibits

Each EvidenceExhibit in a court report includes the forensic evidence, a Merkle proof linking the evidence to the block’s state root, and block finality data proving the block has been finalized by the consensus mechanism. This provides cryptographic proof that the evidence existed on-chain at a specific point in time and has not been altered since.

Chain of Custody

Every court report includes a digital Chain of Custody record — an immutable, timestamped log that tracks every action taken on the evidence from creation to delivery:

18.4 Confidential Evidence

When combined with the Hash Commitment Privacy system, evidence can be encrypted and stored with hash commitments of authenticity. The ConfidentialEvidence mechanism stores:

Only authorized viewers (judges, investigators, regulators) can access the decrypted content using their private keys. The hash commitment ensures that anyone — including unauthorized parties — can verify that the evidence has not been altered, without seeing the evidence itself. This enables privacy-preserving legal compliance: sensitive data remains encrypted while its integrity is publicly verifiable.

18.5 Legal Admissibility & Compliance

Positronic’s evidence system is designed to meet the evidentiary requirements of multiple legal frameworks. The following integrity chain ensures that every piece of evidence can withstand legal scrutiny:

GDPR & Privacy Compliance

Blockchain immutability and GDPR’s right to erasure present a fundamental tension. Positronic resolves this through the Confidential Evidence mechanism: personal data is never stored in plaintext on-chain. Instead, encrypted evidence can have its decryption keys revoked, making the on-chain data effectively inaccessible while preserving the integrity proof. This satisfies the “right to be forgotten” without compromising the evidence chain.

Law Enforcement & Regulatory Access

Authorized entities (law enforcement, regulators, court-appointed investigators) can request evidence through the RPC API endpoints described in Section 18.6. All access is logged in the chain of custody, and confidential evidence requires the requester’s public key to be in the authorized viewers list — ensuring that access control is cryptographically enforced rather than policy-based.

18.6 RPC API for Legal Access

Positronic exposes five dedicated JSON-RPC endpoints for forensic and legal operations. These endpoints enable authorized tools and interfaces to interact with the compliance system programmatically:

GOD CHAIN — Phase 17

Phase 17 represents the culmination of the ASF protocol design: a mega-phase that combines four enhancement pillars into a single cohesive upgrade. Named GOD CHAIN, this phase embodies the project's core philosophy: no transaction is ever rejected because of infrastructure failures, no user is ever unhappy. Every new feature follows a fail-open design — if any component fails, the old behavior continues silently.

19.1 Pillar 1: Transaction Pipeline Optimization

EIP-1559 Adaptive Gas Oracle

ASF now implements an Ethereum-style EIP-1559 gas pricing mechanism with bounded adaptive base fees. The base fee adjusts up or down by a maximum of 12.5% per block based on utilization. The fee is clamped to a range of [1, 1000] to prevent extreme pricing.

Transaction Priority Lanes

Transactions are automatically classified into four priority lanes for optimal ordering within blocks:

Parallel Transaction Validation

Transaction validation (signature verification, nonce checking, balance checking) is now parallelized using a thread pool of 4 workers. Execution remains sequential to preserve state consistency. If the thread pool fails, validation falls back to the original sequential approach.

19.2 Pillar 2: Network Resilience

Compact Block Relay

Block propagation is optimized by transmitting only the block header and ordered transaction hashes. Receiving peers reconstruct the full block from their local mempool. System transactions (rewards, AI treasury) are prefilled since peers won't have them. If reconstruction fails, the peer requests a full block.

Multi-Dimensional Peer Scoring

Each peer is evaluated across five weighted dimensions to optimize connection quality:

Scores gradually decay toward neutral (50) over time with a decay rate of 0.99, preventing permanently biased scoring from temporary network issues.

Network Partition Detection

The partition detector monitors three signals: block arrival timeout (3× BLOCK_TIME without new blocks), peer count drops (below 3 peers), and chain height divergence (peers report heights 10+ blocks ahead). The detector transitions through four states:

Prometheus Monitoring

Every node exposes a GET /metrics endpoint on the RPC port (default 8545) in Prometheus text exposition format. A background MetricsCollector polls blockchain height, peer count, mempool size, AI scoring stats, and consensus participation every 5 seconds. Pre-defined gauges and counters include:

19.3 Pillar 3: Smart Contract VM v2

New Precompiled Contracts

Three new native precompiles extend the VM's capabilities:

VM Simulation

The VM.simulate() method enables state-free execution for eth_call and eth_estimateGas. It takes a state snapshot before execution, runs the transaction fully, and always reverts the state afterward. This allows accurate gas estimation and dry-run queries without any side effects.

Revert Reason Decoder

When smart contracts revert, the decoder extracts human-readable error messages from the revert data. Supported formats include Error(string) (Solidity custom errors), Panic(uint256) (11 mapped panic codes), and raw hex fallback for unknown error selectors.

19.4 Pillar 4: HD Wallet & Enhanced CLI

Hierarchical Deterministic Wallet (BIP-32/44)

ASF now supports hierarchical deterministic key derivation using HMAC-SHA512 for deterministic address generation from a single mnemonic seed phrase:

Transaction History & Address Book

Two new wallet modules provide user-friendly account management:

• Transaction History: Tracks all transactions by watched addresses, categorized by type (transfer, contract, game reward) and direction (sent/received). Includes balance-over-time series for portfolio tracking.
• Address Book: Named address management with search, tagging, and name-to-address resolution. Persists to JSON. resolve("alice") returns the stored address, while resolve("0x1234...") passes through unchanged.

10 New RPC Methods

RPC API Reference

ASF exposes 213 RPC methods organized across 30+ categories. The API is fully compatible with Ethereum's JSON-RPC specification for standard operations, while providing extensive Positronic-specific methods for advanced features.

19.1 Method Categories

19.2 Connection Details

19.3 Example Calls

Get AI Score for a Transaction:

// Request
curl -X POST https://rpc.positronic-ai.network \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "positronic_getAIScore",
    "params": ["0xa1b2c3d4e5f6..."],
    "id": 1
  }'

// Response
{
  "jsonrpc": "2.0",
  "id": 1,
  "result": {
    "tx_hash": "0xa1b2c3d4e5f6...",
    "composite_score": 0.23,
    "verdict": "ACCEPT",
    "models": {
      "TAD": 0.18, "MSAD": 0.31,
      "SCRA": 0.22, "ESG": 0.19
    }
  }
}

Get TRUST Score:

// Request
curl -X POST https://rpc.positronic-ai.network \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "positronic_getTrustScore",
    "params": ["0x742d35Cc6634..."],
    "id": 2
  }'

// Response
{
  "jsonrpc": "2.0",
  "id": 2,
  "result": {
    "address": "0x742d35Cc6634...",
    "score": 2450,
    "level": "VETERAN",
    "multiplier": 1.6
  }
}

Get Balance (Ethereum-compatible):

// Request
curl -X POST https://rpc.positronic-ai.network \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "eth_getBalance",
    "params": ["0x742d35Cc6634...", "latest"],
    "id": 3
  }'

// Response
{
  "jsonrpc": "2.0",
  "id": 3,
  "result": "0x56bc75e2d63100000"
}

Register DePIN Device:

// Request
curl -X POST https://rpc.positronic-ai.network \
  -H "Content-Type: application/json" \
  -d '{
    "jsonrpc": "2.0",
    "method": "positronic_registerDevice",
    "params": [{
      "owner": "0x742d35Cc6634...",
      "device_type": "gpu",
      "capabilities": {"tflops": 12.5},
      "location": "US-WEST"
    }],
    "id": 4
  }'

// Response
{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "device_id": "DEV-1708612345-0001",
    "status": "REGISTERED",
    "rewards_eligible": true
  }
}

Competitor Comparison

The following table compares ASF's capabilities against leading blockchain platforms:

v0.2.0: Advanced Phases (19–24)

Version 0.2.0 upgrades six placeholder modules into fully functional, cryptographically sound implementations. Post-quantum signatures use the pqcrypto library wrapping the NIST-standardized reference C implementation of FIPS 204 (ML-DSA-44).

22.1 Phase 19: Real Post-Quantum Cryptography

Implements real CRYSTALS-Dilithium2 (ML-DSA-44, FIPS 204) via the pqcrypto library. The lattice-based signature scheme provides NIST Level 2 (~128-bit) post-quantum security using Module-LWE / Module-SIS hardness assumptions. Hybrid dual signatures combine Ed25519 (classical) + ML-DSA-44 (post-quantum) so that both must be broken to forge a transaction.

22.2 Phase 20: Cross-Chain Bridge v2 (Lock/Mint)

Implements actual token transfers between ASF and external chains via a lock-on-source / mint-on-target pattern with relayer quorum and fraud proofs.

22.3 Phase 21: AI Explainability (XAI)

Every AI validation decision now produces a human-readable explanation containing per-model contribution breakdowns, top risk signals, and cross-model attention correlations. Explanations are bounded to 500 characters.

Example output: Risk 0.42 (ACCEPTED). TAD:0.35(30%), MSAD:0.55(25%), SCRA:0.30(25%), ESG:0.50(20%). Top signal: MSAD(MEV) at 0.55.

22.4 Phase 22: DePIN Economic Layer

Replaces the flat “1 unit per submission” reward with a three-dimensional scoring formula multiplied by device-type tiers.

Daily cap: 100 reward units per device to prevent gaming.

22.5 Phase 23: Autonomous AI Agents

Upgrades agents from record-keeping to enforced execution with three layers of protection:

• Permission whitelist: Actions must be in the agent’s permission list (empty = unrestricted)
• Rate limiting: Sliding window, max 60 actions/hour (configurable)
• Spending caps: Per-action and daily limits with date-based reset

Autonomous tick() executes per-block actions for eligible agents (minimum trust score: 10). Banned agents cannot be resumed (permanent kill switch).

22.6 Phase 24: Enhanced Hash Commitment Privacy

Upgrades the hash commitment system with proper Schnorr-like response verification. The commitment now embeds a verification tag (64 bytes = 32 core + 32 tag) that binds the response cryptographically. Modular arithmetic over the Curve25519 field prime (2²⁵⁵ − 19).

22.7 Phase 32: Deep AI Integration

Phase 32 extends the AI subsystem with four modules that deepen model coordination and observability: (1) Online Learning Extension for continuous improvement in production, (2) Model Communication Bus for cross-model signal sharing, (3) Causal XAI v2 for permutation-based explainability, and (4) Concept Drift Detection for monitoring score distribution shifts. Full details in Chapter 31 (Neural Self-Preservation).

22.8 Test Coverage

Version 0.2.0 and subsequent phases add 525+ new tests, bringing the total to 6,848 passing tests across 173 test files.

Emergency Control System

The Positronic Emergency Control System provides protocol-level safeguards for responding to security incidents, coordinating network upgrades, and gracefully handling critical failures. It operates as a state machine governing block production and transaction acceptance, ensuring the network can be paused, halted, or upgraded without data loss or chain corruption.

23.1 Network State Machine

The network operates in one of five states, each controlling which operations are permitted. Transitions are authenticated via Ed25519 signatures and recorded in an immutable event log.

23.2 Authorization Levels

Different state transitions require different levels of authorization, ensuring that more dangerous operations require stronger consensus.

23.3 Multi-Signature Manager (3-of-5)

Critical operations such as emergency halts, rollbacks, and key rotations require 3-of-5 Ed25519 multi-signature authorization. Five keys are registered at genesis; any three must sign a canonical message to authorize an action.

The multi-sig lifecycle follows four stages:

23.4 Upgrade Manager

Protocol upgrades are managed through a feature flag system with block-based activation and automatic rollback. This allows the network to evolve without hard forks causing chain splits.

When an upgrade is scheduled, feature flags are registered in a SCHEDULED state. At the activation block, features transition to ACTIVE. If the error rate exceeds 5% within 100 blocks, the system recommends auto-rollback, deactivating all features in the upgrade.

23.5 Health Monitor Integration

The Emergency Controller integrates with the network's HealthMonitor for automatic state transitions. When health metrics deteriorate, the system automatically degrades or pauses without human intervention:

23.6 RPC Emergency Methods

23.7 Test Coverage

The Emergency Control System includes 57 tests covering all state transitions, multi-sig authorization, upgrade lifecycle, node integration, and RPC methods. Combined with the existing test suite, the project maintains 6,848 passing tests.

Production Hardening & Mainnet Readiness

Before a blockchain can launch on mainnet, the protocol must withstand adversarial chain reorganizations, protect data at rest, handle schema evolution gracefully, and rate-limit public endpoints against abuse. This chapter documents the four production-hardening subsystems added in Phase 26, along with the comprehensive test suites that verify their correctness under stress.

24.1 Chain Reorganization Engine (ForkManager)

The ForkManager detects and resolves competing chain tips without manual intervention. When a peer broadcasts a block whose parent is not the current tip, the ForkManager stores it as a ForkCandidate object and evaluates whether the alternative chain is longer. If so, the node rewinds to the common ancestor and replays the longer chain — provided the reorg does not cross a finalized height.

Fork detection is integrated directly into blockchain.add_block(), executing before block validation so that invalid blocks on competing forks are never persisted. Old fork candidates are automatically pruned once their height falls below the finality horizon.

24.2 Database Encryption at Rest

All SQLite database files are encrypted using AES-256-GCM authenticated encryption. The encryption key is derived from a user-supplied passphrase via PBKDF2-HMAC-SHA512 with 100,000 iterations, producing a 256-bit key that is never stored on disk.

The encryption layer is transparent to callers: the database is decrypted into memory on open and re-encrypted atomically on close using a temporary file with os.replace(). This ensures that a crash during write never corrupts the encrypted file.

24.3 Schema Migration System

The schema migration system tracks database versions and applies incremental migrations automatically on node startup. Each migration is idempotent — wrapped in try/except so that re-running a migration on an already-migrated database is a safe no-op.

Schema v2 adds a metadata column to the blocks table, enabling future extensions without further migrations. All migration history is recorded in a schema_version table with timestamps for auditability.

24.4 RPC Rate Limiting

All public RPC endpoints are protected by a sliding-window rate limiter that tracks request counts per IP address. When a client exceeds the configured limit, the server returns HTTP 429 Too Many Requests with a Retry-After header.

Admin endpoints (those requiring authentication) are exempt from rate limiting, ensuring that node operators can always manage their infrastructure regardless of public traffic load.

24.5 Production Hardening Test Suites

Five dedicated test suites validate every production-hardening subsystem under both normal and adversarial conditions. Together they add 76 new tests, bringing the project total to 6,848 passing tests across 173 test files.

24.6 Test Infrastructure

The production-hardening test suites leverage several specialized testing tools to achieve deep coverage beyond what traditional unit tests can provide:

24.7 Performance Benchmarks (TPS)

A dedicated 13-test benchmark suite (test_tps_benchmark.py) measures real throughput across every layer of the transaction pipeline. Results are asserted against minimum thresholds to catch performance regressions.

24.8 Hardware Specifications for TPS Benchmarks

Benchmarks performed using Python 3.10+ with NumPy acceleration. All figures measured in single-node local mode. Multi-node performance varies by network conditions. Formal third-party benchmark is in progress.

Security Hardening v2 — Attack Surface Reduction

Version 0.2.3 implements 12 security fixes identified through a comprehensive internal security audit. The audit simulated real-world attack scenarios across all subsystems, resulting in 218 attack simulation tests across 4 dedicated test files.

25.1 Critical Fixes

25.2 High-Priority Fixes

25.3 Attack Simulation Test Suite

A dedicated 218-test attack simulation suite probes every identified vulnerability from the perspective of a real attacker, organized into 26 attack classes across 4 files:

Development Roadmap

26.1 Completed Phases ✅

26.2 Future Roadmap 🔮

v0.3.0: Mainnet Readiness — Phase 28

Version 0.3.0 delivers the final four infrastructure pillars required before public mainnet launch: a cryptographically sound state commitment scheme, a production-grade chain reorganization engine with full snapshot-and-rollback semantics, Byzantine Fault Tolerant attestation broadcasting over the P2P layer, and NAT traversal so residential validators behind home routers can participate without manual port-forwarding.

27.1 Merkle Patricia Trie (SHA-512 MPT)

The Merkle Patricia Trie replaces the ad-hoc state-root computation with a standards-compliant, cryptographically binding commitment. Each account balance, nonce, and storage slot is inserted into the trie; the resulting root hash is stored in every block header and is verified by light clients without downloading full state.

27.2 Fork Reorg Execution Engine

Building on the ForkManager introduced in Phase 26, the Fork Reorg Execution Engine adds full state snapshot-and-rollback semantics. Before replaying a competing chain, the engine takes a consistent snapshot of the current state; if the competing chain turns out to be invalid, the snapshot is atomically restored. A finality guard prevents any reorganization from reverting blocks that have already received 2/3 BFT attestation.

27.3 BFT Attestation Broadcasting

Each validator signs a block hash with its Ed25519 key and broadcasts the attestation to all peers via the existing P2P gossip layer. Attestations are aggregated per-block; once a block accumulates signatures from more than 2/3 of the active validator set by stake weight, it is marked finalized and the finality height is advanced. Finalized blocks are permanently protected by the reorg finality guard.

27.4 NAT Traversal (UPnP / STUN)

Residential validators are typically behind NAT routers that block inbound connections. The NAT Traversal subsystem attempts UPnP port mapping first (automatic router configuration via the Universal Plug and Play protocol) and falls back to STUN hole-punching (RFC 5389) when UPnP is unavailable. Both methods are tried asynchronously on node startup; the discovered external address is advertised to peers so that inbound validator connections can be established.

27.5 v0.3.0 Test Coverage

Phase 28 adds 150 new tests across 6 specialized suites, bringing the project total to 6,848 passing tests across 173 test files.

AI Agent Marketplace — Phase 29

Phase 29 introduces a fully on-chain AI Agent Marketplace where developers register AI agents, users submit tasks with ASF payment, and agents execute tasks with quality scoring via the PoNC meta-model. The marketplace creates a sustainable revenue loop: agents earn ASF for high-quality work, the platform collects fees for treasury, and deflationary burns reduce supply.

28.1 Agent Registry

Developers register agents by paying a 50 ASF registration fee and providing metadata (name, description, category, fee schedule). Each agent receives a unique on-chain ID and is assigned to one of six categories: ANALYSIS, AUDIT, GOVERNANCE, CREATIVE, DATA, or SECURITY. The registry enforces a soft cap of 10,000 agents and requires agents to maintain a minimum quality score of 7,000 basis points to remain eligible for task assignment.

28.2 Task Submission & Reward Distribution

Users submit tasks to agents by paying a minimum of 1 ASF. The marketplace assigns tasks, monitors execution, and distributes rewards using a three-way split designed to align incentives across the ecosystem.

28.3 Quality Scoring

Every task result is scored by the PoNC AI meta-model for accuracy, relevance, and completeness. Agent quality scores are updated as exponential moving averages. Agents falling below the 7,000 bp threshold are suspended from receiving new tasks until their score recovers. A leaderboard ranks agents by quality score, tasks completed, and user ratings.

28.4 RPC Methods

Phase 29 adds 11 new RPC methods for marketplace interaction:

RWA Tokenization Engine (PRC-3643) — Phase 30

Phase 30 introduces the PRC-3643 token standard for tokenizing real-world assets (real estate, equity, commodities, bonds, art) with built-in compliance hooks, KYC verification via the DID system, fractional ownership, and automatic dividend distribution. This brings trillions of dollars in real-world value on-chain while maintaining regulatory compliance.

29.1 PRC-3643 Token Standard

PRC-3643 extends the PRC-20 fungible token standard with a compliance layer that enforces transfer restrictions based on jurisdiction, KYC level, and holding limits. Every transfer passes through a seven-step compliance check before execution.

29.2 Compliance Flow

Every RWA token transfer undergoes a seven-step compliance verification:

1. Verify sender DID has KYC level ≥ 2
2. Verify receiver DID has KYC level ≥ 2
3. Check jurisdiction rules for both parties
4. Validate transfer amount within daily/weekly limits
5. AI compliance scoring via PoNC (flag suspicious patterns)
6. Execute transfer if ALL checks pass
7. Reject with specific reason code if ANY check fails

29.3 Dividend Distribution

RWA token issuers can trigger pro-rata dividend distributions to all holders. The dividend engine calculates each holder's share based on their token balance, deducts a 5 ASF distribution fee, and credits dividends atomically in a single transaction. Full dividend history is queryable via RPC for auditing and tax reporting.

29.4 Synergy with Existing Features

29.5 RPC Methods

Phase 30 adds 10 new RPC methods for RWA token management:

ZKML — Zero-Knowledge Machine Learning — Phase 31

Phase 31 implements Zero-Knowledge Machine Learning (ZKML), enabling validators to prove that AI score computations are correct without revealing model weights. This prevents adversarial attacks on the PoNC scoring pipeline, protects model intellectual property, and enables lightweight verification (5ms) instead of full model re-execution.

30.1 Architecture

When a transaction arrives, the validator runs the PoNC meta-model to compute a score (e.g., 3,200 bp). The ZKML prover then generates a cryptographic proof that the score was computed correctly from the given inputs using the committed model weights. Other nodes verify the proof (fast, ~5ms) instead of re-running the full neural network. If the proof is invalid, the block is rejected.

30.2 Quantized Arithmetic Circuits

The ZKML circuit operates on quantized 16-bit fixed-point arithmetic to enable efficient proof generation. Floating-point model weights are converted to integers by multiplying by 2¹⁶ (65,536). Each circuit layer computes a matrix-vector product, adds bias, applies quantized ReLU activation, and produces deterministic integer outputs. The circuit's model commitment is the SHA-512 Merkle root of all layer weight matrices and biases.

30.3 Proof Generation & Verification

The ZKMLProver generates non-interactive proofs using the Fiat-Shamir heuristic: (1) compute blinded intermediate activations for each layer, (2) derive challenges from SHA-512 hashes of the proof transcript, (3) produce challenge-response pairs that demonstrate knowledge of the correct computation without revealing weights. The ZKMLVerifier checks all challenge-responses against the committed model hash, input hash, and output score.

30.4 Cross-Feature Synergies

ZKML integrates with both the Agent Marketplace and RWA Engine:

• Agent Marketplace: Agent quality scores use ZK proofs so developers cannot game the scoring system
• RWA Engine: Compliance scoring uses ZK proofs for privacy-preserving KYC verification
• PoNC: All AI-validated transactions can include ZKML proofs for verifiable correctness

30.5 RPC Methods

Phase 31 adds 5 new RPC methods for ZKML interaction:

30.6 Test Coverage

Phases 29–31 collectively add ~320 new tests across 7 test files:

Neural Self-Preservation System — Phase 32

Phase 32 introduces the Neural Self-Preservation (NSP) system — a comprehensive framework that protects the AI validation pipeline from catastrophic failures, enables graceful performance degradation, and ensures rapid recovery from model corruption or network partitions. NSP replaces the binary kill switch with a graduated multi-level response system.

31.1 Neural Snapshot Engine

The NeuralPreservationEngine captures complete AI state snapshots including model weights (16-bit quantized), agent states, trust scores, ZKML commitments, and degradation levels. Each snapshot produces a SHA-512 state root for tamper detection.

31.2 Graceful Degradation Engine

Instead of a binary on/off kill switch, the GracefulDegradationEngine provides five graduated levels that progressively relax AI thresholds while maintaining network operation:

31.3 Pathway Memory (Hebbian Learning)

The PathwayMemory module tracks computation path health using Hebbian learning principles. Each AI pathway (TAD, MSAD, SCRA, ESG, meta-model, consensus) maintains a weight in [0.1, 1.0]:

• On failure: weight × 0.7 (decay)
• On success: weight × 1.3 (boost), clamped to 1.0
• Correlation: Jaccard similarity detects co-failing pathways for preemptive strengthening
• History: Ring buffer (100 entries) per pathway, persisted to SQLite

31.4 Neural Recovery Engine

The NeuralRecoveryEngine restores AI state from snapshots when corruption is detected. Recovery requires 3-of-5 multisig authorization and follows an 8-step protocol:

1. Verify multisig authorization (hmac.compare_digest for timing attack prevention)
2. Check attempt counter (max 3 recovery attempts)
3. Find best available snapshot (most recent, verified integrity)
4. Verify snapshot state root (SHA-512)
5. Extract and restore model weights
6. Ascend degradation level
7. Reset attempt counter on success
8. Log recovery event to history

31.5 Neural Watchdog Service

A separate OS process monitors the main blockchain process via heartbeat files. If the main process stops updating its heartbeat file for 3 consecutive checks (1.5 seconds), the watchdog sends SIGUSR1 to trigger graceful degradation.

31.6 Deep AI Integration Extensions

Phase 32 also deepens the AI subsystem with four integration modules:

31.6.1 Online Learning Extension

Enables continuous model improvement in Phase C (production mode only). Labeled transactions from three sources (validator consensus, appeal results, confirmed attacks) are buffered and used for periodic retraining. A quality gate reverts any update that causes >5% accuracy drop.

31.6.2 Model Communication Bus

The ModelCommunicationBus enables AI models to share signals within transaction-scoped contexts. Signals are typed per model (e.g., TAD emits anomaly_high, MSAD emits mev_detected). Context boosts are capped at ±500 basis points and models cannot read their own signals (no self-subscription).

31.6.3 Causal Explainability (XAI v2)

The CausalExplainer generates human-readable explanations using permutation-based feature importance and greedy counterfactual reasoning. Explanations are available in both English and Persian (Farsi) via the positronic_explainTransaction RPC method.

31.6.4 Concept Drift Detection

The ConceptDriftDetector monitors model score distributions over rolling windows (500 blocks) and compares against baseline means. Three severity levels trigger graduated responses:

31.7 NSP Test Coverage

References & Sources

1. Nakamoto, S. (2008). Bitcoin: A Peer-to-Peer Electronic Cash System.
2. Buterin, V. (2014). Ethereum: A Next-Generation Smart Contract and Decentralized Application Platform.
3. Ducas, L., Kiltz, E., Lepoint, T., et al. (2018). CRYSTALS-Dilithium: A Lattice-Based Digital Signature Scheme. IACR Transactions on Cryptographic Hardware and Embedded Systems.
4. W3C. (2022). Decentralized Identifiers (DIDs) v1.0. W3C Recommendation.
5. EIP-4337: Account Abstraction Using Alt Mempool. Ethereum Improvement Proposals.
6. Castro, M. & Liskov, B. (1999). Practical Byzantine Fault Tolerance. OSDI.
7. Ben-Sasson, E., et al. (2014). Succinct Non-Interactive Zero Knowledge for a von Neumann Architecture. USENIX Security.
8. Goldwasser, S., Micali, S., & Rackoff, C. (1985). The Knowledge Complexity of Interactive Proof-Systems. STOC.
9. Larimer, D. (2014). Delegated Proof-of-Stake (DPoS). Bitshares Technical Paper.
10. NIST. (2024). Post-Quantum Cryptography Standardization. FIPS 204 (ML-DSA).
11. Weiss, Y. et al. (2021). ERC-4337: Account Abstraction via Entry Point Contract Specification.
12. Vitalik Buterin. (2022). Soulbound Tokens. Decentralized Society: Finding Web3's Soul.