Summary
Generate a typed TypeScript client for Tholos using the Stellar CLI's stellar contract bindings typescript, and publish/commit it so JS/TS integrators stop hand-writing raw Contract/TransactionBuilder/nativeToScVal boilerplate. INTEGRATION.md currently only documents the Rust contract-to-contract path (via contractimport!); there's no equivalent for application developers calling in from a browser or Node. demos/freelance-escrow's src/lib/tholos.ts is a concrete example of exactly the boilerplate a generated client would eliminate: manual transaction building, simulate, sign, submit, and poll-for-result, all hand-rolled.
Scope
- Run
stellar contract bindings typescript against the deployed (or wasm) contract, producing a typed package under, e.g., packages/tholos-sdk or a similar location, one method per contract function.
- Decide and document how it's consumed: committed in-repo package, published to npm, or both.
- Add a short section to INTEGRATION.md documenting this as the JS/TS integration path, alongside the existing Rust contract-to-contract pattern.
- Out of scope: migrating demos/freelance-escrow to use it instead of its current hand-rolled client (separate follow-up issue, since the demo works fine as-is and shouldn't block the SDK on unrelated churn).
Proposed approach
Regenerate bindings whenever the contract's public interface changes (a CI check similar to the existing "verify workspace membership" one could catch drift, but that's an implementation detail to work out during the issue, not a decision to make up front).
Summary
Generate a typed TypeScript client for Tholos using the Stellar CLI's
stellar contract bindings typescript, and publish/commit it so JS/TS integrators stop hand-writing raw Contract/TransactionBuilder/nativeToScVal boilerplate. INTEGRATION.md currently only documents the Rust contract-to-contract path (viacontractimport!); there's no equivalent for application developers calling in from a browser or Node. demos/freelance-escrow's src/lib/tholos.ts is a concrete example of exactly the boilerplate a generated client would eliminate: manual transaction building, simulate, sign, submit, and poll-for-result, all hand-rolled.Scope
stellar contract bindings typescriptagainst the deployed (or wasm) contract, producing a typed package under, e.g., packages/tholos-sdk or a similar location, one method per contract function.Proposed approach
Regenerate bindings whenever the contract's public interface changes (a CI check similar to the existing "verify workspace membership" one could catch drift, but that's an implementation detail to work out during the issue, not a decision to make up front).