Fix invokeContract's return type leaking raw stellar-sdk objects instead of ContractCallResult

[meshackyaro]

Description

src/types/contract.ts defines ContractCallResult (success, returnValue?, txHash?, errorCode?, gasUsed?) as the apparent intended shape for a contract invocation's outcome. But invokeContract (src/contract/invoke.ts) is typed to return Promise<unknown> and actually resolves { operation, account, server } — the raw, internal Contract.call(...) operation object, the Account returned by server.getAccount(caller), and the SorobanRpc.Server instance itself — none of which is a ContractCallResult. ContractCallResult currently has zero producers anywhere in src/ (grepping for it shows only its own declaration and its re-export via contract/index.ts), meaning the type that looks like the contract module's primary output type is entirely unused in practice, while the function that should produce it leaks unrelated internal SDK objects to its caller instead.

Component

SDK

Difficulty

🟡 Medium

Tasks

• Change invokeContract's return type to Promise<ContractCallResult>
• Complete the simulate→sign→submit flow inside invokeContract (or clearly split it into prepareInvocation/submitInvocation steps) so it can actually populate success, txHash, returnValue, errorCode, gasUsed instead of returning intermediate SDK objects
• Update any dependent code once real callers exist (tracked in the companion "replace placeholder implementation" issues, which will want to call this)

Acceptance Criteria

• invokeContract returns a ContractCallResult, not raw internal SDK objects
• ContractCallResult has at least one real producer in the codebase

Estimated Time

1-2 days

[smithd2423-beep]

@smithd2423-beep has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hi Maintainer, I’d be glad to take on this issue. I’ve worked on similar tasks before and have the experience needed to handle it. I’m ready to get started right away.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @smithd2423-beep to this issue.

[D-Bluemoon]

@D-Bluemoon has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

Hey maintainer I’d love to take this issue on.

Cleaning up leaky abstractions and tightening API boundaries is right up my alley. I can jump into invokeContract, properly wire up the full simulate → sign → submit flow, and ensure it returns a clean, fully populated ContractCallResult instead of dumping raw internal SDK objects.

Since the companion escrow issues will be depending on this fix to replace their placeholder implementations, I'll make sure the return type is solid and easy for those downstream callers to consume. Let me know if I can take this off your plate!

ℹ️ Repo Maintainers: To accept this application, review their application or assign @D-Bluemoon to this issue.

[KidDev88]

@KidDev88 has applied to work on this issue as part of the Stellar Wave Program's 8th wave.

I would love to work on this issue.

ℹ️ Repo Maintainers: To accept this application, review their application or assign @KidDev88 to this issue.