packages/vechain-kit/src/hooks/signing/useSignTypedData.ts (2)

36-100: Consider adding signer to the dependency array.

The signTypedData callback uses signer (line 55) but doesn't include it in the dependency array (line 99). While this is pre-existing code, adding signer to the dependencies would align with React's exhaustive-deps best practice.

♻️ Suggested fix

        },
-       [connection, privyWalletProvider],
+       [connection, privyWalletProvider, signer],
    );

🤖 Prompt for AI Agents

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

In `@packages/vechain-kit/src/hooks/signing/useSignTypedData.ts` around lines 36 -
100, The useSignTypedData hook's signTypedData callback references the signer
variable but the useCallback dependency array only lists connection and
privyWalletProvider; update the dependency array for the useCallback that
defines signTypedData to include signer (in addition to connection and
privyWalletProvider) so the callback is recreated when signer changes, ensuring
correct behavior and aligning with React's exhaustive-deps rule.

---

3-3: Track the TODO in an issue.

The TODO suggests an investigation is needed for VeWorld in-app browser compatibility with signTypedData. Consider creating a tracking issue to ensure this investigation isn't forgotten.

Would you like me to help draft an issue description for tracking this investigation?

🤖 Prompt for AI Agents

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

In `@packages/vechain-kit/src/hooks/signing/useSignTypedData.ts` at line 3, The
TODO comment in useSignTypedData.ts ("investigate signTypedData support in
VeWorld in-app browser") needs a tracked issue; create a ticket in your issue
tracker referencing the file and symbol useSignTypedData (and the TODO text)
that outlines investigation steps: reproduce signTypedData behavior in VeWorld
in-app browser, test different EIP-712 payloads, document which APIs are
supported or failing, capture console/errors and environment (browser version,
wallet), and propose fallback or polyfill approaches; link the issue ID back in
the TODO comment for traceability.

packages/vechain-kit/src/providers/VeChainKitProvider.tsx (1)

149-165: Consider narrowing contractAddresses to actual address fields.

Partial<AppConfig> allows overriding non-address fields like nodeUrl, explorerUrl, b3trIndexerUrl, network, ipfsFetchingService, etc. The prop name implies addresses only, and overriding e.g. nodeUrl here would diverge from network.nodeUrl (which is independently resolved at line 417 and is what DAppKitProvider/PrivyWalletProvider actually use), producing silent inconsistencies between appConfig.nodeUrl and the active node URL.

Consider tightening the type to a contract-address-only subset:

♻️ Proposed refactor

+type ContractAddressKeys =
+    | 'vthoContractAddress'
+    | 'b3trContractAddress'
+    | 'vot3ContractAddress'
+    | 'b3trGovernorAddress'
+    | 'timelockContractAddress'
+    | 'xAllocationPoolContractAddress'
+    | 'xAllocationVotingContractAddress'
+    | 'emissionsContractAddress'
+    | 'voterRewardsContractAddress'
+    | 'galaxyMemberContractAddress'
+    | 'treasuryContractAddress'
+    | 'x2EarnAppsContractAddress'
+    | 'x2EarnCreatorContractAddress'
+    | 'x2EarnRewardsPoolContractAddress'
+    | 'nodeManagementContractAddress'
+    | 'veBetterPassportContractAddress'
+    | 'veDelegate'
+    | 'veDelegateVotes'
+    | 'veDelegateTokenContractAddress'
+    | 'oracleContractAddress'
+    | 'accountFactoryAddress'
+    | 'cleanifyCampaignsContractAddress'
+    | 'cleanifyChallengesContractAddress'
+    | 'veWorldSubdomainClaimerContractAddress'
+    | 'vetDomainsContractAddress'
+    | 'vetDomainsPublicResolverAddress'
+    | 'vetDomainsReverseRegistrarAddress'
+    | 'vnsResolverAddress'
+    | 'sassContractAddress';
+
-    contractAddresses?: Partial<AppConfig>;
+    contractAddresses?: Partial<Pick<AppConfig, ContractAddressKeys>>;

🤖 Prompt for AI Agents

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

In `@packages/vechain-kit/src/providers/VeChainKitProvider.tsx` around lines 149 -
165, The contractAddresses prop on VeChainKitProvider is typed as
Partial<AppConfig>, which lets callers override non-address fields (e.g.,
nodeUrl, explorerUrl, network) and can silently diverge from the resolved
network.nodeUrl used by DAppKitProvider/PrivyWalletProvider; change
contractAddresses to a narrower type that only includes the contract address
fields (e.g., b3trContractAddress, vot3ContractAddress, and any other on-chain
contract address keys in AppConfig) instead of Partial<AppConfig>, update the
VeChainKitProvider prop type and any related usages to that new address-only
subset type, and ensure consumers and internal merges only accept/merge those
address fields so nodeUrl/explorerUrl/network remain resolved from network.

packages/vechain-kit/src/components/AccountModal/Contents/Assets/ManageCustomTokenContent.tsx (2)

156-164: Use Chakra's FormErrorMessage instead of a hard‑coded red Text.

Hard‑coding color="#ef4444" bypasses the theme/FormControl invalid state and won't respond to dark‑mode token overrides used elsewhere in this file. Since you already wrap the input in FormControl isInvalid={...}, Chakra v2 ships FormErrorMessage which is the idiomatic counterpart and will be wired to the input via aria-describedby automatically.

♻️ Suggested change

-                                {errors.newTokenAddress && (
-                                    <Text
-                                        color="#ef4444"
-                                        fontSize="sm"
-                                        mt={1}
-                                    >
-                                        {errors.newTokenAddress.message}
-                                    </Text>
-                                )}
+                                <FormErrorMessage>
+                                    {errors.newTokenAddress?.message}
+                                </FormErrorMessage>

🤖 Prompt for AI Agents

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

In
`@packages/vechain-kit/src/components/AccountModal/Contents/Assets/ManageCustomTokenContent.tsx`
around lines 156 - 164, Replace the hard-coded red Text used for validation
feedback with Chakra's FormErrorMessage so the message follows FormControl's
isInvalid state and theme (e.g., dark mode). In ManageCustomTokenContent (the
component rendering the input with FormControl isInvalid={...}), swap the
conditional that renders errors.newTokenAddress Text to render
<FormErrorMessage>{errors.newTokenAddress.message}</FormErrorMessage> and remove
the inline color/fontSize styling; also add an import for FormErrorMessage from
`@chakra-ui/react` so the error message is correctly wired to the input's
aria-describedby.

---

112-142: Trim logic overrides register's onChange and is non‑idiomatic.

Spreading {...register(...)} and then declaring onChange replaces RHF's own change handler; you compensate with a manual setValue(..., { shouldValidate: true }) plus a direct mutation of e.target.value. This works but is fragile (DOM mutation on a controlled-by-RHF input) and easy to break in future edits. Prefer setValueAs (or onChange via the register options) so RHF still owns the change pipeline:

♻️ Cleaner alternative

                                     <Input
                                         {...register('newTokenAddress', {
                                             required: t('Address is required'),
+                                            setValueAs: (v: string) =>
+                                                typeof v === 'string'
+                                                    ? v.trim()
+                                                    : v,
                                             pattern: {
                                                 value: /^0x[a-fA-F0-9]{40}$/,
                                                 message: t(
                                                     'Please enter a valid contract address',
                                                 ),
                                             },
                                             validate: (value) =>
                                                 /^0x[a-fA-F0-9]{40}$/.test(
                                                     value,
                                                 ) ||
                                                 t('Invalid contract address'),
                                         })}
-                                        onChange={(e) => {
-                                            const trimmed =
-                                                e.target.value.trim();
-                                            e.target.value = trimmed;
-                                            setValue(
-                                                'newTokenAddress',
-                                                trimmed,
-                                                { shouldValidate: true },
-                                            );
-                                        }}
                                         placeholder="0x..."

🤖 Prompt for AI Agents

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

In
`@packages/vechain-kit/src/components/AccountModal/Contents/Assets/ManageCustomTokenContent.tsx`
around lines 112 - 142, The current onChange prop on the Input in
ManageCustomTokenContent overrides the React Hook Form handler from
register('newTokenAddress') and mutates e.target.value; remove the external
onChange and DOM mutation and instead perform trimming inside RHF by using
register's options (e.g., provide setValueAs or an onChange sanitizer in the
register call for 'newTokenAddress') so RHF owns the change pipeline and
validation (keep the pattern/validate messages and ensure shouldValidate
behavior via RHF config).

Fix all unresolved CodeRabbit comments on this PR:

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