Vendor tinywallet tinydocs

[senamakel]

Summary

Related issue

API or behavior changes

Validation

Commands actually run, with their outcome:

• cargo fmt --all -- --check
• cargo clippy --all-targets --all-features -- -D warnings
• cargo build --all-targets --all-features
• cargo test --all-features

Tests

Documentation

Checklist

• The change is focused on one logical change
• No new #[allow(...)], #[ignore], or relaxed lints
• No secrets, tokens, or .env contents in the diff or the description

Summary by CodeRabbit

• New Features

  • Added asset catalogs covering Bitcoin, EVM networks, Solana, and Tron, including metadata, token details, and explorer links.
  • Added mnemonic-based key derivation for Bitcoin, EVM, Solana, and Tron.
  • Added balance queries, native transfers, UTXO retrieval, transaction broadcasting, and status tracking across supported networks.
  • Added transaction building and signing for Bitcoin, EVM, Solana, and Tron.
  • Added configurable network transport and feature support.

• Bug Fixes

  • Improved validation and error handling for addresses, malformed responses, chain mismatches, transaction data, and insufficient funds.

• Tests

  • Added comprehensive coverage for assets, key derivation, networking, transactions, signing, and status handling.

[coderabbitai]

Caution

Review failed

The pull request is closed.

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: d8f2a849-b509-48e2-8f67-4749da4b8a26

📥 Commits

Reviewing files that changed from the base of the PR and between 6044f12 and caba0c9.

⛔ Files ignored due to path filters (1)

