Core Architecture v2.0

The Fhenix-FairMarket protocol is engineered around a strictly modular, decoupled architecture that separates cryptographic computation, economic verification, state management, and user interaction. This design eliminates the gas bottlenecks, sequencer dependencies, and trust assumptions inherent in traditional on-chain FHE implementations.

Version 2.0 formalizes a layered approach where each component operates independently yet cohesively, ensuring linear scalability, safe upgradability, and cryptoeconomic security without compromising mathematical privacy.

1.1 Asynchronous FHE Coprocessing

Traditional FHE auctions execute heavy homomorphic comparisons (FHE.gt, FHE.select) directly on-chain, causing gas costs to scale exponentially with bid volume. Fhenix-FairMarket v2.0 replaces this with an asynchronous event-driven dispatch model.

Technical Implementation

• O(1) On-Chain Storage: Bidders submit encrypted bids via placeBid(InEuint32). The contract stores only a bytes32 ciphertext hash. No plaintext values or full FHE objects are persisted in Storage or Events.
• Event Trigger Finalization: At endTime, finalizeAuction() emits a DecryptionRequested(auctionId, bytes32[] cipherHashes) event and transitions the state to RESOLVING. Zero FHE computation occurs on-chain.
• Solvency Pre-Check: Before acceptance, the contract verifies FHE.lte(encryptedBid, escrowBalances[msg.sender]) locally. Invalid bids revert instantly without consuming coprocessor resources.

Architectural Impact

1.2 CoFHE Off-Chain Processing

The cryptographic heavy lifting is delegated to FHEOS (Fully Homomorphic Encryption Operating System) servers, acting as specialized coprocessors that maintain mathematical integrity without congesting the settlement layer.

Technical Implementation

• Batch Dispatching: The cofheDispatcher.ts service collects ciphertext hashes from multiple auctions and routes them to FHEOS endpoints in optimized batches (capped at 10 auctions/block to prevent OOG scenarios).
• Constant-Time Execution: Comparisons use FHE.select constant-time multiplexers, ensuring execution time remains uniform regardless of input values. This neutralizes timing side-channel attacks.
• Encrypted Result Return: FHEOS returns only the encrypted winner identifier (winnerCiphertext) and auxiliary settlement data. No intermediate bid values are exposed during processing.

Architectural Impact

• Vickrey Pricing Support: Enables second-price auction mechanics entirely within encrypted space.
• Scalability: Processing capacity scales horizontally with coprocessor nodes, independent of L2 throughput limits.
• Deterministic Output: Results are mathematically verifiable and reproducible, forming the basis for on-chain acceptance.

1.3 EigenLayer AVS Verification

To replace gas-intensive ZK-circuit proofs, the protocol integrates EigenLayer Actively Validated Services (AVS), introducing cryptoeconomic finality and decentralized operator accountability.

Technical Implementation

• Threshold Signature Aggregation: The avsSubmitter.ts service monitors operator responses and aggregates partial signatures. A resolution is only submitted on-chain once a predefined threshold (e.g., 3/5 operators) is met.
• Fraud Proof Verification: submitResolution(auctionId, winnerCiphertext, avsProof) requires a valid AVS signature bundle. The contract cryptographically verifies the proof before transitioning to FINALIZED.
• Economic Slashing: Operators submitting fraudulent or mismatched results trigger automated slashing penalties via MockEigenLayerAVS.sol (simulation) and production AVS contracts, aligning incentives with protocol integrity.

Architectural Impact

1.4 UUPS Proxy Pattern (EIP-1967)

The protocol adopts the Universal Upgradeable Proxy Standard (UUPS) to separate business logic from user funds, enabling safe iterations without fund migration or downtime.

Technical Implementation

• Proxy-Implementation Separation: FhenixFairMarketProxy.sol (EIP-1967 compliant) stores all state variables and delegates execution to FhenixFairMarket.sol (logic implementation).
• Upgrade Authorization: _authorizeUpgrade(address newImplementation) is restricted to a governance multisig/DAO. All upgrades pass through a mandatory 48-hour Timelock, allowing community review and emergency response.
• SDK Isolation via Adapter: All FHE library calls are routed through CofheAdapter.sol. This prevents direct dependency breaks in core contracts when @cofhe/sdk or @fhenixprotocol/cofhe-contracts receive version updates.

Architectural Impact

• Zero Fund Migration Risk: Storage remains intact during logic upgrades.
• Future-Proofing: Adaptable to FHE protocol improvements without redeploying core contracts.
• Governance Transparency: Timelock delays and multisig requirements prevent unilateral or malicious modifications.

1.5 ERC-4337 Account Abstraction

To bridge cryptographic security with mainstream usability, the protocol integrates ERC-4337 Smart Accounts, abstracting signature complexity while enforcing strict security boundaries.

Technical Implementation

• Ephemeral Session Keys: The useERC4337Session.ts hook generates temporary keys with a strict 24-hour TTL. Permissions are scoped exclusively to placeBid, lockEscrow, and claimRefund.
• Secure Storage Enforcement: Session permits are stored in secure memory or encrypted IndexedDB via Web Crypto API. Explicit ESLint/CI rules block localStorage or cookie usage to neutralize XSS theft vectors.
• Bundler Relay: Transactions are routed through ERC-4337 bundlers, enabling gas sponsorship options, batch execution, and seamless fallback handling without repeated Metamask pop-ups.

Architectural Impact

• 1-Click Trading: Users sign once; subsequent bids execute automatically within the session window.
• XSS Mitigation: Eliminates persistent browser storage exposure for sensitive signing permits.
• Optimistic UI Compatibility: Enables instant state updates on signature submission, with automatic rollback if bundler confirmation fails.

Next Steps

• Review the Security & Integrity layer to understand how these components defend against MEV, reentrancy, and sequencer failures.
• Explore the Market Mechanics to see how architecture enables sealed-bid and Vickrey pricing.
• Proceed to Technical Components for contract-level references and function signatures.