chore(deps): bump alloy-signer-ledger from 1.8.3 to 2.0.5 - #1493
chore(deps): bump alloy-signer-ledger from 1.8.3 to 2.0.5#1493dependabot[bot] wants to merge 1 commit into
Conversation
Bumps [alloy-signer-ledger](https://github.com/alloy-rs/alloy) from 1.8.3 to 2.0.5. - [Release notes](https://github.com/alloy-rs/alloy/releases) - [Changelog](https://github.com/alloy-rs/alloy/blob/main/CHANGELOG.md) - [Commits](alloy-rs/alloy@v1.8.3...v2.0.5) --- updated-dependencies: - dependency-name: alloy-signer-ledger dependency-version: 2.0.5 dependency-type: direct:production update-type: version-update:semver-major ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
🟡 Value Audit — sound-with-nits
| Verdict | sound-with-nits |
| Concerns | 1 (1 weak-concern) |
| Heuristic | 0.0s |
| Duplication | 0.0s |
| Interrogation | 900.0s (2 bridge agents) |
| Total | 900.0s |
💰 Value — sound-with-nits
Bumps alloy-signer-ledger 1.8.3→2.0.5 to align it with the already-2.0 aws/gcp remote signers; correct and minimal, but leaves the workspace mid-migration with alloy compiled in two major versions at once.
- What it does: Raises the workspace requirement on
alloy-signer-ledgerfrom1.8to2.0(Cargo.toml:428) and updates Cargo.lock so the Ledger remote-signer path (and its transitivealloy-consensus/alloy-network/alloy-signerdeps) move from the 1.8.3 line to the 2.0.5 line. No source changes — pure manifest/lock bump. - Goals it achieves: Keep the Ledger hardware-wallet signing backend on the current alloy 2.0 release line that the other cloud signers (AWS KMS, GCP KMS) already target, picking up upstream 2.x fixes (e.g. the EIP-1559 divide-by-zero fix, provider cleanup) and consolidating the remote-signer camp on one alloy major.
- Assessment: Coherent and in the grain:
alloy-signer-awsandalloy-signer-gcpwere already pinned at2.0(Cargo.toml:426-427), so this brings the third remote signer onto the same line. The change is minimal and directionally correct. However, the workspace is mid-migration —alloy-signerandalloy-signer-localremain at1.8(Cargo.toml:414-415) while the remote signers sit at2.0, so `alloy-sign - Better / existing approach: A single coordinated PR that also bumps
alloy-signer(Cargo.toml:414) andalloy-signer-local(Cargo.toml:415) from1.8to2.0would collapse the dual-major compile ofalloy-signer/alloy-consensus/alloy-networkin one shot, rather than leaving the 1.8/2.0 split to be chipped at one dependabot PR at a time. Checked: the split predates this PR (aws/gcp were already 2.0), so this PR is n - Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 2
- Bridge warning: opencode/kimi-for-coding/k2p7: opencode: opencode error
🎯 Usefulness — error
usefulness agent produced no parseable value-audit JSON.
- Model: opencode/zai-coding-plan/glm-5.2
- Bridge attempts: 1
- Bridge error: no parseable JSON response
💰 Value Audit
🟡 alloy 1.8/2.0 split left half-finished; keystore is the seam [maintenance] ``
After this bump the tree compiles alloy-signer/consensus/network in two majors at once (Cargo.lock:848 vs :863, :142 vs :169, :432 vs :458), and
crates/keystore/Cargo.toml:37-52consumes bothalloy-signer@1.8 (via local) andalloy-signer-ledger@2.0 under one roof. That dual-compile is bloat and a future type-mismatch hazard at the signer-integration boundary. The cleaner fix is a coordinated follow-up bumpingalloy-signerandalloy-signer-local(Cargo.toml:414-415) to2.0to collapse
What this audit checks
It judges the change on its merits — not whether it was tasked out in an issue. Unticketed, fast-moving work is fine; the question is whether the change is good and whether a better or existing approach should be used instead.
| Pass | What it asks |
|---|---|
| Heuristic | Vague title? Whitespace-only or cruft-bearing diff? (content signals only) |
| Duplication | Do added function/class names already exist elsewhere in the repo? |
| Value Audit | What does it do? What goal does it achieve? Is it good? Better architecture or already-exists? |
| Usefulness Audit | Does it integrate and fit? Will it hold up in real use and actually get used? |
Findings are concerns, not blocks — the human reviewer decides what to do with them.
❌ Needs Work —
|
| glm | deepseek | deepseek-flash | aggregate | |
|---|---|---|---|---|
| Readiness | 92 | 82 | 60 | 60 |
| Confidence | 70 | 70 | 70 | 70 |
| Correctness | 92 | 82 | 60 | 60 |
| Security | 92 | 82 | 60 | 60 |
| Testing | 92 | 82 | 60 | 60 |
| Architecture | 92 | 82 | 60 | 60 |
Reviewer score is advisory once the run is complete and the verdict has no blockers.
Full multi-shot audit completed 2/2 planned shots over 2 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 2/2 planned shots over 2 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 2/2 planned shots over 2 changed files. Global verifier still owns final merge decision.
Blocking
🟣 CRITICAL alloy-signer-ledger 2.0 bump breaks compilation of the ledger remote signer (Signer trait version split) — Cargo.toml
Workspace dependency
alloy-signer-ledgerbumped from 1.8 to 2.0 (line 428) resolves to alloy-signer-ledger 2.0.5 in Cargo.lock, which depends on alloy-signer 2.0.5, alloy-network 2.0.5, alloy-consensus 2.0.5 (Cargo.lock ~L915-930). The workspace still pins alloy-signer=1.8, alloy-network=1.8, alloy-consensus=1.8 (Cargo.toml:414,416,418), so two versions of the same crates coexist. crates/keystore/src/remote/ledger.rs:4 doesuse alloy_signer::Signer;which binds to the 1.8.3 trait, but alloy-signer-ledger 2.0.5's LedgerSigner implements the 2.0.5 Signer trait (verified in ~/.cargo/registry/src/.../alloy-signer-ledger-2.0.5/src/signer.rs:90). CI clippy jobs on head commit 1742480
Other
🟠 MEDIUM Cannot verify compilation — no cargo toolchain in review environment — Cargo.toml
alloy-signer-ledger bumped from 1.8 to 2.0, but no cargo is available in this review jail to run cargo check -p blueprint-keystore --features ledger-node. The ledger.rs consumer (crates/keystore/src/remote/ledger.rs) imports
use alloy_signer::Signerfrom the v1.8 workspace dep while LedgerSigner v2.0 internally depends on alloy-signer 2.0 — though method calls resolve to inherent methods, this should be confirmed with a compile check. CI green on the actual PR should resolve this.
🟡 LOW Duplicate alloy crate versions after ledger 2.0 bump — Cargo.toml
alloy-signer-ledger 2.0.5 hard-depends on alloy-consensus/network/signer = 2.0.5 (verified in registry Cargo.toml:
[dependencies.alloy-consensus] version = "2.0.5"). The workspace still declares alloy-consensus=1.8 (line 418), alloy-network=1.8 (line 416), alloy-signer-local=1.8 (line 415). Cargo.lock now resolves two copies of each (rg -c count=2). Compiles fine but bloats dep graph and signals a partial migration. Fix: either complete the alloy-{consensus,network,s
tangletools · 2026-08-03T12:33:29Z · trace
tangletools
left a comment
tangletools
left a comment
There was a problem hiding this comment.
❌ 1 Blocking Finding — 17424806
Full multi-shot audit completed 2/2 planned shots over 2 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 2/2 planned shots over 2 changed files. Global verifier still owns final merge decision. | Full multi-shot audit completed 2/2 planned shots over 2 changed files. Global verifier still owns final merge decision.
Full immutable report for this review: trace
Summary comment for this run: full summary
tangletools · 2026-08-03T12:33:29Z · immutable trace
1 participant
Bumps alloy-signer-ledger from 1.8.3 to 2.0.5.
Release notes
Sourced from alloy-signer-ledger's releases.
... (truncated)
Changelog
Sourced from alloy-signer-ledger's changelog.
... (truncated)
Commits
653989fchore: release 2.0.5ee8c72fchore: release 2.0.5a90ea92chore: release 2.0.551090d3chore: release 2.0.52d3a3fbdocs(rpc-types-eth): correct sealed_header docs (#3995)a019321fix(ci): satisfy zepter secp256k1 propagation (#3993)a51afc1docs(node-bindings): clarify Reth genesis behavior (#3994)2aa6712chore(deps): bump github/codeql-action from 4.35.2 to 4.35.4 (#3990)f97b3cbfix(network): preserve transaction request extra fields51cb51dchore(deps): bump taiki-e/install-action from 2.75.27 to 2.77.1Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore this major versionwill close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this minor versionwill close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)@dependabot ignore this dependencywill close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)