Home Protocol Architecture Tokens Roadmap FAQ Whitepaper Economics GitHub ↗
01 / Abstract

The fire belongs to humanity,
not to corporations.

Prometheus is a fully decentralized, AI-powered threat intelligence protocol built on the Kaspa blockchain. It transforms every connected device into a node in a global threat detection swarm — without central control, without a foundation, and with zero pre-mined tokens.

The protocol combines three layers: on-device AI (Phi-3-mini 3.8B, 4-bit quantized) for local anomaly detection, Guardian nodes (LLaMA 3 70B/8B) for advanced threat analysis and YARA rule generation, and Kaspa L1 consensus (DAGKnight, 100 BPS) for immutable rule storage and governance.

Key properties: 0% pre-mine · No emergency stop · Fully automated governance · GDPR non-applicable (no personal data on-chain) · Code is the only law.

ParameterValue
BlockchainKaspa (DAGKnight, 10–100 BPS, sub-second finality)
Smart ContractsSilverscript — native L1, from May 5, 2026
Guardian AI (primary)LLaMA 3 70B (Meta, open source)
Guardian AI (fallback)LLaMA 3 8B (RTX 4070 Ti+, 16 GB VRAM)
Client AIPhi-3-mini 3.8B, 4-bit quantized (4 GB RAM, no GPU)
Federated LearningFed-DART (Fraunhofer Institute)
Staking TokenKAS (Kaspa native, 0% pre-mine)
Governance TokenPROM (Prometheus Token, 0% pre-mine)
Total Emission (5 years)80,000,000 PROM
Mainnet LaunchMay 5, 2026 (Covenant-Hardfork)
LicenseMIT / Apache 2.0
02 / Problem Statement

The security industry is structurally compromised.

The failure of signature-based security

Classical antivirus software works by comparing files against a database of known malware signatures. This approach has a fundamental design flaw: it only detects what is already known. New, unknown attacks — zero-day exploits — pass through undetected.

State-sponsored trojans like Pegasus (NSO Group), Predator (Intellexa), and FinFisher were specifically engineered to bypass these detection mechanisms. They use zero-click exploits — the user need not click anything or download anything. A single incoming message is sufficient for complete device compromise.

The structural conflict of interest

The commercial security industry suffers from a fundamental conflict of interest: the same firms that sell protection also sell attack tools to governments. Firms like NSO Group, Hacking Team, and Intellexa profit from enabling espionage — not from preventing it.

  • Zero-day market: A legal but opaque market for security vulnerabilities. Governments pay millions for unknown exploits.
  • Backdoor laws: The US Cloud Act and similar legislation in other countries compel technology companies to cooperate with authorities.
  • Conflict of interest: An antivirus company that simultaneously serves government clients has a financial incentive not to detect government malware.
The credible alternatives

Trustworthy security research does not come from the large corporations — it comes from independent actors: Amnesty International Security Lab (MVT toolkit for Pegasus detection), The Citizen Lab (University of Toronto — the leading address for uncovering state cyber-espionage), ClamAV (fully transparent, community-maintained open source scanner), and Wazuh (open source threat detection platform).

Prometheus builds on this tradition — and scales it to global network effects through blockchain technology.

03 / Solution Overview

Swarm intelligence. Blockchain immutability. AI analysis.

Prometheus solves the three core failures of the current security industry simultaneously:

