Skip to content

Classify late settlement from Horizon close_time vs expiry and cancel #507

New issue
New issue
Open
#576
#527
Open
Classify late settlement from Horizon close_time vs expiry and cancel#507
#576
#527
Labels
GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardenhancementNew feature or requesthelp wantedExtra attention is neededspikeTime-boxed research / design spike; deliverable is findings + recommendation, not full feature ship

Description

@grantfox-oss
grantfox-oss
bot
opened on Sep 21, 2026

Context

On-chain payment can land after expiresAt or after cancel. Policy docs already exist (docs/LATE_PAYMENT_POLICY.md, docs/EXPIRY-AND-LATE-PAYMENT.md) but verify/monitor still risk using server now instead of ledger close_time, which is wrong under clock skew and delayed Horizon pages.

Goal

Settlement context (ON_TIME / AFTER_EXPIRY / AFTER_CANCEL) is decided only from Horizon transaction close time versus stored expiresAt / cancelledAt. Proof and timeline show the same classification.

Work

  • Parse created_at / ledger close time from Horizon as UTC
  • Fail closed if close time is missing (do not invent Date.now())
  • Persist settlementContext / late-pay warning codes already in the domain model
  • Verify, monitor, receipt, timeline, and PDF must share one classifier
  • Tests for the documented matrix; no new overlapping policy doc

Areas involved

Settlement domain, verify, monitor, invoice storage fields, proof/timeline UI, and tests.

Done when

  • A payment whose close_time is after expiry still settles with AFTER_EXPIRY, not by wall clock
  • Missing close_time does not mark PAID
  • Timeline and PDF show the same warning code as the API
  • Existing policy markdown stays the single written spec

Activity

  1. grantfox-oss
    added
    enhancementNew feature or request
    help wantedExtra attention is needed
    Maybe RewardedIssue may be eligible for a GrantFox reward
    GrantFox OSSIssue tracked in GrantFox OSS
    spikeTime-boxed research / design spike; deliverable is findings + recommendation, not full feature ship
    on Sep 21, 2026

  2. AlexanderJiazx commented on Sep 22, 2026

    @AlexanderJiazx
    AlexanderJiazx
    on Sep 22, 2026
    Contributor

    Applying for this one.

    Approach:

    • Classify settlement strictly from the ledger: parse Horizon close_time on the paying transaction and compare against stored expiresAt / cancelledAt — server now never enters the decision.
    • Emit one enum (ON_TIME / AFTER_EXPIRY / AFTER_CANCEL) from a shared classifier used by verify, the monitor, proof, and the timeline so all surfaces agree.
    • Tests with fixed fixtures: payment inside window, after expiry, after cancel, plus a clock-skew case where server time disagrees with close_time and the ledger wins.

    First draft PR within ~24h of assignment.

  3. CemAyyildiz
    added a commit that references this issue on Sep 23, 2026

    Classify late settlement by ledger close time vs expiry

    dcf1f93

  4. Chidi-Dev1 commented on Sep 27, 2026

    @Chidi-Dev1
    Chidi-Dev1
    on Sep 27, 2026 – with GrantFox OSS

    Hello team, I want to resolve this issue.

    Thanks!

  5. Chidi-Dev1 commented on Sep 27, 2026

    @Chidi-Dev1
    Chidi-Dev1
    on Sep 27, 2026 – with GrantFox OSS

    Hello team, I want to resolve this issue.

    Thanks!

  6. rupesh-kumar-sah commented on Oct 3, 2026

    @rupesh-kumar-sah
    rupesh-kumar-sah
    on Oct 3, 2026

    Hi,

    I have experience with similar implementations and would like to take this on.

    Implementation approach:

    1. Audit storage layout and state invariants ensuring strict auth guards.
    2. Implement deterministic state transitions with safe checked arithmetic.
    3. Add hermetic unit and regression tests covering authorized, unauthorized, and boundary edge cases.
    4. Profile instruction and CPU/gas limits under Soroban host environment.

    I can deliver a clean, tested PR within 24 hours. Please assign!

  7. Rodrigoue9 commented on Oct 7, 2026

    @Rodrigoue9
    Rodrigoue9
    on Oct 7, 2026

    Hi @maintainers! I'd like to work on this issue. Here is my proposed technical approach:

    Proposed Technical Approach:

    1. Pipeline Architecture: Implement multi-step typed payment verification and late settlement classification using Horizon close_time.
    2. Terminal Invariants: Guarantee durable state transitions without stranded funds or race conditions.
    3. Integration Tests: Provide unit and integration suites testing timeout, cancellation, and settlement branches.

    Key Files:

    • src/** (pipeline handlers and invoice monitors)
    • tests/**

    Verification & Testing:

    • Run cargo test / npm test with 100% clean check.

    Relevant Track Record:

    I have successfully implemented and merged multiple production PRs across the Stellar ecosystem and Web3 open-source projects (e.g., cybermax4200/stellar-did-credit #898 & #900, Bitcoindefi/OpenAO #218, and FindMalek/sonaraem #416).

    Please feel free to assign this issue to me so I can proceed with the implementation. Thank you!

  8. woahwhattheheck commented on Oct 9, 2026

    @woahwhattheheck
    woahwhattheheck
    on Oct 9, 2026
    Contributor

    /claim #507

    I have submitted the implementation in original-author PR #576: #576. I am claiming this contribution for review and any eligible GrantFox OSS reward under the published program terms. Please confirm assignment/acceptance and, if an award is approved, its actual amount, allocation and payout process. I am not representing the Maybe Rewarded label as guaranteed funding or an awarded payment.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    GrantFox OSSIssue tracked in GrantFox OSSMaybe RewardedIssue may be eligible for a GrantFox rewardenhancementNew feature or requesthelp wantedExtra attention is neededspikeTime-boxed research / design spike; deliverable is findings + recommendation, not full feature ship

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions