ETCswap v3 Integration Analysis for Prediction DAO¶

Research Date: December 23, 2025
Research Focus: Exploring decentralized market mechanics integration
Status: Research Phase - Technical Analysis Complete

Executive Summary¶

This document analyzes the potential integration of ETCswap v3 (a fork of Uniswap v3) concentrated liquidity and automated market making mechanics into the Prediction DAO ecosystem. ETCswap v3 offers sophisticated liquidity management and trading mechanisms that could complement or enhance the current LMSR-based market mechanics used in both ClearPath and FairWins platforms.

Key Findings¶

Platform-Specific Optimization: ClearPath and FairWins have different requirements that make them suited to different market mechanisms
ClearPath + LMSR: Governance decisions require privacy at the core - LMSR with Nightmarket integration is ideal
FairWins + V3: High volume and activity benefit from efficient LPs and transparency - concentrated liquidity is optimal
Liquidity Efficiency: V3's concentrated liquidity provides 3-5x better capital efficiency for high-volume markets
Recommendation: Platform-specific approach - LMSR for ClearPath (privacy-first), V3 for FairWins (efficiency-first)

Background¶

Problem Statement¶

The current Prediction DAO market mechanics use LMSR (Logarithmic Market Scoring Rule) for automated market making. While LMSR provides bounded loss guarantees and consistent liquidity, it has some limitations:

Capital Efficiency: Requires significant upfront liquidity across full price range (0-1)
Fixed Liquidity: Cannot adapt liquidity distribution based on market sentiment
Limited Price Discovery: LMSR prices may lag active trading compared to order book systems
Single Liquidity Provider: Typically requires protocol or creator to provide all liquidity

ETCswap v3 Overview¶

ETCswap v3 is a decentralized exchange protocol forked from Uniswap v3, offering:

Concentrated Liquidity: Liquidity providers (LPs) can concentrate capital within custom price ranges
Multiple Fee Tiers: 0.05%, 0.3%, and 1.0% fee options for different asset pairs
Flexible Position Management: LPs can create multiple positions with different ranges
Capital Efficiency: Up to 4000x more efficient than constant product AMMs
Active Liquidity Management: LPs can adjust positions based on market conditions

ETCswap v3 Architecture¶

Core Components¶

1. UniswapV3Factory¶

Purpose: Deploys and manages liquidity pools

Key Features: - Creates pools for any ERC20 token pair - Supports multiple fee tiers per pair (500, 3000, 10000 basis points) - Maintains pool registry and ownership control - Enables new fee tiers via governance

Contract Reference:

contract UniswapV3Factory {
    mapping(address => mapping(address => mapping(uint24 => address))) public getPool;

    function createPool(address tokenA, address tokenB, uint24 fee) 
        external returns (address pool);
}

2. UniswapV3Pool¶

Purpose: Core liquidity pool implementing concentrated liquidity

Key Features: - Tick System: Price space divided into discrete ticks (1.0001^tick) - Position Tracking: Each LP position tracked by (owner, tickLower, tickUpper) - Virtual Reserves: Only tracks active liquidity in current price range - Oracle Integration: TWAP (Time-Weighted Average Price) oracle built-in - Fee Accumulation: Per-liquidity fee tracking for proportional distribution

State Variables:

struct Slot0 {
    uint160 sqrtPriceX96;           // Current price (sqrt format)
    int24 tick;                      // Current tick
    uint16 observationIndex;         // Oracle observation index
    uint16 observationCardinality;   // Number of oracle observations
    uint8 feeProtocol;              // Protocol fee percentage
    bool unlocked;                   // Reentrancy lock
}

mapping(int24 => Tick.Info) public ticks;           // Tick data
mapping(bytes32 => Position.Info) public positions; // LP positions
uint128 public liquidity;                           // Active liquidity

3. Concentrated Liquidity Mechanism¶

How It Works:

Price Ranges: LPs deposit liquidity between tickLower and tickUpper
Active Liquidity: Only liquidity within current price range is "active"
Capital Efficiency: Concentrate capital where it's most needed
Fee Earnings: LPs earn fees proportional to liquidity and time in range

Example:

Token Pair: PASS/USDC
Current Price: 0.65 USDC per PASS (65% probability)

LP Position Options:
- Wide Range:  [0.10, 0.90] - Lower fees, more consistent
- Narrow Range: [0.60, 0.70] - Higher fees, requires management
- Asymmetric: [0.50, 0.80] - Biased positioning

Mathematical Model:

Constant product formula within active range:

x * y = k  (where x and y are virtual reserves)

Price = y/x
When price moves outside range, liquidity becomes inactive

4. Tick Mathematics¶

Tick Spacing: Determines price granularity - Fee 500 (0.05%): 10 tick spacing - Fee 3000 (0.3%): 60 tick spacing
- Fee 10000 (1%): 200 tick spacing

Price Calculation:

price = 1.0001^tick
tick = log_{1.0001}(price)

Example:
tick = 0    → price = 1.0000
tick = 6931 → price ≈ 2.0000
tick = -6931 → price ≈ 0.5000

5. Fee Structure¶

Trading Fees: 0.05%, 0.3%, or 1.0% (configurable) - Goes entirely to liquidity providers - Distributed proportionally based on liquidity and time in range

Protocol Fees: Optional (0-25% of trading fees) - Controlled by factory owner - Used for protocol development/treasury

Current Prediction DAO Market Mechanics¶

LMSR (Logarithmic Market Scoring Rule)¶

Current Implementation: ConditionalMarketFactory uses LMSR for automated market making

How It Works:

Cost Function:

C(q) = b * ln(e^(q_pass/b) + e^(q_fail/b))

Where:
- b = liquidity parameter (controls depth)
- q_pass = quantity of PASS tokens sold
- q_fail = quantity of FAIL tokens sold

Price Calculation:

P_pass = e^(q_pass/b) / (e^(q_pass/b) + e^(q_fail/b))
P_fail = e^(q_fail/b) / (e^(q_pass/b) + e^(q_fail/b))

Property: P_pass + P_fail = 1

Key Properties: 1. Bounded Loss: Maximum loss for market maker = b * ln(2) 2. Automatic Prices: Prices update based on quantities 3. No Order Book: Instant execution against pool 4. Single Liquidity Provider: Typically protocol-provided

Conditional Token Framework¶

Current Approach: Gnosis CTF-compatible PASS/FAIL tokens

Token Model: - Binary outcomes: PASS vs FAIL - Redemption: Winner tokens redeem for 1 collateral unit - Loser tokens: Worth 0 after resolution

Privacy Integration (Nightmarket)¶

Current Features: - Position encryption using Poseidon hashes - zkSNARK proofs for trade validity - Batch processing in epochs - MACI-style key changes for anti-collusion

Privacy Flow:

1. Trader creates position (amount, direction, price)
2. Generate commitment: H = Poseidon(position, nonce)
3. Generate Groth16 zkSNARK proof
4. Submit (commitment, proof) to PrivacyCoordinator
5. Batch processed with other trades
6. Only aggregate data public

Comparative Analysis¶

Market Mechanics Comparison¶

Aspect	LMSR (Current)	ETCswap v3 Concentrated Liquidity
Liquidity Model	Single automated market maker	Multiple liquidity providers
Capital Efficiency	Low - liquidity across full 0-1 range	High - liquidity concentrated where needed
Price Formula	Logarithmic cost function	Constant product within ranges
Loss Bounds	Bounded: b * ln(2)	Unbounded: Impermanent loss possible
Liquidity Source	Protocol/Creator funded	Community/Market participants
Position Management	Fixed pool parameters	Dynamic LP position adjustment
Fee Structure	Optional fixed fees	Tiered fees (0.05%, 0.3%, 1%)
Complexity	Low - single formula	High - tick system, ranges, positions
Gas Costs	Lower - simpler math	Higher - complex state updates

