fix: resolve build errors in rustchain-miner and cross-chain-airdrop

[jjb9707]

Summary

Two independent build blockers in rustchain-miner and cross-chain-airdrop.
Both are reproducible with a single cargo command; both are shown as a before/after pair below.

---

1. rustchain-miner -- reqwest 0.13 has no rustls-tls feature

On main the manifest asks for a feature that does not exist, so cargo aborts during
dependency resolution, before a single line of code is compiled:

$ cargo generate-lockfile          # main, rustchain-miner
error: failed to select a version for `reqwest`.
    ... required by package `rustchain-miner v0.1.0`
versions that meet the requirements `^0.13` are: 0.13.4, 0.13.3, 0.13.2, 0.13.1, 0.13.0
package `rustchain-miner` depends on `reqwest` with feature `rustls-tls` but `reqwest`
does not have that feature.
failed to select a version for `reqwest` which could resolve this conflict

With this PR:

$ cargo generate-lockfile          # this branch
    Updating crates.io index
     Locking 254 packages to latest compatible versions

$ grep -A1 'name = "reqwest"' Cargo.lock
name = "reqwest"
version = "0.13.4"

The feature set is exactly what the source needs, no more:

feature	why	call site
json	request + response bodies	src/transport.rs:77, src/attestation.rs:223 and 5 more
query	.query(params) -- split into its own feature in 0.13	src/transport.rs:70
rustls	TLS backend; also gates danger_accept_invalid_certs	src/transport.rs:29,36

No multipart / blocking / form usage anywhere in the crate, hence default-features = false.

Correction to an earlier claim in this PR

An earlier revision of this description (and of the inline comment in Cargo.toml) stated
that rustls-native-certs does not exist on reqwest 0.13.x. That was wrong, and it
is worth correcting explicitly because it is trivially disprovable and would cast doubt on the
rest of the analysis. Checked against the crates.io sparse index for every published 0.13.x:

reqwest	rustls-tls	rustls	rustls-native-certs	query
0.13.0-rc.1	no	yes	yes	yes
0.13.0	no	yes	yes	yes
0.13.1	no	yes	yes	yes
0.13.2	no	yes	no	yes
0.13.3	no	yes	no	yes
0.13.4	no	yes	no	yes

So rustls-tls really is absent from every 0.13.x -- that part stands, and it is the hard
error this PR fixes. But rustls-native-certs is present on 0.13.0/0.13.1 as the implicit
feature of an optional dependency (it is not in the index features map, which is why it was
misread as absent). Asking for it therefore does not fail -- it silently backtracks the
resolver, which is the actual reason to leave it out:

# with features = ["json", "rustls", "rustls-native-certs", "query"]
     Locking 264 packages to latest compatible versions
      Adding reqwest v0.13.1 (available: v0.13.4)     <-- silently 3 patch releases behind

It is also redundant: rustls enables rustls-platform-verifier 0.7.0, whose own
dependency list contains rustls-native-certs 0.8.4, so the OS trust store is already in use.

The manifest itself was already correct; commit 7668c50 only fixes the misleading comment
so a future contributor does not re-add the feature.

---

2. cross-chain-airdrop -- corrupt Cargo.lock (removed)

Not the ordinary case of cargo keeping several different versions of a crate. The tracked lock
file has two [[package]] blocks with an identical name, version and checksum but
conflicting dependency lists:

Lock line	Package	Version	Checksum	dependencies
1552	thiserror	2.0.18	4288b5bc...fbc4	thiserror-impl 1.0.69
1561	thiserror	2.0.18	4288b5bc...fbc4	thiserror-impl 2.0.18

thiserror-impl 2.0.18 is duplicated the same way (blocks at lines 1570 and 1581). Cargo does
not pick one -- it refuses the file outright:

$ cargo metadata --locked          # main, cross-chain-airdrop
error: failed to parse lock file at: .../cross-chain-airdrop/Cargo.lock

Caused by:
  package `thiserror` is specified twice in the lockfile

After removing it, resolution is clean and the regenerated lock has no duplicate keys at all:

$ cargo metadata                   # this branch
    Updating crates.io index
     Locking 227 packages to latest compatible versions
-> regenerated lock: 228 packages, 0 duplicate (name, version) keys

