Home Protocol Architecture Tokens Roadmap FAQ Whitepaper Economics GitHub ↗
01

Tokenomics

KAS is the native Kaspa token that already exists. Validators stake KAS as economic collateral. If a validator misbehaves, they lose KAS — real money with real consequences. The alignment of incentives is economic, not ideological.

PROM is the planned Prometheus reward and governance token. Primary issuance is specified for verified contributions; a planned KAS/PROM pool would permit secondary-market purchases after issuance. Minting, emission, liquidity, and trading are not implemented, deployed, or active. Canonical Guardian reputation remains separate Kaspa L1 state.

The key distinction: KAS = economic security deposit. PROM = proof of contribution. Keeping them separate ensures that capital alone cannot buy influence over the protocol.

The specification starts with zero PROM: no pre-mine, ICO, presale, founder allocation, or foundation allocation.

Primary contribution issuance and a later KAS/PROM secondary market funded from the Community allocation are targets. Neither is deployed, active, or a price promise.

No PROM is currently minted. The target uses performance-based emission for verified contributions after consensus, anti-abuse, and deployment gates pass.

YearTotal targetValidators 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

This is planned tokenomics, not active emission. Reporters split 15% Light Clients and 5% Honeypots. Dev Pool and Community are predefined 5% protocol pools, not founder/foundation allocations.

02

Security Protocol

No — four independent checkpoints exist before any rule reaches the blockchain:

1. AI pre-filter ········· min. 85% confidence (automatic)
2. Collection ············ min. 5 independent reports
3. Validator vote ········ 67% majority · Commit-Reveal · bond at risk
4. Challenge period ······ 24 hours · auto-tuning responds to FP rate

No single step is fully automatic without verification. The automation lies in the execution of the rules — the decision itself has multiple independent checkpoints. This makes it structurally difficult to push a false rule through: an attacker would need to simultaneously overcome AI confidence thresholds, gather 5 fake reports, win a validator vote, and survive the challenge period.

Merged and exact-main-verified GH-170 replaces substring shape checks with exact-pinned, compile-only yara-x==1.4.0 validation. It accepts one bounded ASCII rule, disables includes, rejects imports, multiple rules, compiler errors, and warnings, and performs no scan.

PR #171 published exact main 8d8e29c; CI 31650123073, Security 31650123055, and Pages 31650122593 pass. This validates syntax and structure only. Semantic quality, model approval, actionable analysis, submission, publication, and production operation remain separate gates.

Merged and exact-main-verified GH-173 composes this boundary with the governed v2 worker. It derives one memory-only draft from already approved local API-import and byte-pattern observables and stores only exact bindings, kind counts, a nonce-bound candidate-binding digest, and compile status. PR #174 published exact main 1107b11; CI 31654308969, Security 31654308964, and Pages 31654308875 pass. It invokes no model, persists no rule source, scans nothing, and grants no submission, publication, or production authority. Real semantic/actionable quality remains open.

GH-177 is merged and exact-main verified through PR #178 at 396d347. It scans only 20 deterministically generated synthetic in-memory buffers with one fixed rule and emits an authority-none canonical report with exact false-positive and false-negative metrics. It is isolated from governed workers, results, submission, wallet, chain, and deployment. Passing this synthetic gate is regression evidence only, not real-world detection quality, actionable approval, calibration, certification, or production authority.

GH-180 is merged and exact-main verified through PR #181 at a28ad00. Eight POSIX-only cases drive canonical synthetic transport bytes through real Python ingress, governed promotion, schema-v5 atomic outbox, bounded worker, and durable non-actionable semantic-draft completion. Exact bindings, malformed and oversized rejection, replay/restart, duplicate concurrency, lease recovery, redacted analyzer failure, and transactional rollback pass. Prometheus CI 31662874366, Security Audit 31662874399, and Pages 31662873670 pass on the exact merge commit. It adds no runtime authority, keeps GH-177 isolated, and is not production deployment or real-world detection evidence.

Affected users report the false detection. After authenticated metrics, external signatures, and confirmed on-chain execution, GovernanceAutoTuning deterministically raises the confidence threshold for new rules. Those production steps remain gated.

