Month: 1 · Period: mid-July to mid-August
Summary
- First iteration of ecosystem mapping (pre-reconnaissance) completed
- Monitored the Ironwood (NU6.3) mainnet activation end-to-end
- First darknet-monitoring engagement live
Ecosystem mapping & scoping (Pre-reconnaissance)
Built an inventory of the zcash ecosystem
- Assets catalogued: 139
- Coverage dimensions: 15
Reconnaissance
In-progress
Active infrastructure assessments
- Initial findings under investigation: 25
- Defensive positives: reviewed signing / spend-authority components — soundly built; prior third-party audit of a server-side component verified fixed.
Dark PII Reconnaissance
- Organizations opted in: 1
- Individuals assessed: 13
- Identifier touch points: 80+
Projects
Ironwood (NU6.3) activation monitoring
Ironwood network upgrade activated on mainnet on 28 July 2026 at ~14:08 UTC (block 3,428,143). A network upgrade is a moment of elevated risk so this event was treated it as a live resilience test.
Captured a clean pre-activation baseline and a post-cutover rebaseline (including a mid-window client version roll) to distinguish upgrade effects from normal variance. This was done by setting set up probes in 5 regions measuring availability, consistency and performance before, during and after. All monitored endpoints stayed online at 100% availability with only minor, expected slowdown.
Attack vectors threat-modeled for the activation window (and watched for live):
| Vector | Outcome |
|---|---|
| Consensus split / chain fork / partition | Not observed — fleet fully converged |
| Infrastructure overload / availability failure under surge | Not observed — 100% availability |
| Light-client server-selection manipulation (eclipse-style) | Monitored — no evidence |
| Exchange/pool cut-over reorg / double-migration races | Monitored (third-party) — no incident |
| Supply-integrity / turnstile verification failure | Turnstile held — no anomaly |
| Privacy / metadata correlation in the high-volume window | Priority hardening area — handled privately |
This also initiated building an eclipse-scenario PoC, as such an attack is cheaper to perform during an upgrade in terms of resources required.
Eclipse-scenario PoC
Isolated lab — own CA + own instances: built a working proof-of-concept of the transport-trust decision a light-client eclipse relies on — taken up to, but deliberately not through, the point of live impact. Certificate pinning is the effective mitigation; specifics held for private disclosure to the affected wallet team.