Deleting rather than hand-editing is the right fix here because cross-chain-airdrop/.gitignore already lists Cargo.lock -- the file was force-added
against the crate's own stated intent. The rest of that lock was structurally sound (246 packages,
245 from the registry, 0 missing checksums); thiserror / thiserror-impl were the only
corrupt keys.

---

CI scope -- why this was verified locally, and why approving the runs is safe

rust-ci.yml is the only Rust workflow in the repository, and it is scoped to rustchain-wallet and rips:

• its push / pull_request triggers carry a paths: filter listing only rustchain-wallet/**, rips/** and the workflow file itself;
• every cargo step runs with working-directory: rustchain-wallet.

Neither rustchain-miner nor cross-chain-airdrop is built by it, or by any of the
other 19 workflows -- which is why this had to be verified locally, and why the queued runs on this
PR cannot go red because of this change: ci.yml is a Python pipeline (ruff / mypy /
bandit / pytest) and the remaining checks are BCOS, RIP-309 and PoC-audit scans. None of them
compile these two crates. The two checks that did run (PR Size Labeler, Auto Label PRs) are green; the rest sit in action_required waiting on a maintainer.

Worth a separate issue: both crates ship a [[bin]] yet have zero CI coverage, which is how
two resolver-level defects reached main unnoticed. Happy to file it if useful.

Reproducing all of the above

# 1. miner, before  -> resolver error
git checkout main && cd rustchain-miner && cargo generate-lockfile

# 2. miner, after   -> Locking 254 packages, reqwest 0.13.4
git checkout fix/build-errors-3crates && cargo generate-lockfile

# 3. airdrop, before -> "package `thiserror` is specified twice in the lockfile"
git checkout main && cd ../cross-chain-airdrop && cargo metadata --locked

# 4. airdrop, after  -> Locking 227 packages, no duplicate keys
git checkout fix/build-errors-3crates && cargo metadata

Full compilation was not run end to end on the machine used here (its MinGW install is missing
the assembler dlltool shells out to, so getrandom cannot be built locally). Everything
claimed above is at the resolver/lock-file layer, which is exactly where both defects live, and
every step is reproducible with the four commands above.

Out of scope

rips has separate structural issues (missing deep_entropy module, absent src/bin target) and is intentionally not touched here; that deserves its own issue.

[github-actions]

Welcome to RustChain! Thanks for your first pull request.

Before we review, please make sure:

• Non-doc PRs have a BCOS-L1 or BCOS-L2 label
• Doc-only PRs are exempt from BCOS tier labels when they only touch docs/**, *.md, or common image/PDF files
• New code files include an SPDX license header
• You've tested your changes against the live node

Bounty tiers: Micro (1-10 RTC) | Standard (20-50) | Major (75-100) | Critical (100-150)

A maintainer will review your PR soon. Thanks for contributing!

[FlintLeng]

PR Review: Resolve Build Errors in rustchain-miner and cross-chain-airdrop

Reviewed on: 2026-08-13

Summary

Fixes two independent build blockers:

1. rustchain-miner: reqwest 0.13 has no rustls-tls feature (should be rustls-tls-native-roots or rustls-tls-webpki-roots)
2. cross-chain-airdrop: Cargo.lock was severely out of sync (2385-line deletion)

Fix 1: reqwest Feature Name ✅

The bug: Cargo.toml requested reqwest = { version = "0.13", features = ["rustls-tls"] }. This feature does not exist in reqwest 0.13 — the feature names are rustls-tls-native-roots or rustls-tls-webpki-roots. Cargo fails during dependency resolution before compiling anything.

The fix: Updates to the correct feature name. This is a straightforward documentation/API change on the reqwest side.

Fix 2: Cargo.lock Sync ✅

The bug: cross-chain-airdrop/Cargo.lock was severely out of sync with Cargo.toml. The lock file recorded dependencies that no longer match the manifest.

The fix: Delete the entire lock file (2385 lines) and regenerate. This is the correct approach when the lock file is hopelessly stale. The new lock file will be generated on the next cargo build.

Minor Note

This PR is a pure build fix — no runtime logic changes. The 2385-line deletion looks large, but it's just removing a stale lock file. The actual code change is 10 lines in one Cargo.toml.

Wallet: RTC019e78d600fb3131c29d7ba80aba8fe644be426e

✅ LGTM — straightforward build fixes that unblock compilation. No security implications.