Rules & safe harbour

In scope

• The four edge nodes' /hyveguard/challenge HTTPS endpoints.
• The signature submission endpoint on this landing page.
• The four challenge VPS hosts and any service they advertise on this page.
• Port scanning and network probing of the four challenge hosts — explicitly authorised to participants under this policy. Upstream providers' AUPs generally require explicit authorisation from the destination; we are the destination and we are authorising you.
• The .onion mirror of this landing page.
• The published canonical challenge string (today's and any future day's, once it rotates).

Out of scope

• Denial-of-service in any form — volumetric, application-layer, slowloris, amplification, resource exhaustion. The point is to break the system, not knock it offline. This mirrors every upstream provider's AUP; you will get the challenge boxes terminated AND be in breach of their separate contract with us.
• Port scanning or network probing of any host other than the four challenge nodes, regardless of how you reach it (pivoted, adjacent subnet, provider metadata service, etc.). Our authorisation only covers our boxes.
• Attacks against upstream providers — OVH, Netcup, DigitalOcean, Vultr, Cloudflare, the registrar, or their staff or infrastructure.
• Other tenants on shared hardware. If your attack would touch a host that isn't ours, it's out of scope.
• Social engineering against the operator, the operator's family, or any third party.
• Publishing the challenge IPs alongside an invitation to flood them — or any other activity whose foreseeable consequence is a DDoS or retaliation event against our upstream provider. One of them (DigitalOcean) explicitly reserves the right to terminate us if our boxes become the target of such an event, even if we didn't invite it. So don't.
• Running your attack through a Tor exit node that you operate on any of our upstream providers. OVH, Vultr, and DigitalOcean all prohibit hosting Tor exit nodes on their infrastructure. Our hidden service mirror is not an exit node — that's fine. Your exit node is yours to sort out with whichever provider you're using.
• Physical attacks against any equipment or facility.
• Activity that intentionally degrades service for other researchers.

Out-of-scope activity is not authorised under this policy, voids your safe harbour, and may be reported to the relevant provider.

Safe harbour

If you make a good-faith effort to comply with this policy:

1. We will not initiate or recommend legal action against you for your research.
2. We will not pursue a complaint with your educational institution or employer.
3. We will not seek a complaint under the UK Computer Misuse Act 1990 (or any local equivalent) for activity within the scope above.
4. We will treat you as an authorised researcher.
5. If a third party initiates legal action against you for in-scope research, we will publicly state that your activity was authorised under this policy.

Tier rules — Heimdall's trials

1. Draugr — Barrow-breach
   Submit a planted flag from any single node. The flag is a file on disk — find it, read it, submit the value. Timestamps must be consistent with your reported access window.
2. Berserker — Hall-breaker
   Submit a flag from a PostgreSQL row on any node. We've planted them behind real application stacks; they rotate location each season.
3. Skald — Bridge-walker
   Submit flags from ≥2 distinct nodes, with proof of pivot path (DAG entries, traffic timing, or equivalent evidence that you moved between realms).
4. Seiðr — Rune-forger
   A valid Ed25519 threshold signature against today's canonical challenge bytes under the cluster's group_pub. Verifier runs ed25519.Verify(group_pub, canonical, sig). The Gjallarhorn sounds. Bifrost shatters. Season ends.
5. Einherjar — The Unseen
   Achieve Seiðr with zero canary trips, zero Merkle drift, zero alerts throughout the entire approach. Confirmed via clean audit DAG at season end. Heimdall never tells you what he saw — you may genuinely never know whether a canary fired.

Tripping a canary, a honey port, or a DNS sentinel does not banish you. It silently records that Einherjar is no longer in play this season.

Reporting

All tier captures (Draugr / Berserker / Skald flag strings and the Seiðr signature) go through the single form on the landing page. The cluster auto-detects the format, verifies in constant time against the on-box hashed vault (Draugr–Skald) or runs ed25519.Verify against today's canonical bytes (Seiðr), and credits the supplied handle. Einherjar is auto-derived at season end if the audit DAG is clean. No email channel for tier captures.

CVE-style vulnerability disclosure (a code-level bug that warrants out-of-band coordination, redaction, or coordinated release): PGP-encrypted email to [email protected] (key). Acknowledgement within 72 hours. Triage within 7 days. Resolution depends on severity; we aim for ≤30 days for confirmed vulnerabilities.

For a vulnerability disclosure, include:

• Your handle (the one you'd like credited).
• Reproduction steps.
• Impact assessment.
• Any artefacts (logs, traces, screenshots — redact your own identifying info if you don't want it public).

Recognition

• Public credit on the hall of fame (you choose the handle).
• CVE attribution where applicable. We'll request the CVE; you're listed as the reporter.
• Write-up rights — publish what you want, when you want, with whatever framing you want, no embargo unless you request one.
• Joint blog post on request.

No monetary bounty at launch. May be revisited at the 60-day mark of any season if engagement justifies it.

Out-of-scope reports

If you find something interesting that's out of scope (e.g. a vulnerability in one of the upstream providers), we'll forward it to the right party with credit to you, but we have no authority to grant safe harbour outside this policy.

Upstream-provider status

The four edge boxes are hosted on OVH (France), Netcup (Germany), DigitalOcean (Singapore), and Vultr (Japan). We have checked each provider's AUP against the challenge's activity profile and notified them before launch:

• OVH — permitted under the research/security-testing carve-out of the AUP. We enforce OVH's separate prohibitions (no DoS, no targeting OVH infrastructure) via the out-of-scope list above. Notified before launch.
• Netcup — permitted by absence. Netcup's AUP has no clause either authorising or prohibiting security-research hosting; we notified [email protected] of scope and controls before launch.
• DigitalOcean — DigitalOcean confirmed that testing on our droplet is permitted provided it does not degrade shared-infrastructure performance. Our rules prohibit DoS and resource-exhaustion explicitly. Reference on request via [email protected].
• Vultr — permitted by absence. Vultr's AUP authorises scanning of a destination host when that host's operator consents; we notified [email protected] of scope and controls before launch.

This is why the out-of-scope list above is what it is. Staying inside it keeps us — and your research — inside the four separate contracts we hold with these providers.

Versioning

This policy version: v1.1. Last updated: —.