The Guardian who submitted the bad rule loses 50% of their reputation score. Reputation halving is a strong deterrent: it takes many accepted proposals to rebuild what one rejection destroys.

The target false positive rate is under 0.5%. Auto-tuning continuously adjusts parameters to stay within this range.

The implemented ThreatHint v1 path never sends raw files or paths. It does send bounded metadata: a caller-supplied 32-byte hash commitment, confidence, indicator category, proof bytes, nonce, and timestamp. A hash is not encryption and may allow correlation or matching against known content.

The manifest-pinned Groth16 engine binds the v1 statement to its network and domain, but no approved production relation or keys ship yet, so operated verification remains fail-closed. V1 does not prove how the hash was derived, that a report is true, or that its sender is anonymous. The Threat Observable v2 draft defines the additional privacy and proof boundaries required before concrete indicators are sent. Merged and exact-main-verified GH-86 adds isolated Rust and Python structural validators against one shared byte-exact corpus. Merged and exact-main-verified GH-90 adds one local Rust file_sha256 producer from exact caller-supplied bytes and typed scope, with Python validation of the shared vectors. Merged and exact-main-verified GH-94 adds one local Rust byte_pattern producer from exact bytes, a checked offset, boolean wildcard mask, and typed scope. It accepts no pattern string, requires at least eight fixed bytes, and always emits local-only review_required_v1. Neither producer authorizes transport or proves external file provenance, maliciousness, semantic privacy approval, or proof binding.

Merged and exact-main-verified GH-103 adds one bounded local Linux ELF api_import extractor from exact bytes and a checked sorted/deduplicated index. It accepts no path or caller-supplied import string and always emits review_required_v1. This remains local testable derivation only, not permission to disclose, transport, analyze, or publish the value.

Merged and exact-main-verified GH-121 applies the same boundary to exact PE32 and PE32+ bytes. It rejects ordinal or grammar-invalid imports, fixes windows/pe scope, and keeps every result review_required_v1. Library names are never observables, and this adds no transport, proof, analyzer, wallet, chain, or promotion authority.

Merged and exact-main-verified GH-107 can locally authenticate one short-lived BIP340 approval statement for one exact review_required_v1 bundle against separately trusted context, including separately trusted current time that must never be attacker-controlled. It does not disclose, transport, analyze, publish, or persist the bundle. Its signed nonce and deterministic approval ID identify repeats but do not prevent replay; durable one-time consumption and trusted approver policy remain required before promotion.

Merged and exact-main-verified GH-111 adds that local consumption boundary in Guardian Node. One owner-only policy fixes the network, approver public key, and opaque recipient-scope digest; the service verifies in the same call path and atomically records the approval ID and authority-bound nonce in an owner-only SQLite ledger. This prevents local reuse across retries, concurrency, and restarts, but the receipt grants no external authority. Key ownership/rotation, scope semantics, hint/bundle pairing, privacy approval, transport, analyzer execution, promotion, outbox delivery, wallet, and chain behavior remain unimplemented.

Merged and exact-main-verified GH-114 adds isolated local Rust and Python ThreatHint v2 statement parsers. Exact canonical bytes carry separate artifact hash and observable commitment fields plus bounded confidence, structural disclosure class, report nonce, positive observed time, and a network matching separately trusted local context. A domain-separated digest binds every field. This proves only structural consistency: no approved relation, proof, privacy review, approval pairing, replay authority, transport, analyzer, wallet, or chain path uses it, and it does not prove that the artifact or report is genuine.

Merged and exact-main-verified GH-117, but not production-deployed, additionally parses a bounded opaque-proof envelope and strict RelationManifest-v2 in Rust and Python, then binds their exact canonical bytes to a separately trusted network and raw-manifest SHA-256. It derives claimed digest halves only; it does not verify Groth16, approve relation or key artifacts, authorize disclosure, or connect transport, analysis, promotion, wallet, chain, or rollout behavior.

