By building, distributing, or running Nexsiz you acknowledge the following conditions. They exist to keep research productive and to reduce the risk of unintended harm.

Checklist before a campaign

1. Scope document — defined targets, ports, protocols, time windows, and out-of-scope assets.
2. Isolation — prefer dedicated VMs, containers, or lab networks; avoid production paths unless the engagement explicitly requires them.
3. Monitoring — ensure the target owner can observe load, crashes, and resource exhaustion.
4. Data handling — treat seeds, crashes, and NXS artefacts as potentially sensitive; restrict access and retention.
5. RPC exposure — if using -Y, bind only to a local Unix socket with restrictive permissions; never expose the control plane to untrusted networks.
6. Cleanup — remove SHM regions, temporary sockets, and residual process state after the campaign ends.

Red-team / APT-style use

Nexsiz can support authorised red-team operations (protocol fuzzing as part of adversary simulation). In that context:

• Operate strictly inside the approved rules of engagement.
• Coordinate with the blue team on crash reporting and deconfliction when required by the engagement.
• Do not retain or weaponise findings outside the engagement deliverables.

Research & education

• Classroom and lab use is encouraged when targets are purpose-built (intentionally vulnerable services, local daemons).
• Publish methodology and non-sensitive crash patterns; do not publish working exploits against third-party production systems without coordinated disclosure.

No warranty, operator liability

Nexsiz is provided under Apache-2.0 “as is”. The authors accept no liability for damage, downtime, data loss, or legal consequences resulting from its use. The operator who launches the binary is responsible for ensuring every target is in scope and every action is lawful.