Prompt unlock flow needs stale listing and price-change protection before wallet signing

[prissca]

Problem

A buyer can start purchase on one listing snapshot and sign after creator changes price, asset, or prompt version unless the flow binds exact terms.

Scope

• Bind challenge to prompt version, price, asset, seller, and expiry
• Invalidate stale purchase attempts
• Update UI with refreshed quote state

Acceptance criteria

• Changed listing terms invalidate pending challenge
• Buyer sees refreshed terms before signing
• Tests cover price, asset, seller, and version changes

Relevant areas

• api/auth/challenge.ts
• api/prompts/version.ts
• src/pages/prompts

Complexity

High - 200 points

Contributor guidance

Start with a short design note in the issue discussion, then implement with focused tests and documentation for the affected workflow.

[Ranjeet2063]

Hey team, I would love to tackle this issue!

Execution Plan for Prompt unlock flow needs stale listing and price-change protection before wallet signing:

• Clean Implementation: Deliver an idiomatic solution for Prompt unlock flow needs stale listing and price-change protection before wallet signing adhering strictly to Prompt-Hash-Stellar/prompt-hash's architecture.
• Automated Tests: Provide full test coverage asserting both edge cases and core workflows.
• Clean Git Hygiene: Atomic conventional commits with zero merge conflicts.

Why assign me?

• Proven Proof-of-Work: ci(deps): bump actions/upload-artifact from 3 to 7 #1 contributor on Mova Store (28 merged Web3 PRs) and official ElizaOS contributor.
• Fast Turnaround: Dedicated to shipping a tested, production-grade PR within 12–24 hours.
• Zero Maintainer Burden: Self-documenting code with green CI and tests included so you don't spend time debugging.

Ready to deliver within 12–24h—please feel free to assign it to me!

[ZacLou]

I reviewed the current flow: the challenge binds address, prompt ID, nonce, and expiry, but it does not bind the actual purchase quote. I can close that stale-state gap without a broad refactor.

Design:

• At challenge issuance, capture one immutable quote snapshot: prompt ID, version/revision, price, asset, seller/creator, active state, and expiry.
• Include that snapshot in the signed challenge payload and return it to the client; the human-readable challenge message also derives from those exact terms.
• Before wallet signing, re-fetch current listing state and compare it against the signed snapshot. Any price, asset, seller, version/revision, or active-state change invalidates the pending challenge.
• On stale state, clear the old challenge, show the refreshed quote, and require the buyer to confirm the new terms before a new challenge is issued.
• Tests will cover unchanged terms, price change, asset change, seller change, version change, prompt inactive, expiry, and refresh-before-sign behavior. I’ll keep the change scoped to the challenge/version endpoints and prompt purchase UI, with no unrelated refactors.

[rudrasatani13]

Design note, as the contributor guidance asks for, and my application to implement it.

The property to hold: a signature must be bound to the exact terms the buyer saw. Today a buyer can open the purchase flow, the creator can then change price, asset, or prompt version, and the original challenge can still be signed and settled, so the buyer pays terms that no longer exist.

Proposed design:

1. When the challenge is minted (api/auth/challenge.ts), the server reads the listing through the same path api/prompts/version.ts uses and computes a terms hash over the canonical tuple (promptId, version, price, asset, seller, expiresAt). The challenge payload carries the hash and a single-use nonce; nothing about the terms is taken from the client.
2. On settle, the server re-reads the listing, recomputes the hash, and refuses with a stable code (TERMS_CHANGED) when it differs, before any wallet interaction is treated as valid. A consumed nonce is refused as REPLAYED, and an expired challenge as EXPIRED, so the three failure modes stay distinguishable instead of collapsing into "invalid signature".
3. The UI treats TERMS_CHANGED as a refresh, not an error: it refetches the quote, shows the buyer exactly which field changed (price, asset, seller, or version), and re-enables signing only against the new terms. No silent re-signing on the old challenge.

Tests: price change, asset change, seller change, and version change each invalidate a pending challenge; an unchanged listing settles; an expired challenge and a replayed nonce are refused with their own codes; and a test that the client cannot influence the hash, since it never supplies terms.

Two deliberate limits: no new dependency (the repo's existing hashing is enough), and I would not add a terms-negotiation flow - the issue asks for protection before signing, and a partial-refund path would need its own issue.

I will start from current main, keep changes inside the named areas plus tests and the workflow doc, and report what I could not verify locally.