Skip to content

Auto-generate TypeScript bindings for Stellar contracts #8

@truthixify

Description

@truthixify

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

  1. Set up a contracts/stellar/bindings/typescript/ directory.
  2. 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.
  3. Wire it into the build: pnpm bindings:stellar runs the generation, pnpm build:stellar depends on it.
  4. Add a CI step that re-runs the generator on every push and fails if the diff is non-empty (drift detection).
  5. 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

  • Bindings generated for all four contracts and checked in.
  • CI drift-check job in .github/workflows/.
  • README section "Generated bindings" explaining when to regenerate.
  • A draft SDK PR (separate) demonstrating one function call (e.g., 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

Metadata

Metadata

Assignees

Labels

Stellar WaveIssues in the Stellar wave programdripsFunded via Drips NetworkdxDeveloper experiencehelp wantedExtra attention is neededstellarTouches Stellar / Soroban codetoolingBuild / tooling work

Type

No type
No fields configured for issues without a type.

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions