From ad42cb17eb134c6cd4579abbc20f9c241b5552fb Mon Sep 17 00:00:00 2001 From: Dev M Date: Sat, 12 Sep 2026 00:18:35 +0530 Subject: [PATCH 1/2] Handle malformed XDR in the address conversion example Address::from_xdr is fallible, so the smart-contract example now returns Result instead of unwrapping, and the prose notes that untrusted bytes should be handled at the trust boundary. Fixes #2768 --- docs/build/guides/conversions/address-conversions.mdx | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/docs/build/guides/conversions/address-conversions.mdx b/docs/build/guides/conversions/address-conversions.mdx index dea10efd24..61b85b80cf 100644 --- a/docs/build/guides/conversions/address-conversions.mdx +++ b/docs/build/guides/conversions/address-conversions.mdx @@ -109,17 +109,19 @@ Smart contracts don't need to explicitly interact with the XDR types, as all the Note, that XDR conversions are an advanced feature and are not necessary for most Stellar smart contracts. +Deserializing XDR bytes back into a contract type is fallible: the bytes might not contain a valid value of the target type. Contracts that receive XDR bytes from untrusted sources, such as a custom authentication scheme, should handle the error case instead of unwrapping, since malformed input is a normal condition at a trust boundary. + ```rust use soroban_sdk::{ xdr::{FromXdr, ToXdr}, - Address, Bytes, Env, + Address, Bytes, ConversionError, Env, }; pub fn address_to_xdr_bytes(env: Env, address: Address) -> Bytes { address.to_xdr(&env) } -pub fn address_from_xdr_bytes(env: Env, bytes: Bytes) -> Address { - Address::from_xdr(&env, &bytes).unwrap() +pub fn address_from_xdr_bytes(env: Env, bytes: Bytes) -> Result { + Address::from_xdr(&env, &bytes) } ``` From 069610deecac2b5a67cc0e463d79352442e52266 Mon Sep 17 00:00:00 2001 From: devtechedge Date: Sat, 12 Sep 2026 00:30:22 +0530 Subject: [PATCH 2/2] Document the panic path for malformed XDR in the address conversion example FromXdr::from_xdr returns Err only when the bytes deserialize to a valid ScVal of a different type. Bytes that are not valid ScVal XDR at all panic before a Result is produced, and the SDK offers no in-contract recovery for that case. The prose now documents both failure modes and recommends validating untrusted input before it reaches the contract, or preferring typed arguments such as Address. --- docs/build/guides/conversions/address-conversions.mdx | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/build/guides/conversions/address-conversions.mdx b/docs/build/guides/conversions/address-conversions.mdx index 61b85b80cf..479f1a8b3a 100644 --- a/docs/build/guides/conversions/address-conversions.mdx +++ b/docs/build/guides/conversions/address-conversions.mdx @@ -109,7 +109,7 @@ Smart contracts don't need to explicitly interact with the XDR types, as all the Note, that XDR conversions are an advanced feature and are not necessary for most Stellar smart contracts. -Deserializing XDR bytes back into a contract type is fallible: the bytes might not contain a valid value of the target type. Contracts that receive XDR bytes from untrusted sources, such as a custom authentication scheme, should handle the error case instead of unwrapping, since malformed input is a normal condition at a trust boundary. +Deserializing XDR bytes back into a contract type can fail in two ways. If the bytes hold valid XDR for a value of a different type, the conversion returns an error that the contract can handle. If the bytes are not valid XDR for any value at all, the conversion panics, and the SDK offers no in-contract recovery for that case. Contracts that receive XDR bytes from untrusted sources, such as a custom authentication scheme, should handle the error case and validate the input before relying on it: prefer typed arguments such as `Address` where possible, or verify the byte format in the client that submits the transaction. ```rust use soroban_sdk::{