FailurePrometheus Solution
CentralizationNo foundation, no central server, no emergency stop. Protocol exists as long as Kaspa exists.
LatencyThreat to on-chain rule in under 60 seconds. Real-time swarm detection via Light Clients worldwide.
Misaligned incentives0% pre-mine. PROM earned only through verified security work. No commercial relationship with governments.
The threat lifecycle — under 60 seconds
t = 0s
Light Client — Phi-3-mini detects anomaly. SHA-256 hash computed. ZK-proof generated. Anonymous hint sent to 3 Guardian nodes.
t = 2s
Guardian Node — LLaMA 3 aggregates 5+ similar reports. Analyzes entropy, API patterns, CVE correlations. Generates YARA rule proposal (min. 85% confidence).
t = 15s
Validator Network — Commit-Reveal voting. commitment = sha256(vote ‖ salt ‖ block_height). 67% consensus required. 10% bond locked per validator.
t = 35s
Kaspa Layer 1 — Final rule stored as KRC-20 asset (supply=1, immutable). Sub-second finality via DAGKnight.
t = 36s
All Clients — P2P broadcast or Kaspa polling. New rule automatically loaded. Local scanner immediately active. Protection established.
04 / Architecture

Three layers. No center.

Layer 1 — Kaspa (Immutable Truth)

Layer 1 is the core of the security system. Validated threat rules are stored here as KRC-20 assets. These data can be deleted or manipulated by nobody — not governments, not companies, not the developers themselves.

  • DAGKnight consensus: Adaptive, parameterless consensus with theoretically optimal Byzantine fault tolerance (~50%). Converges under attack orders of magnitude faster than classical systems.
  • BlockDAG architecture: Parallel block production eliminates the bottleneck of linear chains. 10 BPS today, 100 BPS with Crescendo upgrade.
  • Silverscript (from May 5, 2026): High-level language for UTXO-based smart contracts. Compiles directly to Kaspa opcodes, no separate VM. Reentrancy attacks are structurally impossible.
  • Native ZK verification: Groth16 Zero-Knowledge Proofs directly on L1 — essential for anonymous threat reports.
Layer 2 — Kasplex zkEVM (Intelligence Layer)

Kasplex brings zkEVM functionality to Kaspa. The complex governance logic runs here: votes, reputation computation, reward distribution. Results are confirmed to L1 via ZK-rollup. Active since August 2025.

Off-Chain — The Action Layer

The actual protective effect arises off-chain on the devices of users and the nodes of operators. This layer communicates constantly with L1 and L2 but acts autonomously. Raw data never leaves this layer.

Why Kaspa? Kaspa is the only Proof-of-Work blockchain that fulfills the technical requirements of Prometheus: sub-second finality, 100+ BPS, Silverscript for native L1 contracts, ZK-proof support on L1, and a 0% pre-mine philosophy identical to Prometheus.

05 / Node Types

Four roles. Every device contributes.

Node TypeHardwareRolePROM Share
Light Client4 GB RAM, no GPULocal detection, ZK-proof generation, anonymous reporting15%
Guardian NodeRTX 4070 Ti+ (8B) or 4× A100 (70B)LLaMA 3 analysis, YARA rule generation, reputation-based voting30%
Validator NodeStandard server + 10,000 KAS stakeCommit-Reveal voting, economic security, slashing enforcement40%
Honeypot NodeAny internet-exposed serverZero-day detection via decoy services5%
Guardian Node — LLaMA 3 8B as fallback

LLaMA 3 70B requires 4× NVIDIA A100/H100 (~$30,000–50,000). This excludes many potential Guardian operators. LLaMA 3 8B runs on a single consumer GPU (e.g. RTX 4070 Ti) — dramatically lower entry barrier. The reputation system automatically filters out poor-quality outputs: incorrect proposals halve reputation and automatically revoke voting rights.

06 / AI Architecture

Open source models. Security specialization. Federated learning.

Why open source models?

The choice of AI model is a security question, not a quality question. Proprietary models (GPT-4, Claude, Gemini) are black boxes — nobody can verify what they actually do. For a security system with transparency as a core principle, they are structurally unsuitable.

Wächter-KI — Phi-3-mini (Light Client)

Microsoft's Phi-3-mini 3.8B runs completely locally on the end user's device. No data transfer, no cloud, no dependency on external services. The model is 4-bit quantized and runs via ONNX Runtime on 4 GB RAM without GPU on Windows, macOS, Linux, and mobile.