User Experience Comparison¶

Feature	LMSR Markets	V3 Liquidity Pools
For Traders	Simple buy/sell	More complex (slippage, tick crossing)
Price Discovery	Algorithmic	Market-driven
Execution	Instant at computed price	Depends on liquidity depth
Slippage	Predictable (based on b)	Variable (based on liquidity)
Front-running Risk	Low (batch processing)	Higher (if not using privacy)

Capital Requirements Comparison¶

LMSR Example (Prediction Market):

Market: Will proposal pass?
Liquidity Parameter (b): 1000 USDC
Maximum Loss: 1000 * ln(2) ≈ 693 USDC
Coverage: Full 0-1 price range
Capital Needed: ~1000 USDC upfront

V3 Example (Liquidity Pool):

Pool: PASS/USDC
Current Price: 0.65 USDC per PASS
LP Position: [0.60, 0.70] range

Capital Needed:
- If price = 0.65:
  - 50% PASS tokens
  - 50% USDC
  - Example: 500 PASS + 325 USDC ≈ 650 USDC

Fees Earned: 0.3% per swap within range
Risk: Impermanent loss if price moves outside range

Capital Efficiency Gain: - Narrow range (±5%): ~3-5x more efficient - Medium range (±15%): ~2-3x more efficient - Wide range (±50%): Similar to LMSR

Privacy Compatibility¶

Mechanism	LMSR + Nightmarket	V3 (No Privacy)
Position Privacy	✅ Fully supported	❌ Not applicable (FairWins uses V3 without privacy)
Trade Batching	✅ Native	❌ Standard V3 execution
Price Privacy	✅ Only aggregate visible	❌ All trades public
LP Privacy	✅ Single provider	❌ All positions public
Implementation	Mature (ClearPath)	Standard V3 (FairWins)

Note: FairWins will use ETCswap V3 without modification. Privacy is not required for public prediction markets, and V3 is deployed as-is for transparency and efficiency.

Integration Approaches¶

Option 1: Platform-Specific Mechanisms (Recommended)¶

Concept: Use different market mechanisms optimized for each platform's unique requirements

Architecture:

┌─────────────────────────────────────────────┐
│         Prediction DAO Ecosystem             │
├─────────────────────────────────────────────┤
│                                              │
│  ┌──────────────┐      ┌─────────────────┐ │
│  │  ClearPath   │      │   FairWins      │ │
│  │  (Governance)│      │   (Prediction)  │ │
│  └──────┬───────┘      └────────┬────────┘ │
│         │                       │           │
│         ↓                       ↓           │
│  ┌──────────────┐      ┌─────────────────┐ │
│  │ LMSR Markets │      │  V3 Pools       │ │
│  │ + Privacy    │      │ (Concentrated   │ │
│  │ (Nightmarket)│      │  Liquidity)     │ │
│  └──────────────┘      └─────────────────┘ │
│                                              │
└─────────────────────────────────────────────┘

Rationale:

ClearPath → LMSR + Privacy: - Governance decisions require privacy to prevent vote buying and collusion - LMSR's bounded loss protects DAO treasury - Predictable pricing for institutional decision-making - Nightmarket integration mature and battle-tested - Lower complexity reduces governance risk

FairWins → V3 Concentrated Liquidity: - High volume and activity justify V3's complexity - Efficient LPs reduce capital requirements - Transparency acceptable for prediction markets - Community liquidity provision increases engagement - Market-driven pricing improves price discovery - Multiple fee tiers suit various market types

Advantages: - ✅ Each platform uses optimal mechanism for its use case - ✅ No liquidity fragmentation within each platform - ✅ Clear separation reduces user confusion - ✅ Privacy where needed, efficiency where possible - ✅ Simpler than running both systems everywhere - ✅ Maintains ClearPath's privacy guarantees

