Performance: Optimize useFetchSubmittedLists with multicall batching

[coderabbitai]

Background

Currently, useFetchSubmittedLists hook makes individual readContract calls for each submitted list, which can create high RPC load and increased latency.

Current Implementation:

• N individual RPC calls for N lists
• Total time = N × (network latency + processing time)
• Each call has separate round-trip latency

Proposed Solution

Use publicClient.multicall with array index tracking to batch all getSubmission calls:

// Current approach
const listsPromises = session.submittedLists.map(async (listId) => {
  const data = await publicClient.readContract({
    address: governorAddress,
    abi: klerosGovernorAbi,
    functionName: "getSubmission",
    args: [listId],
  });
  // process...
});

// Optimized approach with array index tracking
const calls = session.submittedLists.map((listId) => ({
  address: governorAddress,
  abi: klerosGovernorAbi,
  functionName: "getSubmission",
  args: [listId],
}));

const results = await publicClient.multicall({ contracts: calls });

const processedResults = results.map((result, index) => {
  const listId = session.submittedLists[index]; // Use array index to map back
  const data = result.result;
  // process with listId...
  return { ...data, listId };
});

Performance Analysis

Latency Improvement:

• Current: N × (network latency + processing time)
• Optimized: 1 × (network latency + N × processing time)

Example with 5 lists and 100ms network latency:

• Current: 5 × (100ms + 10ms) = 550ms
• Optimized: 1 × (100ms + 5 × 10ms) = 150ms
• ~73% reduction in total time

Benefits:

• Reduces RPC provider rate limiting pressure
• Lower bandwidth usage (single request overhead)
• Better user experience with faster loading
• Scales better as number of lists grows

Tracking Solution:
Since getSubmission doesn't return the listId, we use the fact that multicall returns results in the same order as input calls. The array index from the results maps directly to the corresponding listId in session.submittedLists.

Trade-offs

Pros:

• Significant performance improvement
• Cleaner network usage
• Scales better

Cons:

• Slightly more complex code
• Relies on multicall result ordering (which is guaranteed)
• All-or-nothing: if one call fails, need to handle partial failures

Implementation Priority

Low-Medium priority since the current implementation works well for small numbers of lists, but this optimization would provide measurable benefits as usage scales.

---

Related: Discussion in #10 (comment)
Requested by: @tractorss