Curve Pool Migration: Legacy to New AMM Interfaces

introduction

OPERATIONAL AND SECURITY IMPERATIVE

Why Migrate from Legacy Curve Pools?

Legacy Curve pool interfaces are being superseded by optimized AMM implementations that introduce new state-mutating functions, event signatures, and oracle semantics, requiring active migration from integrators.

Curve's legacy pool interfaces, such as the original StableSwap and CryptoSwap implementations, are being phased out in favor of newer, optimized versions like twocrypto and tricrypto-ng. These new AMM implementations are not simple upgrades; they introduce breaking changes to function signatures, event emissions, and state-mutating methods. For builders and operators, this means that any integration—whether a smart contract, a keeper network, or a data pipeline—hardcoded against a legacy pool's ABI will fail or, worse, silently produce incorrect results when interacting with a new factory-deployed pool.

The operational impact is immediate and multi-faceted. Key function names for swaps, liquidity additions, and fee claims have changed, requiring direct code updates. Event signatures for critical on-chain actions like TokenExchange or AddLiquidity have been altered, which will break subgraph mappings, monitoring alerts, and off-chain accounting systems that rely on specific event topics. Furthermore, the new implementations often feature enhanced oracle mechanisms and different fee accrual logic, meaning that downstream protocols consuming Curve's EMA oracles or calculating yield must re-validate their assumptions against the new pool's behavior to avoid manipulation risks or incorrect financial calculations.

A passive approach of waiting for breakage is a significant risk. Teams should proactively audit their codebase for dependencies on legacy pool interfaces, map out a migration path to the new AMM implementations, and rigorously test their integration against the new contracts on a testnet. Chainscore Labs can support this process by auditing the compatibility of your migration path, reviewing your updated integration logic for edge cases, and verifying that your monitoring and alerting systems correctly interpret the new event signatures and state changes.

LEGACY TO NEW AMM INTERFACE CHANGES

Migration Snapshot

Operational impact of migrating integrations from legacy pool interfaces (stableswap, cryptoswap) to optimized implementations (twocrypto, tricrypto-ng).

Area	What changes	Who is affected	Action
Pool contract address	New pool deployments use factory contracts with different addresses. Legacy pool addresses remain static but are deprecated for new liquidity.	Wallets, DeFi protocols, data indexers	Update address resolution logic to query the factory registry instead of hardcoding legacy addresses.
State-mutating functions	Function signatures for swaps, deposits, and withdrawals may change parameter ordering or add new required arguments (e.g., method_id in twocrypto).	Aggregators, arbitrage bots, yield aggregators	Audit all contract call construction logic. Simulate transactions against new pool interfaces on a fork before mainnet migration.
Event signatures	Event topics and indexed parameters differ between legacy and new implementations. Deposit/Withdraw events may split or rename fields.	Data teams, subgraph operators, monitoring tools	Update event parsing schemas and re-index historical data if backfilling is required. Validate against canonical ABIs.
Oracle behavior	EMA oracle implementations in twocrypto and tricrypto-ng use different observation storage and update mechanics compared to legacy pools.	Lending protocols, derivatives platforms, risk teams	Review oracle consumption logic for staleness checks and manipulation resistance. Do not assume legacy oracle behavior.
Fee accrual and claiming	Admin fee and pool fee accrual logic may differ in new implementations, affecting how fees are calculated and claimed.	Fee recipients, DAO multisigs, integrators	Verify fee recipient configuration and claiming function signatures. Test claiming transactions on testnet deployments.
Virtual price calculation	The get_virtual_price function may incorporate different invariants or rounding behavior in optimized pools.	Yield aggregators, vaults, analytics platforms	Recalibrate any NAV or share-price calculations that depend on virtual price. Compare outputs against legacy pools during simulation.
Gauge compatibility	New pool implementations require updated gauge contracts. Legacy gauges are not forward-compatible with new pool interfaces.	Liquidity providers, gauge weight voters	Ensure new gauges are deployed and proposed before migrating liquidity. Monitor emission rates during the transition period.

technical-context

CONTRACT MIGRATION IMPACT

Interface and ABI Breaking Changes

A technical breakdown of the specific function signature, event, and state-mutating interface changes when migrating from legacy Curve pools to new implementations like twocrypto and tricrypto-ng.

Migrating from legacy Curve pool interfaces (e.g., vyper/stable-ng or older crypto variants) to newer optimized AMM implementations such as twocrypto and tricrypto-ng is not a drop-in replacement. These new pools introduce breaking changes to the Application Binary Interface (ABI) that will cause reverts or silent logic failures in any off-chain client, keeper network, or smart contract that relies on hardcoded function selectors or event signatures. The most impactful changes involve the core state-mutating functions for swaps and liquidity provision. For example, the exchange function signature may change its parameter ordering or return value handling, while the add_liquidity and remove_liquidity flows in tricrypto-ng can require different asset arrays and min_amount parameters compared to the legacy TriCrypto2 implementation.

