docs: price the anti-snipe extension and answer #213

[rudrasatani13]

Closes #213

A written analysis, in the shape of V1_MAINNET_PARAMETERS.md and V2_BOND_SIZING.md, answering the question as posed. No mechanism implemented, per the Scope.

The answer

No per-position throttle is warranted at any parameter set the contract permits — and the reason is mechanical, not a judgement about attacker budgets.

V2_BOND_SIZING.md already derives the extension count, floor((T_hard - T_reg) / T_ext). What it does not do is price it. Pricing it is what settles this issue.

Part 1 — the cost. Reaching the hard cap needs E = ceil((T_hard - T_reg) / T_ext) qualifying deposits of at least min_resolution_bond each, so it costs E x base_bond of at-risk capital — paid once, because once registration_deadline == registration_hard_deadline the trigger saturates and min(now + T_ext, T_hard) keeps returning T_hard with no further deposits needed to hold it. In the worked example already in V2_BOND_SIZING.md, that is 12 x base_bond.

Part 3 — why the proposed throttle cannot change that. A per-position throttle is keyed on the address; the cost is not. Let M = floor(P_max / B):

Case	What happens	Helped?
M >= E	One address pins the cap alone	No — blocking it forces a second address, identical total
M < E	Attacker splits across ceil(E / M) sybils	No — each sybil's first deposit already had to clear base_bond before #155 and still does, so the total is E x B either way

The floor #155 added is what sets the price, and it applies to first deposits as well as top-ups. That is the same statement as your observation that a Sybil actor was never affected by #155. What the throttle would change is behaviour for a genuine late arrival topping up near the deadline — the participant the mechanism exists to protect.

Part 2 — a distinction worth separating. The issue frames this as "griefing the anti-snipe extension", but an extension pushes the deadline out for everyone and registration is permissionless, so a triggered extension gives honest third parties more reaction time. That is the mechanism working as designed. Treating "an attacker can push the deadline" as self-evidently harmful skips the step where the delay is shown to favour the attacker. The real cost is finality latency, bounded by T_hard, and better addressed by choosing T_hard than by adding mechanism.

Part 4 — when I would be wrong. The argument holds while the hard deadline binds. It stops holding as (T_hard - T_reg) / T_reg grows. The contract already bounds that geometry: initialize rejects anti_snipe_hard_max_secs < registration_duration_secs and permits at most 29 days against a 7-day base, so the reachable ratio is 1x to ~4.1x. The number to watch is that ratio, not an attacker budget. If a future deployment adopts a hard cap far above its window, the mechanism worth evaluating is not per-position but per-trigger — a rising floor, B x 2^k for the k-th extension, making E extensions cost of order 2^E rather than E. I have recorded it and deliberately not implemented it, because it is not needed today and it carries the same cost to late honest participants.

What this is not

It is not a claim that repeated extensions are free — they cost E x base_bond at risk. It is a claim that a per-position throttle does not raise that price, which is the specific mechanism the issue proposed. If you would rather have a throttle recommended regardless, say so and I will aim at that instead; I flagged this reading on the issue before starting.

Verification

Documentation only. docs/src/ANTI_SNIPE_THROTTLE.md is added and linked from docs/src/SUMMARY.md so it renders in the mdBook. I did not run a docs build, so I am not asserting the site renders — the SUMMARY link is the part that would break it if it were wrong.

This is AI-assisted implementation. CONTRIBUTING states no policy either way on that, and the PR is yours to judge on its merits — but you should know how it was produced rather than infer it.

[rudrasatani13]

Ready for review.

Same note as on my other PR here: the CI and Docs Check runs are at action_required — GitHub withholds workflow runs from first-time contributors until a maintainer approves them, so the empty checks are not a failure.

The analysis is written against current main and is deliberately narrow: it prices the anti-snipe extension, answers whether it needs a per-position throttle, and states what I could not verify rather than asserting it. Happy to reshape it if you want it shorter or oriented differently.

[collinsezedike]

@rudrasatani13 Closing this, issue #213 is assigned to another contributor. Feel free to pick up another open issue.