contracts/src/token/mock/PinakionV2Local.sol (1)

36-51: Add a comment explaining why increaseAllowance and decreaseAllowance are manually implemented.

These functions were removed from OpenZeppelin ERC20 in v5 as non-standard helpers, but your contract reimplements them. Adding a comment clarifying the rationale (compatibility with existing code, backwards compatibility, etc.) will help future maintainers understand the intent.

contracts/deploy/utils/index.ts (1)

31-32: Consider clarifying the comment.

The comment mentions the network name is "hardhat" when deployed while starting the node, but the code checks for network.name === "localhost". While the chainId check correctly handles both cases (covering "hardhat" name via the chainId), the comment could be clearer.

🔎 Suggested comment improvement

-// when deployed while starting node, the network name is "hardhat", the common factor for determining local node is chainId
+// The network name can be "localhost" or "hardhat" (when deployed while starting the node).
+// ChainId 31337 is the common factor for reliably detecting local Hardhat nodes.
 export const isLocalhost = (network: Network) => network.name === "localhost" || network.config.chainId === 31337;

contracts/deploy/utils/deployTokens.ts (1)

26-27: Consider extracting the repeated condition.

The condition ticker === "PNK" && isLocalhost(hre.network) is repeated on consecutive lines. While this works correctly, extracting it to a variable would improve maintainability.

🔎 Suggested refactor

-  const contractName = ticker === "PNK" && isLocalhost(hre.network) ? "PinakionV2Local" : "TestERC20";
-  const args = ticker === "PNK" && isLocalhost(hre.network) ? [] : [ticker, ticker];
+  const isPNKLocalDeployment = ticker === "PNK" && isLocalhost(hre.network);
+  const contractName = isPNKLocalDeployment ? "PinakionV2Local" : "TestERC20";
+  const args = isPNKLocalDeployment ? [] : [ticker, ticker];

web/src/context/Web3Provider.tsx (1)

53-56: Potential undefined access in defaultTransport websocket fallback.

chain.rpcUrls.default?.webSocket?.[0] may be undefined for chains that don't provide a default WebSocket URL. While webSocket(undefined) is handled gracefully by viem (it becomes a no-op in the fallback), consider making the fallback more explicit or adding a comment explaining this behavior.

🔎 Optional: Make undefined handling explicit

 const defaultTransport = (chain: AppKitNetwork) =>
-  fallback([http(chain.rpcUrls.default?.http?.[0]), webSocket(chain.rpcUrls.default?.webSocket?.[0])]);
+  fallback([
+    http(chain.rpcUrls.default?.http?.[0]),
+    // WebSocket may not be available for all chains; fallback handles undefined gracefully
+    ...(chain.rpcUrls.default?.webSocket?.[0] ? [webSocket(chain.rpcUrls.default.webSocket[0])] : []),
+  ]);

contracts/wagmi.config.hardhat.ts (1)

2-2: Same import assertion syntax note as web/wagmi.config.ts.

Biome flags the assert { type: "json" } syntax. Consider updating to with { type: "json" } for consistency if your TypeScript/bundler versions support import attributes.

🔎 Proposed update to import attributes syntax

-import IHomeGateway from "./artifacts/src/gateway/interfaces/IHomeGateway.sol/IHomeGateway.json" assert { type: "json" };
+import IHomeGateway from "./artifacts/src/gateway/interfaces/IHomeGateway.sol/IHomeGateway.json" with { type: "json" };

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Learnt from: Harman-singh-waraich
Repo: kleros/kleros-v2 PR: 1744
File: web/src/hooks/useGenesisBlock.ts:9-31
Timestamp: 2024-11-19T05:31:48.701Z
Learning: In `useGenesisBlock.ts`, within the `useEffect` hook, the conditions (`isKlerosUniversity`, `isKlerosNeo`, `isTestnetDeployment`) are mutually exclusive, so multiple imports won't execute simultaneously, and race conditions are not a concern.

