fix(hive): render op summaries in the approval card

[BitHighlander]

What was broken

hiveHandler builds a one-line summary per operation and stashes it in unsignedTx.operations (hiveHandler.ts:641). No component ever read it — grepping pages/side-panel/src/approval/ for .operations returns zero hits.

So a Hive op batch fell through to the generic amount table, which has no destination and no amount to show for a batch:

	before	after
To	N/A	(row gone)
Amount	0	(row gone)
Account	—	@alice
limit_order_create	—	Sell 1.500 HIVE for 0.400 HBD
limit_order_cancel	—	Cancel order 1 (@alice)

The summaries did exist in the UI — inside RequestDataCard's collapsed raw-JSON dump.

Why it matters

Four ops in SUPPORTED_OPS are passthrough-only: claim_reward_balance, account_update2, limit_order_create, limit_order_cancel. Keychain has no dedicated request method for them, so a dApp composes them and sends them through requestBroadcast — the panel was the user's only look before the device screen.

The OLED is authoritative and was always correct, so this was never a signing hole. But the clear-sign table exists so the user can compare the screen against what the dApp asked for, and half of that comparison was an unreadable blob.

The move to hiveOps.ts

SUPPORTED_OPS and opSummary are now a leaf module. hiveHandler.ts imports @extension/storage, which touches chrome.* at import time and throws chrome is not defined under vitest — the table was untestable where it lived. Same pattern as the feeFloors / lastResortRpcs leaf modules already in chains/. No logic changed in the move.

Tests

hiveOpSummary.test.ts pins the contract the card now depends on: every op in SUPPORTED_OPS must summarize to something other than its own bare name (opSummary's default arm returns name — precisely the unreadable render this fixes) and must carry a test payload, so adding an op without a summary fails the build.

It also pins what a user has to check against the OLED: amounts with symbols, the counterparty, the '0.000000 VESTS' sentinels that mean stop / remove rather than "send zero", and comment_options beneficiary names + percentages — a payout redirect being the one thing in the table an attacker would most want unreadable.

Differential-verified — deleting the limit_order_create case fails with:

limit_order_create falls through to the default arm — add a case to opSummary()

121 pass, 11 files (up from 116). make type-check clean across all 15 packages; make build clean.

Not in scope

Host-side constraint validation (max-4 ops, single-tier, beneficiary sort, fill_or_kill boolean) stays absent client-side on purpose — the vault enforces all of it with a readable 400 before the device is touched, per docs/handoff-bex-hive-full-operations.md §4. Duplicating it here is two places to drift.

🤖 Generated with Claude Code

[BitHighlander]

All three addressed in a7a44b1. Thanks — #1 and #2 were real divergences between the approval and the signed bytes, which is the one bug class this PR exists to close.

1. custom_json approval vs signed payload — fixed

Mirrored the vault's own expression rather than approximating it:

function serializedJson(json: any): string {
  return typeof json === 'string' ? json : JSON.stringify(json ?? {});
}

Byte-identical to hive-ops.ts:151. Truncation now carries the dropped length, so two payloads sharing a 120-char prefix no longer render alike:

test: xxx…(120)… (+4 more chars)
test: xxx…(120)… (+8 more chars)

Tests added for object payloads, string payloads, the truncation marker, differing suffixes, and the no-marker-when-short case.

2. comment_options payout controls — fixed, both halves

Every control that differs from the Hive default is now named; defaults stay quiet so the common case remains a one-liner:

Payout options for @alice/a-post · max payout 0.000 HBD · 0.0% HBD · votes disabled

Also caught while implementing: percent_steem_dollars is a legacy alias the vault falls back to at hive-ops.ts:225. A summary reading only percent_hbd would have shown the default while a non-default value was signed — same bug class, so it's read and tested.

On recoverability — you're right that {op, summary} made the raw view unable to recover these. unsignedTx.operations now carries params verbatim. Worth recording why this is load-bearing rather than a duplicate copy: RequestDataCard renders transaction.unsignedTx and nothing else, and the event's own request is never displayed in any tab. params is the only surface on which the operation body appears at all.

3. Default tab — fixed, and the finding was stronger than stated

defaultIndex={0}. The situation was worse than "starts collapsed": RequestDataCard is useState(false) with the JSON inside {isOpen && (…)}, so the old landing view was a chevron and the word "Data" — zero transaction facts on any chain, until a click.

Since this changes the default for all five chains routed to OtherTransaction, I checked each rather than assuming Hive's win generalized:

Chain	Basic landing view	vs. before
Hive (ops)	Account + one row per op	Improvement
Ripple	destination / amount / destinationTag	Improvement
Tron contract-call	dedicated contract/function branch	Improvement
Solana, TON	N/A	Wash — old view was empty

No chain regresses; cost is one click to Raw for the wash row.

Verification

125 tests (was 121); type-check, prettier, build clean.

Differential-verified both P1 fixes — reverting each fails loudly:

expected 'follow: [object Object]' not to contain '[object Object]'
expected 'Payout options for @alice/a-post' to contain '0.000 HBD'

I also ran an adversarial audit over the fixes (5 lenses × per-finding refutation, 35 candidates). None survived, but two pre-existing defects it surfaced are worth separate issues, both out of scope here:

• Solana/TON transfer events never populate unsignedTx.payment — solanaHandler.ts:937 / tonHandler.ts:444 stash to/amount at the top level while RequestDetailsCard reads payment?.*, so those approvals show N/A. This is why those two chains are a wash above rather than an improvement.
• isSignMessage is gated on the two solana_* types only, so Hive signBuffer, TON and Tron sign-message events fall through to the To/Amount table. Note for whoever picks it up: don't just widen the predicate — TON puts plain text in unsignedTx.message where Solana puts hex, so the existing fallback would hex-dump readable text and warn "not printable UTF-8" falsely.

Not touched here: host-side constraint validation (max-4, single-tier, beneficiary sort, fill_or_kill boolean). The vault rejects all of those with a 400 before wallet.hiveSignOperations is called, so it costs an error message rather than a device interaction — and the 2048-byte cap is on serialized Graphene bytes the extension never produces, so it can't be checked here without reimplementing the serializer.