feat: implement v2 bonded assertion posting and uncontested finalize - #80
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Implements #65: v2's assert_outcome equivalent (the optimistic first stage, before any dispute exists) and the uncontested-finalize path. Re-reading the issue body, the paragraph about finalize behavior turned out to be a real requirement, not just context: no later v2 issue (#66-#71) covers the uncontested case at all, so leaving it out here would mean nothing in the whole v2 chain ever returns an uncontested asserter's bond.
That also surfaced a real gap in #64: there was no field distinct from registration_duration_secs for "how long can a Pending assertion be disputed before it's eligible for finalize." Added:
PolicySnapshotV2.challenge_window_secsandfinalize_reward_bps(carried over from v1 unchanged: same incentive problem, same solution, independently justified since it's the identical uncontested case in both versions).AssertionV2.opened_atandfinalizer.assert_outcome(asserter, outcome) -> u64: requires asserter auth, writes state before the external token transfer (matching v1's reentrancy-safe ordering), transfers base_bond, emitsAsserted.finalize(caller, id) -> bool: requires caller auth unconditionally (same v1 hardening, sofinalizercan never be spoofed regardless of reward), checkschallenge_window_secselapsed, splits the bond byfinalize_reward_bpsif configured, emitsFinalized.MAX_BOND_AMOUNTis now properly derived (i128::MAX / MAX_FINALIZE_REWARD_BPS) instead of [Feature] V2: implement PolicySnapshot and versioned assertion state #64's interim placeholder, since this issue introduces the real reward-multiply arithmetic that bound protects.Closes #65
Test plan
cargo fmt --check,cargo clippy --workspace --all-targets --locked -- -D warnings,cargo test --workspace --lockedall pass (67 v1 + 30 v2 + 2 integration-example tests)cargo build -p tholos-v2 --target wasm32v1-none --release --lockedsucceedsmdbook buildsucceedsErrorvariant has a dedicated test triggering it