Labels: Stellar Wave, stellar, tooling, dx, drips, help-wanted
Tier: M (2–4 days)
Type: tooling
Context
The SDK currently hand-writes Stellar contract call payloads in sdk/src/chains/stellar/. When a Soroban contract function signature changes, the SDK can silently drift. EVM avoids this through typechain; Solana avoids it through Anchor IDL. Stellar has its own bindings generator (stellar contract bindings typescript) but we don't use it yet.
We want generated, type-safe bindings checked into the contracts repo that the SDK can consume.
Scope
- Set up a
contracts/stellar/bindings/typescript/ directory.
- Add a script
contracts/stellar/scripts/generate-bindings.ts that:
- For each contract crate, runs
stellar contract bindings typescript --contract-id ... --network ... --output-dir bindings/typescript/<contract-name> against the testnet deployment.
- Post-processes the output to use named exports (some generator versions default to default exports).
- Writes a top-level
index.ts re-exporting all per-contract clients.
- Wire it into the build:
pnpm bindings:stellar runs the generation, pnpm build:stellar depends on it.
- Add a CI step that re-runs the generator on every push and fails if the diff is non-empty (drift detection).
- Document the SDK migration path in a follow-up issue: how
sdk/src/chains/stellar/ should switch from hand-written calls to these bindings.
Acceptance criteria
Why not do this in the SDK repo?
The contract source is the source of truth. Keeping bindings here means every contract PR can update bindings atomically with the implementation change, and downstream consumers (SDK, demo, indexers) all sync from the same artifact.
Resources
Labels:
Stellar Wave,stellar,tooling,dx,drips,help-wantedTier: M (2–4 days)
Type: tooling
Context
The SDK currently hand-writes Stellar contract call payloads in
sdk/src/chains/stellar/. When a Soroban contract function signature changes, the SDK can silently drift. EVM avoids this throughtypechain; Solana avoids it through Anchor IDL. Stellar has its own bindings generator (stellar contract bindings typescript) but we don't use it yet.We want generated, type-safe bindings checked into the contracts repo that the SDK can consume.
Scope
contracts/stellar/bindings/typescript/directory.contracts/stellar/scripts/generate-bindings.tsthat:stellar contract bindings typescript --contract-id ... --network ... --output-dir bindings/typescript/<contract-name>against the testnet deployment.index.tsre-exporting all per-contract clients.pnpm bindings:stellarruns the generation,pnpm build:stellardepends on it.sdk/src/chains/stellar/should switch from hand-written calls to these bindings.Acceptance criteria
.github/workflows/.stealth-registry::stealth_meta_address_of) wired through the generated client.Why not do this in the SDK repo?
The contract source is the source of truth. Keeping bindings here means every contract PR can update bindings atomically with the implementation change, and downstream consumers (SDK, demo, indexers) all sync from the same artifact.
Resources
stellar contract bindings: https://developers.stellar.org/docs/tools/developer-tools/cli/install-clisdk/src/chains/stellar/announcements.ts