Learnt from: Harman-singh-waraich
Repo: kleros/kleros-v2 PR: 1703
File: web/src/hooks/queries/usePopulatedDisputeData.ts:58-61
Timestamp: 2024-10-14T13:58:25.708Z
Learning: In `web/src/hooks/queries/usePopulatedDisputeData.ts`, the query and subsequent logic only execute when `disputeData.dispute?.arbitrableChainId` and `disputeData.dispute?.externalDisputeId` are defined, so `initialContext` properties based on these values are safe to use without additional null checks.

Learnt from: Harman-singh-waraich
Repo: kleros/kleros-v2 PR: 1687
File: web/src/context/AtlasProvider.tsx:225-244
Timestamp: 2024-10-15T16:18:32.543Z
Learning: In `web/src/context/AtlasProvider.tsx`, the `atlasUri` variable comes from environment variables and does not change, so it does not need to be included in dependency arrays.

Learnt from: Harman-singh-waraich
Repo: kleros/kleros-v2 PR: 1703
File: kleros-sdk/src/dataMappings/utils/actionTypes.ts:1-1
Timestamp: 2024-10-22T09:38:20.093Z
Learning: In the TypeScript file `kleros-sdk/src/dataMappings/utils/actionTypes.ts`, the `Abi` type is parsed later in the action functions, so importing `Abi` from `viem` in this file is unnecessary.

Learnt from: jaybuidl
Repo: kleros/kleros-v2 PR: 0
File: :0-0
Timestamp: 2025-09-03T22:48:32.972Z
Learning: In the Kleros v2 codebase, the team prioritizes gas optimization over strict CEI pattern compliance when dealing with trusted contracts. For penalty execution logic, they prefer batching storage writes (`round.pnkPenalties`) rather than updating incrementally after each penalty calculation to save gas costs, as the risk is extremely low between trusted contracts.

web/src/pages/Cases/CaseDetails/Voting/Classic/Reveal.tsx (1)

5-5: Unused import.

useLocalStorage is imported but no longer used after the refactor to direct localStorage.getItem().

-import { useLocalStorage } from "react-use";

web/src/utils/crypto/generateSalt.ts (1)

15-16: Unnecessary optional chaining after validation.

The optional chaining signingAccount?.signMessage on line 15 is redundant since signingAccount.signMessage is already validated to exist on line 11. This is a minor inconsistency.

♻️ Suggested cleanup

-  const signature = await signingAccount?.signMessage({ message });
+  const signature = await signingAccount.signMessage({ message });

web/src/hooks/useCastCommit.tsx (1)

67-67: Hardcoded query key may become out of sync.

The query key ["useDrawQuery"] is hardcoded. If the actual query definition uses a different key or includes additional parameters, this invalidation won't work as expected. Consider centralizing query keys to avoid mismatches.

web/src/actions/commit/builders/index.ts (1)

14-23: Consider improving type safety in the builder registry.

The any type in the Record and as never cast work correctly at runtime due to the discriminated union, but they bypass compile-time type checking. This is a common pattern for dispatch tables, but worth noting.

If stricter typing is desired later, an overloaded function signature could enforce the relationship between params.type and the expected param type.

web/src/actions/commit/builders/gated.builder.ts (1)

8-22: Consider validating chain support before address lookup.

The address lookup disputeKitGatedAddress[chain.id] will return undefined for unsupported chains, which would cause a transaction failure. While the UI likely restricts to supported chains, a defensive check could provide a clearer error message.

♻️ Optional defensive check

 export const gatedCommitBuilder: CommitBuilder<GatedCommitParams, typeof disputeKitGatedAbi> = {
   build: async (params, context) => {
     const { disputeId, voteIds, choice, salt } = params;
     const { chain, account } = context;

+    const address = disputeKitGatedAddress[chain.id];
+    if (!address) {
+      throw new Error(`DisputeKitGated not deployed on chain ${chain.id}`);
+    }
+
     const commit = hashVote(choice, salt);
     return {
       account,
-      address: disputeKitGatedAddress[chain.id],
+      address,
       abi: disputeKitGatedAbi,
       functionName: "castCommit",
       args: [disputeId, voteIds, commit],
       chain,
     };
   },
 };

web/src/actions/commit/builders/gatedShutter.builder.ts (1)

27-28: Redundant BigInt() conversion on salt.

