lightsail-network · overcat · Sep 1, 2026 · Sep 1, 2026
diff --git a/CHANGELOG.md b/CHANGELOG.md
@@ -2,8 +2,10 @@
 
 ## Pending
 
+## 5.0.0
+
 ### Breaking changes
-- feat!: CAP-71 `SOROBAN_CREDENTIALS_ADDRESS_V2` credentials are now the default on both ends of the authorization flow — the entries this SDK builds, and the entries it asks RPC to record during simulation. ([#814](https://github.com/lightsail-network/java-stellar-sdk/issues/814))
+- feat!: CAP-71 `SOROBAN_CREDENTIALS_ADDRESS_V2` credentials are now the default on both ends of the authorization flow — the entries this SDK builds, and the entries it asks RPC to record during simulation. ([#815](https://github.com/lightsail-network/java-stellar-sdk/pull/815))
   - `Auth.authorizeInvocation` builds `ADDRESS_V2` entries. The `credentialsType` overloads are the legacy opt-out: pass `SOROBAN_CREDENTIALS_ADDRESS` for the pre-CAP-71 format.
   - `SorobanServer.simulateTransaction` sends `useUpgradedAuth: true`, so simulation records `ADDRESS_V2` entries. Pass `false` to the four-argument overload for the legacy format. The same default flows through `SorobanServer.prepareTransaction`, `ContractClient.invoke`, and `AssembledTransaction.simulate`, each of which has its own `useUpgradedAuth` opt-out.
   - `Sep45Challenge.buildChallengeAuthorizationEntries` follows the new default too, so on a protocol 27 network the challenge it hands to the client carries `ADDRESS_V2` entries. This flip is felt by the client signing the challenge rather than by the anchor calling the SDK, and SEP-45 does not specify a credential format, so it has its own `useUpgradedAuth` opt-out for anchors serving clients whose SDK predates CAP-71. Challenge parsing and verification accept both credential arms either way.
@@ -13,7 +15,7 @@
   - A hand-rolled signer that hardcodes the legacy `ENVELOPE_TYPE_SOROBAN_AUTHORIZATION` preimage now produces signatures the network rejects — build the payload with `Auth.buildAuthorizationEntryPreimage`, which picks the address-bound preimage off the entry. SDK-driven signing (`Auth.authorizeEntry`, `AssembledTransaction.signAuthEntries`, `ContractClient`) needs no change.
 
 ### Update
-- feat: add CAP-85 external executable reference support. A contract instance can now hold a `CONTRACT_EXECUTABLE_EXTERNAL_REF` executable — an owner contract plus an owner-scoped tag — instead of its own Wasm hash. The owner publishes the Wasm hash in a persistent contract data entry keyed by `SCV_EXECUTABLE_TAG(tag)`, so it can upgrade every contract referencing that tag at once. ([#814](https://github.com/lightsail-network/java-stellar-sdk/issues/814))
+- feat: add CAP-85 external executable reference support. A contract instance can now hold a `CONTRACT_EXECUTABLE_EXTERNAL_REF` executable — an owner contract plus an owner-scoped tag — instead of its own Wasm hash. The owner publishes the Wasm hash in a persistent contract data entry keyed by `SCV_EXECUTABLE_TAG(tag)`, so it can upgrade every contract referencing that tag at once. ([#817](https://github.com/lightsail-network/java-stellar-sdk/pull/817))
   - New `SorobanServer.getExternalRefWasmHash(ContractExecutableExternalRef)` resolves a reference to the 32-byte Wasm hash it names, with a single `getLedgerEntries` call; the owner contract is not invoked.
   - `SorobanServer.getContractWasm` — and so `getContractMeta`, `getContractSpec`, and `getContractInfo` — follows an external reference automatically, at the cost of that one extra request.
   - New `ExternalRefNotFoundException` (a `ContractIntrospectionException`) is thrown when the tag entry is missing or archived. An unresolvable reference — one whose owner is not a contract, say, since only a contract can hold the tag entry — is rejected before any request is made: `getExternalRefWasmHash` throws `IllegalArgumentException`, where the reference is the caller's own argument, while `getContractWasm` reports it as `ContractWasmRetrievalException`, where it came off the ledger instead. Every `getContractWasm` failure therefore stays catchable as `ContractIntrospectionException`.
@@ -22,8 +24,9 @@
   - New `Util.decodeUtf8(byte[])` returns `Optional<String>` — the text when the bytes are valid UTF-8, empty otherwise. Use it to display a tag, falling back to the raw bytes, instead of a lenient decode that would render two distinct tags identically.
   - `ScvComparator` orders the new `SCV_EXECUTABLE_TAG` value (lexicographic unsigned bytes) and the new executable arm (by owner, then tag), so a contract instance holding an external reference sorts correctly.
   - CAP-85 requires protocol 28. On an earlier network the new executable arm is not accepted, so deploying from a reference fails at submission; the read paths never encounter one, since no contract can hold a reference there.
-- feat: add `useUpgradedAuth` opt-outs at every layer that simulates: `SorobanServer.prepareTransaction(Transaction, boolean)`, `AssembledTransaction.simulate(boolean, boolean)`, and the `ContractClient.invoke` overload taking `useUpgradedAuth`. Derived transactions inherit the choice — the restore transaction `AssembledTransaction` builds during automatic restoration simulates with the same flag rather than falling back to the default. ([#814](https://github.com/lightsail-network/java-stellar-sdk/issues/814))
-- feat: add a `useUpgradedAuth` opt-out to `Sep45Challenge.buildChallengeAuthorizationEntries`. SEP-45 does not specify a credential format, and the challenge entries are signed by a remote client rather than by the caller, so an anchor serving clients whose SDK cannot sign the address-bound payload can pass `false` to keep issuing legacy challenges. ([#814](https://github.com/lightsail-network/java-stellar-sdk/issues/814))
+- feat: add `useUpgradedAuth` opt-outs at every layer that simulates: `SorobanServer.prepareTransaction(Transaction, boolean)`, `AssembledTransaction.simulate(boolean, boolean)`, and the `ContractClient.invoke` overload taking `useUpgradedAuth`. Derived transactions inherit the choice — the restore transaction `AssembledTransaction` builds during automatic restoration simulates with the same flag rather than falling back to the default. ([#815](https://github.com/lightsail-network/java-stellar-sdk/pull/815))
+- feat: add a `useUpgradedAuth` opt-out to `Sep45Challenge.buildChallengeAuthorizationEntries`. SEP-45 does not specify a credential format, and the challenge entries are signed by a remote client rather than by the caller, so an anchor serving clients whose SDK cannot sign the address-bound payload can pass `false` to keep issuing legacy challenges. ([#815](https://github.com/lightsail-network/java-stellar-sdk/pull/815))
+- chore: upgrade generated XDR definitions to Protocol 28. ([#816](https://github.com/lightsail-network/java-stellar-sdk/pull/816))
 
 ## 4.0.1
 

diff --git a/android_test/app/build.gradle.kts b/android_test/app/build.gradle.kts
@@ -68,7 +68,7 @@ dependencies {
     implementation("androidx.compose.material3:material3")
     // Since we are adding local jar(libs/stellar-sdk.jar) as dependency,
     // gradle cannot automatically download the required third-party dependencies.
-    implementation(files("libs/stellar-sdk-4.0.1.jar"))
+    implementation(files("libs/stellar-sdk-5.0.0.jar"))
     implementation("com.squareup.okhttp3:okhttp:4.11.0")
     implementation("com.squareup.okhttp3:okhttp-sse:4.11.0")
     implementation("com.moandjiezana.toml:toml4j:0.7.2")

diff --git a/build.gradle.kts b/build.gradle.kts
@@ -12,7 +12,7 @@ plugins {
 }
 
 group = "network.lightsail"
-version = "4.0.1"
+version = "5.0.0"
 
 java {
     toolchain {

diff --git a/examples/build.gradle.kts b/examples/build.gradle.kts
@@ -22,7 +22,7 @@ spotless {
 
 dependencies {
     // Use https://central.sonatype.com/artifact/network.lightsail/stellar-sdk in prod.
-    implementation("network.lightsail:stellar-sdk:4.0.1")
+    implementation("network.lightsail:stellar-sdk:5.0.0")
     testImplementation(platform("org.junit:junit-bom:5.10.0"))
     testImplementation("org.junit.jupiter:junit-jupiter")
 }

diff --git a/pom.xml b/pom.xml
@@ -11,7 +11,7 @@
 
     <groupId>network.lightsail</groupId>
     <artifactId>stellar-sdk</artifactId>
-    <version>4.0.1</version>
+    <version>5.0.0</version>
     <packaging>jar</packaging>
 
     <name>stellar-sdk</name>

diff --git a/readme.md b/readme.md
@@ -14,13 +14,13 @@ The Java Stellar SDK library provides APIs to build transactions and connect to
 <dependency>
     <groupId>network.lightsail</groupId>
     <artifactId>stellar-sdk</artifactId>
-    <version>4.0.1</version>
+    <version>5.0.0</version>
 </dependency>
 ```
 
 ### Gradle
 ```groovy
-implementation 'network.lightsail:stellar-sdk:4.0.1'
+implementation 'network.lightsail:stellar-sdk:5.0.0'
 ```
 
 You can find instructions on how to install this dependency using alternative package managers [here](https://central.sonatype.com/artifact/network.lightsail/stellar-sdk).

diff --git a/skills/java-stellar-sdk/SKILL.md b/skills/java-stellar-sdk/SKILL.md
@@ -22,14 +22,14 @@ Maven:
 <dependency>
     <groupId>network.lightsail</groupId>
     <artifactId>stellar-sdk</artifactId>
-    <version>4.0.1</version>
+    <version>5.0.0</version>
 </dependency>
 ```
 
 Gradle:
 
 ```groovy
-implementation 'network.lightsail:stellar-sdk:4.0.1'
+implementation 'network.lightsail:stellar-sdk:5.0.0'
 ```
 
 ## Import style

diff --git a/skills/java-stellar-sdk/references/quickstart.md b/skills/java-stellar-sdk/references/quickstart.md
@@ -6,7 +6,7 @@ from the environment. See `transactions.md` for the full lifecycle.
 ## Install (Gradle)
 
 ```groovy
-implementation 'network.lightsail:stellar-sdk:4.0.1'
+implementation 'network.lightsail:stellar-sdk:5.0.0'
 ```
 
 ## Generate or load a keypair