Production Guidelines

When launching an AVS on mainnet, it is essential to ensure it is fully prepared for production. This structured checklist covers key deployment steps, including multisig governance, EigenLayer registration, and infrastructure best practices, to ensure a seamless deployment and operation.

This guide references the Docker Compose Production YML in the Simple Price Oracle Repository.

---

1. Deployment & Registration

AVS Contracts Deployment

• AVS MultiSig Governance: Use a Multisig Account (SAFE) --avs-governance-multisig-owner to designate the AVS owner when deploying the contracts.

• AVS Hooks: Deploy AVSLogic, AVSGovernance or FeeCalculator Hook contracts if applicable.

EigenLayer Registration

• Register AVS with Eigen Layer

---

2. Operator Setup

Initial Registration Sequence

Please make sure to follow this order when registering the operator. This specific order ensures correct Voting Power sync. Depositing funds after AVS registration requires manual voting power syncing.

• Register Operator to Eigen Layer

• Deposit funds to the strategy: The operator must deposit funds into their chosen Eigen Layer strategy before registering with the AVS.

• Register operator to the AVS: This step also syncs the voting power internally

  • Make sure to use different Consensus Key

  • Make sure to set Rewards Receiver Address (Not applicable when using Rewards v2)

  • Add --l1-chain mainnet flag

Voting Power

• Set the maximum voting power to to cap voting power per operator and prevent any single operator from gaining disproportionate influence over consensus.

• Configure the minimum voting power if required.

---

3. Docker configuration

Updating Operator Commands

• Update the Operator commands in the Docker file to include production chains using --l1-chain <> and --l2-chain <>.

• If using custom messages, enable the --json-rpc.custom-message-enabled flag in the Aggregator command.

Network and Internal Task Verification

• Ensure that Operators holding at least 2/3 of total voting power are connected to the network and running both the Attester node and Validation Service.

• Verify that Internal Tasks are running by checking transactions in the attestation center contract (Look for task definition IDs 10001, 10002). For example 10001, 10002 transactions.

---

4. Task

Task Definitions

• Create Task Definitions on production chains (If applicable)

• Ensure Task definition specific logic is implemented within the Validation Service.

---

5. Rewards

Configuration

• Staking Contracts: Configure the available staking strategies within the AVS.

• Staking Contract Multipliers: Determine and set multipliers to incentivize desired staking behaviors.

• Deposit Rewards: Deposit the reward tokens into the AVS Treasury for distribution.

Distribution

• Unpause the payment flow to enable rewards distribution. By default, its paused.

• Establish a consistent reward distribution schedule based on the rewards distribution mechanism.

---

6. Infrastructure Setup

Chain Config

• Configure chain Ids in the .env file

L1_CHAIN=1
L2_CHAIN=8453 // Set the L2 chain id

RPC Endpoints

• Use paid, highly reliable RPCs for L1/L2 chains to avoid any errors. Configure in .env

L1_RPC="https://..." 
L2_RPC="https://..."

Logging

• Configure comprehensive logging (File-based or Elastic Search) to capture relevant events and debug logs.

Persistent Storage

• Configure persistent storage for critical data to prevent data loss in case of restarts/ failures and avoid reconnection issues.

Metrics and Monitoring

• Set up robust metrics and monitoring systems.

Layerzero Fee

• The MessageHandler contracts manage LayerZero fees. AVS developers are responsible for funding the MessageHandler contracts (deployed during AVS setup) with sufficient funds to cover cross-chain communication costs. Regularly monitor the balance and replenish as needed.

Verify Network Setup

• For Docker ensure that the required ports are open and properly mapped.

• For ISP-hosted nodes, confirm that the port is open and accessible from outside. (Configuration of security groups, firewall rules, etc...)

• For DNS-based configurations, ensure dnsaddr is correctly set and publicly resolvable.

---

7. Operator Configuration

Validate Private key

• Ensure that the private key provided in .env or via CLI option is a valid Consensus Key.

• If the key was not set correctly or needs to be changed, update it using BLS Update.

Check ANNOUNCED_ADDRESSES

• Ensure the addresses specified in ANNOUNCED_ADDRESSES are publicly accessible.

• If using a domain name service (DNS), Its recommended to explicitly add /ip4/ multiaddresses alongside /dnsaddr/ to ensure compatibility across different discovery mechanisms.

---

8. External Operator Onboarding

Onboarding Documentation

• Create comprehensive onboarding documentation for operators, covering all aspects of registration, and best practices. For reference check this.

• Thoroughly test the documentation with new operators to identify any gaps or areas for improvement.

---

Security Guidelines

AVS Governance Multisig

• It is strongly recommended to use a multisig account (SAFE) when deploying AVS contracts to enhance security.

Separation of Controller and Signing Keys for Operators

• It is highly advised to use a different key for signing purposes. By utilizing a separate signing key, the Operator's private key (controller key) does not need to be stored in the .env file, significantly reducing the risk of hacks.

• Using the same key for both functions could expose Operator funds to potential security threats.

✅ By following this checklist, you ensure a secure and efficient AVS deployment in production.