Disadvantages: - ❌ Two systems to maintain (unavoidable) - ❌ Different user experiences across platforms - ❌ Cannot easily move markets between platforms

Use Case Mapping: - ClearPath (LMSR): - DAO governance proposals - Treasury management decisions - Protocol parameter changes - Any decision requiring privacy

FairWins (V3):
Event outcome predictions
Sports and entertainment markets
Financial forecasting
Any high-volume public market

Alternative Approaches¶

During the research phase, four alternative integration approaches were evaluated:

Option 2: Parallel Markets - Both LMSR and V3 on both platforms
Option 3: Hybrid Model - LMSR base layer with V3 supplementary liquidity
Option 4: Specialized Markets - Mechanism choice based on market characteristics
Option 5: Post-Resolution Secondary Market - V3 pools for resolved token trading

These alternatives provided valuable insights but were not recommended given the platform-specific approach is optimal for the dual-platform structure. Each option had significant drawbacks including liquidity fragmentation, increased complexity, or misalignment with platform-specific requirements.

For detailed analysis of each alternative approach, see: Alternative Approaches Appendix

Technical Design¶

Recommended Architecture: Option 1 (Platform-Specific Mechanisms)¶

Component Structure¶

┌─────────────────────────────────────────────────────────────┐
│              Prediction DAO Ecosystem                        │
├─────────────────────────────────────────────────────────────┤
│                                                              │
│  ┌────────────────────────┐   ┌──────────────────────────┐ │
│  │   ClearPath Platform   │   │   FairWins Platform      │ │
│  │   (DAO Governance)     │   │   (Prediction Markets)   │ │
│  └───────────┬────────────┘   └──────────┬───────────────┘ │
│              │                            │                  │
│              ↓                            ↓                  │
│  ┌────────────────────┐     ┌────────────────────────────┐ │
│  │ LMSR Markets       │     │ V3 Concentrated Liquidity  │ │
│  │ + Privacy          │     │ Pools                      │ │
│  │ (Nightmarket)      │     │ (Community LPs)            │ │
│  └──────────┬─────────┘     └──────────┬─────────────────┘ │
│             │                           │                   │
│             ↓                           ↓                   │
│  ┌──────────────────┐       ┌─────────────────────────┐   │
│  │ Privacy          │       │ Multiple Fee Tiers      │   │
│  │ Coordinator      │       │ (0.05%, 0.3%, 1%)       │   │
│  └──────────────────┘       └─────────────────────────┘   │
│                                                              │
│             Both use Conditional Tokens (PASS/FAIL)         │
└─────────────────────────────────────────────────────────────┘

Key Design Principles:

ClearPath:
Uses existing LMSR + ConditionalMarketFactory
Maintains Nightmarket privacy integration
No V3 integration needed (privacy requirement)
Bounded loss protects DAO treasury
FairWins:
Deploys V3 pools for all markets
No privacy requirement (public prediction markets)
Community liquidity provision enabled
Multiple fee tiers for different market types
Shared Infrastructure:
Both platforms use same conditional token standard
OracleResolver works for both systems
ProposalRegistry shared for metadata
Frontend routes to appropriate platform

New Smart Contracts Required (FairWins Only)¶

1. V3MarketFactory (FairWins)¶

/**
 * @title V3MarketFactory
 * @notice Factory for creating V3 liquidity pools for FairWins prediction markets
 * @dev Wraps Uniswap V3 Factory with prediction market specific logic
 */
