Approved workflow

startRound() is permissionless, becomes callable at nextRoundAt and then stays callable with no deadline (README documents exactly this). snapshotAt is set to the caller's block.timestamp and _advanceSnapshot counts a holder only if lease.expiresAt > snapshotAt (line 157).

The two facts together let whoever calls startRound choose which holders are 'current': an interested party who has renewed simply waits until a rival's lease has lapsed and then opens the round, and the rival's own registration fees are redistributed to the survivors.

README section 'Operations and availability' acknowledges that the caller chooses the moment and lists two consequences of that (renewal must not be frozen; small registries settle inline), but not this one, and no test covers snapshot membership as a function of when startRound is called.

This is self-mitigable -- any holder can call startRound at nextRoundAt itself, or renew -- so it is not a blocker, but it is a real, undocumented incentive to delay the round and the README's timing discussion should cover it. No code change is required to resolve it if the workflow owner accepts the behaviour.

README 'Sybil economics' asks the independent review to rule on this explicitly, so it is recorded here with a measured reproduction rather than left implicit. share = snapshotPool / holderCount and a new eligible address costs exactly FEE, so whenever snapshotPool > FEE * holderCount -- the normal state, because renewals and rolled-over unclaimed shares add to the pool without adding holders -- registering n fresh addresses returns more than n * FEE. register() and startRound() are both permissionless and can sit in the same block, so the attacker sizes n after reading poolBalance and holderCount and locks up no capital.

I agree with the author's analysis: every candidate mitigation (weighting by names held, a minimum holding age) contradicts the approved rule that every current holder gets an equal share, so this is not fixable inside the agreed design. It is reported as info, not as a blocker: it needs a workflow-owner decision about the distribution rule, not a revision of this code.

Confirmed fixed. claim() now takes no arguments and gates only on round != 0, eligibleRound[msg.sender] == round, share != 0 and claimedRound[msg.sender] != round (lines 174-177); the second 'still holds a live name' proof that stranded the share is gone. I re-ran the original reproduction against the current source and it no longer reproduces: alice is paid and poolBalance reaches 0.

Repeat protection is intact -- claimedRound[msg.sender] == round still reverts AlreadyClaimed, including after the claimant has transferred the name away, and a recipient who acquires its first name after snapshotAt is still NotEligible until the next snapshot.

The scope decision the fix took (entitlement is fixed at snapshotAt and does not travel with the name) is stated in README section 4 with the rejected alternatives, which is what was asked for. docs/abi/NameRegistry.json and docs/abi/Handle.json both match forge inspect ... abi --json byte for byte, so the ABI export tracks the new signature.

processSnapshot counts one eligible address per distinct holder (line 145-149) and share = snapshotPool / holderCount, while each new holder costs only FEE = 100 HNDL.

Whenever snapshotPool > FEE * holderCount - which is the normal state, because every renewal and every rollover of unclaimed dust adds to snapshotPool without adding a holder - adding n sybil addresses yields (snapshotPool + n*FEE)/(holderCount + n) > FEE per address, so the attacker gets back more than the fees paid.

Registration and startRound() are both permissionless and can be placed in the same block, so the attacker needs no capital lock-up beyond one block and can size n after observing snapshotPool and holderCount on-chain.

The README states 'No Sybil resistance is promised', so this is a disclosed property rather than a hidden bug, but the workflow requirement is an equal annual share for every current name holder and this converts a fixed fraction of honest holders' fees into attacker profit each round.

Mitigating it requires an agreed design change (for example weighting by names held, or requiring the proof name to have existed for a minimum age before the snapshot) and is therefore a scope decision, not a fix the review can prescribe.

claim() requires both eligibleRound[msg.sender] == round and current ownership of a live name (line 162-163). If a snapshot-eligible address transfers away its only name, the old holder fails _requireHolder and the new holder fails the eligibility check, so that share cannot be claimed by anyone for the round; it rolls into poolBalance for the next snapshot.

The workflow says every current name holder may claim an equal share once per year, and after a transfer the current holder cannot.

The README documents this explicitly ('Eligibility stays with the snapshot address, never with a transferred name') and the builder's own testLateEntryTransferAndCurrentHolderProof asserts it, so it is an accepted design choice, not an accident - it is recorded here because it is a literal conflict with the stated requirement and because the funds silently move a year into the future for the transferor.

Any resolution (carrying eligibility with the name, or letting a snapshot holder claim without a live name) changes the agreed snapshot semantics and needs a scope decision.