Feature: Implement a Commit-Reveal Scheme for Front-Running-Resistant Auction Tie-Breaking

[Emmyt24]

Overview

Add a commit-reveal randomness scheme for front-running-resistant auction tie-breaking:

• Bidders submit a hashed commitment during a bidding window, then reveal the pre-image during a separate reveal window.
• The final tie-break seed is derived from the hash-chain of all valid reveals (seed = H(reveal_1 || reveal_2 || ... || reveal_n), applied in deterministic submission order — e.g. commitment index, not reveal-arrival order), so no single participant can unilaterally determine the outcome.
• A bidder who commits but never reveals forfeits their slot and is excluded from tie-break resolution — with no refund advantage granted to non-revealers.

0 ──── commit_start ──── commit_end / reveal_start ──── reveal_end
         [commit window]                [reveal window]

Scope: contract only. No backend or frontend integration is required for this feature.

This module is designed to serve auction-style mechanisms that need fair tie-breaking. The Burn Auction issue is the most likely consumer — check whether you're picking this up standalone or alongside that issue, since a tie-breaking primitive with no auction to consume it has limited value on its own (it's still independently testable and mergeable, though).

Integration points

• New module file contracts/token-factory/src/commit_reveal.rs, declared via mod commit_reveal; in lib.rs
• Public #[contractimpl] entry points added to the TokenFactory impl block in lib.rs — suggested names: create_commit_reveal_session, submit_commitment, reveal_pre_image, finalise_commit_reveal_session, get_commit_reveal_session, get_commitment
• New DataKey variants added to types.rs for session/commitment state — do not reuse existing discriminants
• New Error variants added to types.rs starting at 133 (current highest in-use code is 132), with matching entries added to Error::name()
• Storage getters/setters added in storage.rs following the existing pattern
• Events emitted via events.rs using short symbol_short! topic names (Soroban's 9-character limit)

Acceptance criteria

• commit_reveal.rs implemented under contracts/token-factory/src/, wired into lib.rs
• Session creation, commit, reveal, finalise, and query entry points implemented
• DataKey/Error additions follow the checklist above
• Storage and events wired following existing patterns
• Unit tests in commit_reveal_test.rs covering: full commit-then-reveal happy path, hash-chain derivation determinism, non-revealer forfeiture, reveal-outside-window rejection, commit-outside-window rejection, mismatched pre-image rejection
• cargo check --lib and cargo test --lib clean in contracts/token-factory
• cargo build --target wasm32v1-none --release --lib succeeds

Notes for implementers

• The hash-chain must be applied in a deterministic order (commitment index, not reveal-arrival order) — getting this wrong reintroduces exactly the manipulability this module exists to prevent. Keep the ordering rule explicit and tested.
• Enforce sane minimum window durations (e.g. a MIN_COMMIT_WINDOW floor) as a safety measure against griefing with an artificially short window.

[benzy018]

Hello Maintainer I’d like to work on this issue. I can deliver it according to the requirements and submit a PR within 2 days. Thank you

[benzy018]

Hello Maintainer I’d like to work on this issue. I can deliver it according to the requirements and submit a PR within 2 days. Thank you

[Peculiarr7]

Hi! I’m a full-stack developer with a strong blockchain background, and I’m confident I can resolve this issue quickly and effectively. I’ll deliver a clean, reliable solution with immediate attention to detail, ensuring it’s completed as soon as possible. Please assign it to me—I’m ready to get started right away.

[Bamzy123]

Hi maintainer, i have experience handling issues like this and I'll submit PR within 2 days.