How to Launch Custom Curve Pools

Launching a custom pool on Curve Finance requires deploying a new liquidity pool contract via one of its official factory contracts. Unlike adding liquidity to an existing pool, this process involves specifying the pool's unique parameters, including the underlying assets, amplification coefficient (A), and fee structure. The most common factory is the StableSwap Factory (0x0959158b6040D32d04c301A72CBFD6b39E21c9AE), which is designed for pools containing pegged assets like stablecoins or wrapped versions of the same asset (e.g., stETH/ETH). You must ensure your token contracts are compatible and have proper decimal handling.

Before deployment, you must decide on critical pool parameters. The amplification coefficient A determines the pool's curvature and slippage profile; a higher A (e.g., 2000) creates a flatter curve better for tightly-correlated assets. The swap fee (e.g., 0.04%) and admin fee (a percentage of the swap fee) are set at creation. You also need the token addresses and their respective precisions. All parameters are immutable after deployment, so careful testing on a testnet like Sepolia or Goerli using forked mainnet contracts is essential. Use the official Curve Factory Deployer repository as a reference.

Deployment is typically done via a script that calls the deploy_plain_pool or deploy_metapool function on the factory contract. Here's a simplified example using Foundry and forge script:

solidityCopy
// Example parameters for a 2-pool of USDC and USDT
string memory _name = "Curve USDC-USDT";
string memory _symbol = "crvUSDCUSDT";
address[] memory _coins = new address[](2);
_coins[0] = 0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48; // USDC
_coins[1] = 0xdAC17F958D2ee523a2206206994597C13D831ec7; // USDT
uint256 _A = 2000;
uint256 _fee = 4000000; // 0.04% in 1e8 precision
uint256 _admin_fee = 5000000000; // 50% of fee in 1e10 precision

The factory will deploy a new pool and return its address, which you must then seed with initial liquidity.

After deployment, the pool is inactive until initial liquidity is deposited and the pool is officially "whitelisted" for gauge creation and CRV emissions. The deployer (or a designated liquidity provider) must call add_liquidity on the new pool contract with a balanced deposit of all underlying tokens. Following this, a governance proposal must be submitted to the Curve DAO to add a gauge for the pool, which is necessary for liquidity providers to earn CRV incentives. Without a gauge, the pool will not attract significant liquidity. Monitor the Curve DAO forums for the proposal process and requirements.

Key considerations for a successful launch include security audits of any custom token implementations, ensuring sufficient initial liquidity depth to minimize early slippage, and planning for gauge voting. Pools for non-standard or uncorrelated assets may require using a different factory, like the CryptoSwap Factory for volatile assets, which uses a different bonding curve math. Always verify transaction success and pool contract verification on Etherscan. Post-launch, monitor pool metrics like volume, fees, and liquidity concentration using tools like Curve Analytics.

A custom Curve pool is a smart contract deployed on-chain that manages liquidity for a specific set of assets. The primary prerequisites are a clear understanding of the Curve protocol's architecture, particularly the StableSwap invariant and its extensions like the CryptoSwap invariant for volatile assets. You should be familiar with the core components: the Liquidity Pool contract, the Liquidity Gauge for emissions, and the DAO's gauge controller. Reviewing existing pool implementations on Curve's GitHub is essential.

From a technical standpoint, you need the source code for your pool's token contracts. For a standard StableSwap pool, this typically requires 2-4 assets that are pegged to a similar value (e.g., stablecoins like USDC, DAI, USDT). For a CryptoSwap pool, you can use more volatile assets (e.g., wBTC, ETH). All tokens must implement a standard ERC-20 interface and be verified on a block explorer. You must also prepare the pool's parameters: the amplification coefficient A (for StableSwap), the fee structure, and the admin fee percentage.

Financial requirements include securing the initial liquidity for your pool. You must provide a seed deposit of all pool tokens in balanced proportions. For example, to launch a 3CRV metapool (e.g., FRAX/3CRV), you need both FRAX tokens and 3CRV LP tokens. Additionally, you should budget for gas costs associated with deployment and initial transactions, which can be significant on Ethereum mainnet. Planning for ongoing liquidity incentives, often via CRV emissions directed through a gauge, is also a critical long-term consideration.