• Cargo.lock is excluded by !**/*.lock

📒 Files selected for processing (30)

• Cargo.toml
• src/address/mod.rs
• src/asset/mod.rs
• src/asset/test.rs
• src/client/btc.rs
• src/client/evm.rs
• src/client/mod.rs
• src/client/solana.rs
• src/client/status.rs
• src/client/test.rs
• src/client/tron.rs
• src/error/mod.rs
• src/key/bip32.rs
• src/key/btc.rs
• src/key/evm.rs
• src/key/mod.rs
• src/key/slip10.rs
• src/key/solana.rs
• src/key/test.rs
• src/key/tron.rs
• src/lib.rs
• src/rpc/mod.rs
• src/rpc/test.rs
• src/tx/btc.rs
• src/tx/evm.rs
• src/tx/mod.rs
• src/tx/rlp.rs
• src/tx/solana.rs
• src/tx/test.rs
• src/tx/tron.rs

---

📝 Walkthrough

Walkthrough

Added feature-gated multi-chain wallet support for asset catalogs, mnemonic key derivation, async transport, transaction signing, native transfers, balances, UTXOs, broadcasting, and transaction status.

Changes

Wallet foundation

Layer / File(s)	Summary
Feature gates and asset catalogs Cargo.toml, src/lib.rs, src/asset/*, src/address/mod.rs, src/error/mod.rs	Added feature wiring and network and asset catalogs for Bitcoin, EVM, Solana, and Tron. Updated documentation references.
Mnemonic key derivation src/key/*	Added BIP-32 and hardened SLIP-0010 derivation with chain-specific addresses, sanitized errors, zeroizing secrets, and redacted debug output.
Transaction construction and signing src/tx/*	Added Bitcoin, EVM, Solana, and Tron transaction encoding, validation, signing, hashing, and transaction tests.
Async transport seam src/rpc/*	Added network identity, retry-aware errors, async JSON-RPC and REST methods, typed decoding, and transport tests.
Chain clients and status src/client/*	Added balance, UTXO, transfer, broadcast, and normalized transaction-status APIs with chain-specific request and response handling.

Estimated code review effort: 5 (Critical) | ~120 minutes

Sequence Diagram(s)

sequenceDiagram
  participant Caller
  participant Client
  participant Transport
  participant ChainService
  Caller->>Client: Request balance or transfer
  Client->>Transport: Send JSON-RPC or REST request
  Transport->>ChainService: Forward request
  ChainService-->>Transport: Return chain response
  Transport-->>Client: Return decoded data
  Client->>Client: Validate and sign transaction
  Client->>Transport: Broadcast signed transaction
  Transport->>ChainService: Submit transaction
  ChainService-->>Transport: Return transaction hash
  Transport-->>Client: Return validated result
  Client-->>Caller: Return balance or transaction result

Loading

Possibly related PRs

• tinyhumansai/tinywallet#1: Provides the Chain, address-validation, and error APIs used by the new key, transaction, and client layers.

Poem

A rabbit checked each chain with care,
Then signed bright bytes through network air.
Keys stayed hidden, clean and tight,
While coins and hashes hopped in flight.
“Four chains ready!” the rabbit cried.
And tucked the tests safely by its side.

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

---

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.}

[tinysweeper]

Requesting changes: 3 lane(s) blocking, worst finding is high.

Fix or reply to the findings below and push. The next review clears this automatically once they are gone — you should not need to dismiss anything by hand.

             $0.0469 · 533,584 in / 143,574 out · 424,371 cached (80%) · z-ai/glm-5.2, deepseek/deepseek-v4-pro
critique:    $0.0250 · 168,236 in / 84,617 out  · 133,492 cached (79%) · z-ai/glm-5.2, deepseek/deepseek-v4-pro
security:    $0.0095 · 128,451 in / 28,954 out  · 102,388 cached (80%) · z-ai/glm-5.2
tests:       $0.0094 · 157,750 in / 26,782 out  · 131,795 cached (84%) · z-ai/glm-5.2
description: $0.0030 · 79,147 in  / 3,221 out   · 56,696 cached (72%)  · z-ai/glm-5.2

[tinysweeper]

getLatestBlockhash reads value off the JSON-RPC envelope without decoding

The getLatestBlockhash response is read without unwrapping the JSON-RPC envelope. In balance, the response is passed through decode(id, "getBalance", raw)? before its value field is read, which implies transport.json_rpc returns the full {"result": ..., "id": ...} envelope and decode extracts the result object (and checks for an error field). Here raw.get("value") is called on the envelope directly, but value lives at raw["result"]["value"]["blockhash"], not at the top level. This path will therefore always produce Error::MalformedResponse and never reach signing. It needs decode(id, "getLatestBlockhash", raw)? (or an explicit .get("result")) before .get("value").

[RULE] correctness ·

[tinysweeper]

sendTransaction reads signature off the JSON-RPC envelope without decoding

The sendTransaction result is read with raw.as_str() on the full JSON-RPC envelope returned by transport.json_rpc, but the signature string is at raw["result"] (and any RPC error lives alongside it, not inside). Since the envelope is a JSON object, raw.as_str() returns None, so this always fails with Error::MalformedResponse and the successfully broadcast signature is discarded. As in balance, this needs decode(id, "sendTransaction", raw)? before .as_str(), otherwise the error envelope is never inspected either.

[RULE] correctness ·

[tinysweeper]

verify_transfer claims to check the amount but only checks the recipient

Both the module-level doc and verify_transfer's own rustdoc promise that this function confirms the amount, but the implementation never checks it. verify_transfer takes no amount parameter and only tests whether the recipient's hex appears in raw_data_hex. Given the module's stated purpose — defending against a malicious/compromised node that substitutes the transfer — this is a real gap: a node can return a transaction paying the requested to address with a different (e.g. near-zero) amount and verify_transfer will return Ok(()). Either verify the amount (accept it as a parameter and confirm its varint encoding is present) or correct the documentation to state that only the recipient is checked, and rename/reshape the API so callers cannot infer stronger guarantees than are provided.

[RULE] Documented behavior does not match implementation ·

[tinysweeper]

Capture secret bytes before moving key.secret into PrivateKey::new

If this compiles, it is only because key.secret is Copy; otherwise it is a use-after-move. The intent is clearly secp256k1::SecretKey: key.secret is passed by value into PrivateKey::new (which takes SecretKey by value), and then key.secret.secret_bytes() is called on the final line. secp256k1::SecretKey implements Clone but not Copy (copying secret material silently is a deliberate non-derivation), so the first call moves the field out of key and the second use of key.secret is a use of a moved value — a compile error, or a bug if the type happens to be Copy. Capture the secret bytes (or clone the key) before moving it into PrivateKey::new, e.g. compute key.secret.secret_bytes().to_vec() into a local first.

**[RULE] ** ·

[tinysweeper]

Add a # Errors section to the derive doc comment

The public fallible function derive returns Result, but its doc comment lacks the required # Errors section.

[RULE] Document a # Errors section on every public fallible function and a # Panics section on anything that can panic. ·

[tinysweeper]

Parse the protobuf recipient field instead of substring-matching address hex

verify_transfer confirms the recipient by checking whether the hex encoding of the requested address appears as a substring anywhere in raw_data_hex. Because raw_data is an untrusted protobuf blob built by the node, a malicious endpoint can craft a transaction that pays a different recipient in the real to field while embedding the expected 21 address bytes (42 hex chars) in any other protobuf field — a data/memo field, a contract parameter, or even an amount varint chosen to collide. The substring check would pass, the function returns Ok(()), and the client signs a transaction paying an attacker-chosen address.

    let to_hex = crate::address::tron::to_hex(to).map_err(Error::Address)?;
    if !raw_data_hex
        .to_ascii_lowercase()
        .contains(&to_hex.to_ascii_lowercase())
    {
        return Err(Error::UntrustedResponse {
            reason: "the node's transaction does not pay the requested recipient".to_string(),
        });
    }
    Ok(())

The module comments acknowledge that the function "does not parse the protobuf" and only "confirms the values are present," and claim that is "enough to catch a node that substituted either." It is enough to catch a naive substitution of the recipient field, but it is not enough to stop a node that deliberately fabricates a raw_data to satisfy the substring check while paying someone else. The only robust defence is to parse the protobuf and locate the actual to field — which the module text says it deliberately avoids because the node "owns" the schema. That trade-off leaves a real bypass.

[RULE] untrusted-repo-rules ·

[tinysweeper]

Validate tx_hash before interpolating into the Bitcoin REST path

User-supplied tx_hash is trimmed but otherwise unsanitized, then interpolated directly into a REST URL path for the Bitcoin branch. A caller passing a string containing / or .. (e.g. "../blocks/123") causes the transport to request a different endpoint than intended — tx/../blocks/123/status resolves to blocks/123/status — which is path injection into the REST path. The JSON-RPC branches are not affected because the hash is serialized as a JSON string parameter there, but the Bitcoin branch builds a raw URL string via format!.

The fix is to validate that hash is a plausible transaction hash (hex for Bitcoin) before interpolating, or to percent-encode the segment.

[RULE] untrusted input reaching a dangerous sink ·

[tinysweeper]

Validate address before interpolating into Esplora URL path

The address parameter is interpolated directly into the REST path with format! and no URL-encoding or validation. A caller passing a string containing / or .. (e.g. ../tx or foo/bar) causes rest_get to request an arbitrary endpoint on the Esplora host instead of the intended address resource. Bitcoin addresses are a fixed alphabet that excludes these characters, so the function should reject anything outside it rather than forwarding the raw string into a URL path. from in send reaches the same sink via utxos.

existing_code: .rest_get(id, &format!("address/{address}"))

[RULE] Validate or URL-encode the address before interpolating it into a REST path ·

[tinysweeper]

Add a test that verifies the base64-encoded Solana transaction

The hand-written base64_encode in src/client/solana.rs is exercised only by send_solana_fetches_a_blockhash_then_broadcasts_base64, but that test uses Sequenced, whose json_rpc implementation ignores _params — it dispatches by method name alone and returns a canned answer. The base64-encoded transaction is sent as a parameter to sendTransaction, so no test ever observes the encoder's output. A broken base64_encode would produce a transaction Solana rejects, but every test would still pass.

async fn json_rpc(
    &self,
    network: NetworkId,
    method: &str,
    _params: Value,
) -> TransportResult<Value> {
    self.calls.lock().unwrap().push(method.to_string());
    self.answers
        .get(method)
        .cloned()
        .ok_or_else(|| TransportError::Rpc {

[RULE] Maintain at least 80% coverage of meaningful library behavior ·

[tinysweeper]

Cover the send_evm path with non-empty calldata

Every send_evm test passes Vec::new() for the data parameter. The branch that adds calldata to the gas-estimation request is new code and is never taken:

if !data.is_empty() {
    estimate["data"] = json!(format!("0x{}", hex_string(&data)));
}

If the data field were omitted from the estimate or the hex prefix were wrong, no test would fail. The ERC-20 signing path is tested in tx/test.rs, but the send_evm orchestration with non-empty calldata — from estimate through broadcast — has no end-to-end coverage.

[RULE] Maintain at least 80% coverage of meaningful library behavior ·

[tinysweeper]

What this change touches

30 files, +5682 -7 across 9 components. The code graph knows nothing about these files yet — normal for newly added files, and a cold index otherwise.

flowchart LR
  n0["src/client<br/>7 files +1898 -0<br/>7 findings"]:::blocking
  n1["src/tx<br/>7 files +1801 -0<br/>5 findings"]:::blocking
  n2["src/key<br/>8 files +757 -0<br/>2 findings"]:::blocking
  n3["src/asset<br/>2 files +666 -0"]:::changed
  n4["src/rpc<br/>2 files +485 -0"]:::changed
  n5["root<br/>1 file +55 -2<br/>1 finding"]:::blocking
  n6["src<br/>1 file +15 -0"]:::changed
  n7["src/address<br/>1 file +4 -4"]:::changed
  n8["src/error<br/>1 file +1 -1"]:::changed
  classDef changed fill:#0d4429,stroke:#238636,color:#e6edf3
  classDef impacted fill:#161b22,stroke:#6e7681,color:#c9d1d9
  classDef flagged fill:#5a1e02,stroke:#d93f0b,color:#ffffff
  classDef blocking fill:#67060c,stroke:#f85149,color:#ffffff

Loading

_{Green: changed. Grey: untouched, reached through an import or a call. Orange: has findings. Red: has a finding that blocks the merge.}

Component		Files	Lines	Findings
src/client	changed	7	+1898 -0	7 (high)
src/tx	changed	7	+1801 -0	5 (high)
src/key	changed	8	+757 -0	2 (high)
src/asset	changed	2	+666 -0	—
src/rpc	changed	2	+485 -0	—
(root)	changed	1	+55 -2	1 (high)
src	changed	1	+15 -0	—
src/address	changed	1	+4 -4	—
src/error	changed	1	+1 -1	—

Changed files

src/client

• src/client/btc.rs
• src/client/evm.rs
• src/client/mod.rs
• src/client/solana.rs
• src/client/status.rs
• src/client/test.rs
• src/client/tron.rs

src/tx

• src/tx/btc.rs
• src/tx/evm.rs
• src/tx/mod.rs
• src/tx/rlp.rs
• src/tx/solana.rs
• src/tx/test.rs
• src/tx/tron.rs

src/key

• src/key/bip32.rs
• src/key/btc.rs
• src/key/evm.rs
• src/key/mod.rs
• src/key/slip10.rs
• src/key/solana.rs
• src/key/test.rs
• src/key/tron.rs

src/asset

• src/asset/mod.rs
• src/asset/test.rs

src/rpc

• src/rpc/mod.rs
• src/rpc/test.rs

(root)

• Cargo.toml

src

• src/lib.rs

src/address

• src/address/mod.rs

src/error

• src/error/mod.rs