Frequently asked
questions.

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 Prometheus reward and governance token. It cannot be purchased at launch. It is minted exclusively through consensus-accepted security contribution paths. Canonical Guardian reputation remains separate Kaspa L1 state.

On launch day, zero PROM exist. No presale, no airdrop, no team allocation. The first PROM are minted when the first threat rule passes consensus.

Simultaneously with the mainnet launch, a KAS/PROM liquidity pool opens on Kasplex DEX (funded from the 5% community pool). From this moment, PROM has a market price formed entirely by supply and demand — no ICO, no listing price, no market-making.

The deflationary emission schedule (−10% per year) combined with growing network demand creates natural upward price pressure over time. The more threats Prometheus detects, the more PROM is earned by participants — and the more PROM is needed to vote on governance and access the AI assistant.

Not in the traditional sense. PROM is minted when a threat rule is accepted by consensus — this is performance-based emission.

Guardian Nodes are the closest equivalent to "miners": instead of GPU hashrate, they contribute AI compute and threat intelligence. They run LLaMA 3 to analyze threats, generate YARA rules, and earn PROM for accepted proposals.

The analogy holds deeper: just as Bitcoin miners must spend real electricity to earn Bitcoin, Guardian operators must spend real compute and produce real security value to earn PROM.

Reporters (20%) split: 75% to Light Clients for validated threat reports, 25% to Honeypot operators for zero-day discoveries. Dev Pool (5%) is only released via DAO vote — no automatic flow to any team member.

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

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.

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.

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

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.

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 takes existing state-of-the-art open-source models and specializes them for security work using LoRA fine-tuning. This is the Prometheus metaphor in practice: we take the fire that already exists and give it to humanity in a new, more powerful form.

Proprietary models (GPT-4, Claude, Gemini) are black boxes — nobody can verify what they actually do with your data. For a security system whose core principle is transparency, they are structurally unsuitable. Open source models can be audited, self-hosted, and fine-tuned. Malware samples never leave the local environment.

Through LoRA (Low-Rank Adaptation) — a technique that fine-tunes only 1-5% of the model's parameters. A single A100 GPU is sufficient. No supercomputer needed.

Training datasets:

The result is a security-specialized model that understands malware behavior, CVE correlations, and can generate syntactically valid YARA rules with high confidence.

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.

After 1 month: 50 nodes × 1,000 threats = 50,000 new patterns learned network-wide.

After 6 months: the model outperforms commercial solutions because it trains on real threats from the entire world in real time.

No. Every model update follows this integrity chain:

A manipulated model would produce a different hash and be rejected by every node automatically. Compromising the model distribution would require compromising the Kaspa blockchain itself — which has approximately 50% Byzantine fault tolerance under DAGKnight consensus.

Real-time threat response requires sub-second finality. Ethereum's 12-second blocks make it unsuitable. Kaspa's DAGKnight consensus also shares the 0% pre-mine philosophy of Prometheus — the alignment of values matters.

ClamAV and Wazuh are signature-based — they only detect what is already known and catalogued. A zero-day exploit that appeared 10 minutes ago is invisible to them.

Prometheus detects unknown threats through behavioral AI analysis and swarm intelligence. It also stores rules permanently on a public blockchain that no organization can modify, censor, or selectively enforce.

Prometheus is designed to complement existing tools, not replace them. A device running ClamAV, Wazuh, and the Prometheus Light Client has layered defense — signatures for the known, AI for the unknown.

Prometheus has no repository-controlled emergency stop, foundation server, or central protocol operator. Once deployed, covenant state transitions follow their scripts rather than a developer kill switch.

Availability still depends on Kaspa, participating nodes, clients, and network access; infrastructure can be disrupted or blocked. The absence of an emergency-stop path is a deliberate architectural decision, not an availability guarantee.

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.

Honeypot operators receive the highest reward per discovery because zero-day threats are rare and extremely valuable. A single validated zero-day can earn significantly more than thousands of ordinary threat reports.

The Guardian 8B option was specifically added to lower the barrier for smaller operators. The reputation system automatically filters out low-quality outputs — hardware alone does not guarantee influence.