Operationally, launching a pool requires interaction with the Curve DAO. While factory pools can be deployed permissionlessly, to list your pool on the Curve frontend and, crucially, to receive CRV gauge weight for liquidity incentives, you must submit a governance proposal. This process involves community discussion, a temperature check, and a formal vote. Preparing clear documentation about your pool's use case, tokenomics, and security audits is vital for a successful proposal.

Curve v2, or the Curve Crypto Pools architecture, represents a significant evolution from its v1 stable-swap predecessor. While v1 pools are optimized for assets pegged to the same value (like stablecoins), v2 introduces a dynamic automated market maker (AMM) formula. This formula, defined by the StableSwapNG contract, allows for efficient trading between correlated but volatile assets, such as ETH/wBTC or other crypto-native pairs. The core innovation is its ability to concentrate liquidity around a moving price range, reducing slippage while maintaining capital efficiency for assets that experience price drift.

Launching a custom Curve v2 pool requires deploying several key smart contracts. The primary factory contract, CryptoPoolFactory, is the entry point. You will first need to deploy a liquidity gauge for your pool using the GaugeFactory to enable CRV emissions and governance voting. Next, you interact with the factory to deploy the pool itself, which creates a new CryptoPool contract. This contract is linked to your chosen oracle (like a time-weighted average price feed) and a math contract that implements the bonding curve's complex calculations. All parameters, including the amplification coefficient (A) and the fee structure, are set at deployment.

The most critical step is parameter configuration. The A parameter controls the pool's sensitivity to price changes; a higher A (e.g., 400) makes the curve more like a constant sum (stable) formula, while a lower A makes it behave more like a constant product (Uniswap-style) curve. You must also set the swap fee (e.g., 0.04%), the admin fee (a portion of the swap fee), and the mid_fee and out_fee for the dynamic fee mechanism. This mechanism adjusts fees based on how far the current price is from the oracle price, penalizing large imbalances to protect liquidity providers.

After deployment, the pool must be seeded with initial liquidity. This is a security-critical phase to prevent manipulation. The first deposit should be perfectly balanced according to the initial oracle price. It's common practice for the deploying team or a trusted entity to provide this seed liquidity. Once live, the pool's price oracle begins accumulating data, and the AMM's internal price_scale variable adjusts, allowing the concentrated liquidity band to follow the market price. The pool can then be added to the Curve DAO's gauge controller to receive CRV token emissions, incentivizing further liquidity provision.

Developers should be aware of the operational and security considerations. Managing the pool's parameters (like A) requires a DAO vote via a Curve Improvement Proposal (CIP), making initial choices crucial. Furthermore, the oracle is a trusted component; using a decentralized and robust oracle like Chainlink is essential. All contracts are upgradeable via proxy patterns controlled by the Curve DAO, meaning governance ultimately oversees your pool. For a complete implementation example, review the official factory deployment script on GitHub.

Before deploying a custom Curve pool, ensure you have the necessary prerequisites. You will need a Web3 wallet like MetaMask, sufficient ETH for gas fees on the target network (e.g., Ethereum Mainnet, Arbitrum, Optimism), and the two tokens you intend to pair in the pool. Crucially, you must verify that a suitable Curve Factory v2 (also known as the CryptoSwap Factory) exists on your chosen network. The deployment process is conducted via the official Curve Factory contract interface, not through a web UI. You can find the latest factory addresses and ABIs on the Curve GitHub repository or the Curve Docs.

The core deployment is executed by calling the deploy_pool function on the Factory contract. This function requires several parameters: the pool's name and symbol, the addresses of the two constituent coins, the A (amplification coefficient) value, the fee (typically 4000000, representing 0.04%), the admin fee (often 5000000000, or 50% of the fee), and the gamma parameter for the CryptoSwap math. The A and gamma values are critical for defining the pool's bonding curve and slippage profile; miscalculation can lead to poor liquidity or vulnerability. Use the Curve team's parameter recommendation tool to calculate appropriate values for your asset pair.