Jäger-KI — LLaMA 3 (Guardian Nodes)

Meta's LLaMA 3 in the 70B or 8B variant is the centerpiece of the Guardian AI. It runs self-hosted on Guardian nodes and analyzes incoming threat hints from Light Clients across the network. Both variants are fine-tuned with LoRA (Low-Rank Adaptation) on security-specific datasets:

  • VirusShare: Largest public malware database, millions of samples
  • MalwareBazaar: Current malware samples, daily updated
  • Exploit-DB: Complete exploit database for CVE correlations
  • CuckooSandbox Reports: Behavioral analysis of malware in sandbox environments
# LoRA Fine-Tuning Configuration
lora_config = LoraConfig(
    r=16,                              # Rank
    lora_alpha=32,                     # Scaling factor
    target_modules=['q_proj', 'v_proj'], # Attention layers only
    lora_dropout=0.1,
    task_type='CAUSAL_LM'
)
# Only 1-5% of parameters are trained → efficient
# Training on ~500k malware samples
# Result: specialized security model on LLaMA 3 base
Federated Learning — Fed-DART

The network improves continuously without central data exchange. Fed-DART (Fraunhofer Institute) enables decentralized training: clients train locally and send only mathematical gradients — never the underlying data.

Privacy guarantee: Only gradients (mathematical differences to the global model) are transmitted. No conclusions about original data can be drawn from gradients. ZK-proofs additionally secure the anonymity of the reporting client.

07 / Smart Contracts

Six Silverscript contracts. Fully automated. Audited.

All contracts are written in Silverscript, audited before mainnet deployment, and use uint64 with 10,000× scaling for all reputation and confidence values (no float64).

ContractPurposeKey Functions
ValidatorStaking.ssKAS staking + consensus votingregister, commitVote, revealVote, slash, withdraw
GuardianReputation.ssReputation + quadratic votingregister, voting_power, proposal_accepted/rejected
GovernanceAutoTuning.ssWeekly parameter adjustmentauto_tune, get_parameter
DevIncentivePool.ssDAO-voted developer rewardsproposeGrant, vote, executeGrant
CommunityDonations.ssTransparent community funddonateKas, proposeDisbursement
RuleStorage.ssKRC-20 rule mintingsubmitProposal, voteOnProposal, finalizeProposal

CRITICAL — KAS/PROM separation: Validators stake KAS (tx.value = KAS, constant = MIN_STAKE_KAS = 10,000). PROM is earned by Guardians through accepted proposals — never staked by Validators. Confusing the two tokens is the most common implementation error (PATTERN-001).

08 / Token Design

Two tokens. No shortcuts.

TokenRoleSourceValue basis
KASValidator staking + slashingKaspa network (existing asset)Kaspa network usage, $1B+ market cap
PROMReputation + governanceMinted per accepted rule (0% pre-mine)Utility in Prometheus ecosystem
PROM emission — first 5 years
YearEmissionValidators 40%Guardians 30%Reporters 20%Dev Pool 5%Community 5%
Year 120,000,0008,000,0006,000,0004,000,0001,000,0001,000,000
Year 218,000,0007,200,0005,400,0003,600,000900,000900,000
Year 316,000,0006,400,0004,800,0003,200,000800,000800,000
Year 512,000,0004,800,0003,600,0002,400,000600,000600,000
Total80,000,00032,000,00024,000,00016,000,0004,000,0004,000,000

0% Pre-mine — absolute and unchangeable. Not a single PROM token is issued before mainnet launch. No founder allocation. No investor tranche. No team reserve. Developers are compensated exclusively through DAO grants from the 5% Dev Pool — only for work performed.

09 / Validator System

Economic security through KAS staking.

Validator nodes are the economic backbone of the network. By staking KAS they put economic capital on the line as a guarantee for honest behavior. Misbehavior is punished by slashing — a direct financial loss.

