Description
Problem
Contract metadata can evolve as contracts are upgraded. The SDK currently has no standardized mechanism for determining whether cached or generated metadata remains compatible with the contract version being invoked.
This can lead to confusing runtime failures when function signatures, argument types, storage definitions, or contract interfaces change.
Solution
Introduce metadata version tracking and compatibility validation.
The SDK should associate metadata with a contract identifier and version/fingerprint. Before using cached metadata, it should validate that the metadata corresponds to the expected contract interface.
Provide compatibility checks capable of identifying breaking and non-breaking changes and expose migration hooks for supported metadata transformations.
Acceptance Criteria
Note for Contributors
Avoid relying exclusively on semantic version strings. Contract interface fingerprints should provide deterministic compatibility validation where possible.
Description
Problem
Contract metadata can evolve as contracts are upgraded. The SDK currently has no standardized mechanism for determining whether cached or generated metadata remains compatible with the contract version being invoked.
This can lead to confusing runtime failures when function signatures, argument types, storage definitions, or contract interfaces change.
Solution
Introduce metadata version tracking and compatibility validation.
The SDK should associate metadata with a contract identifier and version/fingerprint. Before using cached metadata, it should validate that the metadata corresponds to the expected contract interface.
Provide compatibility checks capable of identifying breaking and non-breaking changes and expose migration hooks for supported metadata transformations.
Acceptance Criteria
src/soroban/index.tsandsrc/index.ts.Note for Contributors
Avoid relying exclusively on semantic version strings. Contract interface fingerprints should provide deterministic compatibility validation where possible.