Move wallet transaction building into the tinywallet module (-51 crates)

[senamakel]

Moves Bitcoin, EVM, Solana and Tron transaction building out of this binary and into the loadable tinywallet module, the way documents moved into tinydocs. The signing key never leaves this process.

Depends on tinywallet #10 / #11, released as v0.2.0. The gitlink is pinned to that tag and the eleven digests in registry.rs are copied verbatim from its checksum.toml.

Measured

Product profile	before	after
unique crate names	448	397
packages	485	430

bitcoin, ethers-core, ethers-signers, secp256k1 and the native secp256k1-sys C build are all gone — proven with scripts/assert-shed.sh, not cargo tree -i. Kernel floor unchanged (282 names / 2 native).

The structural reason this took a tinywallet change first: bitcoin had two parents, this crate and tinywallet, whose key feature required btc. Cutting our own edge shed nothing. tinywallet now reaches bitcoin only through tx, which lives exclusively in the module.

Keys stay here

host  --BuildUnsigned{fields, public key}-->  module
host  <--[digests to sign]-------------------  module
host    (signs locally with k256 / ed25519-dalek)
host  --AttachSignature{fields, signatures}->  module
host  <--{raw transaction, txid}-------------  module

k256 is a new direct dependency and costs nothing — it was already in the graph beneath coins-bip32, which derives the key being signed with. AttachSignature re-sends the fields rather than a handle, so the module keeps no state between calls: no store, no bounds, no expiry.

A loaded module shares this address space, so this is not hard isolation and is not claimed as such — a hostile module could read the seed from process memory anyway. It is a refusal to widen a boundary that already exists, for the price of one extra in-process round trip.

Two behaviour changes worth reviewing

Tron now verifies what the node returns before signing it. The module recomputes txID == sha256(raw_data) and checks the recipient appears in the bytes. The previous code signed whatever createtransaction handed back. This caught the test fixtures immediately — they had arbitrary txIDs and no recipient, and had been signed without complaint for as long as they existed. They are now well-formed node responses.

A TRC20 transaction is verified against the contract, not the recipient. A token transfer pays the contract and carries the real recipient padded inside the calldata, without the 41 prefix that appears for a native transfer — so verifying against quote.to_address would break every token transfer. Handled per transfer kind.

UTXO selection was safe to delegate: I checked rather than assumed, and select_utxos here and select_coins in tinywallet are the same largest-first algorithm down to the 546-sat dust rule.

Test coverage, honestly

8 mock-server tests are #[ignore]d. Not because they fail — each passes in isolation, exercising the full path: download, digest verification, dlopen, and a real signed transaction. They cannot run together, because tinybus never unloads a module and the module bus belongs to whichever tokio runtime created it; the second #[tokio::test] finds a dead broker. Same constraint tinydocs documents. Each ignore attribute carries the command that runs it.

Everything else is green: 140 web3 tests, 51 module tests, clippy clean on the product profile, Feature Forwarding Gate and kernel-floor ratchet both pass.

Not claimed

This does not make builds faster. The documents port shed 60 crates for zero wall-clock change — measured cold with sccache disabled, the build is critical-path-bound at ~200% CPU on 14 cores and the shed crates are parallel leaves. The win here is supply-chain surface, binary size, and one fewer native C toolchain build.

Summary by CodeRabbit

• New Features
  • Added local transaction signing across EVM, Bitcoin, and Tron networks.
  • Added wallet readiness checks and clearer error handling.
  • Added EIP-712 payment signing for x402 flows.
• Improvements
  • Consolidated transaction validation and signing for consistent behavior.
  • Improved address, payload, amount, and signature validation.
  • Added explicit EVM numeric overflow and invalid-value handling.
  • Improved ERC-20 transfer encoding and Bitcoin transaction signing.
  • Improved module availability reporting when features are disabled.
• Tests
  • Expanded coverage for signing, validation, error handling, and encoded transaction data.

[coderabbitai]