contract V3MarketFactory {
    IUniswapV3Factory public immutable v3Factory;
    ConditionalMarketFactory public immutable conditionalFactory;

    // Mapping: marketId => (token0, token1, fee) => pool address
    mapping(uint256 => mapping(bytes32 => address)) public marketPools;

    event V3PoolCreated(
        uint256 indexed proposalId,
        address indexed token0,
        address indexed token1,
        uint24 fee,
        address pool
    );

    /**
     * @notice Create V3 pool for prediction market tokens
     * @param proposalId ID of the proposal
     * @param collateralToken Collateral token (e.g., USDC)
     * @param fee Fee tier (500, 3000, or 10000)
     * @param initialPrice Initial sqrt price X96
     * @return pool Address of created pool
     */
    function createMarketPool(
        uint256 proposalId,
        address collateralToken,
        uint24 fee,
        uint160 initialPrice
    ) external returns (address pool);
}

Note: MarketRouter is not needed with platform-specific approach. ClearPath uses only LMSR, and FairWins uses only V3.

Integration Flow¶

Creating Markets¶

ClearPath (Governance):

1. Proposal created in ProposalRegistry
2. ConditionalMarketFactory creates LMSR market (current flow)
3. PrivacyCoordinator enables encrypted trading
4. Protocol provides liquidity with bounded loss guarantee

FairWins (Prediction Markets):

1. Market created in FairWins platform
2. V3MarketFactory creates V3 pool
3. Market creator or community provides initial liquidity
4. LPs can add liquidity in custom ranges
5. Trading occurs through standard V3 interface

Trading Flow¶

ClearPath:

User → Privacy-Enabled LMSR Market
  │
  ├─► Create encrypted position
  ├─► Generate zkSNARK proof
  ├─► Submit to PrivacyCoordinator
  └─► Batch processing with other trades

FairWins:

User → V3 Pool (Direct)
  │
  ├─► Quote from pool
  ├─► Execute swap through V3 interface
  └─► Transparent on-chain execution

Benefits and Synergies¶

Benefits of Platform-Specific Integration¶

1. Optimal Mechanism for Each Use Case¶

ClearPath (LMSR): - Privacy preserved for governance decisions - Bounded loss protects DAO treasury - Predictable pricing for institutional decisions - Proven Nightmarket integration - Lower complexity reduces risk

FairWins (V3): - 3-5x capital efficiency for LPs - Community liquidity provision - Market-driven price discovery - Transparent for public predictions - Multiple fee tiers for different markets

2. No Liquidity Fragmentation¶

Previous Concern (Parallel Markets):

$100k total liquidity split:
- $60k in LMSR
- $40k in V3
→ Both pools less deep than unified

Platform-Specific Solution:

ClearPath: $50k in LMSR (100% of platform liquidity)
FairWins: $50k in V3 (100% of platform liquidity)
→ No fragmentation within each platform

3. Clear User Experience¶

No Confusion: - ClearPath users = LMSR + Privacy (only option) - FairWins users = V3 + Transparency (only option) - No need to choose between mechanisms - Platform selection is the mechanism selection

4. Simplified Development¶

Compared to Parallel Markets: - No router needed - No arbitrage concerns between mechanisms - Simpler frontend (one mechanism per platform) - Easier to test and audit - Lower maintenance burden

5. Community Liquidity Provision (FairWins)¶

LMSR (ClearPath): - Protocol/DAO provides all liquidity - Controlled and predictable - Bounded loss protection

V3 (FairWins): - Anyone can become LP - Earn fees from market activity - Permissionless participation - Increases community engagement

6. Multiple Fee Tiers (FairWins)¶

V3 Flexibility: - 0.05% tier: Stable/obvious outcome markets - 0.3% tier: Standard uncertainty markets - 1% tier: High volatility/speculation markets

Benefit: LPs choose risk/reward profile matching their strategy

7. Risk Distribution¶

ClearPath: Protocol bears all market making risk (acceptable for governance)

FairWins: Risk distributed across many LPs (appropriate for predictions) - Protocol can participate as LP but not required - Market participants self-regulate liquidity - Reduces protocol's capital requirements

Synergies Between Platforms¶

Despite using different mechanisms, the platforms can still benefit from shared infrastructure:

