[Quality] Define offer expiration at exact ledger boundaries

[1nonlypiece]

Problem

Offers can be accepted at or around expiry unless timestamp semantics are explicit and consistently enforced.

This issue requires a meaningful production implementation. Typo-only, documentation-only, formatting-only, dependency-only, or cosmetic changes do not satisfy the scope.

Objective

Implement one documented expiration policy for creation, update, acceptance, and cancellation.

Scope

Centralize timestamp comparisons and cover ledger-time behavior, zero duration, and maximum duration.

Acceptance criteria

• An offer at the exact expiry boundary follows the documented policy.
• Expired offers cannot be accepted or mutated in unsafe ways.
• Events expose the effective expiry and resulting state.
• Boundary and property tests cover time progression and retries.
• Existing CI/CD checks remain green.
• The PR explains the design, tradeoffs, test evidence, and any remaining limitations.
• The PR references this issue with Closes #{issue-number} or Fixes #{issue-number}.

Implementation notes

Implement only the stated behavior; keep unrelated refactors out of the PR.

Non-goals

• Do not remove tests merely to make CI pass.
• Do not introduce secrets, private keys, credentials, or mainnet-only values.
• Do not change unrelated APIs, UI surfaces, contract behavior, or deployment configuration.

Contributor application

Before starting, comment with relevant experience, a 1–4 bullet implementation approach, and an estimate for opening the first draft PR. Wait for maintainer assignment before coding. Only the assigned contributor is eligible for reward consideration.

Submission requirements

• Use PR title format [#<issue-number>] <short summary>.
• Check off each completed acceptance criterion.
• Include focused automated tests for success, failure, authorization, and boundary behavior where applicable.
• Include the validation commands and results in the PR description.
• Address maintainer review feedback before merge.

GrantFox reward consideration is based on the original scope, implementation quality, tests, security review, CI/CD results, review feedback, and follow-up stability; completion or merge alone is not a guarantee.

[guptakumarranjeet150]

Hello @maintainers,

I would love to take this on. My planned approach:

• Implement [Quality] Define offer expiration at exact ledger boundaries with explicit require_auth checks, clean storage layouts, and robust Soroban contract logic.
• Add comprehensive unit tests verifying both happy-path invocations and unauthorized revert scenarios.

Looking forward to contributing—please feel free to assign!

[shobhamerabacha-star]

Hi everyone,

I would love to take this on. My planned approach:

• Implement [Quality] Define offer expiration at exact ledger boundaries with explicit require_auth checks, clean storage layouts, and robust Soroban contract logic.
• Add comprehensive unit tests verifying both happy-path invocations and unauthorized revert scenarios.

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

[ranjeet150]

Hi maintainers,

I can tackle [Quality] Define offer expiration at exact ledger boundaries. Proposed implementation roadmap:

• Analysis: Inspect current behavior and edge cases in Commitlabs-Org/Commitlabs-Contracts
• Implementation: Implement [Quality] Define offer expiration at exact ledger boundaries 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

Excited to work on this—please assign to me and I'll submit a clean PR shortly!