Event signatures are also fundamentally altered, breaking any indexer, subgraph, or monitoring system that filters on the old event topics. The TokenExchange event, a primary signal for trade settlement, is often replaced or augmented with a new Exchange event that includes more granular parameters like the exact fee charged. Similarly, AddLiquidity and RemoveLiquidity events are updated to emit the precise virtual price and fee growth indices at the time of the action. Integrators must update their event parsing logic and historical data schemas to handle these new topics. A failure to do so results in incomplete or corrupted volume, TVL, and fee revenue data pipelines.

For smart contract integrators, the most dangerous breaking change is the removal or alteration of view functions used for on-chain state checks. Legacy functions like get_dy (get amount out) and calc_token_amount may be renamed or have their return value structure changed in the new ng contracts. A yield aggregator or lending protocol that calls a deprecated view function to calculate a position's value before a withdrawal will experience a hard revert, potentially locking user funds. Teams must audit their integration code against the canonical ng contract ABIs, paying close attention to immutable variable getters and the new internal price oracle methods. Chainscore Labs can perform a differential ABI audit to identify every breaking call path in your integration before you deploy a migration.

MIGRATION IMPACT BY ACTOR

Affected Systems and Integrators

Aggregators and DEX Routers

Legacy pool interfaces expose exchange and exchange_underlying functions with different parameter ordering and event signatures than new implementations like twocrypto and tricrypto-ng. Routers that hardcode function selectors or assume specific event topics will fail to detect swaps or misroute user orders.

Critical actions:

Audit all pool-type detection logic to distinguish legacy from new AMM variants before constructing calldata.
Update event monitoring for TokenExchange and TokenExchangeUnderlying to handle the new indexed parameter layouts.
Test swap simulation paths against both legacy and new pool deployments on a forked mainnet before releasing router updates.

Chainscore can audit your router's pool-type dispatch logic and event ingestion pipeline to catch silent failures before they affect live order flow.

implementation-impact

MIGRATION RISK CONTROLS

Operational Impact Areas

Moving integrations from legacy Curve pools to new AMM implementations introduces interface, event, and state-mutation risks. The following areas require targeted review and operational verification.

Function Signature and ABI Compatibility

New implementations like twocrypto and tricrypto-ng alter or deprecate state-mutating functions. Direct calls to exchange, add_liquidity, or remove_liquidity may have changed parameter ordering or return values. Teams must diff the ABI of the target implementation against the legacy interface to identify breaking changes in their transaction construction logic. A mismatch can cause silent failures or fund loss if calldata is not regenerated.

Event Signature and Indexing Migration

Event signatures for core actions like TokenExchange, AddLiquidity, and RemoveLiquidity often change between pool versions. Subgraph handlers, data pipelines, and monitoring alerts keyed on legacy event topics will silently break. Indexers must remap handlers to new event signatures and replay historical data to maintain continuity. Verify that your subgraph manifest targets the correct pool factory and ABI for the new implementation.

Oracle and Price Feed Integrity

The get_price_cumulative_last and EMA oracle mechanisms in new pools may have different update semantics or precision. Lending protocols and derivatives platforms consuming these oracles must re-validate manipulation resistance and staleness thresholds against the new implementation. A direct swap of the pool address without adjusting oracle wrapper parameters can introduce a silent pricing vulnerability.

Liquidity Migration and State Transition

Legacy pool liquidity does not automatically migrate to new implementations. If a factory or DAO deploys a replacement pool, integrators must manage the user-facing withdrawal and redeposit flow. This includes handling the virtual price reset, potential impermanent loss realization, and the coordination of gauge weight transfers. Automated migration scripts require thorough simulation against the new pool's boundary conditions.

Gauge and Reward Claiming Logic

New pool implementations may interact with the GaugeController and reward claiming mechanisms differently. The claim_rewards function signature or the method for accruing fees to veCRV holders can change. Yield aggregators and vaults must verify that their reward-claiming and compounding logic is compatible with the new pool's gauge interface to prevent stuck or unclaimable rewards.

Factory and Registry Resolution

The Curve AddressProvider and registry contracts are the canonical source for resolving pool addresses. A migration may involve a new factory or a new entry in the registry. Integrators relying on hardcoded addresses will fail to discover the active pool. Update your resolution logic to query the latest registry ID for the target coin pairing and verify the returned address against the expected new implementation.

LEGACY TO NEW AMM IMPLEMENTATION RISKS

Migration Risk Matrix

