[Contracts] open-market: TWAP guard against settlement-price manipulation

[Olowodarey]

Problem
The TWAP ring buffer exists in liquidity.rs, but settlement/resolution can still read a spot price that a single large swap moved. This enables last-block price manipulation of payouts.

Requirements

• Add a settlement helper that requires the spot vs. TWAP deviation to be within a configurable max-deviation (bps); revert PriceDeviationTooHigh otherwise.
• Return TwapInsufficientHistory (already modeled) when the window isn't covered, instead of silently using a short window.
• Config value stored/validated in config.rs.

Acceptance Criteria

• Manipulated spot price beyond the deviation band is rejected at settlement; normal price passes. Covered by tests.

Files

• contracts/open-market/src/liquidity.rs
• contracts/open-market/src/market.rs
• contracts/open-market/src/config.rs
• contracts/open-market/tests/twap_validation_tests.rs

[Emmanuellsensai]

I would like to apply for the bounty to address issue 1762, "[Contracts] open-market: TWAP guard against settlement-price manipulation," within the Arena1X/InsightArena repository. This issue aims to prevent malicious actors from manipulating settlement prices by executing large, last-block swaps.

I understand the core problem arises because the current settlement logic can read a spot price directly, even though a TWAP ring buffer exists in liquidity.rs. This allows a single, strategically timed swap to skew the final settlement price, enabling payout manipulation. The proposed changes will introduce a robust deviation guard, ensuring settlement prices are resilient against such attacks by comparing the spot price to the TWAP.

Here is my plan for implementing the solution:

• In contracts/open-market/src/config.rs, I will add a new configuration field, max_price_deviation_bps, to define the maximum allowed deviation between the spot price and the TWAP. This value will be validated upon configuration updates.
• I will implement a new helper function within contracts/open-market/src/liquidity.rs that retrieves both the current spot price and the TWAP from the ring buffer. This function will calculate the percentage deviation between these two prices and return TwapInsufficientHistory if the TWAP window is not fully covered, or PriceDeviationTooHigh if the deviation exceeds the configured max_price_deviation_bps.
• Within contracts/open-market/src/market.rs, I will integrate this new helper function into the settlement or resolution logic. Before finalizing any settlement based on a spot price, this logic will call the helper and revert the transaction if either PriceDeviationTooHigh or TwapInsufficientHistory is returned.

I will verify the implementation using contracts/open-market/tests/twap_validation_tests.rs. This will involve adding specific test cases to confirm that a manipulated spot price exceeding the deviation band correctly triggers a PriceDeviationTooHigh revert, while a normal, non-manipulated price allows settlement to proceed successfully, and that TwapInsufficientHistory is returned when the window is not covered.

I will await assignment before commencing any work on this issue.

[Ranjeet2063]

Hello @maintainers,

I'd love to take ownership of this issue.

Technical Approach:

1. Core Work: Implement [Contracts] open-market: TWAP guard against settlement-price manipulation with explicit require_auth checks, clean storage schemas, and robust Soroban contract logic.
2. Quality Gate: Add unit tests asserting both happy-path invocations and unauthorized revert conditions.

Background: #1 contributor to Mova Store and verified contributor to multiple Stellar protocols.

Ready to deliver a clean, tested PR within 12–24 hours. Please assign!

[guptakumarranjeet150]

Hello @maintainers,

I can tackle [Contracts] open-market: TWAP guard against settlement-price manipulation. Proposed implementation roadmap:

• Analysis: Inspect current behavior and edge cases in Arena1X/InsightArena
• Implementation: Implement [Contracts] open-market: TWAP guard against settlement-price manipulation 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

Happy to pick this up today—please assign to me!