Challenges I Ran Into

1. Contract Authorization Nightmare

The Problem

The biggest hurdle was a seemingly simple error:

UnauthorizedVerifier

. Users couldn't register credentials because the

CredentialRegistry

contract had an

onlyAuthorizedVerifier

modifier that required explicit authorization from the contract owner.

The Journey

• Initial Approach: Tried to work around it by implementing auto-authorization mechanisms
• Failed Attempts: Attempted to use the

  SigilCredentialVerifier

  contract as a workaround
• Complex Debugging: Spent hours parsing viem contract errors and implementing simulation checks
• The Lightbulb Moment: Realized the simplest solution was to fix the root cause

The Solution

Instead of complex workarounds, I modified the contract itself:

• Removed the

  onlyAuthorizedVerifier

  modifier from the

  registerCredential

  function
• Redeployed all contracts to Sepolia with the authorization requirement removed
• Updated frontend contract addresses

Lesson Learned: Sometimes the best solution is the simplest one - fix the root cause rather than building elaborate workarounds.

---

2. Real vs Mock Proof Integration

The Problem

The system was using mock proofs instead of actual ZK proof generation, making it more of a demo than a real implementation.

The Technical Challenge

• Circuit Compilation Issues: Many ZK circuits had invalid or empty

  .zkey

  files
• Trusted Setup Problems: The

  repository_credential

  circuit required 772,125*2 constraints but the Powers of Tau file only supported 2^16 (65,536)
• Performance Issues: Real ZK proof generation took 84+ seconds per proof

The Solution

• Circuit Analysis: Discovered 18 working circuits and identified which ones had valid trusted setups
• Fallback Strategy: Used the simpler

  hash_chain

  circuit for demo purposes
• API Integration: Built

  /api/snark/generate

  endpoint using actual snarkjs library
• Caching System: Implemented proof caching to avoid regenerating identical proofs
• Timeout Protection: Added 2-minute timeouts to prevent hanging requests

Lesson Learned: ZK proof systems are complex - having fallback strategies and proper error handling is crucial for production systems.

---

3. Chain Mismatch Hell

The Problem

Users kept getting

ContractFunctionExecutionError: The current chain of the wallet (id: 84532) does not match the target chain for the transaction (id: 11155111 – Sepolia)

.

The Debugging Process

• Multiple Issues: Users had wallets connected to Base network instead of Sepolia
• Missing Parameters: Contract calls were missing

  account

  and

  chain

  parameters
• Type Conversion Errors: BigInt conversion errors with decimal values like "86.09"

The Solution

• Network Detection: Built

  NetworkSwitcher

  component to detect and warn about wrong networks
• Auto-Switching: Implemented

  ensureSepoliaNetwork()

  method for automatic network switching
• Parameter Fixes: Added explicit

  account: userAddress

  and

  chain: sepolia

  to all contract calls
• Data Validation: Added

  Math.floor()

  before BigInt conversions

Lesson Learned: Multi-chain applications need robust network management and clear user guidance.

---

4. JSON Upload Format Chaos

The Problem

Users couldn't upload proof JSON files because the system only supported one specific format, but the proof generation created a different format.

The Format Confusion

The proof generation created full Verifiable Credentials:

{
  "proof": {
    "proofValue": { "a": [...], "b": [...], "c": [...] },
    "publicSignals": [...],
    "credentialType": "aggregate"
  },
  "credentialSubject": {...}
}

But the verification expected simple proof objects.

The Solution

Built a universal JSON parser that handles multiple formats:

• Full Verifiable Credential format
• Raw proof format from credentials
• Simple ZKProofData format
• Standard snarkjs format
• Groth16 format with

  pi_a

  ,

  pi_b

  ,

  pi_c

Lesson Learned: When building developer tools, support multiple input formats to improve user experience.

---

5. React Hooks Dependency Array Mayhem

The Problem

Getting warnings about useEffect dependency arrays changing size between renders, causing infinite re-renders.

The Root Cause

useEffect(() => {
  // Set demo data
}, [credentialHash, proof, publicSignals]); // These values change!

The Solution

Realized this should only run once on mount:

useEffect(() => {
  // Set demo data - only run once on mount
  // eslint-disable-next-line react-hooks/exhaustive-deps
}, []);

Lesson Learned: Understanding when effects should run is crucial - not every effect needs reactive dependencies.

---

6. TypeScript Warning Avalanche

The Problem

Build was successful but had 20+ TypeScript warnings about unused variables,

any

types, and missin