schema-based request validation with bounds for contracts endpoints

[mikewheeleer]

Summary

contracts inputs are validated inconsistently and some bounds are missing, allowing oversized or malformed payloads through. Add declarative schema validation with explicit bounds at the boundary.

Why this matters

Unvalidated input is a correctness and security risk. Declarative schemas make the contract explicit, consistent, and testable.

Requirements

• Define request schemas for the contracts endpoints with explicit min/max bounds.
• Reject invalid input at the boundary with a structured validation_error (field-level details).
• Strip unknown fields; never pass unvalidated data to the service layer.
• Behavior is otherwise unchanged for valid input.

Technical guidance

• Validate at the edge (middleware), not deep in handlers.
• Return all field errors at once, not just the first.

Edge cases — each must have a test

• valid payload -> passes unchanged
• missing required field -> 400 with field detail
• oversized string/number -> 400
• unknown field -> stripped
• wrong type -> 400

Acceptance criteria

• All requirements and every edge case above implemented and covered by tests
• New unit and integration tests; existing tests still pass and no regressions
• Structured, typed errors (no leaked internals; stable codes)
• npm run lint, npm test, and npm run build all pass locally
• Code follows the repo's existing conventions; no duplication or dead code
• Short docs/comments explaining the design and any non-obvious decisions
• PR description explains the approach and includes Closes #<issue>

Out of scope

• Cross-field business rules (service layer)
• Response validation

Rewards

Part of the GrantFox OSS / Official Campaign (FWC26) — this task may be rewarded. PR quality is assessed by AI: depth, correctness under edge cases, meaningful tests, and clean design are what earn the reward. Shallow changes (typos, formatting, trivial docs) do not qualify.

[greatest0fallt1me]

Hello Maintainers 👋,
I’m interested in picking up this issue and contributing to the project.
I have solid experience working across both frontend and blockchain layers, including building user interfaces with Next.js and developing Stellar smart contracts using Rust (Soroban). I’m familiar with translating Figma designs into pixel-accurate UIs, handling wallet integrations, and writing efficient, well-tested contract logic.
I focus on writing clean, maintainable code, following repository standards, and keeping communication transparent throughout the development process. I can start immediately and complete the work within the expected timeframe.
Excited to collaborate and add value to the project 🚀
Thank you!

[Iker2522]

I'd like to take this issue on!

I can implement declarative schema validation with boundary-level enforcement for the contracts endpoints to ensure strict input correctness.

I will build edge middleware that validates incoming payloads against declarative schemas with explicit min/max constraints, strips unknown parameters, and returns comprehensive, field-level validation_error responses for all invalid inputs simultaneously. Valid requests will pass through unchanged without modifying service-layer handling.

I will also write unit and integration tests covering all boundary edge cases (type mismatches, missing required fields, oversized payloads, and field stripping) and confirm that npm run lint, npm test, and npm run build pass cleanly. PR ready in 1 day. Closes #.

[Okorie2000-code]

The issue description is crystal clear, and I’d be glad to work on it. I’ll ensure the implementation is clean, tested, and submit a clean PR. Kindly assign it to me. 🙏

[guptakumarranjeet150]

Hello @maintainers,

I would love to take this on. My planned approach:

• Implement schema-based request validation with bounds for contracts endpoints with explicit require_auth checks, clean storage layouts, and robust Soroban contract logic.
• Add comprehensive unit tests verifying both happy-path invocations and unauthorized revert scenarios.

Looking forward to contributing—please feel free to assign!