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: LLaMA 3 70B requires hardware that costs $60,000–120,000 to acquire and $8,000–12,000/year to operate. Globally, only 50–200 nodes at this level are realistic. This contradicts the decentralization promise.
| Node Type | Hardware | Acquisition cost | Annual electricity | Accessibility |
|---|---|---|---|---|
| Light Client | Any device, 4 GB RAM | $0 extra | Minimal | Everyone |
| Guardian (8B) | RTX 4070 Ti+, 16 GB VRAM | $800–1,500 | ~$1,000 | Enthusiasts |
| Guardian (70B) | 4× A100/H100, 128 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 is accessible — RTX 4070 Ti hardware is within reach for enthusiasts, and the reputation system rewards quality output regardless of model size. The 70B Guardian is categorically different: it requires institutional-grade infrastructure.
Break-even calculations.
For a Guardian operator to run a node economically, PROM earnings must cover hardware and operating costs. The following calculations use conservative assumptions and are based on Year 1 emission.
Important caveat: PROM has no price before mainnet (May 5, 2026). These calculations use target price scenarios — not predictions. Actual economics depend entirely on market adoption.
| Variable | Value | Source |
|---|---|---|
| Guardian emission Y1 | 6,000,000 PROM | Whitepaper tokenomics |
| Active Guardians (realistic Y1) | 50–150 nodes | Conservative estimate |
| 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 |
Key insight: The 8B Guardian is economically the most attractive entry point. Break-even at $0.10/PROM is achievable if the network gains meaningful adoption. Cloud-hosted 70B is actually more capital-efficient than owning hardware — but depends entirely on PROM market price.
| 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 |
Early operators earn significantly more PROM per node — both because emission is higher in Year 1 and because fewer nodes compete for rewards. This is the strongest economic argument for early participation despite the uncertain PROM price.
Five paths to solving Guardian centralization.
None of these solutions is implemented yet. They represent the current best thinking on how to address the problem. Community input is explicitly invited — this is an open design question.
Current recommendation: Solutions 1 (Hybrid Routing) and 2 (Ensemble Voting) can be implemented immediately with existing architecture. They are the highest-impact, lowest-risk interventions. Solutions 3–6 require additional protocol design and will be addressed in Sprints 9–14.
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 critical insight: KAS already has economic value. On day one of mainnet, Validators stake KAS — an asset worth over $1 billion in market capitalization that has been established since 2021. This means Prometheus inherits real economic security immediately, without waiting for PROM to develop a price.
Why this matters: Most new protocols bootstrap security with their own token that has zero initial value. Prometheus bootstraps with KAS — a proven asset. Security comes from established value on day one. PROM can develop a price organically, under no pressure to be the primary security mechanism.
The deflationary emission schedule creates a natural bootstrapping incentive. Year 1 emits 20M PROM across fewer nodes than Year 3. An operator who joins in Month 1 earns dramatically more PROM per node than one who joins in Year 2 — at lower competition and higher token scarcity.
This is not artificial scarcity. It is a direct consequence of the network growing while emission decreases. The economic rational actor calculation strongly favors early participation even under price uncertainty.
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 60-second end-to-end guarantee has been proven in E2E tests — but under controlled conditions with no network latency, no load, and stub implementations for ZK-proof and AI inference.
| 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 | Adequate (with fine-tuning) | Reliable |
| YARA for common CVEs | Possible with fine-tuning | Reliable |
| Zero-day analysis | Insufficient alone | Required |
| Multi-stage threats (>128k context) | Context window too small | 128k token context |
| YARA syntax correctness | Improvable via YARA-specific fine-tuning | High quality |
The 85% confidence threshold combined with the reputation system provides a natural quality filter — 8B Guardians that produce poor rules lose reputation and influence over time. However, for genuine zero-day threats, 70B remains necessary. This is why maintaining at least a small number of 70B Guardians in the network is critical even if 8B dominates in count.
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.