# Grant Application - Offensive Security #340

**URL:** https://forum.zcashcommunity.com/t/grant-application-offensive-security-340/56474
**Category:** Applications
**Created:** [June 30, 2026, 9:29pm UTC](https://forum.zcashcommunity.com/t/grant-application-offensive-security-340/56474 "2026-06-30T21:29:08Z")
**Posts on this page:** 1
**Showing post:** 8

<div class="post-metadata">

### Author: ![phill](https://sea2.discourse-cdn.com/zcash/user_avatar/forum.zcashcommunity.com/phill/32/46087_2.png) [@phill](https://forum.zcashcommunity.com/u/phill)
#### Post date: [August 9, 2026, 7:28pm UTC](https://forum.zcashcommunity.com/t/grant-application-offensive-security-340/56474/8 "2026-08-09T19:28:26Z")

</div>

**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.

---

_[View the full topic](https://forum.zcashcommunity.com/t/grant-application-offensive-security-340/56474)._