Three declared dependencies (validator, once_cell, base64) are completely unused in the real source tree

[abayomicornelius]

Overview

Three crates declared as direct dependencies in Cargo.toml are never referenced anywhere in the real application source tree:

# Cargo.toml
once_cell = "1"
...
base64 = "0.21"
...
# Validation
validator = { version = "0.17", features = ["derive"] }

Verified by grepping src/ (excluding the synthetic src/commits/ seed-history files) for each crate's usage:

• once_cell: zero matches for once_cell anywhere in src/*.rs/src/**/*.rs.
• base64: zero matches for use base64 or base64:: anywhere — the codebase's actual base64 XDR encode/decode goes exclusively through stellar_xdr::curr::{WriteXdr, ReadXdr}'s own to_xdr_base64/from_xdr_base64 methods (via stellar-xdr's "base64" Cargo feature), never through this separately-declared base64 crate.
• validator: zero matches for validator::Validate, #[derive(Validate)], or any other use of the crate anywhere. All input validation in this codebase is hand-rolled inline in each service's create/get_quote/etc. method (e.g. the repeated let amount: f64 = req.amount.parse()...; if amount <= 0.0 { ... } pattern across escrow.rs, batch.rs, payment_request.rs, subscription.rs, payment.rs) — the validator crate that would let these checks be declared as struct field attributes instead is pulled in as a dependency (with its derive feature enabled, meaning its proc-macro is compiled too) but never actually invoked.

Unused dependencies are more than just build-time waste here:

• Each pulls in its own transitive dependency tree, increasing the total supply-chain surface that would need auditing (relevant to the companion issue on the complete absence of cargo-deny/supply-chain tooling) for code that contributes nothing to the running binary.
• validator's presence is actively misleading to a reader auditing this codebase's input-validation posture: seeing validator = { ..., features = ["derive"] } in Cargo.toml reasonably suggests structured, declarative validation exists somewhere, when in fact every validation check in the codebase (including the several gaps already flagged in Registration accepts unvalidated stellar_address and lacks structured input validation #16, No numeric validation on payment amount fields (QuoteRequest.amount, SendPaymentRequest.send_amount) #17, and elsewhere) is hand-written ad hoc Rust with no shared validation framework backing it at all.
• Compile time and binary size both pay a small but non-zero tax for three fully-unused dependency trees, validator's proc-macro derive machinery being the heaviest of the three.

Requirements

• Remove once_cell, base64, and validator from Cargo.toml if they remain genuinely unused, or actually adopt them where they'd help (in particular, validator could meaningfully replace the repeated hand-rolled amount/account validation logic flagged across several other issues in this codebase, which would be the more valuable outcome if the removal alternative is considered too blunt).
• If validator is kept with the intent to actually use it, that should be tracked as its own follow-up (migrating the existing hand-rolled checks), not left as a dependency that merely could be used someday.

Acceptance Criteria

• cargo tree (or cargo machete/similar unused-dependency tooling, itself worth adding to CI once No CI workflow configured (missing .github/workflows) #6's CI gap is addressed) confirms no dependency in Cargo.toml is unreferenced by the compiled binary.
• Either the three crates are removed and cargo build succeeds with an unchanged binary surface, or each is demonstrably wired into real code with at least one call site.
• If removed, Cargo.lock is regenerated to drop their transitive trees as well.

Additional Notes

Edge cases

• Double-check none of the three are pulled in as an indirect requirement of another direct dependency's feature flags before removing (e.g. confirm stellar-xdr's "base64" feature doesn't happen to re-export the base64 crate's types in a way any code depends on structurally, even without an explicit use — a cargo build after removal is the definitive check).
• If once_cell was intended for the dead RateService-per-request caching bug (a natural fit — a shared, lazily-initialized singleton is exactly what once_cell::sync::Lazy/OnceCell is for), consider whether fixing that issue is a better use of this dependency than removing it; the two issues are worth resolving in a coordinated way if that's the direction taken.

Testing strategy

• No functional test is needed beyond a successful cargo build/cargo test after removal — this is a dependency-hygiene issue, not a behavioral one, unless the "actually adopt validator" path is taken, in which case each migrated validation check needs its existing test coverage preserved.

Cross-references

• Complements the companion "no cargo-deny/supply-chain audit" issue — trimming genuinely-unused dependencies is a smaller but immediately actionable step toward the same broader goal of minimizing this project's dependency-supply-chain surface.
• If once_cell is used to fix the RateService-per-request caching bug, this issue and that one become linked; noting the connection here so whichever is picked up first can reference the other.

[davidishere1]

I’m interested in this issue because removing unused dependencies is a simple but valuable way to keep a Rust project clean, maintainable, and efficient. Unnecessary crates can increase compile times, dependency resolution overhead, and long-term maintenance burden.

I have 5+ years of programming experience and am comfortable working with Rust projects, Cargo, dependency management, and codebase cleanup. I’d verify that once_cell, base64, and validator are genuinely unused across the application and its build configuration, remove them safely from Cargo.toml, and run the relevant tests and build checks to ensure there are no regressions.

[grantfox-oss]

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

Next steps:

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

Good luck! Track your progress on GrantFox.