After the transaction confirms, the factory will deploy two new contracts: the main liquidity pool and a corresponding liquidity gauge. Note the deployed pool address from the transaction logs. The next step is to seed the pool with initial liquidity. You must approve the new pool contract to spend your tokens, then call the pool's add_liquidity function with the desired amounts for each asset. The initial deposit ratio should be close to the market price to minimize arbitrage loss. Failure to add liquidity will result in a non-functional pool. Finally, to enable CRV emissions and gauge voting, the pool's LP token must be added to the gauge controller via a governance proposal, which is a separate, permissioned process.

Launching a custom Curve v2 pool requires deploying a factory contract and configuring its core parameters. The primary contracts are the CurveTwocryptoFactory and the CurveTwocryptoNGFactory. The process involves calling deploy_pool with the pool's name, symbol, and the addresses of the two constituent coins. The factory then deploys a new CurveCryptoSwap pool contract. Before deployment, you must ensure the coins are approved for the factory and that you have sufficient liquidity to seed the initial deposit. The pool's AMM math is handled by the Math contract, which uses an invariant designed for volatile assets.

The most critical parameters to tune are the amplification coefficient A, the fee structure, and the mid-fee to out-fee ratio. The A parameter controls the pool's curvature and slippage profile. A higher A (e.g., 4000) creates a more linear curve, suitable for correlated assets like stablecoin derivatives. A lower A (e.g., 100) creates a more exponential curve, better for volatile, uncorrelated assets. Setting this incorrectly can lead to high slippage or impermanent loss. The fee is split into a mid_fee (applied near equilibrium) and an out_fee (applied when the price deviates). The fee_gamma parameter defines the transition between these fee regimes.

Optimizing for capital efficiency involves balancing the A parameter with the gamma parameter used in the invariant. The gamma is a small number (e.g., 1e-10) that prevents the invariant from approaching zero, which would make the pool vulnerable to manipulation. A well-tuned A and gamma pair minimizes slippage for the expected trading volume and price volatility of your asset pair. You can simulate different parameter sets using the get_dy and get_dx view functions to estimate slippage under various swap sizes before committing liquidity.

Fee optimization is key for sustainable pool economics. The mid_fee (e.g., 0.04%) should be competitive with other DEXs to attract volume. The out_fee (e.g., 0.40%) acts as a dynamic spread, increasing during large price moves to compensate LPs for higher risk. The fee_gamma determines how quickly the fee shifts from mid_fee to out_fee as the internal oracle price moves away from the market price. A lower fee_gamma makes the transition sharper. You must also set the admin_fee (a fraction of the trading fee taken by the DAO) and the initial ma_exp_time, which is the half-life for the pool's internal price oracle.

After deployment, you must seed the pool with an initial deposit using the add_liquidity function. The initial deposit ratio should closely reflect the current market price to avoid immediate arbitrage that drains liquidity. Use the calc_token_amount function to verify the LP token minting. Post-launch, monitor key metrics: the pool's virtual price (should steadily increase with fees), the actual vs. oracle price divergence, and the fee accrual rate. Parameter adjustments are possible via the pool's ramp_A, ramp_gamma, or apply_new_fee functions, but these are typically timelocked and require DAO governance approval via a Curve gauge vote.

A liquidity gauge is a smart contract that manages the distribution of CRV token emissions to users who provide liquidity to a specific Curve pool. When you deploy a new pool, you must also deploy a gauge to make it eligible for these rewards, which are a primary incentive for liquidity providers (LPs). The gauge measures a user's share of the pool's liquidity over time and allocates CRV accordingly. This process is governed by Curve's DAO, specifically the veCRV (vote-escrowed CRV) holders, who must vote to approve and whitelist your new gauge before it can begin distributing rewards.

Before deployment, ensure your pool's LP token is finalized and its address is correct, as it is immutable once set in the gauge. The standard gauge contract is LiquidityGaugeV5 (or the latest version; always verify on the Curve DAO GitHub). You will deploy this contract, initializing it with your LP token address. Deployment is typically done via a script or directly through a tool like Foundry or Hardhat. A basic deployment transaction looks like this, where _lp_token is your pool's LP token address:

solidityCopy
GaugeV5 gauge = new GaugeV5(_lp_token);

