Month: 1
Infrastructure:
Assets catalogued: 139
Findings under investigation & undisclosed: 25
Active advisories monitored: 22 (not ours; several intersect our findings)
Reports/vulnerabilities delivered: 2/19
Dark PII Recon:
Organisations opted in: 1
Individuals assessed: 13
Identifier touch points: 80+
Notes:
Defensive positives: reviewed signing / spend-authority components — soundly built; prior third-party audit of a server-side component verified fixed.
Summary
First iteration of ecosystem mapping (pre-reconnaissance) completed
Survey and Inventory of all assessable assets in-porgress
Monitored the Ironwood (NU6.3) mainnet activation end-to-end
First darknet-monitoring engagement live
Projects
I believe that the Ironwood upgrade event took precedence over the initial milesontes, below is a summary of what that event entailed from an offensive point of view.
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.
Finding: 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.