Evaluates the operational, integration, and security risks when migrating from legacy Curve pool interfaces (e.g., stableswap, cryptoswap) to newer optimized implementations like twocrypto and tricrypto-ng. Teams should verify each risk area against their specific integration architecture.

Risk Area	Failure Mode	Severity	Affected Actors	Mitigation
Function Signature Mismatch	State-mutating functions (e.g., exchange, add_liquidity) have changed parameter ordering or types, causing silent reverts or unexpected slippage	High	DeFi protocols, aggregators, arbitrage bots	Audit all contract interfaces against the new ABI; simulate transactions on a fork before mainnet migration
Event Signature Changes	Event topics and indexed parameters differ, breaking subgraph handlers, alerting systems, and off-chain data pipelines	High	Indexers, data teams, monitoring services	Update event filters and ABI definitions; replay historical event processing to validate data continuity
Oracle Behavior Divergence	New pool implementations may use different oracle algorithms (e.g., EMA vs. TWAP) or update frequencies, leading to stale or incorrect price feeds	Critical	Lending protocols, derivatives platforms, oracle consumers	Compare oracle output against legacy pool over a multi-day observation period; implement staleness checks specific to the new implementation
Virtual Price Calculation	The virtual price invariant may be computed differently, affecting share-value calculations used by vaults and yield aggregators	Medium	Yield aggregators, vault strategies, accounting systems	Verify virtual price logic against the new contract's get_virtual_price implementation; test share redemption flows end-to-end
Fee Accrual and Claiming Logic	Admin fee and LP fee accrual mechanisms may differ, causing fee misattribution or stuck rewards for integrators relying on legacy claiming patterns	Medium	Fee recipients, gauge operators, DAO multisigs	Review fee receiver configuration and claiming function signatures; simulate fee accrual over multiple epochs
Pool Parameter Boundaries	New implementations may enforce different bounds for A, gamma, or fee parameters, causing deployment reverts or suboptimal pool configurations	Medium	Pool deployers, factory operators, parameter governance	Validate parameter ranges against the new factory's deployment constraints; use simulation tools to test edge-case parameters
Gauge Compatibility	Legacy gauges may not be compatible with new pool implementations, disrupting CRV emissions and bribe reward flows	High	Liquidity providers, gauge weight voters, bribe protocols	Confirm gauge-pool compatibility with the Curve DAO; test reward claiming and compounding flows on testnet
Emergency Shutdown Handling	Pause and kill-switch mechanisms may differ, causing integrators to miss emergency states or fail to halt dependent operations	Critical	Downstream protocols, risk managers, keeper networks	Implement detection logic for new pause events; test automated circuit-breaker responses in a staging environment

LEGACY TO MODERN AMM MIGRATION

Integration Migration Checklist

A structured checklist for developers migrating integrations from legacy Curve pool interfaces (e.g., stableswap, cryptoswap) to newer optimized implementations like twocrypto and tricrypto-ng. Each item identifies a critical change area, explains the operational risk, and specifies the signal or artifact that confirms readiness.

What to check: Compare the function signatures for core operations—exchange, add_liquidity, remove_liquidity, remove_liquidity_one_coin—between the legacy and new pool implementations.

Why it matters: Newer pools like twocrypto and tricrypto-ng may introduce additional parameters (e.g., min_x for precise slippage control) or alter return value structures. Calling a legacy signature on a new pool will cause a revert or, worse, a silent failure if the fallback is mishandled.

Readiness signal: All integration tests pass against a mainnet-forked instance of the target new pool using the updated ABI. Transaction traces confirm the correct function selector is invoked.

resource-links

CURVE MIGRATION REFERENCES

Canonical Resources

Use these canonical Curve resources to verify ABI, event, factory, registry, and gauge assumptions before migrating from legacy pool integrations to newer AMM implementations such as twocrypto and tricrypto-ng.

Curve Documentation Hub

Start with the official Curve documentation to identify the pool family you are integrating: StableSwap, CryptoSwap, factory pools, metapools, twocrypto, tricrypto, or NG variants. Migration teams should not assume that legacy pool functions, return values, event names, or fee accounting behavior apply across newer implementations. Use the docs as the routing map, then confirm every production address against registries, factories, and verified source before changing swap, liquidity, quote, or indexing logic.

EXPLORE

Legacy StableSwap Contract Repository

Use the legacy Curve contract repository to document the baseline behavior your current integration depends on. Pay particular attention to functions such as exchange, add_liquidity, remove_liquidity, get_dy, balances, coins, and virtual price reads. Many older integrations were built around StableSwap assumptions that do not map cleanly to CryptoSwap or NG pool implementations. Before migrating, create an ABI compatibility matrix that separates read-only quoting, state-changing swaps, liquidity operations, and event indexing.

EXPLORE

CryptoSwap Contract Repository