According to BaseCommitParams in params.ts, salt is already typed as bigint. The BigInt(salt) calls are unnecessary and could be simplified.

Suggested simplification

-    const choiceCommit = hashVote(choice, BigInt(salt));
-    const justificationCommit = hashJustification(BigInt(salt), justification);
+    const choiceCommit = hashVote(choice, salt);
+    const justificationCommit = hashJustification(salt, justification);

web/src/actions/commit/builders/shutter.builder.ts (2)

13-38: Significant code duplication with gatedShutter.builder.ts.

This builder shares nearly identical logic with gatedShutter.builder.ts (env validation, message encoding, encryption, hashing). Consider extracting shared Shutter-specific logic into a helper function to reduce duplication.

---

27-28: Redundant BigInt() conversion on salt.

Same issue as gatedShutter.builder.ts - salt is already bigint per BaseCommitParams.

Suggested simplification

-    const choiceCommit = hashVote(choice, BigInt(salt));
-    const justificationCommit = hashJustification(BigInt(salt), justification);
+    const choiceCommit = hashVote(choice, salt);
+    const justificationCommit = hashJustification(salt, justification);

web/src/pages/Cases/CaseDetails/Voting/Shutter/Commit.tsx (1)

37-39: Duplicate data fetching for dispute details.

The component receives dispute as a prop (line 25) but also calls useDisputeDetailsQuery(id) (line 37) just to get currentRoundIndex. Consider using dispute?.currentRoundIndex from the prop instead to avoid redundant network requests.

Suggested change

-  const { data: disputeData } = useDisputeDetailsQuery(id);
-
-  const currentRoundIndex = disputeData?.dispute?.currentRoundIndex;
+  const currentRoundIndex = dispute?.currentRoundIndex;

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Learnt from: Harman-singh-waraich
Repo: kleros/kleros-v2 PR: 1703
File: web/src/hooks/queries/usePopulatedDisputeData.ts:58-61
Timestamp: 2024-10-14T13:58:25.708Z
Learning: In `web/src/hooks/queries/usePopulatedDisputeData.ts`, the query and subsequent logic only execute when `disputeData.dispute?.arbitrableChainId` and `disputeData.dispute?.externalDisputeId` are defined, so `initialContext` properties based on these values are safe to use without additional null checks.

Learnt from: tractorss
Repo: kleros/kleros-v2 PR: 1982
File: web/src/pages/Resolver/Landing/index.tsx:62-62
Timestamp: 2025-05-15T06:50:40.859Z
Learning: In the Landing component, it's safe to pass `dispute?.dispute?.arbitrated.id as 0x${string}` to `usePopulatedDisputeData` without additional null checks because the hook internally handles undefined parameters through its `isEnabled` flag and won't execute the query unless all required data is available.

Learnt from: jaybuidl
Repo: kleros/kleros-v2 PR: 2145
File: contracts/src/arbitration/dispute-kits/DisputeKitClassicBase.sol:277-286
Timestamp: 2025-09-30T17:18:12.895Z
Learning: In DisputeKitClassicBase.sol's castCommit function, jurors are allowed to re-submit commits during the commit period. The implementation uses a commitCount variable to track only first-time commits (where commit == bytes32(0)) so that totalCommitted is not incremented when a juror updates their existing commit.

Learnt from: Harman-singh-waraich
Repo: kleros/kleros-v2 PR: 1716
File: web-devtools/src/app/(main)/dispute-template/CustomContextInputs.tsx:29-42
Timestamp: 2024-10-28T05:55:12.728Z
Learning: In the `CustomContextInputs` component located at `web-devtools/src/app/(main)/dispute-template/CustomContextInputs.tsx`, the `DisputeRequestParams` array is used to exclude certain variables from the custom input since they are already provided in a preceding component. Therefore, converting it to a type is unnecessary.

Learnt from: Harman-singh-waraich
Repo: kleros/kleros-v2 PR: 1794
File: web/src/hooks/useStarredCases.tsx:13-18
Timestamp: 2024-12-16T17:17:32.359Z
Learning: In `useStarredCases.tsx`, when handling the `starredCases` Map from local storage, direct mutation is acceptable to prevent the overhead of copying, provided it doesn't adversely affect React's render cycle.

