data/src/main/kotlin/com/vultisig/wallet/data/utils/AbiToJson.kt (1)

81-86: Narrow the fallback to NumberFormatException.

BigInteger(value) only needs a parse-error fallback here. Catching Exception also hides unrelated failures in this conversion path.

♻️ Proposed change

 private fun parseBigIntAsJsonString(value: String): JsonElement {
     return try {
         val big = BigInteger(value)
         JsonPrimitive(big.toString())
-    } catch (_: Exception) {
+    } catch (_: NumberFormatException) {
         JsonPrimitive(value)
     }
 }

Based on learnings: Do not use a broad catch (`catch (Exception)`) to swallow errors in Kotlin.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@data/src/main/kotlin/com/vultisig/wallet/data/utils/AbiToJson.kt` around
lines 81 - 86, The parseBigIntAsJsonString function currently catches all
Exceptions which can mask unrelated errors; change the catch to specifically
catch NumberFormatException when calling BigInteger(value) and keep the fallback
JsonPrimitive(value) behavior so only parse errors are handled; update the catch
clause in parseBigIntAsJsonString and leave other logic (creating BigInteger and
returning JsonPrimitive(big.toString())) unchanged.

Fix all unresolved CodeRabbit comments on this PR:

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

app/src/main/java/com/vultisig/wallet/ui/screens/TransactionDoneScreen.kt (1)

70-83: ⚠️ Potential issue | 🟠 Major

Avoid native-token fallback for decoded send calls with unresolved sentinel token.

On Line 75, resolvedToken ?: token reintroduces the misleading native hero when functionName != null && resolvedToken == null (intentional sentinel case). Render a header-only hero in that branch (same behavior already applied in verify screen).

Suggested fix

                     if (transactionTypeUiModel is TransactionTypeUiModel.Send) {
                         val transaction = transactionTypeUiModel.tx
-                        val heroHeader =
-                            transaction.functionName
-                                ?: stringResource(R.string.tx_overview_screen_tx_send)
-                        val heroToken = transaction.resolvedToken ?: transaction.token
-
-                        VsOverviewToken(
-                            header = heroHeader,
-                            valuedToken = heroToken,
-                            shape = RoundedCornerShape(24.dp),
-                            modifier = Modifier.fillMaxWidth(),
-                        )
+                        if (transaction.functionName != null && transaction.resolvedToken == null) {
+                            Text(
+                                text = transaction.functionName,
+                                style = Theme.brockmann.headings.title3,
+                                color = Theme.v2.colors.text.primary,
+                                modifier = Modifier.fillMaxWidth(),
+                            )
+                        } else {
+                            val heroHeader =
+                                transaction.functionName
+                                    ?: stringResource(R.string.tx_overview_screen_tx_send)
+                            val heroToken = transaction.resolvedToken ?: transaction.token
+
+                            VsOverviewToken(
+                                header = heroHeader,
+                                valuedToken = heroToken,
+                                shape = RoundedCornerShape(24.dp),
+                                modifier = Modifier.fillMaxWidth(),
+                            )
+                        }
                     }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/com/vultisig/wallet/ui/screens/TransactionDoneScreen.kt`
around lines 70 - 83, The code in TransactionDoneScreen.kt currently uses
transaction.resolvedToken ?: transaction.token inside the
TransactionTypeUiModel.Send branch which resurrects a native-token hero when
resolvedToken is intentionally null for decoded send calls; change the logic to
detect when transaction.functionName != null and resolvedToken == null and in
that case pass no token to VsOverviewToken so it renders a header-only hero
(mirror the behavior used in the verify screen) instead of falling back to
transaction.token; update the TransactionTypeUiModel.Send branch that builds
heroHeader and heroToken and ensure VsOverviewToken is called without a
valuedToken when resolvedToken is the sentinel null.

data/src/main/kotlin/com/vultisig/wallet/data/repositories/ContractCallExtractor.kt (1)

127-152: Normalize ABI type tokens before matching uint256 / address.

The matcher currently requires exact tokens ("uint256", "address"). If signatures include parameter names (for example, uint256 amount), extraction silently fails. Normalizing to base type makes this parser more resilient.

Suggested refactor

 private fun splitTopLevel(params: String): List<String> {
@@
 }
+
+private fun String.baseAbiType(): String = trim().substringBefore(' ')
@@
-        val uint256Idx = paramTypes.indexOf("uint256")
+        val uint256Idx = paramTypes.indexOfFirst { it.baseAbiType() == "uint256" }
@@
-                val addressIdx = paramTypes.indexOf("address")
+                val addressIdx = paramTypes.indexOfFirst { it.baseAbiType() == "address" }
@@
-                    if (type == "address") {
+                    if (type.baseAbiType() == "address") {

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@data/src/main/kotlin/com/vultisig/wallet/data/repositories/ContractCallExtractor.kt`
around lines 127 - 152, The parser in ContractCallExtractor is matching exact
strings "uint256" and "address" against paramTypes, which fails when ABI tokens
include parameter names (e.g., "uint256 amount"); update the normalization of
paramTypes before matching by transforming each entry to its base type (trim
whitespace and take the leading token before any space or other suffix like
parameter name or modifiers) so comparisons such as val uint256Idx =
paramTypes.indexOf("uint256") and subsequent address checks work reliably across
ExtractionStrategy cases (including FirstAddressBeforeFirstUint and NthAddress).

Fix all unresolved CodeRabbit comments on this PR:

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

app/src/main/java/com/vultisig/wallet/ui/components/buttons/VsHoldableButton.kt (1)

37-37: Caller-supplied holdDuration can re-introduce the visual/firing mismatch.

When a caller overrides the default with a value other than the platform long-press timeout, combinedClickable.onLongClick will still fire at ViewConfiguration.longPressTimeoutMillis (~400 ms) regardless of holdDuration, so the fill animation will again be out of sync with the actual long-press callback. Consider either:

• Documenting that holdDuration is purely cosmetic and cannot extend/shorten the actual long-press window, or
• Removing the parameter entirely and always using LocalViewConfiguration.current.longPressTimeoutMillis to prevent misuse.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/src/main/java/com/vultisig/wallet/ui/components/buttons/VsHoldableButton.kt`
at line 37, The caller-controlled holdDuration parameter can desynchronize the
visual fill and the actual long-press event (combinedClickable.onLongClick fires
at ViewConfiguration.longPressTimeoutMillis regardless), so remove the
holdDuration parameter from the VsHoldableButton API and always source the
duration from LocalViewConfiguration.current.longPressTimeoutMillis inside the
component; update any references to holdDuration within VsHoldableButton (e.g.,
animation timing, CombinedClickable/combinedClickable usage and any local
variables) to use the platform timeout and remove or adapt any external call
sites that passed holdDuration.

app/src/main/java/com/vultisig/wallet/ui/screens/send/VerifySendScreen.kt (2)

412-440: Using a borders token as a background fill is a theme-token mismatch.

Theme.v2.colors.variables.bordersLight is intended for stroke colors. For the expanded panel's background, switch to a backgrounds token (e.g., Theme.v2.colors.backgrounds.secondary/tertiary) so the panel honors light/dark theming consistently and stays aligned with Figma. As per coding guidelines, "Use the project's existing theme tokens (Theme.v2.colors., Theme.brockmann.)".

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/com/vultisig/wallet/ui/screens/send/VerifySendScreen.kt`
around lines 412 - 440, The panel is using a stroke token for its fill; update
the Modifier.background call inside the AnimatedVisibility block (the Column
that wraps VerifyCardJsonDetails) to use a background token such as
Theme.v2.colors.backgrounds.secondary or .tertiary instead of
Theme.v2.colors.variables.bordersLight so the expanded panel (where
functionSignature/functionInputs are shown) follows background theming and Figma
tokens.

---

402-409: Animate the chevron rotation for smoother expand/collapse.

A bare rotationZ = if (isExpanded) 180f else 0f snaps. animateFloatAsState matches the AnimatedVisibility timing and is idiomatic in Compose.

Suggested fix

+            val chevronRotation by animateFloatAsState(targetValue = if (isExpanded) 180f else 0f)
             IconButton(onClick = { isExpanded = !isExpanded }, modifier = Modifier.size(16.dp)) {
                 UiIcon(
                     drawableResId = R.drawable.chevron,
                     tint = Theme.v2.colors.text.tertiary,
                     size = 8.dp,
-                    modifier = Modifier.graphicsLayer(rotationZ = if (isExpanded) 180f else 0f),
+                    modifier = Modifier.graphicsLayer(rotationZ = chevronRotation),
                 )
             }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/com/vultisig/wallet/ui/screens/send/VerifySendScreen.kt`
around lines 402 - 409, The chevron rotation currently snaps because rotationZ
is set directly; replace it with an animated float using animateFloatAsState
(e.g., val rotation by animateFloatAsState(targetValue = if (isExpanded) 180f
else 0f, animationSpec = ...) ) and use that animated value in
Modifier.graphicsLayer(rotationZ = rotation) inside the IconButton in
VerifySendScreen (the block with IconButton/UiIcon), so the chevron rotation is
smooth and synced with the AnimatedVisibility timing.

app/src/main/java/com/vultisig/wallet/ui/screens/TransactionDoneScreen.kt (1)

260-280: Inconsistent disclosure pattern between Verify and Done screens.

VerifySendScreen shows function signature/inputs inside a collapsible TransactionDetailsSection (chevron + scrollable card), but TransactionDoneScreen lays them out as flat divider-separated OtherField rows. For long ABI inputs (which can be hundreds of chars for swaps/multicalls), this expands the done screen unboundedly with no way to collapse. Consider mirroring the same TransactionDetailsSection here for consistency and to keep the done-screen scrollable area sane.

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@app/src/main/java/com/vultisig/wallet/ui/screens/TransactionDoneScreen.kt`
around lines 260 - 280, TransactionDoneScreen currently renders long ABI fields
as flat OtherField rows (surrounded by UiHorizontalDivider), causing unbounded
expansion; replace the functionSignature and functionInputs blocks with the same
TransactionDetailsSection used in VerifySendScreen so they are rendered inside a
collapsible chevron + scrollable card. Specifically, remove the OtherField +
UiHorizontalDivider pairs for transaction.functionSignature and
transaction.functionInputs and invoke TransactionDetailsSection (passing the
appropriate title strings and the functionSignature/functionInputs values) so
long inputs are collapsible and scrollable like VerifySendScreen.

Fix all unresolved CodeRabbit comments on this PR:

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

app/src/main/java/com/vultisig/wallet/ui/screens/transaction/SendTxOverviewScreen.kt (1)

79-85: ⚠️ Potential issue | 🟡 Minor | ⚡ Quick win

Hero typography is still title2 here while VerifySendScreen uses title3 for the same field.

Line 81 uses Theme.brockmann.headings.title2; VerifySendScreen line 201 uses headings.title3. A user sees the hero grow when navigating from the verify screen to the done/overview screen for the same transaction.

🔧 Proposed fix

-                    style = Theme.brockmann.headings.title2,
+                    style = Theme.brockmann.headings.title3,

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/src/main/java/com/vultisig/wallet/ui/screens/transaction/SendTxOverviewScreen.kt`
around lines 79 - 85, The hero typography in SendTxOverviewScreen is using
Theme.brockmann.headings.title2 for the tx.functionName Text, causing a size
jump compared to VerifySendScreen which uses headings.title3; update the Text
style in SendTxOverviewScreen (the Text that displays tx.functionName) to use
Theme.brockmann.headings.title3 so both screens use the same hero typography.

app/src/main/java/com/vultisig/wallet/ui/models/keysign/JoinKeysignViewModel.kt (1)

1339-1353: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

functionName (the signing-screen hero) is sourced from an unauthenticated, crowdsourced registry.

prettifyEvmFunctionName processes text returned by FourByteRepository, which queries 4byte.directory with ordering=created_at + firstOrNull(). The registry is crowdsourced and has no signature-authenticity guarantees: anyone can submit a fraudulent text for any 4-byte selector before the legitimate entry, causing every signing device to display an attacker-chosen string as the prominent action hero (e.g., "Supply 100 USDC" for a transferFrom call). The reviewer rkokhatskyi already raised this concern in the PR thread with the same risk analysis and proposed mitigations.

app/src/main/java/com/vultisig/wallet/ui/models/keysign/JoinKeysignViewModel.kt (1)

1327-1334: ⚡ Quick win

decodeFunctionArgs failure silently drops functionName even when the signature was resolved.

If fourByteRepository.decodeFunctionArgs returns null the entire FunctionInfo is null (line 1329 return@withContext null), so functionName is never set and the hero falls back to the native token display — even though the 4byte signature lookup succeeded. Making FunctionInfo.inputs nullable preserves the function name in the hero when only arg-decoding fails:

♻️ Proposed fix

 internal data class FunctionInfo(
     val signature: String,
-    val inputs: String,
+    val inputs: String?,
     val functionName: String? = null,
 )

         return withContext(Dispatchers.IO) {
             val functionSignature =
                 fourByteRepository.decodeFunction(memo) ?: return@withContext null
-            val functionInputs =
-                fourByteRepository.decodeFunctionArgs(functionSignature, memo)
-                    ?: return@withContext null
             FunctionInfo(
                 signature = functionSignature,
-                inputs = functionInputs,
+                inputs = fourByteRepository.decodeFunctionArgs(functionSignature, memo),
                 functionName = prettifyEvmFunctionName(functionSignature),
             )
         }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@app/src/main/java/com/vultisig/wallet/ui/models/keysign/JoinKeysignViewModel.kt`
around lines 1327 - 1334, The current logic returns null when
fourByteRepository.decodeFunctionArgs(functionSignature, memo) returns null,
which drops the FunctionInfo (so prettifyEvmFunctionName is never used);
instead, make FunctionInfo.inputs nullable and change the call in
JoinKeysignViewModel to always construct FunctionInfo with signature =
functionSignature, functionName = prettifyEvmFunctionName(functionSignature),
and inputs = resultOfDecode (which may be null) rather than returning null;
update the FunctionInfo data class (and any usages) to accept inputs: List<...>?
so the hero can display the resolved functionName even if arg decoding failed.

Fix all unresolved CodeRabbit comments on this PR:

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