Shared Conditional Token Standard: Both use PASS/FAIL tokens
Oracle Resolution: OracleResolver works for both platforms
Metadata Registry: ProposalRegistry provides standardized data
Frontend Components: Reusable UI elements where appropriate
Community: Users can participate in both platforms

Risks and Limitations¶

Technical Risks (Primarily FairWins/V3)¶

Risk 1: Smart Contract Complexity¶

Issue: V3 is significantly more complex than LMSR

Impact: Higher audit costs, more potential bugs

Mitigation: - Use battle-tested Uniswap V3 code as-is - Minimal custom modifications - Extensive testing required - Gradual rollout

Risk 2: Gas Costs¶

Issue: V3 operations more gas-intensive than LMSR

Estimates: - LMSR trade: ~100k gas - V3 swap (single tick): ~150k gas - V3 swap (multiple ticks): ~200-300k gas

Mitigation: - Use for high-value trades where efficiency matters - Batch operations when possible - Consider L2 deployment for high-frequency use

Risk 3: Liquidity Fragmentation¶

Issue: Splitting liquidity between LMSR and V3

Mitigation: - Smart routing ensures best execution - Arbitrage incentivizes balanced liquidity - Start with V3 as supplement, not replacement

Risk 4: Privacy Compatibility¶

Issue: V3 not designed for private trading

Challenges: - Tick movements visible on-chain - LP positions publicly tracked - Trade amounts deducible from state changes

Current Limitations: - Cannot fully hide V3 trading activity - Nightmarket privacy effective only for LMSR

Future Solution: - Research ZK-compatible AMM designs - Batch V3 trades through privacy coordinator - Use V3 for non-private trades only

Risk 5: Impermanent Loss for LPs¶

Issue: LPs can lose value vs. holding tokens

Example:

LP deposits: 100 PASS @ 0.50 + 50 USDC (total $100)
Price moves to 0.70 PASS
LP position now: 84 PASS + 58.8 USDC = $117.6
But if held: 100 PASS @ 0.70 = $70 PASS + $50 USDC = $120
Impermanent loss: $2.4 (2%)

Mitigation: - Education: Ensure LPs understand risk - Narrow ranges: Reduce IL exposure - Fee capture: Fees offset IL

Economic Risks¶

Risk 1: Insufficient LP Participation¶

Issue: V3 pools need active LPs to function

Mitigation: - Start with protocol-provided liquidity - Incentivize early LPs with rewards - Only enable V3 for high-volume markets - Keep LMSR as always-available fallback

Risk 2: Manipulability¶

Issue: Thin V3 pools could be manipulated

Mitigation: - Minimum liquidity requirements for V3 pools - Circuit breakers on large price deviations - Monitor LMSR/V3 price divergence - Rate limiting for large trades

Implementation Roadmap¶

Phase 0: Research & Planning (Complete)¶

Objective: Understand V3 mechanics and integration options

Analyze Uniswap/ETCswap V3 architecture
Compare with current LMSR implementation
Identify integration approaches
Document findings (this document)

Deliverables: - ✅ Research document - ✅ Technical analysis - ✅ Integration recommendations

Phase 1: Prototype Development¶

Objective: Build proof-of-concept V3 integration for FairWins

Tasks:

Core Contracts - [ ] Fork/adapt Uniswap V3 contracts for Solidity 0.8.24 - [ ] Implement V3MarketFactory - [ ] Connect to existing ConditionalMarketFactory - [ ] Create test pools for PASS/FAIL tokens

Testing & Documentation - [ ] Write unit tests for V3MarketFactory - [ ] Write integration tests for FairWins V3 markets - [ ] Document integration API - [ ] Create deployment scripts

Deliverables: - V3MarketFactory contract - Test suite (>90% coverage) - Integration documentation

Phase 2: Testnet Deployment¶

Objective: Deploy and test on Mordor testnet

Tasks: - [ ] Deploy V3Factory to Mordor - [ ] Deploy V3MarketFactory - [ ] Create test FairWins markets - [ ] Gather community feedback