PropertyValue
MIN_STAKE_KAS10,000 KAS (dynamic via auto-tuning)
Slashing — simple5% KAS loss
Slashing — double vote10% KAS loss
Slashing — collusion20% KAS loss
Escalationmultiplier = min(3, slashing_count / 3 + 1)
Cooldown7 days (100,800 blocks at 10 BPS)
Bond per vote10% of current stake
Access control on slash()Only GOVERNANCE_CONTRACT or RULE_STORAGE_CONTRACT
10 / Guardian System

Reputation capital through AI contribution.

Guardian nodes are the intelligence of the network. They operate the Jäger-KI, analyze threat patterns, and create rule proposals. Their "stake" is not financial but reputational — a form of social capital earned through good work.

PropertyValue
REPUTATION_START1,000 (= 0.1 at 10,000× scale)
MIN_REPUTATION1,000 — below this: voting rights revoked
On accepted proposalreputation += sqrt(compute_power) × 100
On rejected proposalreputation × 0.5 (halving)
Voting power formula(reputation / 100)² × compute_power / 1,000
Anti-SybilPoW registration + quadratic voting
Model auto-assignment≥ 500 GFLOPS → 70B, < 500 GFLOPS → 8B
11 / Voting Mechanism

Commit-Reveal. Bond system. 67% quorum.

Commit-Reveal is the core protection mechanism against collusion among validators. No validator knows how the others will vote before they themselves have committed.

# Phase 1: COMMIT — validator sends only a hash
# commitment = sha256(vote_byte || salt_LE || block_height_LE)
# vote_byte: 1 = true, 0 = false
# salt and block_height as 8-byte little-endian

# Phase 2: REVEAL — after 10-second collection phase
# Validator reveals actual vote + salt
# Network verifies: sha256(vote||salt||block) == commitment
# Invalid reveal → bond slashed immediately

This formula is identical in Silverscript contracts and Rust implementation. Cross-verification tests ensure bit-for-bit identity between the contract and the validator node code.

12 / Rule Storage

KRC-20 assets. Supply 1. Immutable.

Each accepted rule is stored as a unique KRC-20 asset on Kaspa L1:

  • Tick: PROM-RULES
  • Supply: 1 per rule (NFT-like — unique and non-fungible)
  • ID format: PROM-RULE-2026-XXXX
  • IPFS reference: bytes(36) — CIDv1 binary with SHA-256 multihash (not bytes(46) — corrected in audit V-002)
  • Minimum confidence: 0.85 (stored as 8,500 at 10,000× scale)
  • Challenge period: 24 hours after acceptance

Rule content is stored on IPFS. The CIDv1 hash is stored on-chain. Every client verifies the IPFS content hash against the on-chain hash before loading a rule — manipulation is structurally impossible.

13 / Federated Learning

The network learns. Raw data never leaves.

Fed-DART enables decentralized training: clients train locally and send only mathematical gradients — never the underlying data. The global model improves without any central party knowing the data of the users.

# Fed-DART Training Round (simplified)
async def training_round(self):
    # 1. Fetch global model from coordinator
    global_model = await self.client.fetch_global_model()
    # 2. Train locally — ONLY with local threat data
    local_gradients = await self.train_local(global_model)
    # 3. Send ONLY gradients — NEVER raw data
    await self.client.submit_update(ModelUpdate(
        gradients=local_gradients,      # Mathematical difference
        client_id=self.anonymized_id(), # Anonymous
        data_size=self.local_data_count,# Count, not content
        signature=self.sign_update()    # Authenticity
    ))
    # 4. Aggregated global model is distributed
    # No single client knows the data of any other
14 / Governance Auto-Tuning

Fully automated. No human intervention possible.

All protocol parameters adjust themselves weekly based on network data. No human can intervene — or needs to.

