Spike: Define the real on-chain invocation pipeline and contract-ABI strategy

[meshackyaro]

Description

TrustFlowEscrowClient.createEscrow/releaseEscrow/getEscrow (src/escrow/client.ts) are entirely mocked — they return fabricated mock-${Date.now()} transaction hashes and null state, with the code explicitly commented // Build and submit Soroban invocation (placeholder). src/contract/invoke.ts builds an unsimulated, unsigned operation and returns it without submitting anything, and src/contract/build.ts hand-encodes ScVal arguments with no schema tied to the actual deployed contract interface — so there's no defined mechanism to detect when the on-chain contract's interface (ABI) changes out from under the SDK.

Separately, src/contracts.ts is orphaned dead code: it imports abundance-token, crowdfund-contract, and soroban-client, none of which exist in package.json, and loads a ./config.json that doesn't exist in src/. It isn't imported by anything else in the SDK.

Component

SDK

Difficulty

🟣 Spike — investigation required, scope not yet defined

Tasks

• Design the real simulate→sign→submit→confirm pipeline for TrustFlowEscrowClient, building on stellar/transaction.ts / stellar/rpc.ts
• Decide how contract ABI/interface drift should be detected — codegen from the contract's WASM/spec, a versioned interface package, or manual sync
• Prototype one real escrow action end-to-end against Soroban testnet
• Investigate src/contracts.ts — confirm it's dead/orphaned and safe to delete, or determine what abandoned multi-contract design it was meant to support

Acceptance Criteria

• A written recommendation for the invocation pipeline and ABI-drift strategy
• A working prototype of one real escrow action reaching chain
• src/contracts.ts either deleted (with rationale) or a follow-up issue filed to properly implement its intent
• Follow-up implementation issue(s) filed for the remaining mocked client methods
• Any blocking unknowns flagged

Estimated Time

2-3 days (time-boxed spike)