Actionable comments posted: 2

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/openhuman/web3/wallet/chains/tron.rs`:
- Around line 315-320: Add debug or trace diagnostics around the validation flow
containing compressed_public_key and tron_transaction_spec: log both successful
validation and rejection outcomes with quote_id, transaction ID, and transfer
kind. Use grep-friendly structured fields, and explicitly exclude raw_data_hex,
mnemonic, key bytes, and other secrets or full PII from all messages.
- Around line 114-136: Replace the byte-substring checks in the Tron transaction
verification flow with parsing of the canonical contract payload from
raw_data_hex. Update TransactionSpec::Tron and its callers as needed to carry
the expected native amount or TRC20 parameter, then compare the parsed
recipient, exact amount, or decoded TRC20 ABI argument before sign_transaction
is reached; do not permit a transaction to pass based only on bytes occurring
elsewhere in raw.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: f3d3e236-053c-461f-9e57-f5c8d9a4463a

📥 Commits

Reviewing files that changed from the base of the PR and between 752b5bf and fcc0d0b.

⛔ Files ignored due to path filters (1)

• app/src-tauri/Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (10)

• src/openhuman/modules/mod.rs
• src/openhuman/modules/wallet.rs
• src/openhuman/modules/wallet_tests.rs
• src/openhuman/web3/wallet/chains/btc.rs
• src/openhuman/web3/wallet/chains/evm.rs
• src/openhuman/web3/wallet/chains/tron.rs
• src/openhuman/web3/wallet/execution.rs
• src/openhuman/web3/wallet/execution_tests.rs
• src/openhuman/web3/x402/ops.rs
• src/openhuman/web3/x402/x402_tests.rs

🚧 Files skipped from review as they are similar to previous changes (6)

• src/openhuman/modules/wallet_tests.rs
• src/openhuman/web3/wallet/execution_tests.rs
• src/openhuman/modules/wallet.rs
• src/openhuman/web3/x402/ops.rs
• src/openhuman/web3/wallet/chains/btc.rs
• src/openhuman/web3/x402/x402_tests.rs

[coderabbitai]

Actionable comments posted: 1

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/openhuman/web3/wallet/chains/tron.rs`:
- Around line 128-163: Update tron_transaction_spec to validate node-controlled
transaction values: in the TRC20 TriggerSmartContract path, parse and reject any
non-zero call_value, and validate Transaction.raw.fee_limit as either absent or
equal to TRC20_FEE_LIMIT_SUN. Preserve the existing recipient and transfer-data
checks while returning an appropriate validation error for either mismatch.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 6841fb31-c967-48be-afca-146e44fe6a55

📥 Commits

Reviewing files that changed from the base of the PR and between fcc0d0b and abb1c95.

📒 Files selected for processing (1)

• src/openhuman/web3/wallet/chains/tron.rs

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

src/openhuman/modules/ops_tests.rs (1)

42-46: 📐 Maintainability & Code Quality | 🔵 Trivial | ⚡ Quick win

Add a regression test for disabled-module precedence.

offline_config() sets config.modules.enabled = true at Line 16, so this test never reaches the new disabled branch in src/openhuman/modules/ops.rs Lines 314-317. Add a separate case with modules disabled. Assert ModuleState::Unsupported and the detail "modules are disabled in configuration", including when the resolution cache contains Ready or Failed.

Example regression test

+#[test]
+fn disabled_modules_override_cached_resolution() {
+    let mut config = offline_config();
+    config.modules.enabled = false;
+
+    for status in list(&config) {
+        assert_eq!(status.state, ModuleState::Unsupported);
+        assert_eq!(
+            status.detail.as_deref(),
+            Some("modules are disabled in configuration")
+        );
+    }
+}

This review uses the changed disabled-state branch in src/openhuman/modules/ops.rs.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@src/openhuman/modules/ops_tests.rs` around lines 42 - 46, Add a separate
regression test in the ops tests that configures modules as disabled, then
asserts the reported state is ModuleState::Unsupported with detail "modules are
disabled in configuration". Cover both preexisting resolution-cache states,
Ready and Failed, ensuring disabled configuration takes precedence regardless of
cached resolution.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@src/openhuman/modules/ops_tests.rs`:
- Around line 47-51: Update the status assertion in the relevant ops test to
also accept ModuleState::Failed, and require status.detail.is_some() whenever
the state is Failed or Unsupported. Preserve acceptance of Available and Ready
while accounting for cached resolution failures.

---

Nitpick comments:
In `@src/openhuman/modules/ops_tests.rs`:
- Around line 42-46: Add a separate regression test in the ops tests that
configures modules as disabled, then asserts the reported state is
ModuleState::Unsupported with detail "modules are disabled in configuration".
Cover both preexisting resolution-cache states, Ready and Failed, ensuring
disabled configuration takes precedence regardless of cached resolution.

🪄 Autofix

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 392325e7-4aca-4eec-a364-84c67645df06

📥 Commits

Reviewing files that changed from the base of the PR and between 3847dd0 and bcd9898.

📒 Files selected for processing (2)

• src/openhuman/modules/ops.rs
• src/openhuman/modules/ops_tests.rs