ParameterStart valueTarget
MIN_STAKE_KAS10,00050–200 active validators
MIN_GUARDIAN_REP3,000 (= 0.3)200–1,000 active guardians
MIN_CONFIDENCE_KI8,500 (= 0.85)False positive rate < 0.5%
VALIDATOR_CONSENSUS6,700 (= 0.67)Stable rule acceptance
REWARD_BASE100 PROM100–200 proposals/day
CHALLENGE_PERIOD86,400s24 hours
15 / Security Analysis

Sybil resistance. FP flood. 51% attack. Collusion.

AttackCountermeasure
Sybil attackQuadratic voting (power = rep²). 1 real guardian outweighs 500+ fakes mathematically.
CollusionCommit-Reveal: nobody knows others' votes before committing. Bond loss makes false voting irrational.
False positive floodMin. 85% confidence threshold. Only 5+ independent reports trigger Guardian analysis.
Model poisoningOn-chain model hash. Any manipulation produces a different hash → rejected by all nodes.
51% attackDAGKnight: ~50% Byzantine fault tolerance. Prometheus inherits Kaspa security.
Long-range attackWeak subjectivity: new validators can only vote from their entry timestamp.
Emergency stopDoes not exist — by design. No single point of failure. The protocol cannot be paused.
16 / Developer Incentives

5% Dev Pool. DAO vote only. No foundation.

5% of annual PROM emission (1,000,000 PROM/year) is allocated to developer grants. Every single payment requires a DAO vote — full transparency, no hidden payments, no founder allocation.

Recommended reward formula: lines × 10 × (100 + complexity × 10) / 100 — capped at 100,000 PROM per grant. Complexity scale: 1–10.

Bootstrap financing (before mainnet)

Before mainnet launch, no tokens are issued. Development is financed through external funding — Gitcoin Grants (quadratic funding, community-decided), Octant (matching pools for open-source infrastructure), and community donations in KAS.

17 / Roadmap

Built in public. Audited in public.

PhaseTimelineMilestone
FoundationMarch 2026Sprints 0–8 complete. 6 contracts, 160+ tests, landing page live.
HardforkMay 5, 2026ssc ships. All contracts on mainnet. First PROM minted. DEX pool live.
AI ProductionMay–June 2026Real ZK-proof, P2P, Phi-3, LLaMA fine-tuned, Fed-DART live.
Desktop ReleaseJuly–August 2026Windows / macOS / Linux installers. One-click Guardian setup.
Mobile ReleaseSeptember 2026iOS (App Store) + Android (Google Play + F-Droid).
vProgsQ4 2026AI results anchored to L1 via ZK-proofs. Complete architectural vision.
18 / Audit Findings

All findings public. All resolved before mainnet.

All development is subject to continuous architect audit via the Claude Code workflow. Every finding is documented in memory/AUDIT.md and publicly visible in the repository.

FindingSeverityResolution
V-001: float64 not supported in sscHIGHuint64 with 10,000× scaling in all contracts
V-002: CID bytes(46) incorrectHIGHbytes(36) for CIDv1 binary SHA-256 multihash
V-003: Recursive slash() functionHIGHNon-recursive: multiplier = min(3, count/3+1), applied once
FIX-001: slash() without access controlCRITICALACL: only GOVERNANCE_CONTRACT or RULE_STORAGE_CONTRACT
FIX-002: .active() compile errorHIGHChanged to registered_at == 0
FIX-003: Cumulative FP counterHIGHTime-windowed counter (864,000 blocks = 1 day)
FIX-004: Bond not returned on revealLOWtransfer(msg.sender, vc.bond_kas) on valid reveal
FIX-005: Reward formula mismatchLOWCorrected to whitepaper formula
Testnet-12 does not existINFOkaspa-testnet-10 confirmed via rusty-kaspa v1.1.0

Total audit rounds: 10 · Sprint findings: 9 · All critical and high findings resolved before mainnet. Full audit log: memory/AUDIT.md