Curve CryptoSwap contracts are the reference point for integrations moving beyond classic stable pools. Teams should inspect the verified implementation path for crypto pools rather than relying on interface similarity alone. Review parameter handling, oracle-related reads, price scale behavior, fee mechanics, and event emissions before using CryptoSwap pools as drop-in replacements for legacy pools. Aggregators, vaults, and lending protocols should test quote consistency and slippage boundaries under imbalanced pool states, not only under normal liquidity conditions.

EXPLORE

Curve GitHub Organization for NG and Factory Sources

For newer implementations such as twocrypto and tricrypto-ng, use the Curve GitHub organization to locate the current source repositories, factory templates, deployment scripts, and test suites. Do not hard-code assumptions from an unofficial ABI bundle or copied interface. Migration reviewers should match each target pool address to its verified source, compiler settings, and factory lineage, then run integration tests against forked mainnet or the relevant chain deployment. This is especially important where function names look familiar but internal accounting and events differ.

EXPLORE

Curve DAO and Gauge Contract References

If the migration touches yield aggregation, reward claiming, LP token staking, or gauge discovery, review the Curve DAO contract sources alongside the pool implementation. Pool migration can break downstream assumptions about LP token addresses, gauge controllers, reward distributors, and claim flows even when swap execution remains compatible. Indexers and vaults should validate gauge lookup logic, reward event parsing, and allowance handling for every migrated pool type before enabling deposits or automated compounding.

EXPLORE

Chains We Build On

Looking to build on a specific blockchain?

We build smart contracts, DeFi applications, wallets, tokenization platforms, and blockchain infrastructure across the major ecosystems teams choose today. That includes Ethereum, Arbitrum, Optimism, Polygon, Avalanche, Solana, Sui, Aptos, Hedera, Stellar, and NEAR, with support for additional EVM and non-EVM networks based on your product requirements.

Learn More

EVM ecosystems

Ethereum
Arbitrum
Optimism
Polygon
Avalanche
Cronos

Non-EVM ecosystems

Solana
Sui
Aptos
Hedera
Stellar
NEAR

Additional ecosystems

Polkadot
Cosmos
TON
Cardano
Algorand
Tempo

Also available for Base, appchains, custom EVM networks, and cross-chain product architecture.

MIGRATION FAQ

Frequently Asked Questions

Common questions from teams migrating integrations from legacy Curve pool interfaces to newer AMM implementations like twocrypto and tricrypto-ng.

The new implementations introduce distinct ABI changes that break backward compatibility:

State-mutating functions: exchange and exchange_underlying signatures may have updated parameter ordering or types. add_liquidity and remove_liquidity often require different min_amounts arrays or return values.
View functions: get_dy and calc_token_amount may return values in different precision or accept different indexing. balances and fee getters can change naming or return structures.
Event signatures: TokenExchange, AddLiquidity, and RemoveLiquidity events often include additional indexed parameters or change their topic hashes entirely.

Teams should diff the full ABI between the legacy and target pool versions, not rely on function-name matching alone. A mismatch in event signatures will silently break off-chain indexers and subgraphs.

Trusted by Industry Leaders

Delivering blockchain solutions for 5+ years.

We have partnered with 50+ leading DeFi protocols, NFT ecosystems, and fintech innovators to build secure, scalable, and capital-efficient blockchain products.

Selected Partners & Clients

“I've been working with Chainscore Labs for last 3+ years, they've consistently delivered with strong ownership across multiple projects. The team is reliable and detail-oriented.”

Lee Erswell

CEO, Telos Foundation

how to get started

How to get started?

If you're looking for blockchain integration, ChainScore Labs has 5+ years of experience helping teams build and integrate exchanges, wallets, smart contracts, tokenization solutions, and protocol-connected products, we can help you choose the right path, integrate securely, and get to production faster. Our team consists of experienced blockchain developers and architects who can help you with your blockchain integration needs.

Exploration & Strategy

Define your product goals and choose the right blockchain architecture for your use case.

Architecture & Design

Design the smart contracts, tokenomics, and security parameters of your system.

Development & Integration

Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.

Security & Launch

Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.

Learn More

Explore More Solutions

Discover our
blockchain development services.

We build production-grade blockchain solutions for top-tier projects across DeFi and Web3.

Book a Call

DeFi Protocol Development

End-to-end development of custom DeFi protocols including core smart contracts and system architecture.

DEX & Exchange Development

Building high-performance decentralized exchanges with optimized liquidity and advanced trading logic.

Lending & Borrowing Platforms

Scalable credit markets and money protocols built for production-grade liquidity and security.

Migrating from Legacy Pool Interfaces to New AMM Implementations

Why Migrate from Legacy Curve Pools?

Migration Snapshot

Interface and ABI Breaking Changes

Affected Systems and Integrators

Aggregators and DEX Routers