[Chore] Reconcile V2_RESOLUTION.md's open design questions against the shipped v2 implementation

[collinsezedike]

Summary

docs/src/V2_RESOLUTION.md is a design proposal doc: its status banner reads "Proposed; design-only and not implemented," and it closes with "Until those economic choices are approved and threat-modeled, this proposal must remain Proposed and no implementation issue should treat its interface sketch as final." But tholos-v2 has since been fully implemented (contracts/tholos-v2, with a full test suite and now a complete interface reference in CONTRACT_V2.md, see #104). The doc was never updated to reflect that.

The doc lists 9 open "Questions for design review" (starting around line 681). At least two are confirmably answered by the shipped code:

• Question 2 ("Should the minimum external position always equal the base assertion bond, or be a separately pinned parameter?"): resolved as "always equal to base_bond" (contracts/tholos-v2/src/lib.rs:700).
• Question 3 (anti-sniping extension qualification and hard maximum): resolved by the shipped anti_snipe_extension_secs/anti_snipe_hard_max_secs parameters.

The other 7 questions haven't been checked against the implementation.

Scope

• Go through each of the 9 open questions and determine whether the shipped tholos-v2 implementation answers it, and if so, how.
• Update the status banner to reflect that implementation happened (no longer purely "Proposed").
• Update or remove the closing "must remain Proposed" statement accordingly.
• For any question the implementation doesn't actually resolve (a genuine remaining ambiguity, or a place where the code made an implicit choice worth documenting explicitly), note that too rather than assuming everything got answered.

Proposed approach

Read contracts/tholos-v2/src/lib.rs question by question against the design doc, the same way CONTRACT_V2.md (#104) was written by checking every claim against source rather than restating doc comments. This is closer to CONTRACT_V2.md's scope than a quick doc tweak, budget accordingly.

[divinemike019]

Hi! I'd like to contribute to this issue.

I have experience reviewing implemented smart-contract systems and reconciling technical documentation with production code. I'll review all 9 open design questions in "docs/src/V2_RESOLUTION.md" against the shipped "contracts/tholos-v2" implementation, using the contract source and existing tests to determine which questions have been resolved and what specific implementation decisions answer them.

I'll update the document's status banner to accurately reflect the implemented V2 contract, revise the closing guidance accordingly, and clearly document any questions that remain genuinely unresolved or were answered implicitly by the implementation. I'll ensure the documentation stays consistent with "CONTRACT_V2.md" and the actual contract behavior rather than assuming the original proposal was fully implemented as written.

[0xNinx]

I’d be happy to take this issue. I have experience building Web3 applications and working with Stellar SDK and Soroban. I’ll first reproduce the issue, find the cause, then make and test the fix. I can also handle any changes needed across the related frontend or backend.

[Akinyemi04]

i would like to work on this issue

[collinsezedike]

I like your plan @divinemike019

[grantfox-oss]

🦊 GrantFox — @divinemike019 has been assigned to this issue as part of the Third Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #115)
2. Your PR will be reviewed by the drydocs maintainers

Good luck! Track your progress on GrantFox.

[collinsezedike]

@0xNinx can you pick up #72?
Or would like to take #75?