Learnt from: jaybuidl
Repo: kleros/kleros-v2 PR: 1582
File: web-devtools/src/app/(main)/ruler/SelectArbitrable.tsx:88-90
Timestamp: 2024-10-09T10:22:41.474Z
Learning: Next.js recommends using the `useEffect` hook to set `isClient` and using `suppressHydrationWarning` as a workaround for handling hydration inconsistencies, especially when dealing with data like `knownArbitrables` that may differ between server-side and client-side rendering. This approach is acceptable in TypeScript/React applications, such as in `web-devtools/src/app/(main)/ruler/SelectArbitrable.tsx`.

Learnt from: Harman-singh-waraich
Repo: kleros/kleros-v2 PR: 1775
File: web/src/pages/Courts/CourtDetails/StakePanel/StakeWithdrawButton.tsx:0-0
Timestamp: 2024-12-09T12:36:59.441Z
Learning: In the `StakeWithdrawButton` component, the transaction flow logic is tightly linked to component updates, so extracting it into a custom hook does not provide significant benefits.

Learnt from: Harman-singh-waraich
Repo: kleros/kleros-v2 PR: 1744
File: web/src/hooks/useGenesisBlock.ts:9-31
Timestamp: 2024-11-19T05:31:48.701Z
Learning: In `useGenesisBlock.ts`, within the `useEffect` hook, the conditions (`isKlerosUniversity`, `isKlerosNeo`, `isTestnetDeployment`) are mutually exclusive, so multiple imports won't execute simultaneously, and race conditions are not a concern.

Learnt from: tractorss
Repo: kleros/kleros-v2 PR: 2117
File: web/src/components/DisputeFeatures/Features/GatedErc1155.tsx:51-66
Timestamp: 2025-09-09T13:33:46.896Z
Learning: The `setDisputeData` function in `NewDisputeContext` at `web/src/context/NewDisputeContext.tsx` has signature `(disputeData: IDisputeData) => void` and only accepts direct state values, not functional updates like standard React state setters. It cannot be used with the pattern `setDisputeData((prev) => ...)`.

Learnt from: kemuru
Repo: kleros/kleros-v2 PR: 1871
File: web/src/pages/Profile/Votes/index.tsx:69-75
Timestamp: 2025-12-17T14:55:22.988Z
Learning: In `web/src/pages/Profile/Votes/index.tsx`, fetching up to 1000 draws client-side is a temporary solution until the subgraph supports fetching `totalVotes` directly. This is acknowledged technical debt that will be addressed when the subgraph capability becomes available.

Learnt from: nikhilverma360
Repo: kleros/kleros-v2 PR: 1632
File: web/src/components/DisputeView/DisputeInfo/DisputeInfoList.tsx:37-42
Timestamp: 2024-06-27T10:11:54.861Z
Learning: `useMemo` is used in `DisputeInfoList` to optimize the rendering of `FieldItems` based on changes in `fieldItems`, ensuring that the mapping and truncation operation are only performed when necessary.

Learnt from: tractorss
Repo: kleros/kleros-v2 PR: 1982
File: web/src/pages/Resolver/Parameters/NotablePersons/PersonFields.tsx:64-0
Timestamp: 2025-05-09T13:39:15.086Z
Learning: In PersonFields.tsx, the useEffect hook for address validation intentionally uses an empty dependency array to run only once on component mount. This is specifically designed for the dispute duplication flow when aliasesArray is already populated with addresses that need initial validation.

web/src/pages/Cases/CaseDetails/Voting/Classic/Commit.tsx (1)

37-48: Guard against undefined currentRoundIndex before calling castCommit.

currentRoundIndex (line 31) can be undefined when disputeData hasn't loaded. Passing undefined to castCommit will propagate to getVoteKey() and salt generation, likely causing runtime issues.

Suggested fix

   const handleCommit = useCallback(
     async (choice: bigint) => {
+      if (currentRoundIndex === undefined) {
+        return;
+      }
       castCommit({
         type: isGated ? DisputeKits.Gated : DisputeKits.Classic,
         disputeId: parsedDisputeID,
         choice,
         voteIds: parsedVoteIDs,
         roundIndex: currentRoundIndex,
       });
     },
     [castCommit, parsedDisputeID, currentRoundIndex, parsedVoteIDs, isGated]
   );

