Skip to content

Contracts

Jump to bottom
M1k3lee edited this page Nov 21, 2025 · 2 revisions

Smart Contracts Deep Dive

Written by MikeLee

This page provides a comprehensive overview of every smart contract in the Crossify platform. Each contract was designed, tested, and deployed with careful attention to security, gas efficiency, and cross-chain compatibility.

Contract Overview

The Crossify platform consists of 10 core smart contracts, each serving a specific purpose in the token launch and trading ecosystem:

  1. TokenFactory - Entry point for token creation
  2. BondingCurve - Manages token sales with linear pricing
  3. GlobalSupplyTracker - Tracks supply across all chains
  4. CrossChainSync - Handles LayerZero messaging
  5. CrossChainLiquidityBridge - Manages liquidity across chains
  6. CrossifyToken - Standard ERC20 token implementation
  7. Migration - Handles DEX graduation
  8. DEXDetector - Identifies available DEXes
  9. UnifiedLiquidityPool - Shared liquidity management
  10. CFY Contracts - Platform token ecosystem (separate system)

1. TokenFactory

Purpose: Factory contract that creates new tokens and their associated bonding curves.

Key Features:

  • Deploys ERC20 tokens with custom parameters
  • Creates BondingCurve instances for each token
  • Registers tokens with GlobalSupplyTracker
  • Tracks all tokens created by each address
  • Chain-aware deployment (knows which chain it's on)

Constructor Parameters:

constructor(
    address initialOwner,
    address _globalSupplyTracker,
    string memory _chainName,
    bool _useGlobalSupply,
    address _lzEndpoint,
    address _crossChainSync,
    address _priceOracle,
    uint32 _chainEID
)

Key Functions:

  • createToken() - Main function to create a new token
  • setGlobalSupplyTracker() - Update tracker address
  • setUseGlobalSupply() - Enable/disable global supply tracking
  • setLiquidityBridge() - Configure liquidity bridge

Design Decisions:

  • Why a Factory? Centralized creation makes it easier to track all tokens and ensures consistent deployment parameters.
  • Chain Awareness: Each factory knows its chain, enabling proper cross-chain communication setup.
  • Owner Control: Critical parameters can only be updated by owner, preventing unauthorized changes.

Testing: We tested with 100+ token creations across all testnets, verifying each token was properly registered and configured.

2. BondingCurve

Purpose: Manages the buy/sell mechanism for tokens using a linear bonding curve.

Price Formula: price = basePrice + (slope * globalSupply)

This is where our innovation shines. Instead of using local supply (like traditional bonding curves), we use global supply from the GlobalSupplyTracker. This means:

  • A buy on BSC Testnet increases the price on Base Sepolia
  • Prices stay synchronized across all chains
  • Unified market experience

Key Features:

  • Buy/sell operations with automatic pricing
  • Global supply integration for cross-chain sync
  • Graduation detection (when market cap threshold reached)
  • Liquidity bridging when reserves are low
  • Fee collection (buy/sell fees configurable)

Constructor Parameters:

constructor(
    address _token,
    uint256 _basePrice,
    uint256 _slope,
    uint256 _graduationThreshold,
    uint256 _buyFeePercent,
    uint256 _sellFeePercent,
    address _owner,
    address _globalSupplyTracker,
    string memory _chainName,
    bool _useGlobalSupply,
    address _liquidityBridge,
    uint32 _chainEID,
    bool _useLiquidityBridge
)

Key Functions:

  • buy(uint256 tokenAmount) - Buy tokens
  • sell(uint256 tokenAmount) - Sell tokens
  • getCurrentPrice() - Get current price per token
  • getPriceForAmountLocal(uint256 tokenAmount) - Calculate price for specific amount
  • checkAndGraduate() - Check if graduation threshold reached

Security Features:

  • Reentrancy guards on all external functions
  • Price validation (max 1 ETH per token, 100 ETH per transaction)
  • Reserve checks before sells
  • Owner-only functions for critical operations

Gas Optimization:

  • Cached global supply reads
  • Batch operations where possible
  • Minimal storage writes

Testing: We ran extensive tests:

  • 1000+ buy/sell transactions
  • Edge cases (max amounts, zero amounts, etc.)
  • Cross-chain price synchronization
  • Graduation scenarios

3. GlobalSupplyTracker

Purpose: The heart of cross-chain price synchronization. Tracks the total supply sold across all chains.

Key Innovation: This contract maintains a single source of truth for supply across all chains. When a token is bought on any chain, the global supply updates, and all chains see the new price.

Key Features:

  • Global supply tracking per token
  • Per-chain supply tracking
  • Cross-chain synchronization via LayerZero
  • Authorized updater system (only bonding curves can update)
  • Fallback to local pricing if cross-chain fails
  • NEW: Enhanced authorization system
  • NEW: Owner can authorize updaters automatically

Deployed Addresses (Testnet):

  • Sepolia: 0x130195A8D09dfd99c36D5903B94088EDBD66533e
  • BSC Testnet: 0xe84Ae64735261F441e0bcB12bCf60630c5239ef4
  • Base Sepolia: 0x1eC9ee96EbD41111ad7b99f29D9a61e46b721C65

Data Structure:

mapping(address => uint256) public globalSupply; // token => total supply
mapping(address => mapping(string => uint256)) public chainSupply; // token => chain => supply
mapping(address => bool) public authorizedUpdaters; // bonding curves

Key Functions:

  • updateSupply() - Update supply (called by bonding curves)
  • getGlobalSupply() - Get current global supply
  • syncSupplyUpdate() - Cross-chain sync via LayerZero
  • authorizeUpdater() - Add authorized bonding curve

Cross-Chain Flow:

  1. BondingCurve calls updateSupply() with new supply
  2. GlobalSupplyTracker updates local state
  3. Sends LayerZero message to all other chains
  4. Other chains receive message and update their trackers
  5. All BondingCurves now see updated global supply

Testing:

  • Tested cross-chain messaging between Sepolia, BSC Testnet, and Base Sepolia
  • Verified supply updates propagate correctly
  • Tested failure scenarios (message failures, network issues)
  • Confirmed price synchronization within 0.5% variance

4. CrossChainSync

Purpose: Handles LayerZero messaging for cross-chain communication.

Key Features:

  • Sends supply updates to other chains
  • Receives and processes incoming messages
  • Message verification and authentication
  • Retry logic for failed messages
  • Fee estimation

LayerZero Integration:

  • Uses LayerZero Endpoint V2
  • Implements ILayerZeroReceiver for message receiving
  • Handles message encoding/decoding
  • Manages gas limits and fees

Security:

  • Only authorized contracts can send messages
  • Message verification before processing
  • Replay attack prevention
  • Rate limiting

5. CrossChainLiquidityBridge

Purpose: Manages liquidity across chains, ensuring all chains have sufficient reserves.

The Problem: Without this, each chain would need its own liquidity pool. If one chain runs low on reserves, sells would fail.

The Solution: Shared liquidity pool that automatically rebalances. When a chain needs liquidity, it requests it from other chains via LayerZero.

Key Features:

  • Reserve tracking per chain
  • Automatic liquidity requests
  • Cross-chain liquidity transfers
  • Volume-based reserve calculation
  • Minimum reserve thresholds

How It Works:

  1. BondingCurve detects low reserves
  2. Calls requestLiquidity() on bridge
  3. Bridge sends LayerZero message to other chains
  4. Chain with excess liquidity sends it back
  5. Target chain receives liquidity and updates reserves

Testing:

  • Tested with various reserve scenarios
  • Verified automatic rebalancing
  • Confirmed liquidity transfers work correctly
  • Tested edge cases (all chains low, one chain very high)

6. CrossifyToken

Purpose: Standard ERC20 token implementation with additional features.

Key Features:

  • Standard ERC20 functionality
  • Burnable (deflationary mechanism)
  • Pausable (emergency stops)
  • Custom metadata support
  • Transfer restrictions (optional)

Why Custom Token?: We needed a token that integrates seamlessly with our bonding curve system and supports all our features.

7. Migration

Purpose: Handles the migration from bonding curve to DEX when graduation threshold is reached.

Key Features:

  • Detects graduation conditions
  • Creates DEX pool (Uniswap V3, PancakeSwap, etc.)
  • Transfers liquidity from bonding curve to DEX
  • Updates token state
  • Emits graduation events

DEX Support:

  • Uniswap V3 (Ethereum)
  • PancakeSwap (BSC)
  • BaseSwap (Base)
  • Raydium (Solana - planned)

8. DEXDetector

Purpose: Automatically detects available DEXes on each chain.

Key Features:

  • Chain-specific DEX detection
  • Router address resolution
  • Factory address resolution
  • Pool creation parameters

9. UnifiedLiquidityPool

Purpose: Manages shared liquidity across chains (alternative to bridge approach).

Status: Implemented but using bridge approach for now. This provides a different architecture option.

Contract Deployment

Testnet Addresses

Sepolia (Ethereum):

  • TokenFactory: 0x8eF1A74d477448630282EFC130ac9D17f495Bca4
  • GlobalSupplyTracker: [Address]
  • CrossChainLiquidityBridge: 0x7005c0A2c9Cd108af213c717cA6d7232AcBD1b29

BSC Testnet:

  • TokenFactory: 0xFF8c690B5b65905da20D8de87Cd6298c223a40B6
  • GlobalSupplyTracker: [Address]
  • CrossChainLiquidityBridge: 0x08BA4231c0843375714Ef89999C9F908735E0Ec2

Base Sepolia:

  • TokenFactory: 0x170EE984fBcfd01599312EaA1AD4D35Ad5e66f58
  • GlobalSupplyTracker: [Address]
  • CrossChainLiquidityBridge: 0xDeFC8B749e68b5e21b3873928e68Aaf56031C6EA

Deployment Process

  1. Compile Contracts: npx hardhat compile
  2. Run Tests: npx hardhat test
  3. Deploy: npx hardhat run scripts/deploy-[chain].ts --network [network]
  4. Verify: npx hardhat verify --network [network] [address]
  5. Authorize: Authorize bonding curves in GlobalSupplyTracker
  6. Configure: Set cross-chain sync addresses

Security Considerations

Audits

  • Internal security review completed
  • External audit planned before mainnet
  • OpenZeppelin libraries used (audited)

Best Practices

  • Reentrancy guards on all external functions
  • Access control with Ownable pattern
  • Input validation
  • Gas optimization
  • Event logging for transparency

Known Limitations

  • Cross-chain messages can fail (fallback to local pricing)
  • Gas costs on some chains can be high
  • LayerZero dependency for cross-chain sync

Gas Costs

Typical Operations (approximate):

  • Token Creation: ~2,000,000 gas
  • Buy (first): ~150,000 gas
  • Buy (subsequent): ~120,000 gas
  • Sell: ~130,000 gas
  • Cross-chain sync: ~200,000 gas (source) + ~100,000 gas (destination)

Future Improvements

  • Batch cross-chain updates to reduce gas
  • Optimize storage layout for gas savings
  • Add more DEX support
  • Implement oracle price verification
  • Add governance features

Conclusion

These contracts represent months of development, testing, and iteration. Each contract was built with security, efficiency, and cross-chain compatibility in mind. The result is a robust, scalable system that enables true multichain token launches.

- MikeLee

For development process, see Development Process For testing details, see Testing

Clone this wiki locally