Success Criteria: - Stable operation over extended testing period - No critical bugs found - Gas costs within acceptable range - Positive community feedback

Phase 3: Security Audit¶

Objective: Professional security review

Tasks: - [ ] Code freeze - [ ] Internal security review - [ ] External audit by professional firm - [ ] Fix critical/high severity issues

Success Criteria: - No critical vulnerabilities - High/medium issues resolved - Audit report published

Phase 4: Mainnet Launch (Phased)¶

Objective: Gradual rollout to mainnet

Stage 1: Limited Launch - [ ] Deploy to mainnet - [ ] Enable V3 for pilot FairWins markets - [ ] Protocol provides initial liquidity - [ ] Monitor closely

Stage 2: Expansion - [ ] Open to additional markets - [ ] Allow community LP participation - [ ] Gather usage data

Stage 3: Full Availability - [ ] Available for all FairWins markets - [ ] Fully permissionless LP participation - [ ] Documentation and guides complete

Success Criteria: - Significant volume on V3 pools - Reduced average slippage - Active LP community - No security incidents

Phase 5: Advanced Features (Future)¶

Objective: Add sophisticated V3 capabilities for FairWins

Potential Features: - [ ] Multi-outcome markets (>2 outcomes) - [ ] Range order automation (keeper bots) - [ ] IL insurance protocol - [ ] Advanced analytics dashboard - [ ] LP strategy templates - [ ] Cross-chain liquidity bridging

Conclusion¶

Summary of Findings¶

ETCswap v3's concentrated liquidity mechanisms offer compelling advantages for high-volume prediction markets:

Capital Efficiency: 3-5x improvement for concentrated positions
Community Participation: Permissionless liquidity provision
Flexible Fee Structures: Multiple tiers for different market types
Price Discovery: Market-driven pricing for active markets

LMSR remains optimal for privacy-required governance:

Privacy Integration: Mature Nightmarket implementation
Bounded Loss: Protects protocol/DAO treasury
Predictability: Consistent pricing for governance
Simplicity: Lower complexity reduces risk

Platform-Specific Recommendation¶

The analysis shows that ClearPath and FairWins have fundamentally different requirements:

ClearPath: Privacy is paramount for governance → LMSR + Nightmarket is ideal FairWins: Volume and efficiency matter → V3 concentrated liquidity is optimal

This platform-specific approach: - ✅ Eliminates liquidity fragmentation (no split within platforms) - ✅ Provides optimal mechanism for each use case - ✅ Simplifies user experience (one mechanism per platform) - ✅ Reduces development complexity (no routing needed) - ✅ Maintains ClearPath's privacy guarantees

Recommended Approach¶

Platform-Specific Mechanisms (Option 1):

ClearPath → LMSR + Privacy:
Governance requires privacy to prevent collusion
Bounded loss protects DAO treasury
Proven Nightmarket integration
Maintain current implementation
FairWins → V3 Concentrated Liquidity:
High volume justifies complexity
Community LP participation
Transparency acceptable for predictions
Capital efficiency gains
Market-driven price discovery
No Fragmentation:
Each platform has single mechanism
No user confusion about which to use
No liquidity split within platforms

Key Principles: - Right tool for right job (governance vs predictions) - Privacy where critical (ClearPath) - Efficiency where beneficial (FairWins) - Simpler than parallel markets approach - Clear user experience per platform

Strategic Value¶

Short-term (6-12 months): - ClearPath: Maintains privacy-first governance with LMSR - FairWins: V3 attracts liquidity providers and increases volume - Reduced overall protocol liquidity requirements - Clear differentiation between platforms

Medium-term (1-2 years): - ClearPath: Remains privacy-focused governance platform - FairWins: Becomes leading efficient prediction market - V3 liquidity depth rivals centralized prediction markets - Community LP ecosystem matures

