[Bug] dispute doesn't prevent an asserter from disputing their own assertion

[collinsezedike]

Summary

dispute (contracts/tholos/src/lib.rs:618-655) requires disputer.require_auth() and checks the assertion is Pending and within the challenge window, but never checks disputer != assertion.asserter. An asserter can call dispute on their own pending assertion, consuming the assertion's one dispute slot and locking out any honest third party who might otherwise have disputed a bad-faith assertion. Because resolve's winner is selected purely from assertion.asserter/assertion.disputer, when disputer == asserter the winner is the same address regardless of the resolver committee's actual vote, guaranteeing both bonds back independent of the truth. This nullifies the bond-forfeiture deterrent that is the entire economic premise of the dispute mechanism.

Scope

• Add a check in dispute rejecting a caller whose address matches assertion.asserter.
• Add a new Error::SelfDispute variant.

Proposed approach

if disputer == assertion.asserter {
    return Err(Error::SelfDispute);
}

Placed alongside the existing Pending/challenge-window checks in dispute. Add a test asserting this returns Err(Error::SelfDispute) and doesn't mutate assertion state.

[Kayce10]

Hi @maintainers, I’d like to work on this issue.

I’ll add an explicit self-dispute guard in dispute to reject cases where the disputer is the same address as the assertion’s asserter, along with a dedicated Error::SelfDispute variant.

I’ll place the validation alongside the existing assertion state and challenge-window checks, and add regression tests verifying that a self-dispute returns Err(Error::SelfDispute) without mutating the assertion state or consuming the available dispute slot.

I’ll also run the relevant contract formatting, clippy, and test checks to ensure the fix integrates cleanly with the existing dispute and resolution flow.

Could this issue be assigned to me?

[collinsezedike]

Over to you @Kayce10

[grantfox-oss]

🦊 GrantFox — @Kayce10 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 #113)
2. Your PR will be reviewed by the drydocs maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Third Campaign campaign!

@Kayce10's PR #117 was approved and merged by @collinsezedike.

🏆 @Kayce10: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (51 total points). Track your full progress on GrantFox.

👏 Great work, @Kayce10! Keep contributing to drydocs.