Security Program
Continuous adversarial testing against state-level synthesis attacks. Methodology public, defenses layered, results measured.
Who we build against
We assume a well-resourced adversary with access to modern voice cloning (XTTS-v2, F5-TTS, ElevenLabs), generative models for biometric time-series, full source-code access to our public components (SDK, circuits, on-chain programs), unlimited wallets and devnet SOL, and days to weeks of time per attack campaign.
We do not assume the adversary can compromise user devices, mount physical hardware attacks on phones, or access our private defense-layer infrastructure. Those are separate threat categories covered by standard client-side hardening, hardware root-of-trust guidance, and infrastructure security practice respectively.
How we defend
Zero-knowledge proofs of behavioral consistency. Groth16 proving system. Public verifier on Solana. Every verification produces a proof that the user’s behavioral fingerprint is within a hidden Hamming distance threshold of their baseline, without revealing either fingerprint. Open source, auditable, verifiable on-chain.
Server-side validation of the 134-dimensional feature vector extracted from each verification. Multiple independent checks verify that the statistical properties of extracted features are consistent with human physiology, not synthetic generation. Specific checks and threshold values are not published.
Time-series analysis of phonation and kinematic signals sampled during capture. Real human speech and hand motion share motor-cortex origins and produce measurable temporal coupling at short lags; independent synthesis does not. Currently deployed in structured-log mode for empirical threshold calibration; enforcement flips after pen-test data validates the signal.
How we test our defenses
We maintain an internal adversarial testing harness that runs continuously against our production verification pipeline. The harness implements eight distinct attack tiers, ordered by sophistication. Each campaign generates hundreds to thousands of bot attempts, measures pass rates per defense layer, and feeds the results into threshold calibration and defense roadmap decisions.
| Tier | Attack class | Tests defense against |
|---|---|---|
| T1 | Procedural synthesis (script-kiddie baseline) | Absolute attacker floor |
| T2 | Parameter-varied procedural | Tier 1 cross-modality and variance checks |
| T3 | Feature-space optimization with source access | Tier 1 distributional realism |
| T4 | Modern voice cloning (XTTS-v2, F5-TTS, API-based) | Tier 1 TTS artifact detection |
| T5 | Coupled cross-modal synthesis | Tier 2 temporal coupling |
| T6 | Targeted human-mimicry / identity theft | Hamming distance gate + Sybil registry |
| T7 | Replay with adversarial perturbation | Min-distance floor + commitment registry |
| T8 | Black-box adaptive probing | Rate limits + response opacity |
Attack implementation code, per-attempt telemetry, and specific parameter values that produce elevated pass rates are kept in a private repository per responsible-disclosure convention. This matches the posture of comparable infrastructure projects (Ethereum Foundation, Uniswap, Aztec, MakerDAO) and professional security programs (NCC Group, Trail of Bits): methodology public, weapons private.
Current measurements
| Attack tier | Pass rate | Cost per success | Status |
|---|---|---|---|
| T1 | ~0% | negligible | Defended (baseline) |
| T2 | pending | pending | Log-only measurement |
| T3 | pending | pending | Not yet tested |
| T4 | pending | pending | Log-only measurement |
| T5 | pending | pending | Log-only measurement |
| T6 | pending | pending | Not yet tested |
| T7 | pending | pending | Not yet tested |
| T8 | pending | pending | Not yet tested |
Last updated: April 2026
Pass rate = fraction of bot attempts that successfully create or update an on-chain Anchor. Cost estimates in devnet SOL + wall-clock time per successful identity. Rounded to prevent adversarial threshold inference.
What we open-source, and why
IAM Protocol is open-source where open-source matters for user trust, and deliberately private where privacy protects users. This split is standard practice across Ethereum Foundation, Uniswap, Aztec, MakerDAO, and professional security-program norms. Not a departure from crypto's open-source values. A mature implementation of them.
Open source (MIT)
- ›On-chain programs (iam-anchor, iam-verifier, iam-registry)
- ›ZK circuits and trusted setup artifacts
- ›Client SDK (pulse-sdk on npm)
- ›Executor node
- ›Website and documentation
- ›Security program page, blueprint documents, and aggregate results
- ›Baseline adversarial testing (script-kiddie tier in pulse-sdk)
Private (defense-layer only)
- ›Server-side validation service (iam-validation): check thresholds and parameter values
- ›Red-team harness (iam-redteam): attack code, per-attempt telemetry, captured baseline fixtures
- ›Pre-disclosure vulnerability reports (per standard responsible-disclosure practice)
Nothing that affects verifiable protocol behavior is private. Every on-chain transition, every cryptographic operation, every client-side computation is open and auditable. The private components are the detection surface an attacker would otherwise exploit to calibrate their attacks.
Reporting vulnerabilities
Learn more
Read the research behind our verification pipeline.