Spike: Prototype the Soroban transaction build→simulate→sign→submit→confirm flow

[meshackyaro]

Description

No code anywhere in the frontend builds, simulates, signs, submits, or confirms a Soroban transaction, despite the README claiming "XDR simulation run before every transaction submission." Every contract-touching UI action is stubbed:

• components/molecules/form-pledge/index.tsx and components/molecules/deposits/index.tsx use setTimeout/hardcoded BigInt(0) with TODOs ("call TrustFlow contract deposit")
• components/organisms/pledge/index.tsx uses a mockEscrow object and a literal alert('Contract integration coming soon') for the escrow deposit button
• hooks/useSubscription.ts, meant for on-chain event polling, is a documented "Placeholder subscription hook" with an empty body and a TODO
• shared/contracts.ts is just three env-var constants (CONTRACT_ID, RPC_URL, NETWORK_PASSPHRASE) — nothing consumes them to actually talk to the chain

This blocks every real contract-integration ticket until the flow and its home in the codebase are decided.

Component

Frontend

Difficulty

🟣 Spike — investigation required, scope not yet defined

Tasks

• Decide where build→simulate→sign→submit→confirm logic should live (a shared hook? a shared/ service module consumed by hooks?)
• Evaluate reusing trustflow-sdk's contract client vs. calling @stellar/stellar-sdk directly from the frontend (the SDK's own client is also currently mocked — see the related spike in trustflow-sdk)
• Prototype the full flow end-to-end for one action (recommend the escrow deposit in pledge/index.tsx) against Soroban testnet via Freighter
• Prototype useSubscription.ts's event-polling approach (RPC getEvents polling vs. a backend push channel) and confirm it fits the existing Edge-runtime API routes

Acceptance Criteria

• A written recommendation for where the transaction-flow logic lives and how it relates to the SDK
• A working prototype of one real contract action end-to-end on testnet
• A written recommendation for the event-subscription approach
• Follow-up implementation issue(s) filed per remaining stubbed action
• Any blocking unknowns flagged

Estimated Time

2-3 days (time-boxed spike)