Merged and exact-main-verified GH-117 adds a local Rust verify-v2 boundary that performs real canonical BN254 Groth16 verification against owner-only manifest, relation-source, and verifying-key files. Runtime loads no proving key and the generated relation, keys, and proofs are test-only. This does not approve production artifacts or a ceremony.

GH-117 also adds an owner-only local preflight that pins the network, BIP340 approver, recipient scope, and manifest digest, then derives the statement from the bound envelope and verifies its review-required bundle and approval. It consumes nothing and grants no proof, privacy, disclosure, transport, analysis, promotion, chain, or rollout authority by itself.

The merged verified-preflight boundary composes those checks with an owner-pinned executable SHA-256, approval/privacy preflight first, then the exact envelope over stdin to a bounded, scrubbed, shell-free verify-v2 process. Atomic acceptance then re-verifies the approval ID and observable commitment before durable consumption; failed verification consumes nothing and advances no ledger time.

Enforceable owner policy binds authority, recipient scope, per-kind retention/privacy decisions, and exact policy digests. Governed schema v4 durably stores the statement, nonce, bundle, approval, lease, and retention; atomic completion stores one canonical non-actionable result before deleting work. The bounded worker uses only a deterministic test analyzer.

Merged and exact-main-verified GH-152, not production-deployed, advances governed durable-outbox ledgers to schema v5. The same promotion transaction permanently records a strict one-to-one-to-one binding between the exact statement digest, approval ID, and observable commitment, so retention cannot reopen those identities for a fresh counterpart. A v4 ledger migrates only when its outbox and result tables are empty; authority, replay high-water, and approval-consumption state are preserved. Any retained v4 outbox or result row fails closed unchanged. This adds no proof, analysis, transport, wallet, chain, reward, deployment, or production authority.

GH-117 remains non-production: production relation/key/ceremony approval, independent cryptographic and privacy review, real semantic/actionable analysis, operated multi-host v2 transport evidence, chain effects, and rollout evidence remain separate gates.

Merged and exact-main-verified GH-167 closes the bounded repository transport substrate: exact canonical v2 wires now cross an independent libp2p protocol into owner-only local IPC and are reparsed against trusted network, session, and time context before governed promotion. PR #168 published exact main 7c62608; Prometheus CI 31645624623, Security Audit 31645624601, and Pages 31645623547 pass. This is same-host engineering evidence only. Production artifacts, privacy-reviewed semantic/actionable analysis, public multi-host operation, disclosure, models/YARA, wallet, chain, rewards, and deployment remain blocked.

Merged and exact-main-verified PR #227 published exact main 6c39af5; Prometheus CI 32675287618, Security Audit 32675287530, and Pages 32675287300 pass. GH-226 adds one Development-only Light Client v1 sender over one static literal-loopback Guardian QUIC peer. Strict owner-only files, offline preflight, exact canonical bytes, bounded redacted outcomes, and real same-host binary tests cover accepted, duplicate, rejected, busy and transport failure. The Guardian acknowledgement is only a local boundary result, not proof, membership, privacy approval, reward, chain or production authority. Beta and Mainnet reject before network activity; public Testnet and multi-host operation remain open.

Merged GH-229/PR #230 at exact main fba8bb4 provides the tested capability for one controlled Development/Testnet-10 direct-QUIC run; exact-main CI 33017195813, Security Audit 33017196184, and Pages 33017194744 pass. At 2026-08-26T23:36:04Z (2026-08-27 operator-local), one operator-attested run from source commit 27e8b02 delivered one canonical hint between two distinct controlled hosts. Sender and Guardian both recorded non-authorizing rejected, with zero retries, no persistence and acknowledgement authority none. The temporary sender-restricted UDP rule was removed immediately. The redacted evidence does not independently prove host separation and is not public-network, relay/v2, proof, membership, deployment or production evidence.

Merged and exact-main-verified GH-234/PR #235, code commit b450740, exact main f146fb2, adds one Development/Testnet-10-only Light Client v2 submission command. It reads an owner-only canonical shared payload, reparses it against separately trusted testnet-10 before identity/network activity, and submits exactly once over the Guardian v2 channel. Local unit and real same-host binary/QUIC tests cover offline preflight, accepted/rejected/busy/transport-failure, redaction, Beta/Mainnet gates and unchanged v1 behavior. Exact-main CI 33272578070, Security Audit 33272577951, and Pages 33272577407 pass. It adds no proof generation or production approval authority, public/multi-host v2 evidence, deployment, Mainnet or production operation.

