Audit Status

Specter has undergone multiple independent security audits covering smart contracts, ZK circuits, scaling infrastructure, and operational security. This page summarizes audit findings, remediation status, and outstanding mainnet-blocking issues.

Audits are a point-in-time assessment. They identify issues in the codebase as it existed at audit time. Subsequent code changes may introduce new issues or resolve identified ones. This page reflects the current understanding of all findings.

Audit Summary

Audit	Total Findings	Critical	High/Major	Medium	Low/Minor	Informational
Smart Contract	65	3	14	18	16	14
ZK Circuit	11	1	2	2	2	4
Scaling Contracts	24	2	2	9	8	3
Infrastructure	25	2	4	10	7	2
Total	125	8	22	39	33	23

Smart Contract Audit

Scope

The smart contract audit covered the core Ghost Protocol contracts deployed on Specter's EVM:

Contract	Description
CommitRevealVault	Core commit/reveal logic — accepts commitments, verifies proofs, processes reveals
NullifierRegistry	Tracks spent nullifiers to prevent double-spending
CommitmentTree	Merkle tree implementation for commitment storage and root management
NativeAssetHandler	Bridges between native Cosmos SDK tokens and EVM-side operations via the ghostmint precompile
AssetGuard	Controls which assets can enter and exit the privacy system
Policy contracts	Programmable constraints on commit/reveal operations (time locks, amount limits, compliance rules)

Findings Breakdown

Severity	Count	Description
Critical (3)	3	Issues that could result in loss of funds, broken privacy guarantees, or protocol bypass
Major (14)	14	Issues that could result in degraded security, incorrect state, or exploitable edge cases
Medium (18)	18	Issues with limited exploitability but requiring code changes for correctness
Minor (16)	16	Code quality, gas optimization, and defensive programming improvements
Informational (14)	14	Best practices, documentation gaps, and stylistic suggestions

Key Finding Categories

• Access control: Several functions lacked appropriate caller restrictions, potentially allowing unauthorized state modifications.
• Reentrancy: Token callback patterns required reentrancy guards in specific reveal flows.
• Integer handling: Edge cases in amount encoding/decoding for the 7-input token commitment variant.
• Root staleness: Insufficient validation of Merkle root freshness in certain reveal paths.
• Policy bypass: Specific sequences of operations that could circumvent policy constraints.

ZK Circuit Audit

Scope

The ZK circuit audit covered the Circom circuits that generate and verify zero-knowledge proofs:

Circuit	Description
redemption.circom	Core reveal circuit — proves knowledge of commitment preimage and Merkle membership
accessProof.circom	Persistent access circuit — proves knowledge without consuming the nullifier
Commitment libraries	Shared Poseidon hashing and constraint generation code used by both circuits

Findings Breakdown

Severity	Count	Description
Critical (1)	1	Constraint under-specification that could allow proof forgery
High (2)	2	Missing range checks and insufficient input validation
Medium (2)	2	Redundant constraints and optimization opportunities
Low (2)	2	Documentation and naming clarity
Informational (4)	4	Circuit design patterns and best practices

Key Finding Categories

• Under-constrained signals: A circuit signal that was not fully constrained, potentially allowing an adversary to manipulate a proof input without detection.
• Range checks: Missing bit-length constraints on inputs that should be bounded to specific ranges (e.g., token amounts must fit in 64 bits).
• Nullifier derivation: Verification that the nullifier derivation path in the circuit matches the on-chain expectation exactly.

Scaling Contracts Audit

Scope

The scaling contracts audit covered the batch processing and session infrastructure designed for high-throughput operations:

Contract	Description
BatchCommitRevealVault	Processes multiple commits and/or reveals in a single transaction
SessionVault	Manages session-based access with time-bounded authentication
RunnerRegistry	Registry for authorized proof generation runners in the scaling infrastructure
ShardedTreeRegistry	Manages multiple Merkle tree shards for horizontal scaling

Findings Breakdown

Severity	Count	Description
Critical (2)	2	Issues in batch processing that could corrupt Merkle tree state or allow cross-session attacks
High (2)	2	Race conditions in concurrent session management
Medium (9)	9	Gas optimization, event emission completeness, and edge case handling
Low (8)	8	Code quality and documentation
Informational (3)	3	Architecture suggestions

Key Finding Categories

• Batch atomicity: Ensuring that a partially-failed batch does not leave the Merkle tree in an inconsistent state.
• Session isolation: Preventing one session's proof from being replayed in another session context.
• Shard consistency: Ensuring cross-shard operations maintain global nullifier uniqueness.
• Runner authorization: Access control for the runner registry to prevent unauthorized proof submissions.

Infrastructure Audit

Scope

The infrastructure audit covered operational security of the deployed system:

Component	Description
Validator node	CometBFT validator configuration, key management, sentry node architecture
Relayer services	Root Updater, Commitment Relayer, Proof Relayer — authentication, rate limiting, input validation
Firewall	Network configuration, port exposure, ingress/egress rules
TLS	Certificate management, cipher suite selection, HSTS configuration

Findings Breakdown

Severity	Count	Description
Critical (2)	2	Exposed management interfaces and insufficient key protection
High (4)	4	Missing rate limiting on critical endpoints, weak TLS configurations
Medium (10)	10	Logging gaps, monitoring coverage, backup procedures
Low (7)	7	Documentation, operational procedures, and configuration hardening
Informational (2)	2	Best practices and recommendations

Key Finding Categories

• Key management: Validator private keys and relayer signing keys required improved storage and rotation procedures.
• Rate limiting: Several relayer endpoints lacked per-IP and per-wallet rate limiting, enabling potential denial-of-service.
• Monitoring: Insufficient alerting on anomalous patterns (e.g., rapid nullifier spending, unusual proof generation rates).
• TLS configuration: Cipher suite and protocol version hardening recommendations.

Mainnet-Blocking Issues

The following issues have been identified as blockers for mainnet launch. All are tracked and remediation is planned:

Issue	Source Audit	Severity	Status	Description
Phase 2 Trusted Setup	ZK Circuit	Critical	Planned	The current circuits use a development-phase trusted setup. A public multi-party computation (MPC) ceremony is required before mainnet to ensure no single party holds the toxic waste.
SessionVault Payment Timing	Scaling Contracts	Critical	Identified	A timing vulnerability in session payment processing that could allow a session to be used without completing payment.
Policy Validation Bypass	Smart Contract	Critical	Identified	A specific sequence of operations that can circumvent policy enforcement under certain conditions.

Remediation Timeline

Audit Philosophy

Specter treats audits as one input to a broader security strategy, not as a certification of correctness. The complete security approach includes:

1. External audits — independent expert review (completed, documented above).
2. Formal verification — mathematical proofs of circuit constraint correctness (research phase).
3. Fuzz testing — automated property-based testing of contract edge cases (ongoing).
4. Bug bounty — public reward program for responsibly disclosed vulnerabilities (planned for mainnet).
5. Incremental deployment — testnet operation with progressive feature activation before mainnet.

No software is bug-free. The goal is to systematically identify, prioritize, and remediate issues before they can be exploited, and to design the system so that individual component failures do not cascade into catastrophic outcomes.