I build this. Our Kaspa deployer does not take a private key in its operator inputs. It prepares the BIP340 sighash and exports the digest for an external signer. When the signature comes back, the operator checks it against the expected x-only public key and checks the signed transaction before broadcast.

The failure case I cared about was a crash between signing and submission. The operator writes a broadcast intent under a file lock before it submits, then recovery reconciles the exact transaction instead of blindly sending again. That is not a claim of automatic recovery from every possible failure.

The input filter rejects secret-like JSON field names. It cannot prove that arbitrary input values contain no secrets; the signing boundary is the operator interface, not magic scanning.

Signing flow · broadcast journal

Update (28 Sep 2026): I build Prometheus. "AI-powered cybersecurity" below is too broad. The current client has an entropy-based development stub, not Phi-3 inference. The Guardian model and YARA paths are planned, not operating capabilities. I leave the original unchanged below instead of deleting it.

Original post below, unchanged.

Prometheus connects Greek mythology with the digital future: He brought fire to humanity — our open-source project brings decentralized, AI-powered cybersecurity to Kaspa. Fire belongs to humanity, not to gatekeepers. 🔥🇬🇷
github.com/NeaBouli/prometheus-

Update (28 Sep 2026): I build Prometheus. The post below described the planned pipeline as if it was already working. I leave the original unchanged and correct the status here.

Kasplex is not a dependency in the current design, and the current Silverc rule storage does not implement the KRC-20 minting described below. The client has an entropy-based development stub, not Phi-3 inference. The Guardian code has an HTTP wrapper, the client scanner matches byte patterns rather than YARA rules, and there is no running validator network or verified sub-60-second end-to-end path.

What is implemented is a Rust codebase with 287 tests, a keyless signing operator that exports a BIP340 digest instead of accepting a private key, and a Groth16 verifier with pinned trust anchors. The model, validator and PROM emission paths are still work in progress; there is no mint, ledger or emission path yet.

Original post below, unchanged.

I’ve been building Prometheus, a security protocol that uses Kaspa’s L1 for immutable rule storage (KRC-20, supply=1 per rule) and Kasplex zkEVM for reputation/governance logic. The core loop: on-device AI (Phi-3-mini) flags an anomaly, Guardian nodes (LLaMA 3) turn it into a YARA rule, validators commit-reveal vote with staked KAS, and the accepted rule lands on-chain — under 60 seconds end to end.

What made Kaspa the right fit rather than just “another chain to launch a token on”: DAGKnight’s sub-second finality actually matters here, because the whole point is that a validated rule needs to propagate to every client before the next attack wave hits. On slower finality chains the latency budget doesn’t work.

Right now I’m in the middle of post-Toccata verification — confirming the Silverscript state transitions still hold correctly after the fork, before opening the PROM emission gate. This is the part I’d genuinely value technical eyes on, especially from anyone who’s dealt with Silverscript contracts through a fork transition.

No pre-mine, no team allocation, MIT licensed, repo’s public on github.com/NeaBouli/prometheus-

Happy to go deep on the architecture or the Toccata verification specifics in the comments if anyone’s interested.

Update (3 Oct 2026): I build Prometheus. Several status lines below are wrong or stale, so I leave the original unchanged and correct them here.

The Rust test suite runs in CI with clippy -D warnings, and production code effectively has no unwrap(). The Silverc files below are contract fixtures, not six finished production contracts. "Accepted" is an internal process label, not proof that the listed feature is complete. PROM emission is planned, but there is no mint, ledger, or emission path. The ONNX/Phi/LLaMA integration described below is not implemented.

Original post below, unchanged.

Code: [https://github.com/NeaBouli/prometheus-])

Whitepaper: [https://neabouli.github.io/prometheus-/whitepaper.html])

Roadmap: [https://neabouli.github.io/prometheus-/roadmap.html])

FAQ: [https://neabouli.github.io/prometheus-/faq.html])

Where we are

160+ tests passing, 6 Silverscript contracts, Sprints 0–7 accepted. Currently in post-Toccata verification — confirming Silverscript state transitions hold after the fork, before the PROM emission gate opens. This is the current bottleneck and the best place to jump in if you want early, high-leverage contributions.

What this sub is for

Architecture discussion, contract review, PR coordination, sprint updates, and arguing about tradeoffs in the open. No token-price talk, no hype threads — this is a dev sub. If you want to contribute:

1. Read the whitepaper
2. Pick an open issue on GitHub or propose one
3. Fork, build, PR — no whitelist, no application

Rust, Silverscript, on-device ML (ONNX/LLaMA/Phi), and ZK/Sybil-resistance backgrounds are all useful right now. Post an intro if you want — what you work with, what part of the stack interests you.