Guardian centralization risk.Open
This is the most significant structural tension in Prometheus. We document it transparently because pretending it doesn't exist would undermine the trust the protocol depends on.
The problem in one sentence: Using the illustrative planning ranges below, LLaMA 3 70B requires institutional-grade hardware and operating cost. Globally, only a limited number of nodes at this level are realistic. This contradicts the decentralization promise.
All cost figures below are illustrative planning ranges, not current quotes. Acquisition cost may mix new and used purchases; electricity varies materially with regional rates, utilization, cooling, and power limits; cloud pricing varies by provider, commitment, and availability.
| Node Type | Hardware | Illustrative acquisition | Illustrative annual electricity | Accessibility |
|---|---|---|---|---|
| Light Client | Any device, 4 GB RAM | $0 extra | Minimal | Everyone |
| Guardian (8B) | 24 GB NVIDIA GPU (RTX 3090/4090 class) | $800–1,500 | ~$1,000 | Enthusiasts |
| Guardian (70B) | 4× A100/H100 80 GB, 256 GB RAM | $60,000–120,000 | $8,000–12,000 | Data centers only |
| Validator | Standard server + 10,000 KAS | ~$500–1,000 | ~$500–1,000 | KAS holders |
| Honeypot | Any internet-exposed server | ~$0 | Minimal | Everyone |
The 8B Guardian remains accessible on a single 24 GB consumer GPU, including RTX 3090/4090-class hardware. The reputation system rewards quality output regardless of model size. The 70B Guardian is categorically different: it requires institutional-grade infrastructure.
Break-even calculations.
A future Guardian operator would need rewards to cover hardware and operating costs. The following calculations are hypothetical sensitivity scenarios based on planned Year 1 tokenomics, not forecasts or active rewards.
Important caveat: PROM minting, emission, liquidity and trading are not implemented, deployed or active. These values are planning inputs, not current quotes, expected earnings, investment guidance or predictions.
| Variable | Value | Source |
|---|---|---|
| Guardian emission Y1 | 6,000,000 PROM | Whitepaper tokenomics |
| Guardian scenario | 50–150 nodes | Unproven planning assumption |
| PROM per Guardian (avg, 100 nodes) | 60,000 PROM/year | 6M ÷ 100 |
| Reputation weighting | 70B earns ~3–5× more than 8B | Quadratic voting power formula |
Scenario result: Under these selected inputs, 8B has a lower modeled cost threshold than 70B. This does not establish achievable profitability, future PROM value, cloud availability, real model quality or an operating reward path.
| Year | Total Guardian emission | At 100 nodes | At 500 nodes | At 2000 nodes |
|---|---|---|---|---|
| Year 1 | 6,000,000 PROM | 60,000/node | 12,000/node | 3,000/node |
| Year 2 | 5,400,000 PROM | 54,000/node | 10,800/node | 2,700/node |
| Year 3 | 4,800,000 PROM | 48,000/node | 9,600/node | 2,400/node |
The table illustrates how a fixed planned pool would divide across assumed node counts. It does not promise earnings, encourage early participation, or account for eligibility, quality, uptime, abuse controls, market value, taxes or operating-network rules.
Six candidate paths for Guardian centralization.
Repository state machines and an 8B-first routing scaffold exist, but none of these approaches is proven as an operated decentralization solution. Merged and exact-main-verified GH-253/PR #254 adds owner-local transition-key succession mechanics only; real-world key ownership, external/decentralized membership authority, Sybil resistance, model quality, public multi-host behavior and economics remain open, and no production authority follows. Product exact main is 5920cb4bb737376977f762beb0d5e3108519c7a0; Prometheus CI 34031999904, Security Audit 34031999907, and Pages 34031999575 pass.
Current engineering direction: Continue testing the existing hybrid-routing and ensemble state-machine foundations before evaluating them with real models and independent operators. No candidate is approved as a production decentralization solution; pooling, specialization, grants and alternate proof systems require separate design and review.
The chicken-egg problem — and how KAS solves it.
Every decentralized network faces the same fundamental challenge: without nodes, there is no protection. Without protection, there are no users. Without users, there is no incentive for nodes. Prometheus has a structural answer to this that most protocols lack.
The design uses KAS, never PROM, for validator stake. KAS is an external network asset, but this does not automatically give Prometheus economic security. That requires deployed contracts, correct membership and stake operation, adequate value at risk, monitoring and a live validator network.
Design intent: separating KAS collateral from PROM rewards avoids PROM self-staking. It is an incentive assumption, not proof of day-one security or future PROM value.
The specification plans 20M PROM in Year 1 and a declining schedule. Actual per-node issuance would depend on implementation, verified contributions, eligibility, abuse controls and active operation. No early-operator return is promised.
Mo 1–3
Mo 4–12
Year 2+
Sybil resistance for Guardians.Partial
An attacker who operates 10 A100 GPUs could theoretically create 5 independent 70B Guardian identities and dominate the pre-analysis stage — injecting malicious YARA rules.
- Quadratic voting power: power = (reputation / 100)² × compute. Linear expansion of nodes does not linearly expand power.
- PoW registration: Difficulty scales with current Guardian count. 100 fake nodes cost 100× the registration effort.
- Historical success rate: New nodes start at reputation 0.1 (REPUTATION_START). Building influence requires a track record of accepted proposals — which requires honest behavior over time.
- Validator final gate: Guardians propose, Validators decide. Even if all Guardians collude, 67% of Validators (who have KAS at risk) must also approve.
How do we prevent a single operator with 10 A100s from registering 5 independent 70B identities? Current PoW scales with node count but does not verify that two nodes are operated by different people. Proposed approaches under consideration:
- Require KAS or PROM stake per Guardian identity (financial Sybil cost)
- Minimum time-weighted reputation before high voting power (slow Sybil)
- Hardware fingerprinting via ZK-proof (verifiable compute without revealing identity)
- Geographic distribution requirements (prevents single-datacenter dominance)
Status: This is an open design question. Community proposals are welcome. A final mechanism will be specified before mainnet deployment.
60-second SLA under real-world load.Partial
The repository has a same-host development-stub fixture below 60 seconds. It is not a guarantee or production performance evidence because it has no real model, approved proof, public network load, IPFS availability or operated consensus.
| Step | Target time | Risk factor | Status |
|---|---|---|---|
| ZK-proof generation | ~2s | CPU: 5–30s possible on weak hardware | Risk |
| LLaMA inference | ~12s | High load: queue buildup on popular Guardian nodes | Risk |
| Network propagation | ~1s | Intercontinental latency: +100–300ms per hop | Low risk |
| Validator voting window | 20s | Fixed — not a bottleneck | Fixed |
| Kaspa finality | <1s | DAGKnight — proven | Proven |
The real risk is ZK-proof generation on low-end hardware. Groth16 on a 5-year-old laptop CPU can take 20–30 seconds — which would push the total time beyond 60 seconds before the threat even reaches the first Guardian node.
Mitigation under evaluation: PLONK proofs (faster on CPU) as alternative to Groth16. Local GPU for Light Clients as optional recommendation. Asynchronous proof generation (Light Client submits hint immediately, proof follows). Final decision in Sprint 9.
8B vs 70B YARA rule quality.Acknowledged
| Task | LLaMA 3 8B | LLaMA 3 70B |
|---|---|---|
| Known malware families | Not evaluated | Not evaluated |
| YARA for common CVEs | Not evaluated | Not evaluated |
| Zero-day analysis | Not evaluated | Not evaluated |
| Multi-stage threats | Not evaluated | Not evaluated |
| YARA syntax correctness | Compile-only fixture exists | No real-model output evaluated |
No independently evaluated real 8B/70B run, calibration, real-sample quality result or actionable authority is published. The 85% threshold and reputation transitions are policy/state-machine inputs, not proof of detection quality or a requirement that 70B solves zero-day analysis.
Questions we do not yet have answers to.
The following are genuine open questions where Prometheus would benefit from community research, academic collaboration, or external input. If you have relevant expertise, contributions are welcome.
- Guardian routing mechanism: What is the optimal algorithm for deciding 8B vs 70B escalation? Confidence-score-based? Reputation-weighted? Random sample? Combination?
- Ensemble protocol design: If 7 of 10 8B Guardians agree on a YARA rule — what constitutes "agreement"? Exact match? Semantic similarity? Confidence-weighted average?
- PLONK on Kaspa: Does the Kaspa L1 support PLONK proof verification natively, or would this require a protocol change?
- YARA-specialized 8B model: Training a fine-tuned 8B exclusively on YARA syntax and CVE datasets — does this reach 70B quality for rule generation while keeping inference lightweight?
- On-chain reputation formula: The current formula (quadratic voting power) works well theoretically. Does it hold under adversarial conditions with coordinated reputation farming?
- Guardian Pooling cryptography: How do multiple operators share a 70B node with on-chain PROM splitting without any single operator being able to defect with the full reward?
- Sub-1B ZK-capable models: Are there models under 1 billion parameters that can reliably detect specific anomaly types — small enough to run on IoT devices or phones with <2 GB RAM?
- Decentralized Guardian orchestration: How do Guardians coordinate without a central coordinator — especially for multi-stage threat analysis that requires sequential steps?
- Privacy-preserving model evaluation: Can we verify that a Guardian's AI model is the authentic, unmodified version using ZK-proofs — without revealing model weights?
Contributing: Open issues for each of these research questions are tracked in the GitHub repository. If you have relevant expertise in cryptography, distributed systems, or ML, your input is genuinely valued. This is not vaporware — the foundation code exists and these are real engineering problems.