After deployment, the gauge must be added to the GaugeController. This is a permissioned action that requires a DAO vote. You must submit a proposal to the Curve DAO requesting the gauge's addition. The proposal should include the gauge address, the pool's type, and any relevant metrics. If the vote passes, the gauge is whitelisted and assigned a gauge type and weight. Once approved, LPs can deposit their LP tokens into the gauge contract to start earning CRV emissions. The gauge's inflation rate and the pool's share of weekly CRV are controlled by the GaugeController weights, which are adjusted weekly via ongoing veCRV votes.

Managing the gauge involves monitoring its performance and incentives. You can integrate additional reward tokens beyond CRV by deploying a RewardsDistributor contract or using the gauge's built-in functionality for extra rewards. It's critical to ensure the gauge remains secure; always use the audited, official contracts from Curve. For ongoing maintenance, monitor the gauge's weight in the GaugeController, as this determines its CRV allocation. Engage with the veCRV governance community to advocate for your pool and maintain its gauge weight, which directly impacts LP yields and the pool's overall liquidity depth.

The primary security responsibility for a custom pool deployer is the initial parameter configuration. Incorrect settings for the amplification coefficient (A), fee structure (fee, admin_fee), or the ma_exp_time for the EMA oracle can lead to immediate financial loss or a non-functional pool. For example, setting A too low reduces capital efficiency, while setting it too high can make the pool vulnerable to manipulation. These parameters are immutable for factory-deployed pools, making the deployment transaction a critical, one-time security event that requires extensive testing on a testnet.

A major technical risk is the integrity of the oracle price feed used by the pool's internal price_scale. The Curve stableswap math relies on a cached, time-weighted average price (TWAP) to measure impermanent loss and calculate profits for liquidity providers. If the underlying oracle (like a Chainlink price feed) is manipulated or fails, the pool's internal accounting can become inaccurate, potentially allowing an attacker to drain funds through arbitrage. It is essential to use a robust, decentralized oracle and understand the ma_exp_time parameter that controls the TWAP window.

For pools containing non-standard or rebasing tokens, additional attack vectors exist. Tokens with transfer fees, pausing mechanisms, or balance-changing callbacks (like some ERC-777 tokens) can break the pool's internal accounting if not handled. The pool's token implementation must be audited for compliance with Curve's expected behavior. Furthermore, the admin privileges of a pool—such as the ability to withdraw coins in an emergency via withdraw_admin_fees or, in older pools, to kill the gauge—represent a centralization risk that depositors must trust.

Finally, consider the economic security of the pool's liquidity. A new pool with low total value locked (TVL) is highly susceptible to manipulation and slippage attacks. An attacker could perform a large swap to skew the price_scale, then drain fees from subsequent, natural trading volume. Bootstrapping sufficient liquidity and potentially using a gauge to incentivize deposits are crucial for stabilizing the pool's economics. Always reference the official Curve Finance documentation and audit reports for the specific pool factory you are using.

Before directing users to your new pool, conduct a final verification. Use the Curve DAO's pool registry to ensure your pool's contract is correctly listed. Test all core functions on a testnet or via a forked mainnet environment using tools like Foundry or Hardhat. Key tests include deposit/withdrawal at different liquidity levels, exchange and exchange_underlying swaps, and fee accrual. Verify that the admin_balances for the protocol fee are correctly tracked. A single bug in the invariant or fee math can lead to significant, irreversible losses.

Post-launch, your primary focus shifts to liquidity management and community engagement. Monitor the pool's TVL, volume, and fee generation via the Curve UI or subgraph. Consider deploying a gauge through a Curve DAO vote to enable CRV emissions and boost liquidity provider rewards, which is critical for attracting capital. Engage with the Curve community on the Governance Forum to discuss potential parameter adjustments, like fee changes or weight updates, which require a DAO proposal.

For ongoing development, explore advanced customizations. You can integrate oracle rates for lending protocols, implement a rate calculator for rebasing tokens, or use the factory metapool pattern to create a pool that connects your LP token to the broader Curve ecosystem. Always refer to the official Curve Documentation and audit reports for the latest best practices and security considerations. Launching a pool is the beginning; its long-term success depends on active maintenance and integration within the DeFi landscape.