Merged and exact-main-verified GH-238/PR #239, exact main 912d96d, implements and locally tests repository-only preparation for one later controlled distinct-host Development/Testnet-10 ThreatHint-v2 attempt. The tooling uses challenge-bound, role-specific operator attestations over the source commit, the actual executable digest, the exact canonical payload digest, the exact v2 protocol, one shared observed UTC time, the actual rejected status, one attempt, zero retries and no persistence, with strict owner-only/no-symlink files, the exact 9,265-byte Rust wire bound, atomic no-clobber record output, a closed redacted verifier and CI test wiring. Exact-main CI 33279351831, Security Audit 33279351822, and Pages 33279351387 pass. No real GH-238 remote run has occurred and no GH-238 evidence record exists; host separation is not independently proven. This repository preparation is not a deployment or remote demonstration and adds no port, firewall, host, IAM, wallet, chain, deployment, Mainnet or production action or authority; a later real run requires separate explicit authorization.

Privacy by design. The protocol minimizes on-chain data, but applicable privacy obligations depend on the deployed data flows and jurisdiction. This FAQ is not a legal determination.

A cryptographic protocol that prevents validators from copying each other's votes or coordinating before voting ends.

Commit phase: Each validator submits sha256(vote ‖ salt ‖ block_height) — a sealed envelope. Nobody can see what's inside.

Reveal phase: After all validators have committed, everyone opens their envelope simultaneously. The network verifies that the revealed vote matches the original commitment.

A 10% bond (in KAS) is locked during voting. Invalid reveals — or no reveal at all — result in immediate bond slashing. This makes strategic abstention and vote-copying economically irrational.

03

AI Architecture

No — and that would be the wrong approach. Training foundation models from scratch costs hundreds of millions of dollars and years of research time. That is not Prometheus.

Prometheus targets existing locally operated models and planned LoRA specialization. No completed fine-tuning or independently evaluated real 8B/70B run is currently evidenced.

We are not reinventing the wheel. We are building the vehicle.

ModelWhereLicenseRole
Phi-3-mini 3.8BLight Client targetMITPlanned ONNX inference; current code is a bounded fail-closed safe-default stub with no loaded-model or quarantine authority
LLaMA 3 8BGuardian targetCommunityPlanned first analysis tier
LLaMA 3 70BGuardian targetCommunityPlanned confidence escalation tier

Proprietary hosted models do not expose all weights or service internals for independent inspection. The target therefore favors locally operated, inspectable models. Open weights alone do not prove quality, privacy, provenance, or safe operation. No production malware-sample workflow is deployed, so no absolute data-locality claim is made.

This is a planned GH-258/GH-261 use case, not a current capability. It includes unauthorized compute conscription of endpoints, accelerators, servers or data-center capacity into a distributed mesh. Prometheus could classify observable process/resource ownership, unexpected CPU/GPU workload, scheduler/orchestrator drift, workload-identity, persistence, credential-access, outbound fan-out, model/runtime-integrity and agent tool-policy signals and correlate bounded privacy-reviewed ThreatHints. It cannot reliably identify a superintelligence or attribute an event to AI, AGI, a specific actor or intent.

The target stages are observe-only, warn-only, operator-confirmed reversible containment, and only later separately approved limited automation after independent real-sample, adversarial, privacy, false-positive, multi-host and rollback evidence. No real-time endpoint sensor or response engine is implemented. Automatic process termination, quarantine, firewall mutation, credential rotation, remote commands, deletion and host isolation are disabled and unauthorized.

GH-264 adds only a canonical 512-byte observe-only statement parser in Rust and Python. Closed behavior domains/signals, bounded counts/windows, an opaque nonce, minute-granularity time and a separately trusted network are accepted; free text and host-identifying fields are not. It reads no endpoint data and provides no event truth, correlation, AI/actor attribution, warning, transport, response authority or production capability.

