Nothing verifies that the market a user signs for is the market they were shown

[Muyideen-js]

Problem

The market question a user reads and the market their money goes to are two unrelated values, and
no code checks that they agree.

What the user reads comes from a JavaScript literal, frontend/script.js:10:

{ category: "crypto",
  title: "Will Stellar XLM trade above $0.50 before September 30, 2026?",
  detail: "Live Stellar Testnet market #3...",
  close: "Sep 30, 2026",
  onchainId: 3 }

What the user signs is built from onchainId alone -- frontend/script.js:268 passes
marketId: market.onchainId into placeBet, which puts nativeToScVal(BigInt(marketId)) into the
operation. The title, the close date, and the resolution criteria never leave the browser.

get_market is never called anywhere in this codebase. Confirmed by grep: the only contract
call the frontend makes is place_bet. So the app has no idea what on-chain market 3 actually is.

Impact

The binding between the displayed question and the signed transaction is a hardcoded integer that
nobody validates. That breaks in ordinary operation, not just under attack:

• A redeploy renumbers markets. scripts/deploy-testnet.sh deploys fresh contracts and
  scripts/create-mainnet-markets.sh creates markets in sequence. After any redeploy, on-chain
  market 3 is a different question -- but script.js still advertises the XLM question against id 3.
  The user reads one question and stakes XLM on another.
• A resolved or cancelled market still accepts a click. The UI has no idea market 3 closed. The
  user only learns when simulation returns error 5 MarketExpired, 7 MarketResolved, or
  8 MarketCancelled -- after they have committed to the flow.
• The close date is decoration. "Sep 30, 2026" is a string; the contract's real close ledger is
  never read, so the countdown a user makes their decision on may be wrong.
• The odds are decoration too. yes: 50 is a literal, not derived from the YES/NO pools, so the
  implied payout shown before signing has no relationship to the actual payout.

The user is being asked to approve a financial transaction on the basis of information that the
application has never verified and cannot verify in its current shape.

What to do

• Fetch the market with get_market(market_id) and render the question, close time, and
  resolution status from the contract, so the displayed market and the signed market are the
  same object by construction
• Re-read market state immediately before building the transaction, and abort with a clear
  message if it is resolved, cancelled, frozen, or past close
• Derive the implied probability and the estimated payout from the on-chain YES/NO pools and the
  contract's fee configuration, not from literals
• Show the user, in the confirmation step, the exact market id and question the transaction
  targets, before they are handed to the wallet
• Remove onchainId as a hand-maintained field -- the on-chain id should come from enumeration,
  never from a value typed into a source file
• Surface the minimum stake and the fee from get_config rather than discovering them through
  error 10 BetTooSmall after submission

Why this is critical

This is a what-you-see-is-what-you-sign failure on a money path. The current design can take a real
XLM stake for a market the user never agreed to, through nothing more exotic than a routine
contract redeploy -- and the user has no way to detect it, because the only place the real question
exists is on chain, and the app never looks there.

[guptakumarranjeet150]

Hello team,

I can take on this market signature verification issue.

Proposed Implementation:

1. Market Binding Verification: Bind signing intent to canonical market address and chain ID within the transaction envelope.
2. Invariant Checks: Assert that signing payload matches active market metadata before executing signature request.
3. Tests: Add unit/integration tests covering cross-market mismatch detection and payload tampering attempts.

Ready to deliver a robust PR. Please assign to me!

[Iker2522]

I'd like to take this issue on!

I can fix this critical security flaw by binding the frontend market rendering and transaction construction directly to live on-chain contract state in SPulse-Org / SPulse.

I will eliminate hardcoded market literals and onchainId fields in frontend/script.js, replacing them with dynamic market enumeration using get_market(market_id) and config retrieval via get_config. I will update the UI to derive implied probabilities, pool ratios, fees, and minimum stakes from on-chain state. Furthermore, I will implement a pre-signing validation check to prevent transactions on resolved, frozen, or expired markets, and add a pre-wallet confirmation dialog showing the exact verified market ID and title targeted by the place_bet operation.

I will verify the fix by running e2e checks against freshly deployed contract instances, ensuring that displayed questions, odds, and dates strictly match on-chain ledger state before wallet signing. PR ready in 1 day. Closes #212.

[JohnArayaE]

I would like to work on this issue because the current frontend has a serious what-you-see-is-what-you-sign gap: the market question, close date, odds, and fee information are local literals, while the transaction is built from only a hardcoded marketId, so the UI cannot guarantee that the market the user sees is the one their funds are actually targeting. I can first audit the current market rendering and placeBet flow, then introduce get_market/get_config reads so the displayed question, close state, minimum stake, fee, and pool data come from the contract rather than duplicated frontend values. From there, I can remove the hand-maintained onchainId mapping, derive implied probability and estimated payout from the live YES/NO pools, and re-read market state immediately before transaction construction to block resolved, cancelled, frozen, or expired markets before the wallet prompt. I can also update the confirmation step to show the exact on-chain market id and question being signed, and add focused tests for redeployed/renumbered markets, stale market state, fee/minimum-stake rendering, and payout calculations so the displayed terms and signed transaction remain bound to the same on-chain object. I can have a PR ready within 1–2 days.

[guptakumarranjeet150]

Hi there,

I would like to resolve this issue. Here is my proposed execution plan:

• Implementation: Provide a structured solution for Nothing verifies that the market a user signs for is the market they were shown addressing all stated requirements.
• Testing: Ensure the change passes all existing lint, format, and CI verification pipelines.

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