Moving an Actively Validated Service (AVS) from testnet to mainnet on EigenLayer is the highest-stakes operational transition a protocol team will execute. The migration involves more than deploying a new set of smart contracts; it requires synchronizing operator recruitment, finalizing security parameters, verifying slashing conditions, and ensuring that monitoring infrastructure is production-grade. A misconfiguration during this phase can lead to operator downtime, slashing events, or a loss of confidence from restakers whose delegated stake underpins the AVS's economic security.
Protocols
AVS Onboarding Testnet-to-Mainnet Migration Checklist
A production-readiness checklist for AVS teams moving from testnet to mainnet. Covers contract verification, operator recruitment, monitoring setup, and security audit finalization. Reduces the risk of misconfiguration during critical launches.
introduction
PRODUCTION READINESS
Introduction
A structured checklist for AVS teams transitioning from testnet validation to mainnet deployment on EigenLayer.
This checklist is designed to reduce the risk of critical launch failures by enforcing a gated, verifiable process. It covers the finalization of contract audits and formal verification, the operational readiness of the AVS's operator set, the configuration of slashing and dispute windows, and the deployment of a monitoring stack capable of detecting anomalies before they become incidents. Each item is a gate that should be demonstrably satisfied before the AVS begins accepting mainnet restaked assets.
For AVS development teams, security councils, and the institutional operators who will run the service, this checklist serves as a shared source of truth for launch readiness. Chainscore Labs can provide independent review of the migration plan, validate that slashing conditions match the intended economic model, and conduct a pre-launch assessment of the AVS's integration with EigenLayer core contracts to identify risks that internal testing may miss.
TESTNET-TO-MAINNET PRODUCTION READINESS
Migration Quick Facts
A quick-reference table for AVS teams to assess the operational, contractual, and security deltas between testnet validation and mainnet launch.
| Area | What changes | Who is affected | Action |
|---|---|---|---|
Contract Verification | Mainnet deployments require verified source code on Etherscan; testnet often uses unverified or mutable proxies. | AVS developers, security auditors, integrators | Verify all mainnet contracts and confirm proxy admin ownership before operator opt-in. |
Operator Recruitment | Testnet operators are often self-served via faucets; mainnet requires real stake delegation and economic incentives. | AVS teams, institutional validators, delegators | Finalize operator commission rates and ensure a sufficient quorum of bonded operators exists before launch. |
Slashing Conditions | Slashing logic is often simulated or disabled on testnet; mainnet introduces real cryptoeconomic penalties. | Node operators, AVS security councils, stakers | Audit slashing contracts and ensure operators have monitoring and alerting for slashing events. |
Monitoring and Alerting | Testnet monitoring is often best-effort; mainnet requires production-grade uptime and signing-performance alerts. | SRE teams, node operators, AVS developers | Deploy a sidecar or indexer to track operator set health and configure pager alerts for missed tasks. |
Key Management | Testnet keys are often hot and disposable; mainnet requires secure signer architectures to prevent slashing. | Institutional validators, custody providers, operators | Implement hot/cold key separation and proxy signer setups; never reuse testnet keys on mainnet. |
Fee and Payment Configuration | Testnet payment tokens have no value; mainnet requires correct fee parameters and reward distribution logic. | AVS developers, operators, delegators | Validate payment split logic and ensure fee recipient addresses are correctly configured on mainnet. |
Security Audit Finalization | Testnet allows rapid iteration; mainnet launch should be gated on a completed audit with all findings resolved. | AVS teams, security auditors, governance councils | Publish audit reports and confirm no critical or high-severity issues remain open before enabling slashing. |
technical-context
PRODUCTION READINESS
The Migration Surface: What Must Be Verified
A systematic breakdown of the technical artifacts, on-chain state, and operational configurations that must be validated before an AVS activates on EigenLayer mainnet.
Migrating an Actively Validated Service (AVS) from testnet to EigenLayer mainnet is not a simple redeployment. It is a full-scope verification exercise across immutable contracts, operator relationships, and real economic stakes. The migration surface includes every component that, if misconfigured, can lead to a slashing event, a liveness failure, or a permanent loss of protocol credibility. Teams must treat the mainnet launch as a security-critical state transition, not a feature release.
The verification checklist begins with contract immutability and bytecode equivalence. The mainnet deployment must exactly match the audited testnet bytecode, with no last-minute changes to slashing conditions, fee parameters, or pauser roles. Next, operator registration state must be validated: AVS teams need to confirm that their intended operator set has successfully opted in on mainnet, that their delegation stakes are correctly attributed, and that any quorum thresholds defined in the middleware contracts are met. A mismatch between expected and actual operator weight can leave the AVS without sufficient cryptoeconomic security at launch.
Beyond on-chain state, the off-chain operational surface is equally critical. This includes verifying that the AVS's production monitoring and alerting systems are ingesting mainnet contract events—such as OperatorAVSRegistrationStatusUpdated and slashing-related events—and that operator signer configurations are correctly pointing to mainnet RPC endpoints. AVS teams should also validate their incident response playbooks against mainnet parameters, particularly the dispute window and slashing escape procedures. A testnet where slashing has no economic consequence cannot surface the operational gaps that real value at risk will expose.
Chainscore Labs supports AVS teams through this migration surface with structured readiness reviews that examine contract verification, operator set validation, monitoring coverage, and incident response planning. For teams approaching mainnet launch, a pre-activation assessment can identify the single point of failure that testnet simulations missed.
MIGRATION CHECKLIST
Affected Actors and Responsibilities
AVS Development Team
The AVS team owns the entire migration lifecycle and is ultimately responsible for a safe mainnet launch.
Pre-Migration Responsibilities:
- Finalize all smart contract audits and resolve every finding, not just criticals.
- Verify the bytecode of all mainnet contracts on Etherscan or a compatible explorer.
- Conduct a full operational security review of deployer keys and multisig configurations.
- Publish a complete, versioned technical specification for operators.
During Migration:
- Coordinate the registration of a sufficient and decentralized operator set before enabling slashing.
- Execute a phased rollout: bootstrap operators, enable soft slashing, then harden parameters.
- Monitor the initial reward distribution cycle to ensure correctness.
Post-Migration:
- Establish a clear communication channel (e.g., a dedicated Discord or Telegram) for operators.
- Implement a bug bounty program with defined scope and rewards.
- Schedule regular security council drills for emergency pause and upgrade scenarios.
implementation-impact
PRODUCTION READINESS GATES
Phase-Gated Migration Checklist
A phased checklist for AVS teams moving from testnet to mainnet, covering contract verification, operator recruitment, monitoring setup, and security audit finalization to reduce the risk of misconfiguration during critical launches.
01
Phase 1: Contract Verification and Audit Finalization
Complete all security audits and formally verify AVS middleware contracts on mainnet-equivalent testnets. Ensure bytecode matches the audited commit hash and that all privileged roles (pausers, upgrade proxies) are configured with production multi-sigs. Any unresolved critical or high-severity findings must be remediated and re-reviewed before proceeding to operator recruitment. Teams should publish verification reports for operator due diligence.
02
Phase 2: Operator Recruitment and Opt-In Validation
Distribute operator onboarding packages including hardware requirements, slashing condition documentation, and expected reward ranges. Validate that recruited operators can successfully opt-in on testnet and that their signing infrastructure correctly responds to AVS task events. Confirm operator set diversity targets are met to avoid single points of failure. Use the Holesky testnet to simulate mainnet registration flows and delegation mechanics.
03
Phase 3: Monitoring and Alerting Deployment
Deploy production monitoring for all AVS-specific slashing conditions, operator liveness, and task performance metrics. Configure alerting thresholds for signing latency, missed tasks, and anomalous operator behavior before mainnet activation. Integrate with the EigenLayer Sidecar and relevant subgraphs to track operator share changes and delegation flows. Runbooks for slashing disputes and emergency pauses must be tested and accessible to all security council members.
04
Phase 4: Fee Model and Reward Distribution Testing
Finalize on-chain fee parameters and validate reward distribution logic end-to-end on testnet. Confirm that Merkle tree generation, reward claiming, and fee recipient configuration work correctly for all operator profiles. Test edge cases including partial withdrawals, operator churn, and reward accrual during slashing events. Operators must verify that their cost models remain viable under mainnet gas conditions.
05
Phase 5: Mainnet Activation and Post-Launch Surveillance
Execute a staged mainnet activation starting with a restricted operator set and gradually expanding. Monitor the first reward cycle, slashing condition triggers, and operator performance metrics in real-time. Maintain a war room with security council members and core developers for the initial 72-hour window. Document any deviations from expected behavior for post-launch review and operator communication.
06
Phase 6: Incident Response and Slashing Remediation Readiness
Confirm that the AVS security council can execute emergency pauses and that operators have tested slashing dispute procedures within the challenge window. Pre-draft communication templates for slashing events, downtime incidents, and contract migrations. Establish a clear escalation path for operators to report anomalous behavior. Chainscore Labs can assist with incident response planning and postmortem analysis for AVS teams.
TESTNET-TO-MAINNET MIGRATION RISKS
Migration Risk Matrix
Identifies key failure modes and affected parties when an AVS transitions from testnet to mainnet, with concrete actions to mitigate operational and economic risks.
| Risk Area | Failure Mode | Affected Parties | Mitigation Action |
|---|---|---|---|
Contract Verification | Mainnet deployment does not match the audited testnet bytecode, introducing backdoors or unintended logic. | AVS developers, operators, delegators | Verify deployed mainnet contract bytecode against the canonical audit commit hash on Etherscan. |
Operator Recruitment | Insufficient or misconfigured operator set leads to liveness failures and inability to meet service commitments. | AVS teams, operators, end-users | Run a coordinated dress rehearsal on Holesky testnet with all recruited operators before mainnet opt-in. |
Slashing Parameter Misconfiguration | Incorrect slashing thresholds or unbonding periods cause unjustified stake seizure or make the AVS unenforceable. | Operators, delegators, AVS security council | Validate all slashing parameters against the audited specification and simulate a slashing event on testnet. |
Monitoring Gap | Mainnet alerting is not configured, causing the team to miss a liveness fault or slashing event until after the dispute window closes. | AVS security council, operators | Deploy and verify monitoring for all critical on-chain events (e.g., OperatorAVSRegistrationStatusUpdated) before mainnet launch. |
Key Management Failure | Operator or AVS admin keys are generated or stored insecurely for mainnet, leading to key compromise and slashing. | Operators, AVS governance, custody providers | Enforce a strict key ceremony using secure enclaves or HSMs, with hot/cold key separation distinct from testnet keys. |
Fee Model Mismatch | Mainnet gas costs and fee parameters make operation unprofitable, causing operators to churn and destabilize the service. | Operators, AVS developers | Model mainnet gas costs against the proposed fee structure and confirm operator profitability with a representative cost analysis. |
Upgrade Proxy Misconfiguration | Proxy admin or upgrade timelock is set incorrectly, allowing unauthorized upgrades or permanently bricking the AVS. | AVS developers, security council, users | Verify proxy admin ownership and timelock duration on mainnet, and test a full upgrade lifecycle on a production-like testnet fork. |
TESTNET-TO-MAINNET MIGRATION
Pre-Launch Verification Checklist
A production-readiness checklist for AVS teams moving from testnet to mainnet. Each item defines a critical verification step, the operational risk it mitigates, and the specific signal or artifact that confirms readiness before mainnet activation.
What to check: Confirm that all mainnet-deployed AVS contracts (ServiceManager, registry entries, custom logic) are verified on Etherscan and that proxy admin ownership is correctly configured. Compare the deployed bytecode hash against the audited commit hash from the testnet deployment.
Why it matters: Unverified or mismatched contracts are the most common cause of mainnet launch failures. A bytecode mismatch indicates either an incorrect deployment or an unreviewed hotfix that bypassed the security audit.
Readiness signal: The Etherscan verification status shows an exact match, and a diff between the testnet and mainnet deployment artifacts produces zero discrepancies in the core logic contracts. The proxy admin is held by the intended multi-sig or governance contract, not an EOA.
resource-links
OFFICIAL REFERENCES
Canonical Resources
Use these resources as the starting point for AVS testnet-to-mainnet migration checks. Teams should verify contract addresses, release tags, operator workflows, and network-specific behavior against canonical EigenLayer sources before production launch.
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.
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.
AVS MAINNET MIGRATION FAQ
Frequently Asked Questions
Common operational and security questions from AVS teams finalizing their testnet-to-mainnet migration. Use these answers to validate your launch readiness and avoid misconfiguration during critical deployments.
Incorrect contract addresses and chain IDs in operator-facing configuration.
AVS teams often hardcode Holesky testnet addresses for EigenLayer core contracts (DelegationManager, AVSDirectory, RewardsCoordinator) or use testnet chain IDs in their operator CLI instructions.
What to check:
- Verify all EigenLayer core contract addresses match the canonical EigenLayer Mainnet Deployment List.
- Confirm your AVS middleware contracts are deployed on Ethereum mainnet (chain ID 1) and verified on Etherscan.
- Audit any off-chain operator software for hardcoded testnet RPC endpoints or contract addresses.
Why it matters: Operators following testnet instructions on mainnet will fail to register, submit tasks, or claim rewards. In slashing-enabled AVSs, this could lead to downtime penalties.
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.”
L
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.
01
Exploration & Strategy
Define your product goals and choose the right blockchain architecture for your use case.
02
Architecture & Design
Design the smart contracts, tokenomics, and security parameters of your system.
03
Development & Integration
Build and integrate with wallets, oracles, and front-end dApps for a seamless experience.
04
Security & Launch
Comprehensive audits followed by a risk-managed mainnet deployment to protect your users.
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
Start a build
Need a blockchain engineering team?
Send the project context and we will respond with next steps, scope questions, and a practical path to delivery.