You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
V2's parameters (registration duration, reveal duration, minimum resolution bond, anti-sniping extension) are currently reasoned about qualitatively in docs/src/V2_RESOLUTION.md, not modeled quantitatively. This is a research/design issue, not implementation: model the tradeoffs before picking real deployment defaults.
Scope
Model default frequency: given plausible turnout distributions, how often does a genuinely wrong assertion survive via the optimistic timeout default purely because turnout was too low? (This is the same dynamic worked through in [Feature] V2: implement weighted-majority outcome resolution #68's issue body, e.g. 49% revealed against, 50% non-reveal, assertion still stands.)
Model window-length tradeoffs: how does registration/reveal duration trade off against genuine participation (longer windows let more people join, but delay resolution and give more time for coordinated capture).
Recommend concrete starting parameter values, following the same profile-based approach docs/src/BOND_SIZING.md already established for v1 (private beta / public testnet / higher-value mainnet candidate).
Output: a new docs/src/V2_BOND_SIZING.md (or an extension of the existing one) with the model and recommended profiles, in the same style as the v1 document.
Depends on
Conceptually depends on #64's parameter list existing, but can proceed in parallel with implementation since this is modeling, not code against a live contract.
Summary
V2's parameters (registration duration, reveal duration, minimum resolution bond, anti-sniping extension) are currently reasoned about qualitatively in docs/src/V2_RESOLUTION.md, not modeled quantitatively. This is a research/design issue, not implementation: model the tradeoffs before picking real deployment defaults.
Scope
Depends on
Conceptually depends on #64's parameter list existing, but can proceed in parallel with implementation since this is modeling, not code against a live contract.