[Testing] Fuzz Testing for XDR Transaction Builder Payload Parsing

[AlAfiz]

Description: Implement property-based fuzz testing on the /transactions/batch-build payload parser to ensure malformed, unexpectedly large, or maliciously structured JSON arrays cannot crash the XDR builder logic.
Context / Motivation: The transaction builder endpoint processes complex nested arrays of routing intents. Edge cases in user input (like missing fields, negative amounts, or recursive objects) must be caught safely by validation logic, rather than panicking the Stellar SDK.
Acceptance Criteria: - [ ] Integrate a fuzzing library such as fast-check.

• Define arbitrary schemas that generate highly randomized arrays of swap intents.
• Assert that the endpoint consistently returns a 400 Bad Request for invalid schemas and never returns a 500 Internal Server Error.
  Technical Pointers: Focus the fuzzers on the asset amount properties. Test how the TypeScript logic handles Javascript's MAX_SAFE_INTEGER, NaN, and extremely long string lengths for Stellar addresses.

[MoscowDev]

Hello,

I would like to implement property-based fuzz testing for the /transactions/batch-build payload parser to improve its resilience against malformed and malicious input.

I have experience working with TypeScript backend systems, validation layers, and property-based testing using fuzzing tools such as fast-check, and I can help ensure the XDR builder is robust under extreme and unexpected input conditions.

My approach will include:

• Integrating a property-based testing library such as fast-check into the test suite.
• Defining arbitrary schemas that generate highly randomized arrays of swap intents, including deeply nested and malformed structures.
• Focusing fuzz coverage on critical fields such as asset amounts, ensuring edge cases like NaN, Infinity, MAX_SAFE_INTEGER, negative values, and string overflow conditions are thoroughly tested.
• Generating invalid and adversarial inputs such as missing fields, incorrect types, recursive objects, and excessively large payloads.
• Validating that the /transactions/batch-build endpoint consistently returns 400 Bad Request for invalid inputs.
• Ensuring that no test case results in a 500 Internal Server Error, confirming that the system gracefully handles all malformed input scenarios.
• Adding assertions to detect and prevent any unintended crashes in the Stellar SDK or XDR builder logic.

This implementation will significantly strengthen input validation and ensure the transaction builder is safe, stable, and resistant to malformed or malicious payloads.

Best regards,
Nnaji Moses Ogomegbunam

[grantfox-oss]

🦊 GrantFox — @MoscowDev has been assigned to this issue as part of the Official Campaign campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #171)
2. Your PR will be reviewed by the BETAIL-BOYS maintainers

Good luck! Track your progress on GrantFox.