diff --git a/docs/build/guides/conversions/address-conversions.mdx b/docs/build/guides/conversions/address-conversions.mdx
index dea10efd24..479f1a8b3a 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 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::{
     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, ConversionError> {
+    Address::from_xdr(&env, &bytes)
 }
 ```