polish: signing dialog, unpriced balances, Hive button contrast

[sktbrd]

Three independent UI/correctness fixes found while running the latest develop locally. Each is its own commit and can be split if you'd rather review separately.

1. Hive panel outline buttons unreadable

The PeakD / Hive.blog / Ecency profile links and both Retry buttons used a bare Chakra variant="outline". The app mounts ChakraProvider with no color-mode provider, so that variant resolves against the gray palette's light-mode pair — near-black text inside a bright border — which inverts against the dark glass card.

Every other outline button in the app already passes explicit colors (SweepDialog, AddChainDialog, StakingPanel, …); this panel was the only one relying on the default, which is why it was the only place the inversion was visible.

Worth a follow-up: the light-color-mode setup means the next bare variant="outline" hits this again. Either force dark mode or add _dark conditions to the semantic tokens in theme.ts.

2. Signing dialog polish

• Glow — the card ran an infinite 2s pulse peaking at a 24px/0.7-alpha gold shadow plus a 48px halo. Reduced to a faint 10px/0.18 breathe over 4s; border 2px solid gold → 1px at 45% alpha.
• Actions always visible — the whole card was maxH="90vh" overflowY="auto", so a large calldata blob pushed Approve/Reject below the fold. Now: pinned header, scrolling content region, pinned action row.
• Decoded calldata — new Etherscan-style Hex/Decoded toggle for payloads we can't clear-sign. No ABI means no parameter names, but selector + indexed 32-byte words (annotated where a word looks like an address or fits a safe integer) is what makes a blind-signing payload auditable. Malformed non-word-aligned trailing bytes are flagged.

New strings added to en only — other locales already run behind and fallbackLng: "en" covers them.

3. Unpriced balances rendered as "no balance"

const hasAggregate = (agg?.balanceUsd ?? 0) > 0

The drilled chain view gated its empty state on USD alone. A chain with a missing/failing price feed reports balanceUsd: 0 while the user still holds funds, so the pane rendered "No Arbitrum balance yet" over a real 0.000891 ETH balance — the sidebar showed the amount, the detail pane claimed the chain was empty. The fundedAddrs filter above it had the same bug.

Both now also check the token amount, via a shared hasNonZeroBalance() in lib/formatting.

Out of scope: the All-Chains total still excludes unpriced chains — that figure is USD and the arithmetic is correct. That Arbitrum native ETH resolves no price at all is a separate upstream pricing bug worth its own issue.

Testing

tsc --noEmit clean (aside from the pre-existing TS2688 minimatch implicit-type-library error on develop), vite build passes.

🤖 Generated with Claude Code

[sktbrd]

Added a fourth commit (ab68484e) — the funds-safety gap found while diagnosing the wrong-signer report.

Verify the device signer before broadcasting

Every EVM broadcast path handed the device's serialized bytes straight to eth_sendRawTransaction with no check that the signature recovers to the account we asked to sign. The browser extension already guards this; the vault had no equivalent, so a WalletConnect dApp signing through the vault would silently broadcast a doomed transaction.

This isn't about a compromised device. Firmware 7.x.0–7.14.0 hashes the EIP-1559 empty access-list byte (0xC0) too early, so any tx whose calldata exceeds the 1024-byte single-chunk transport limit gets a non-canonical pre-image. The signature is mathematically valid, so RPC nodes accept the broadcast — then it's dropped from the mempool forever, because the recovered address has no balance and the wrong nonce. Fixed in firmware 7.14.1, but stable still ships an affected build, so the check belongs in the vault.

Design note: expectedFrom is a required parameter of broadcastEvmTx() rather than optional. A silently mis-signed tx is unrecoverable once it leaves, so a future broadcast path must not be able to forget the check. All five call sites updated — three in swap.ts, the custom-chain handler in index.ts, and WalletConnect.

WalletConnect verifies even when it isn't the broadcaster, since the dApp may broadcast the bytes we hand back.

Tests

New __tests__/evm-signer-verify.test.ts, wired into make test-unit — 4 passing: valid signature accepted, checksum-case tolerated, mismatch rejected (the firmware bug in miniature), unparseable bytes rejected rather than passed through.

Full suite: 325 pass / 2 fail. Those 2 failures are pre-existing — I confirmed by stashing this branch's changes and re-running develop, which gives the identical 2 fail / 2 errors (the errors are electrobun's Updater.ts looking for ../Resources/version.json outside an app bundle). Not introduced here.

[BitHighlander]

Reviewed the full 11-file diff. I found two fail-open paths in the EVM signer guard and pushed commit 33495f65 to the PR branch:

• signer-verification failures are now typed and rethrown before the swap code can fall back to Pioneer, so rejected bytes cannot route around the guard
• custom EVM broadcast now verifies against the request's fromAddress, not mutable current account selection between build/sign/broadcast

Validation after the correction:

• bun test __tests__/evm-signer-verify.test.ts — 4 passed
• full renderer/backend/Electrobun bun run build passed
• git diff --check passed

I found no further code-review blockers in the Hive styling, unpriced-balance handling, signing-dialog/calldata inspector, WalletConnect verification, or EVM paths. The remaining gate is canonical GitHub Actions; develop PR builds are being enabled in #381, after which this branch should be synchronized/re-run before merge.

[BitHighlander]

Approved after full review and correction of the EVM signer-verification paths.

The branch was synchronized with current develop after #381 merged. Combined head 33a33e00 passes canonical GitHub Actions on Linux and macOS, including module builds, the Ironwood Zcash sidecar, the full Vault app build, architecture verification, packaging, and artifact upload.

The earlier fail-open findings remain fixed:

• signer-verification errors cannot fall through to Pioneer broadcast
• custom EVM broadcast verifies against the signed request's fromAddress, not mutable account selection

No unresolved review threads or remaining merge blockers.