feat(module): verify Tron structurally on the signing side too

[senamakel]

The gap

#18 added verify_contract and openhuman moved to it. The module did not — and the module is the side that holds the key and produces the signature.

Both of its call sites still ran verify_transfer, which searches for the recipient and amount as byte runs anywhere in raw_data. A node can pay someone else and leave the requested address in an unrelated field; the search is satisfied, and the module signs it.

The test states the precondition first

// The old check would have passed this.
assert!(
    tx::tron::verify_transfer(&raw_data_hex, REQUESTED, &expected_txid, &transfer).is_ok(),
    "precondition: the byte-run search is fooled by the decoy"
);

let error = build_unsigned(&SigningRequest { /* TransferContract pays ATTACKER */ }).unwrap_err();
assert!(rendered.contains("does not pay the requested recipient"), "{rendered}");

The fixture builds a real TransferContract paying ATTACKER for the requested amount, with the requested address appended as field 99 — a decoy. Asserting the precondition means this test fails loudly if the gap it guards ever stops existing, rather than passing vacuously once verify_transfer changes again.

Why host-side checking was not enough

A host is precisely what a caller could be lying to. The module exists to be the boundary the key sits behind, so the check that decides whether a signature is produced belongs on this side of it. That is the same reasoning behind attach_signature verifying a second time rather than trusting the build_unsigned call — the two requests are independent, and a host could reach the second with different bytes than the digest was computed over.

fee_limit_sun is None, deliberately

The wire spec does not carry it. Only the host knows what it pinned in its createtransaction request, and it checks that before handing the spec over. Every other field — contract type, recipient at its declared field number, amount, TRC-20 calldata including the selector, call_value — is checked here.

Adding it to wire::TransactionSpec::Tron would be the more complete answer, but it is a wire-contract change requiring host and module to move together; worth doing separately if we want it.

Verification

Check	Result
cargo test --all-features	299 + 7 + 10 + 18 doctests, 0 failed (module tests 9 → 10)
cargo clippy --all-features --all-targets	clean
cargo fmt	clean

Why now

This wants to land before the next module artifact is cut, so the release that openhuman downloads has the check in it. The registry entry in openhuman/src/openhuman/modules/registry.rs pins 0.2.1 by SHA-256 today; a 0.2.2 release built from this would be the version that entry moves to.

[coderabbitai]

Warning

Review limit reached

@senamakel, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 61 minutes

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: a4747e15-2917-4a34-92b7-b3193f2bd999

📥 Commits

Reviewing files that changed from the base of the PR and between b128082 and 60c6c0d.

📒 Files selected for processing (2)

• crates/tinywallet-module/src/service/mod.rs
• crates/tinywallet-module/src/service/test.rs

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}