@Noctum_io

upcoming: security scanner threat intel the current scanner at https://t.co/N2vL0yFBzX reads Base mainnet directly ERC20 approvals, balances, nonce, contract flags. it does not query Chainalysis, TRM, or any external threat intel database. that is by design. we do not want to send your address to a surveillance API. the next iteration adds pattern-based heuristics derived entirely from on-chain data: cross-pool timing correlation detection, known drainer contract bytecode fingerprinting, and MEV bot interaction flags. no external data. no third-party APIs. the analysis stays on-chain and stays private.

Upcoming: multi-party ceremony the Groth16 proving keys currently live on Base were generated from a Hermez ptau + local single-party zkey setup. the math is correct. the soundness caveat is that the toxic waste from that ceremony was not destroyed in a multi-party setting one party knows it. that matters for real-fund security at scale. so the next step is coordinating a multi-party ceremony with external contributors. each participant adds entropy and deletes their share. a single honest participant is enough to guarantee the final key is sound. details on how to participate will be announced here. this is the one trust assumption left in the protocol.

UPCOMING the contracts running right now on Base are verified, open source, and have passed Slither + Aderyn static analysis. no confirmed exploitable issue. but automated tools are not an audit. we are scheduling a third-party security review by an independent firm. full circuit analysis (the withdraw.circom ZK circuit), smart contract audit across all five Poseidon pools and the Groth16 verifier, and the keccak Phase 1 pool factory. results will be published in full at https://t.co/wfCO9C6cD1 . if something is found, you will know exactly what and how it was addressed. that is what trustless actually means.

The security scanner at https://t.co/N2vL0yFBzX currently reads live on-chain state balances, nonce, contract code, and ERC20 approval history. it flags behavioral signals, not known identities. what it does not do yet: check against external threat intelligence databases. if an address is a known sanctioned entity or linked to documented hacks, the scanner returns clean because it has no access to that data. this is a gap we acknowledge directly. the next iteration adds an external threat intel feed so flagged and sanctioned addresses are identified on scan. until that ships, the scanner is a behavioral tool, not an identity one.

noctum's smart contracts have been analyzed using two automated static analysis tools: Slither and Aderyn. these tools scan Solidity source code and compiled bytecode for known vulnerability patterns reentrancy, unsafe external calls, integer handling issues, access control gaps, and others. neither tool returned critical findings on the pool contracts, the Groth16 verifier, or the Poseidon hasher. the analysis results will be published when the formal writeup is complete. it is important to be precise about what this means. automated static analysis is a useful and important first pass. it is not a security audit. a security audit is a manual review by an independent firm that thinks adversarially about the system, models attacker behavior, and produces a signed report. noctum has not yet commissioned or completed a formal audit. stating otherwise would be false. this work is on the roadmap. the ZK circuit has not yet been reviewed with circomspect, a static analyzer specifically designed for circom circuits. circuit bugs are a distinct class of vulnerability from contract bugs a flawed constraint system can allow invalid proofs to pass verification. circomspect is pending. the trusted setup is also a known limitation: the ptau used is from the Hermez ceremony, but the zkey was generated with a single party locally. this is not a multi-party trusted setup, which means the toxic waste from the ceremony cannot be proven discarded. real ETH deposits carry this risk and users should understand it. the contract addresses, circuit source, deployment scripts, and zk-deployments.json are all public in the GitHub repository. the Groth16 verifier bytecode is deterministic from the circuit anyone with the source and zkey can recompile and verify the deployed bytecode matches. the goal is to make every security assumption visible so users can make informed decisions. an honest security disclosure at this stage is worth more than a false sense of completeness.