Handle malformed XDR in the smart-contract address conversion example

[kalepail]

Note

Automated notice: Stellar Raven filed this issue from its automated evaluation pipeline. The issue includes evidence and a public source record. Please verify the live surface before you act.

Finding

The smart-contract address conversion example accepts Bytes and calls
Address::from_xdr(&env, &bytes).unwrap().

from_xdr is fallible. The unwrap() call therefore panics when the bytes do
not contain a valid address value.

The page names custom authentication as a use case. That use case can process
untrusted bytes, so malformed input is a normal trust-boundary condition.

The page gives no fallible return, validation step, contract error, or malformed-input test.

Evidence

This live read reproduced the example on 2026-08-11:

await stellarDocs.get_doc_page_sections({
  path: "/docs/build/guides/conversions/address-conversions",
  includeContent: true,
});
// address_from_xdr_bytes(...) -> Address {
//   Address::from_xdr(&env, &bytes).unwrap()
// }

Six focused searches covered Address::from_xdr, malformed XDR, input length,
untrusted bytes, decode panics, and malformed input.

The searches found the conversion page. They found no warning or safe decoding example.

The live smart-contract skill covered typed errors, panic_with_error!, and generated try_* clients.
It did not cover malformed XDR or from_xdr at a trust boundary.

Additional recorded evidence:

• 2026-08-11 live stellarDocs.get_doc_page_sections for /docs/build/guides/conversions/address-conversions returned Address::from_xdr(&env, &bytes).unwrap() in the smart-contract example
• 2026-08-11 six live Soroban documentation searches found the conversion page but no malformed-XDR handling guidance
• 2026-08-11 live smart-contract skill read found generic panic and try_* guidance but no from_xdr or malformed-input rule

Recommendation

Replace the infallible example with a fallible function. Return a result or map decode failure to a contract error.

Add one malformed-byte test. State that contracts must not call unwrap() on untrusted XDR input.

If the expected XDR shape has a fixed length, show that guard before decoding.

Source Record

Raven recorded this finding as sd-040 (stellar-docs, discovered 2026-08-11).

Public source record: improvements/stellar-docs/sd-040-address-from-xdr-unwrap-malformed-input.md

Immutable source snapshot: aa71fa0a5b8f

Resolution Handoff

When you deploy a fix, link the resolving issue or pull request to the source record.
Then notify Raven through:

https://github.com/stellar-experimental/stellar-raven/issues/new?template=upstream-improvement-ready.yml&title=%5Bupstream-ready%5D%20sd-040%3A%20

Include the finding ID and the resolving issue or pull request.
Include the deployed version or timestamp. Include the smallest live recheck.
Raven verifies the live surface before it sets the finding to fixed-upstream.
An issue closure or merged pull request does not prove the fix.
A separate reviewer repeats the live check before Raven retires the active finding.
Raven keeps a commit-pinned snapshot when one is available.

[devtechedge]

@C:/Users/DEVAYA~1/AppData/Local/Temp/claim-comment.md

[kaankacar]

Working this because Raven filed it (label raven).

I verified the finding. main still has Address::from_xdr(&env, &bytes).unwrap() on that page.

PR #2849 from @devtechedge fixes it. I will not open a second PR.

I checked that PR against the soroban-sdk source. Both of its claims hold:

• Address::from_xdr returns Result<Address, ConversionError>.
• Bytes that are not valid XDR for any ScVal panic inside from_xdr, with no in-contract recovery.

After #2849 merges, this issue still needs the Raven sd-040 handoff.