web/src/pages/Cases/CaseDetails/Voting/Shutter/Commit.tsx (1)

51-65: Guard commit when round index is unavailable.

currentRoundIndex can be undefined before the dispute data loads, which makes the commit call invalid. Add a guard before invoking castCommit.

🐛 Suggested guard

   const handleCommit = useCallback(
     async (choice: bigint) => {
       /* an extra 300 seconds (5 minutes) of decryptionDelay is enforced after Commit period is over
       to avoid premature decryption and voting attacks if no one passes the Commit period quickly */
       const decryptionDelay = (countdownToVotingPeriod ?? 0) + 300;
 
+      if (currentRoundIndex === undefined) {
+        console.error("Round index not available");
+        return;
+      }
       castCommit({
         type: isGated ? DisputeKits.GatedShutter : DisputeKits.Shutter,
         disputeId: parsedDisputeID,
         choice,
         voteIds: parsedVoteIDs,
         roundIndex: currentRoundIndex,
         justification,
         decryptionDelay,
       });
     },
     [justification, parsedVoteIDs, parsedDisputeID, countdownToVotingPeriod, isGated, castCommit, currentRoundIndex]
   );

web/src/pages/Cases/CaseDetails/Voting/Classic/index.tsx (1)

33-42: Unsafe type assertion on commit.

Casting commit as \0x${string}`bypasses TypeScript's type checking. Ifcommitisundefinedor an empty string fromuseVotingContext()`, this assertion masks the issue until runtime.

Since Reveal.tsx already handles isUndefined(commit) in rendering, consider passing commit with its actual type and letting the child component handle the typing:

Safer approach

       <Reveal
         {...{
           arbitrable,
           setIsOpen,
           voteIDs,
           isRevealPeriod: !isCommitPeriod,
           isGated,
-          commit: commit as `0x${string}`,
+          commit,
         }}
       />

Then update IReveal interface in Reveal.tsx to accept commit?: \0x${string}`` and handle the undefined case explicitly.

web/src/actions/helpers/storage/key.ts (1)

1-3: Make array-to-string conversion explicit for clarity.

The voteIds array is implicitly converted to a comma-separated string via template literal interpolation. While this works and produces consistent keys within a session (React Query caches the query results), the implicit toString() behavior is non-obvious to readers.

Suggested improvement

 export const getVoteKey = (disputeId: bigint, roundIndex: number, voteIds: bigint[]) => {
-  return `dispute-${disputeId}-round-${roundIndex}-voteids-${voteIds}`;
+  return `dispute-${disputeId}-round-${roundIndex}-voteids-${voteIds.join(",")}`;
 };

web/src/actions/commit/builders/gatedShutter.builder.ts (1)

23-35: Normalize justification before hashing/encrypting.

If justification is optional, passing undefined into encodeShutterMessage/hashJustification can produce inconsistent commits or runtime errors. Consider normalizing to an empty string and storing that.

♻️ Suggested tweak

-    const { disputeId, voteIds, choice, salt, decryptionDelay, justification, roundIndex } = params;
+    const { disputeId, voteIds, choice, salt, decryptionDelay, justification, roundIndex } = params;
+    const normalizedJustification = justification ?? "";
@@
-    storeCommitData(key, { choice, salt, justification });
+    storeCommitData(key, { choice, salt, justification: normalizedJustification });
@@
-    const encodedMessage = encodeShutterMessage(choice, salt, justification);
+    const encodedMessage = encodeShutterMessage(choice, salt, normalizedJustification);
@@
-    const justificationCommit = hashJustification(BigInt(salt), justification);
+    const justificationCommit = hashJustification(BigInt(salt), normalizedJustification);

web/src/utils/crypto/hashVote.test.ts (1)

173-178: Consider adding a symmetric test for negative salt.

Since salt is also encoded as uint256, a negative salt should throw IntegerOutOfRangeError just like negative choice. Adding this test would provide symmetric coverage.