LoRA (Low-Rank Adaptation) and the listed datasets are roadmap inputs. Fine-tuning, provenance review, real-sample evaluation, calibration, and production authorization remain unproven.

Training datasets:

DatasetContent
VirusShareLargest public malware database, millions of samples
MalwareBazaarDaily updated current malware samples
Exploit-DBComplete CVE and exploit correlation database
CuckooSandboxBehavioral analysis reports of malware in sandboxes

No resulting model-quality claim is currently enabled. Compile-valid YARA syntax and synthetic regression data do not establish real-world detection quality.

Target architecture: federated learning via the Fed-DART protocol keeps training records local and sends bounded model updates. Updates can still leak information, so production requires clipping, secure aggregation, privacy accounting, authentication, and validation.

Guardian Node A sees threat X in Germany → local gradient
Guardian Node B sees threat X in Japan ··· → local gradient
Guardian Node C sees threat X in Brazil · → local gradient
·············································· ↓
Coordinator aggregates gradients (weighted by reputation)
·············································· ↓
Improved global model → IPFS → on-chain hash → all nodes

No node-count, learning-rate, quality-improvement, or commercial-outperformance claim has been demonstrated.

The target model-distribution integrity chain is:

1. Target: model bytes published to IPFS (content-addressed; availability and authorization remain separate)
2. CIDv1 hash stored on Kaspa L1 (tamper-proof)
3. Every node verifies: IPFS hash == on-chain hash
4. Mismatch = automatic rejection, no installation

Hash matching can provide tamper evidence for exact bytes. It does not prove upstream authenticity, model quality, authorization, IPFS availability, replication, or censorship resistance. This distribution path is not deployed.

04

Technical

RequirementKaspaEthereum
Block finality<1 second (DAGKnight)~12 seconds
Throughput100 BPS (Crescendo)~15 TPS
Pre-mine0%72M ETH pre-mined
Native ZKGroth16 on L1External circuits
Smart contractsSilverscript (L1)Solidity (EVM)

The target rule lifecycle benefits from fast settlement, but current same-host timing is not production response evidence. Kaspa's planned execution environment and 0% pre-mine history align with the protocol design; chain speed alone does not provide endpoint detection or safe response.

ClamAV is primarily signature-driven, while Wazuh combines multiple monitoring and detection approaches. Neither comparison proves Prometheus detection quality, and real-world performance depends on configuration, rules, telemetry and evaluation.

Prometheus targets behavioral analysis and shared rule state but does not currently provide production unknown-threat detection. Canonical state and a CID are targeted for Kaspa while content lives on IPFS; authorized deactivation exists, and anchoring does not guarantee availability, replication, or universal censorship resistance.

Merged and exact-main-verified GH-197/PR #198 adds a development Testnet-10 consistency check: one separately owner-pin-hashed canonical manifest must match exactly one bounded RuleStorage UTXO observation before the bound constructor JSON is decoded. GH-203/PR #204 adds a development-only live adapter that asks one connected node for exact Testnet-10 virtual DAA and UTXOs for one explicit kaspatest address. GH-205 composes one complete owner-pinned snapshot through that injected/live observation, a credential-free loopback-only local IPFS gateway, exact CID/content binding, and one atomic scanner replacement. GH-207 adds an owner-local POSIX checkpoint ordered by minimum verified virtual DAA, rejects rollback and same-order equivocation across restarts, and supports exact replay recovery. GH-209 adds bounded opt-in development orchestration. GH-211 adds a strict canonical BIP340-authenticated complete-snapshot envelope using a separately owner-pinned x-only key, external nonzero minimum sequence, and separately trusted clock rechecked on every fetch. Merged and exact-main-verified GH-213/PR #214 at bbe7efb adds an operator-invoked Development/Testnet-10 preflight/run CLI with private strict local files, offline non-mutating preflight, loopback-IP-literal RPC/IPFS, redacted status, and signal cancellation; CI 31950806131, Security 31950806118, and Pages 31950805653 pass. It authenticates one owner-authorized snapshot envelope only; it adds no signer, key-authority/rotation proof, persistent sequence authority, autonomous authority, wallet, chain write, independent proof of RPC truth or history, consensus finality, canonical manifest authority, IPFS availability or replication, production YARA quality, deployment, Mainnet, or production readiness.

