chore(deps): bump stellar-sdk from 14.1.0 to 16.0.0 in /quantara

[dependabot]

Bumps stellar-sdk from 14.1.0 to 16.0.0.

Release notes

Sourced from stellar-sdk's releases.

16.0.0

This release adds support for Protocol 28.

Breaking changes

• CAP-71 authorization now defaults to the address-bound ADDRESS_V2 credentials, with a legacy opt-out on each end: (#1213)
  • stellar_sdk.auth.authorize_invocation builds SOROBAN_CREDENTIALS_ADDRESS_V2 entries; pass credentials_type=SorobanCredentialsType.SOROBAN_CREDENTIALS_ADDRESS for the legacy format.
  • SorobanServer[Async].simulate_transaction sends useUpgradedAuth: true, so simulation records ADDRESS_V2 credentials; pass use_upgraded_auth=False for the legacy format. AssembledTransaction[Async] and ContractClient[Async].invoke follow the same default, and SorobanServer[Async].prepare_transaction gains a use_upgraded_auth parameter it forwards to simulation.

Update

• Add CAP-85 (Protocol 28) external executable reference support across the high-level API. A contract created from an external executable reference carries no Wasm hash of its own: the reference names an owner contract and an owner-scoped tag, and the contract follows whatever Wasm hash the owner publishes under that tag. Updating the tag therefore upgrades every contract following it at once. (#1211)
  • New TransactionBuilder.append_create_contract_from_external_ref_op builds the creation operation. owner must be a contract address, since only a contract can hold the persistent tag entry that names the Wasm; tag is an unbounded SCString, so a binary tag is passed through undecoded.
  • New ContractClient[Async].create_contract_from_external_ref wraps that operation, mirroring create_contract.
  • New SorobanServer[Async].get_external_ref_wasm_hash returns the Wasm hash a reference currently names by reading the owner's persistent tag entry. The owner contract is not invoked.
  • SorobanServer[Async].get_contract_wasm — and so get_contract_meta, get_contract_spec and get_contract_info — resolves external references instead of rejecting them as an unsupported executable kind.
  • New ExternalRefNotFoundError (a ContractWasmRetrievalError) reports a tag entry that is missing or archived.
  • stellar_sdk.scval.to_native converts SCV_EXECUTABLE_TAG the way it converts SCV_STRING: to str, or to the raw bytes when the tag is not valid UTF-8.
  • The SCVal comparator behind stellar_sdk.scval.to_map key ordering handles the new variants; it previously raised ValueError for SCV_EXECUTABLE_TAG and treated every non-Wasm executable as equal.
• chore: upgrade generated XDR definitions to Protocol 28. (#1209)

Fixes

• Forward the supplied client to the stellar.toml lookup in federation.resolve_stellar_address; it previously used a default RequestsClient for that request.

15.0.0

This release adds support for Protocol 27.

This release contains the same content as 15.0.0-beta0, plus the use_upgraded_auth simulation flag. Below is the changelog since 14.1.1.

Update

• Add CAP-71 (Protocol 27) Soroban authorization support across the high-level API. (#1189)
  • New credential types (from the Protocol 27 XDR):
    • SOROBAN_CREDENTIALS_ADDRESS_V2 (CAP-71-02) — same fields as the legacy SOROBAN_CREDENTIALS_ADDRESS, but the signed payload is bound to the signer's address.
    • SOROBAN_CREDENTIALS_ADDRESS_WITH_DELEGATES (CAP-71-01) — delegated / multi-party signing via a (possibly nested) tree of delegate signatures.
  • stellar_sdk.auth.authorize_entry (and stellar_sdk.auth.build_authorization_preimage):
    • Sign all three address-based credential types, selecting the signature payload from the credential type: legacy ADDRESS keeps the non-address-bound preimage; ADDRESS_V2 and ADDRESS_WITH_DELEGATES use the address-bound ENVELOPE_TYPE_SOROBAN_AUTHORIZATION_WITH_ADDRESS preimage. authorize_entry previously returned entries with non-ADDRESS credentials unchanged, without signing them.
    • authorize_entry gains a keyword-only for_address parameter that writes the signature into a specific (possibly nested) delegate node. All signers of one delegated entry sign the same payload, bound to the top-level address, and must use the same valid_until_ledger_sequence.
  • stellar_sdk.auth.authorize_invocation:
    • Still builds legacy ADDRESS entries by default, so its output stays valid on every network regardless of Protocol 27 activation.
    • Gains a keyword-only credentials_type parameter to opt in to ADDRESS_V2. The default will flip to V2 once Protocol 28 makes it mandatory.
  • New stellar_sdk.auth.build_with_delegates_entry / stellar_sdk.auth.DelegateSignature wrap an ADDRESS/ADDRESS_V2 entry together with delegate signers (CAP-71-01), sorting each delegates level by address and rejecting duplicates, as the protocol requires.
  • AssembledTransaction: sign_auth_entries and needs_non_invoker_signing_by (and the async variants) handle all address-based credential types; V2 entries previously crashed with AssertionError.
  • SEP-45 (stellar_sdk.sep.stellar_soroban_web_authentication): challenge parsing and building accept ADDRESS_V2 entries in addition to the legacy type; delegated entries are rejected.
• feat: add use_upgraded_auth to SorobanServer[Async].simulate_transaction and the contract clients, mapping to the useUpgradedAuth flag from Stellar RPC v27.1.0 to opt simulation into recording ADDRESS_V2 (CAP-71) auth credentials. Best-effort and transitional; older RPC servers ignore it. (#1198)
• chore: upgrade generated XDR definitions to Protocol 27. (#1186)

15.0.0-beta0

Update

• Add CAP-71 (Protocol 27) Soroban authorization support across the high-level API. (#1189)
  • New credential types (from the Protocol 27 XDR):
    • SOROBAN_CREDENTIALS_ADDRESS_V2 (CAP-71-02) — same fields as the legacy SOROBAN_CREDENTIALS_ADDRESS, but the signed payload is bound to the signer's address.
    • SOROBAN_CREDENTIALS_ADDRESS_WITH_DELEGATES (CAP-71-01) — delegated / multi-party signing via a (possibly nested) tree of delegate signatures.

... (truncated)

Changelog

Sourced from stellar-sdk's changelog.

Version 16.0.0

Released on Aug 28, 2026

Breaking changes

• CAP-71 authorization now defaults to the address-bound ADDRESS_V2 credentials, with a legacy opt-out on each end: (#1213)
  • stellar_sdk.auth.authorize_invocation builds SOROBAN_CREDENTIALS_ADDRESS_V2 entries; pass credentials_type=SorobanCredentialsType.SOROBAN_CREDENTIALS_ADDRESS for the legacy format.
  • SorobanServer[Async].simulate_transaction sends useUpgradedAuth: true, so simulation records ADDRESS_V2 credentials; pass use_upgraded_auth=False for the legacy format. AssembledTransaction[Async] and ContractClient[Async].invoke follow the same default, and SorobanServer[Async].prepare_transaction gains a use_upgraded_auth parameter it forwards to simulation.

Update

• Add CAP-85 (Protocol 28) external executable reference support across the high-level API. A contract created from an external executable reference carries no Wasm hash of its own: the reference names an owner contract and an owner-scoped tag, and the contract follows whatever Wasm hash the owner publishes under that tag. Updating the tag therefore upgrades every contract following it at once. (#1211)
  • New TransactionBuilder.append_create_contract_from_external_ref_op builds the creation operation. owner must be a contract address, since only a contract can hold the persistent tag entry that names the Wasm; tag is an unbounded SCString, so a binary tag is passed through undecoded.
  • New ContractClient[Async].create_contract_from_external_ref wraps that operation, mirroring create_contract.
  • New SorobanServer[Async].get_external_ref_wasm_hash returns the Wasm hash a reference currently names by reading the owner's persistent tag entry. The owner contract is not invoked.
  • SorobanServer[Async].get_contract_wasm — and so get_contract_meta, get_contract_spec and get_contract_info — resolves external references instead of rejecting them as an unsupported executable kind.
  • New ExternalRefNotFoundError (a ContractWasmRetrievalError) reports a tag entry that is missing or archived.
  • stellar_sdk.scval.to_native converts SCV_EXECUTABLE_TAG the way it converts SCV_STRING: to str, or to the raw bytes when the tag is not valid UTF-8.
  • The SCVal comparator behind stellar_sdk.scval.to_map key ordering handles the new variants; it previously raised ValueError for SCV_EXECUTABLE_TAG and treated every non-Wasm executable as equal.
• chore: upgrade generated XDR definitions to Protocol 28. (#1209)

Fixes

• Forward the supplied client to the stellar.toml lookup in federation.resolve_stellar_address; it previously used a default RequestsClient for that request.

Version 15.0.0

Released on July 04, 2026

This release adds support for Protocol 27.

This release contains the same content as 15.0.0-beta0, plus the use_upgraded_auth simulation flag. Below is the changelog since 14.1.1.

Update

• Add CAP-71 (Protocol 27) Soroban authorization support across the high-level API. (#1189)
  • New credential types (from the Protocol 27 XDR):
    • SOROBAN_CREDENTIALS_ADDRESS_V2 (CAP-71-02) — same fields as the legacy SOROBAN_CREDENTIALS_ADDRESS, but the signed payload is bound to the signer's address.
    • SOROBAN_CREDENTIALS_ADDRESS_WITH_DELEGATES (CAP-71-01) — delegated / multi-party signing via a (possibly nested) tree of delegate signatures.
  • stellar_sdk.auth.authorize_entry (and stellar_sdk.auth.build_authorization_preimage):
    • Sign all three address-based credential types, selecting the signature payload from the credential type: legacy ADDRESS keeps the non-address-bound preimage; ADDRESS_V2 and ADDRESS_WITH_DELEGATES use the address-bound ENVELOPE_TYPE_SOROBAN_AUTHORIZATION_WITH_ADDRESS preimage. authorize_entry previously returned entries with non-ADDRESS credentials unchanged, without signing them.
    • authorize_entry gains a keyword-only for_address parameter that writes the signature into a specific (possibly nested) delegate node. All signers of one delegated entry sign the same payload, bound to the top-level address, and must use the same valid_until_ledger_sequence.
  • stellar_sdk.auth.authorize_invocation:
    • Still builds legacy ADDRESS entries by default, so its output stays valid on every network regardless of Protocol 27 activation.
    • Gains a keyword-only credentials_type parameter to opt in to ADDRESS_V2. The default will flip to V2 once Protocol 28 makes it mandatory.
  • New stellar_sdk.auth.build_with_delegates_entry / stellar_sdk.auth.DelegateSignature wrap an ADDRESS/ADDRESS_V2 entry together with delegate signers (CAP-71-01), sorting each delegates level by address and rejecting duplicates, as the protocol requires.
  • AssembledTransaction: sign_auth_entries and needs_non_invoker_signing_by (and the async variants) handle all address-based credential types; V2 entries previously crashed with AssertionError.
  • SEP-45 (stellar_sdk.sep.stellar_soroban_web_authentication): challenge parsing and building accept ADDRESS_V2 entries in addition to the legacy type; delegated entries are rejected.
• feat: add use_upgraded_auth to SorobanServer[Async].simulate_transaction and the contract clients, mapping to the useUpgradedAuth flag from Stellar RPC v27.1.0 to opt simulation into recording ADDRESS_V2 (CAP-71) auth credentials. Best-effort and transitional; older RPC servers ignore it. (#1198)
• chore: upgrade generated XDR definitions to Protocol 27. (#1186)

Version 15.0.0-beta0

... (truncated)

Commits

• a0e9f8b release: 16.0.0 (#1214)
• 300fa1a feat!: default CAP-71 authorization to ADDRESS_V2 (#1213)
• 1fa9306 feat: add CAP-85 external executable reference support (#1211)
• 4439dce chore: upgrade generated XDR definitions to Protocol 28. (#1209)
• 96c1910 test: close two boundary gaps found by mutation testing
• 54c8705 test: restore behavioral coverage lost in the sync/async merges
• 7862af1 test: make aiohttp network-error test deterministic
• 0b1ad8b test: restore full federation error-message assertions
• de59851 test: close SDK-internal AiohttpClient sessions in SEP tests
• 7535bf3 test: strengthen outcome assertions, resolve TODOs and dead skips
• Additional commits viewable in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)