💡 Suggested addition

     it("should throw on negative choice", () => {
       const choice = -1n;
       const salt = 123456789n;

       expect(() => hashVote(choice, salt)).toThrow(IntegerOutOfRangeError);
     });
+
+    it("should throw on negative salt", () => {
+      const choice = 1n;
+      const salt = -1n;
+
+      expect(() => hashVote(choice, salt)).toThrow(IntegerOutOfRangeError);
+    });
   });
 });

web/src/actions/commit/builders/classic.builder.test.ts (1)

88-104: Prefer getVoteKey over a hardcoded key string.
This keeps the test aligned with the production key format if it changes.

♻️ Proposed refactor

-import { storeCommitData } from "actions/helpers/storage";
+import { storeCommitData, getVoteKey } from "actions/helpers/storage";
@@
-      expect(storeCommitData).toHaveBeenCalledWith("dispute-100-round-2-voteids-5,6", {
+      const expectedKey = getVoteKey(params.disputeId, params.roundIndex, params.voteIds);
+      expect(storeCommitData).toHaveBeenCalledWith(expectedKey, {
         choice: 1n,
         salt: 777n,
       });

web/src/actions/vote/builders/classic.builder.test.ts (2)

13-18: Mock address is malformed.

The mock address 0xVOTEADDRESS12345678901234567890123456 is invalid:

1. Contains non-hex characters (O, T, D).
2. Only 37 characters after 0x instead of the required 40.

While this works because of the type assertion, using a valid address improves test robustness and avoids potential issues with stricter validation.

Suggested fix

 vi.mock("hooks/contracts/generated", () => ({
   disputeKitClassicAbi: [{ name: "castVote", type: "function" }],
   disputeKitClassicAddress: {
-    421614: "0xVOTEADDRESS12345678901234567890123456" as const,
+    421614: "0x1234567890123456789012345678901234567890" as const,
   },
 }));

---

206-226: Test name doesn't match behavior.

The test is named "comparison with reveal builder" but doesn't actually import or compare with the reveal builder's output. It only verifies the structure of the vote builder independently.

Consider either:

1. Renaming the describe block to better reflect what it tests (e.g., "args structure validation")
2. Actually importing and comparing with the reveal builder if cross-builder consistency is the intent

web/src/actions/commit/builders/gated.builder.test.ts (2)

18-23: Use a valid Ethereum address format in mock.

The mock address 0xGATED1234567890123456789012345678901234 is not a valid Ethereum address:

1. Contains 'G' which is not valid hexadecimal (only 0-9 and a-f are valid)
2. Has 39 hex characters instead of the required 40

While this won't break the current tests, it could cause issues if viem performs address validation, and it makes the tests less realistic.

Suggested fix

 vi.mock("hooks/contracts/generated", () => ({
   disputeKitGatedAbi: [{ name: "castCommit", type: "function" }],
   disputeKitGatedAddress: {
-    421614: "0xGATED1234567890123456789012345678901234" as const,
+    421614: "0x1234567890abcdef1234567890abcdef12345678" as const,
   },
 }));

Then update the expectation on line 56:

-        address: "0xGATED1234567890123456789012345678901234",
+        address: "0x1234567890abcdef1234567890abcdef12345678",

---

77-95: Consider mocking getVoteKey for better test isolation.

This test hardcodes the expected key format "dispute-100-round-2-voteids-5,6", creating an implicit dependency on getVoteKey's implementation. If getVoteKey changes its format, this test will fail even though gatedCommitBuilder itself remains correct.

Options:

1. Mock getVoteKey to return a predictable value (better isolation)
2. Import and use getVoteKey to compute the expected key (more maintainable)
3. Keep as-is if intentional integration testing (document the intent)

Option 2: Use getVoteKey for expected value

+import { getVoteKey } from "actions/helpers/storage/key";
+
 // In the test:
+      const expectedKey = getVoteKey(params.disputeId, params.roundIndex, params.voteIds);
       expect(storeCommitData).toHaveBeenCalledTimes(1);
-      expect(storeCommitData).toHaveBeenCalledWith("dispute-100-round-2-voteids-5,6", {
+      expect(storeCommitData).toHaveBeenCalledWith(expectedKey, {
         choice: 1n,
         salt: 777n,
       });

web/src/actions/helpers/storage/key.test.ts (1)

5-65: Good test coverage, consider adding edge case for empty voteIds.

The test suite comprehensively covers key formatting, large values, determinism, and uniqueness. Consider adding a test for an empty voteIds array to document the expected behavior in that edge case.

Optional: Add edge case test

+  it("should handle empty voteIds array", () => {
+    const result = getVoteKey(1n, 0, []);
+
+    expect(result).toBe("dispute-1-round-0-voteids-");
+  });

web/src/test/fakes/shutter.ts (1)

18-27: Deterministic test fake is well-designed.

The fake produces verifiable, deterministic outputs using keccak256 hashing. The TODO comment appropriately notes the need to validate against the real API.

Consider extracting the shared hash computation to reduce duplication between fakeEncrypt and verifyFakeEncryptOutput.

Optional: Extract shared computation

+function computeShutterOutputs(message: string, decryptionDelay: number): ShutterEncryptResult {
+  const identity = keccak256(encodePacked(["string", "uint256"], [message, BigInt(decryptionDelay)]));
+  const encryptedCommitment = keccak256(encodePacked(["bytes32", "string"], [identity, "encrypted"]));
+  return { encryptedCommitment, identity };
+}
+
 export function fakeEncrypt(message: string, decryptionDelay: number): ShutterEncryptResult {
-  const identity = keccak256(encodePacked(["string", "uint256"], [message, BigInt(decryptionDelay)]));
-  const encryptedCommitment = keccak256(encodePacked(["bytes32", "string"], [identity, "encrypted"]));
-
-  return {
-    encryptedCommitment,
-    identity,
-  };
+  return computeShutterOutputs(message, decryptionDelay);
 }

 export function verifyFakeEncryptOutput(
   message: string,
   decryptionDelay: number,
   actualIdentity: `0x${string}`,
   actualEncrypted: `0x${string}`
 ): boolean {
-  const expectedIdentity = keccak256(encodePacked(["string", "uint256"], [message, BigInt(decryptionDelay)]));
-  const expectedEncrypted = keccak256(encodePacked(["bytes32", "string"], [expectedIdentity, "encrypted"]));
-
-  return actualIdentity === expectedIdentity && actualEncrypted === expectedEncrypted;
+  const expected = computeShutterOutputs(message, decryptionDelay);
+  return actualIdentity === expected.identity && actualEncrypted === expected.encryptedCommitment;
 }

Also applies to: 33-43

web/src/actions/commit/builders/shutter.builder.test.ts (1)

130-135: Use getVoteKey to keep the test aligned with key formatting.

This avoids duplicating the string format and protects the test if key formatting changes.

♻️ Suggested update

-import { storeCommitData } from "actions/helpers/storage";
+import { storeCommitData, getVoteKey } from "actions/helpers/storage";
@@
-      expect(storeCommitData).toHaveBeenCalledWith("dispute-100-round-2-voteids-5,6", {
+      const expectedKey = getVoteKey(params.disputeId, params.roundIndex, params.voteIds);
+      expect(storeCommitData).toHaveBeenCalledWith(expectedKey, {
         choice: 1n,
         salt: 777n,
         justification: "Stored justification",
       });

README.md (1)

239-239: Wrap bare URL in angle brackets.

Use <http://localhost> to satisfy markdownlint and keep link formatting consistent.

web/src/pages/Cases/CaseDetails/Voting/Classic/Reveal.tsx (1)

100-107: Button should also be disabled when currentRoundIndex is undefined.

The early return guard in handleReveal prevents the reveal action when currentRoundIndex is undefined, but the button remains clickable. From a UX perspective, clicking the button would do nothing, which could confuse users. Adding the check to the disabled state provides proper feedback.

♻️ Suggested fix

             <StyledButton
               variant="secondary"
               text={t("buttons.justify_and_reveal")}
-              disabled={isPending || isUndefined(disputeDetails)}
+              disabled={isPending || isUndefined(disputeDetails) || isUndefined(currentRoundIndex)}
               isLoading={isPending}
               onClick={handleReveal}
             />

web/src/actions/helpers/storage/index.ts (1)

18-37: localStorage.getItem and removeItem calls are still unguarded.

The try/catch was added to storeCommitData, but restoreCommitData and removeCommitData still have unguarded localStorage calls that can throw when storage is unavailable (private browsing, blocked, quota exceeded).

🛠️ Proposed fix

 export function restoreCommitData(key: string): CommitData | undefined {
-  const raw = localStorage.getItem(key);
-  if (!raw) return undefined;
-
   try {
+    const raw = localStorage.getItem(key);
+    if (!raw) return undefined;
+
     const storedData = JSON.parse(raw) as StoredCommitData;
 
     return {
       salt: BigInt(storedData.salt),
       choice: BigInt(storedData.choice),
       justification: storedData.justification,
     };
   } catch {
     return undefined;
   }
 }
 
 export function removeCommitData(key: string): void {
-  localStorage.removeItem(key);
+  try {
+    localStorage.removeItem(key);
+  } catch {
+    // Storage unavailable - no-op
+  }
 }

web/src/pages/Cases/CaseDetails/Voting/Shutter/Reveal.tsx (1)

48-71: Disable reveal while currentRoundIndex is unknown.
Line 49 already guards, but Line 70 still allows a click that no-ops. Please disable the button until the round index is available.

🐛 Suggested guard

-      <Button text={t("buttons.reveal_your_vote")} onClick={handleReveal} disabled={isPending} isLoading={isPending} />
+      <Button
+        text={t("buttons.reveal_your_vote")}
+        onClick={handleReveal}
+        disabled={isPending || isUndefined(currentRoundIndex)}
+        isLoading={isPending}
+      />

web/src/pages/Cases/CaseDetails/Voting/Classic/Reveal.tsx (1)

62-78: Consider awaiting revealVote for consistent async handling.

The revealVote mutation is not awaited, so handleReveal returns immediately while the mutation runs in the background. While useRevealVote handles errors via toast internally, awaiting ensures the callback completes with the mutation and enables potential future error handling at the call site.

♻️ Suggested change

   const handleReveal = useCallback(async () => {
     if (isUndefined(currentRoundIndex)) {
       return;
     }
-    revealVote({
+    await revealVote({
       params: {
         disputeId: parsedDisputeID,
         voteIds: parsedVoteIDs,
         justification,
         roundIndex: Number(currentRoundIndex),
         type: isGated ? DisputeKits.Gated : DisputeKits.Classic,
       },
       context: {
         commit,
         answers: disputeDetails?.answers,
       },
     });
   }, [

web/src/actions/reveal/helpers/bruteForceChoice.test.ts (1)

96-107: Consider clarifying the test description.

The test name "iterates answers in the given order" is slightly misleading. The test actually verifies that bruteForceChoice finds the correct choice regardless of the answer array's ordering (IDs 5, 1 instead of sequential 0, 1, 2...). A clearer name might be "finds matching choice regardless of answer array ordering" or "handles non-sequential answer IDs".

✏️ Suggested rename

-    it("iterates answers in the given order", async () => {
+    it("finds matching choice regardless of answer array ordering", async () => {

web/src/actions/reveal/resolveRevealInputs.integration.test.ts (1)

6-9: Consider consistent path alias usage.

The imports use different path alias patterns (utils/crypto/... vs src/consts). If the project has established conventions for path aliases, consider aligning these for consistency.

web/src/pages/Cases/CaseDetails/Voting/Shutter/Reveal.tsx (1)

44-66: Avoid mutateAsync without awaiting to prevent unhandled rejections.
Line 45 uses mutateAsync but the promise isn’t awaited/caught. Prefer mutate for fire‑and‑forget, or await with a try/catch.

♻️ Suggested adjustment (use mutate)

-  const { mutateAsync: revealVote, isPending } = useRevealVote(() => {
+  const { mutate: revealVote, isPending } = useRevealVote(() => {
     setIsOpen(true);
   });
-  const handleReveal = useCallback(async () => {
+  const handleReveal = useCallback(() => {
     if (isUndefined(currentRoundIndex)) {
       return;
     }

     revealVote({