[Kayce10]

Summary

Adds docs/src/V2_ANTI_SNIPE_THROTTLE.md, the written analysis requested in #213. Updates docs/src/SUMMARY.md to list it under the Deployment V2 section.

closes #213

What the document covers

• How the existing anti-snipe extension works in register(): any qualifying deposit (landing within anti_snipe_extension_secs of the current soft deadline) pushes the deadline out, capped unconditionally at registration_hard_deadline.
• The cost floor imposed by [Chore] Anti-snipe extension griefable via cheap repeated top-ups #155's effective_minimum: every deposit — first-time or top-up — must clear min_resolution_bond, so dust-sized triggers are already blocked.
• Attack cost modelling for both the single-address repeated top-up and the Sybil path, showing that max_total_weight is the binding constraint in practice (not the number of extension slots anti_snipe_hard_max_secs would theoretically permit).
• Two throttle candidates (first-deposit-only restriction; per-assertion has_been_extended flag) and why each reduces coverage for legitimate late-arriving participants more than it constrains attackers — the Sybil path is unaffected by any per-position restriction.
• A verdict that no throttle is recommended, because the existing registration_hard_deadline + max_total_weight + [Chore] Anti-snipe extension griefable via cheap repeated top-ups #155 floor already bound the worst case to a meaningful capital cost with no added mechanism.
• An appendix with two parameter sanity-checks operators can run before launch to verify their configuration sits in the safe region.

What was tested

Documentation-only change; no contract code modified. Verified that:

• The new file follows the same structure and cross-link conventions as V1_MAINNET_PARAMETERS.md and V2_BOND_SIZING.md.
• SUMMARY.md indentation and file reference are consistent with existing entries.

[collinsezedike]

The public testnet row's max-extension count is off by one. (43 200 - 14 400) / 600 = 48, not 47. Correct the table so deployment sizing math built on it doesn't inherit the error.

[collinsezedike]

72 x base_bond is well above the 30 x base_bond cap and above the 28 x base_bond of third-party headroom, so it does not sit just inside the cap. The floor exceeding what max_total_weight can absorb is exactly why the attacker cannot trigger all 72 extensions. Reword accordingly.

[Kayce10]

Requested Change Fixed in 333ceac.

1. Corrected the public testnet max-extensions count to 48 — (43 200 − 14 400) /
   600 = 48, not 47.
2. Rewrote the max_total_weight comparison paragraph — 72 × base_bond exceeds the
   cap (30 × base_bond total, 28 × base_bond of third-party headroom), so the floor
   exceeding the cap is now stated as the reason the attacker can't trigger all 72
   extensions, with max_total_weight explicitly called out as the binding constraint.

[collinsezedike]

Hey @Kayce10, thank you for the contribution and the quick turnaround on the corrections. Merging now.

[collinsezedike]

Hey @Kayce10, thank you for the contribution. If the work was worth your time, a star on the repo helps other contributors find the project.

[Kayce10]

@collinsezedike, It was worth my time. Once again thank you for the opportunity to contribute to this project