Long-term (2+ years): - ClearPath: Gold standard for private DAO governance - FairWins: Most capital-efficient prediction market platform - Potential for additional V3 features (multi-outcome, etc.) - Both platforms reference implementations in their categories

Next Steps¶

Immediate (This Week):
Review this document with core team
Get buy-in on platform-specific approach
Allocate resources for FairWins V3 integration
Short-term (Next Month):
Begin Phase 1 prototype development (FairWins only)
Set up dedicated testnet environment
Engage with potential FairWins LP partners
Medium-term (Next Quarter):
Complete prototype and testing
Select and engage audit firm
Prepare FairWins community for V3 launch

Open Questions for Discussion¶

Timeline: Should FairWins V3 launch before or after ClearPath goes live?
Initial Liquidity: How to bootstrap FairWins V3 pools? Protocol seed funding?
Fee Tiers: Which fee tiers should be enabled initially for FairWins?
LP Incentives: Should protocol offer additional rewards to early LPs?
Resources: Do we have bandwidth for parallel ClearPath and FairWins development?
Migration: Should existing FairWins markets migrate from LMSR to V3?

Appendix¶

A. Technical References¶

Uniswap V3 Resources: - Whitepaper - Core Repository - Periphery Repository - Documentation

ETCswap Resources: - ETCswap v3 Core

Prediction DAO Resources: - Architecture Documentation - ConditionalMarketFactory - FairWins Markets - Nightmarket Privacy

Related Research: - LMSR Paper - Robin Hanson - Gnosis Conditional Tokens - MACI Anti-Collusion

B. Glossary¶

Terms:

AMM (Automated Market Maker): Smart contract that provides liquidity and prices algorithmically
Concentrated Liquidity: Liquidity provided within specific price range
Impermanent Loss: Potential loss for LPs when price moves away from deposit price
LP (Liquidity Provider): User who deposits tokens to provide trading liquidity
LMSR: Logarithmic Market Scoring Rule - algorithmic market maker for prediction markets
Slippage: Price difference between expected and actual execution price
Tick: Discrete price point in Uniswap V3 (1.0001^tick)
TWAP: Time-Weighted Average Price - oracle price feed

C. Comparison Tables¶

Feature Comparison¶

Feature	LMSR	V3	Recommended Usage
Setup Complexity	Low	High	LMSR for quick markets
Capital Efficiency	Low	High	V3 for large markets
Privacy Support	Excellent	Poor (needs work)	LMSR for privacy needs
Price Discovery	Algorithmic	Market-driven	Both complement
Liquidity Source	Centralized	Decentralized	V3 for community markets
Gas Costs	Lower	Higher	LMSR for small trades
Maintenance	Low	Medium	Consider resources
Bounded Loss	Yes	No	LMSR for protocol safety
Fee Flexibility	Limited	Excellent	V3 for varied markets

Market Type Recommendations¶

Market Type	Platform	Mechanism	Rationale
DAO Governance Proposals	ClearPath	LMSR + Privacy	Privacy required for governance, bounded loss
Treasury Management	ClearPath	LMSR + Privacy	Privacy required, controlled liquidity
Protocol Parameter Changes	ClearPath	LMSR + Privacy	Privacy required, predictable pricing
All FairWins Markets	FairWins	V3 Pools	High volume, community LPs, transparency OK
Event Predictions	FairWins	V3 Pools	Market-driven pricing, efficient LPs
Sports/Entertainment	FairWins	V3 Pools	High activity benefits from V3
Financial Forecasting	FairWins	V3 Pools	Multiple fee tiers for different volatility

Key Principle: Platform determines mechanism - ClearPath = Always LMSR (privacy-first) - FairWins = Always V3 (efficiency-first)

Document Version: 2.0
Last Updated: December 23, 2025
Authors: Prediction DAO Research Team
Status: Final - Platform-Specific Approach

Changelog: - v2.0: Updated to platform-specific approach (ClearPath=LMSR, FairWins=V3) - v1.0: Initial parallel markets recommendation