SwapMate Architecture

This page shows an entity-relationship style diagram of the main SwapMate contracts and how they interact.

Explanation

• Factory: deploys POOL contracts and keeps registry of pools.
• Pool: holds reserves for token pairs, executes swaps, and issues liquidity positions.
• Token: standard ERC20 tokens used in pools (KANARI, USDC, etc.).
• Liquidity Position: represents a user's share in a pool.
• Swap: a recorded swap execution between tokens in a pool.
• Farming: reward contract configured by the factory or owner to distribute rewards to LPs.

This diagram should help when integrating frontends or writing scripts to interact with the deployed contracts.

Zama FHE Integration

SwapMate integrates Zama FHE (fully-homomorphic encryption) to enable privacy-preserving computations off-chain while keeping on-chain interactions verifiable. Typical integration points:

• Client-side encryption: sensitive user input (e.g., private order parameters, off-chain pricing data) is encrypted in the browser or client using Zama FHE libraries before being sent to the backend or relayer.
• Off-chain FHE computation: a trusted worker/relayer runs FHE computations (e.g., price calculations, order matching privacy-preserving aggregation) on encrypted data. The worker never decrypts raw inputs — it evaluates circuits over ciphertexts.
• Result verification: the worker publishes a succinct proof or a commitment (depending on your verification architecture) that the computation was correctly performed. The proof or a hash of the result can be stored on-chain or provided to an auditing service.
• Minimal on-chain footprint: only non-sensitive outputs or verification commitments are submitted to contracts (e.g., reward allocation, settlement triggers). Contracts verify commitments or accept proofs before executing state changes.

Security and performance notes:

• FHE computations are expensive; keep heavy computation off-chain and limit on-chain data to commitments/proofs.
• Key management: ensure ciphertexts are encrypted under a public key whose corresponding secret key is kept secure by the compute workers (or split with threshold schemes if needed).
• Latency: off-chain FHE evaluation can increase latency for some flows — use optimistic UI patterns and asynchronous settlement when appropriate.
• Auditing: publish verification artifacts (proofs, commitments) to an immutable storage or event logs so auditors can validate off-chain computation.

Example flow:

1. User encrypts order metadata in the frontend with Zama FHE and submits ciphertext to a relayer.
2. Relayer aggregates ciphertexts and evaluates a matching/pricing circuit over encrypted data.
3. Relayer emits a commitment and a small verification artifact and optionally broadcasts a transaction to trigger settlement.
4. On-chain contract verifies the commitment (or accepts the relayer's settlement) and updates state (e.g., distribute rewards, finalize matched trades).