Implement Beneficiary Conflict Resolution Tie-Break Determinism

[maugauwi-hash]

Labels: bug, ttl-vault
Priority: Medium
Estimated Time: 1.5 hours

Description:
docs/beneficiary-conflict-resolution.md describes resolving conflicting beneficiary claims, but the tie-break logic when two claims have identical priority/timestamp should be verified to be fully deterministic (not dependent on storage iteration order) to avoid consensus divergence.

Tasks:

• Audit the tie-break comparator for any non-deterministic ordering (e.g., HashMap iteration)
• Replace with a deterministic secondary key (e.g., beneficiary address ordering)
• Add tests for exact-tie scenarios asserting stable, repeatable outcomes
• Document the deterministic tie-break rule in docs/beneficiary-conflict-resolution.md

[bobo-24]

Hi! I came across this issue and would love to work on it. I have experience with similar tasks and I'm confident I can investigate, implement a clean solution, and thoroughly test it before submitting a PR. If the issue is still open, I would appreciate it if you could assign it to me. I’ll prioritize this immediately and ensure a reliable solution is delivered as soon as possible. Thank you!

[guptakumarranjeet150]

Hello! I'd like to work on this issue.

I can tackle Implement Beneficiary Conflict Resolution Tie-Break Determinism. Proposed implementation roadmap:

• Analysis: Inspect current behavior and edge cases in ethos-protocol/ethos-contracts-backend
• Implementation: Implement Implement Beneficiary Conflict Resolution Tie-Break Determinism with explicit require_auth checks, clean storage layouts, and robust Soroban contract logic.
• Testing: Add comprehensive unit tests verifying both happy-path invocations and unauthorized revert scenarios.
• PR: Atomic commit with clean git hygiene and passing CI

Looking forward to contributing—please feel free to assign!