Merged and exact-main-verified GH-216/PR #217 at 13c1812 exercises that real CLI binary against test-only ephemeral loopback wRPC/IPFS peers. It covers offline/connected preflight, private checkpoint commit, SIGTERM/SIGINT drain, restart exact replay, rollback/equivocation rejection, and malformed, timeout, or disconnected peers; CI 31978132036, Security 31978132044, and Pages 31978131647 pass. This is local Development evidence only, not public Testnet operation, independent RPC/IPFS truth or availability, deployment, Mainnet, or production readiness.

Prometheus is designed to complement existing tools, not replace them. Today the Light Client is a development foundation, not a production AI detector; any future layered-defense claim requires real inference, real-sample evaluation, endpoint telemetry, and independently reviewed response behavior.

Prometheus has no repository-controlled emergency-stop entrypoint. That invariant is not proof of decentralized operation. Current evidence relies on owner-controlled policies, membership files, and local trust anchors; no public multi-host Prometheus network is operating.

GH-242 removes one local caller-assertion path by deriving ballot committees and public BIP340 signer assignments only from an owner-loaded canonical membership source with a separately trusted network and expected epoch. PR #243 merged normally as exact main 5cb132c670d1e7771ccaf6dab2ddf5b1a6fd905a; exact-main CI 33433012614, Security Audit 33433012605, and Pages 33433011653 pass. It does not make that source externally authoritative, prove key ownership or rotation, prevent Sybil identities, or establish decentralized or production operation.

Merged and exact-main-verified GH-246 adds signed owner-pinned transition continuity and durable rollback, same-epoch equivocation and replay rejection. New ballot sessions use only the ledger's current source. This does not establish who should control the pinned key, prove key ownership or rotation, resist Sybil identities, or demonstrate decentralized or production operation. PR #247 squash-merged normally as exact main f12e821bb492caae3b94e5b3c882488eb7f2982d; CI 33452085421, Security Audit 33452085419, and Pages 33452084065 pass.

Merged and exact-main-verified GH-253/PR #254 at 5920cb4bb737376977f762beb0d5e3108519c7a0 rotates that transition key through an owner-local repository mechanism. The current key authorizes one gapless successor and the new key independently proves possession; current membership, time, nonce and durable replay state are bound atomically, and later membership transitions use only the current durable key. Prometheus CI 34031999904, Security Audit 34031999907, and Pages 34031999575 pass. This owner-local mechanism does not prove real-world key ownership, decide external/decentralized membership authority, resist Sybil identities, attest on L1, or establish deployment or production operation.

Availability also depends on Kaspa, IPFS replication, participating nodes, clients, and network access.

No central kill switch. This invariant does not justify absolute claims about uninterrupted access or network operation.

Desktop and mobile releases are readiness-gated, not date-gated. Production proof artifacts, the v2 observable path, operated networking, security review, and core rollout evidence must pass first.

Flutter remains the mobile implementation target. Production inference and background-scanning behavior still require platform-specific implementation and review.

05

Participation

Target roleFuture verified contributionPlanned PROM share
Light ClientValidated threat reports15%
Guardian NodeAccepted rule proposals30%
Validator NodeKAS-backed honest voting40%
Honeypot NodeValidated discoveries5%

No PROM minting or reward path is active. Running development software earns nothing; all shares require future implementation, audit, deployment, and consensus-verified contributions.

Target rolePlanning profileStatus
Light Client4 GB RAM, no GPU targetReal ONNX inference open
HoneypotIsolated server targetNot implemented
Validator2 vCPU / 4 GB RAM + 10,000 KAS targetNo operated network
Guardian (8B)NVIDIA GPU, 24 GB VRAM targetNo evaluated real-model run
Guardian (70B)4x A100/H100 80 GB targetNo evaluated real-model run

These are planning profiles, not certified production requirements. Hardware alone grants no membership, authority, reputation, or influence.