Title	[ZIP-7] Lens Chain inclusion on Elastic Network
Proposal Type	ZIP
One Sentence Summary:	Proposal for Lens Chain inclusion on Elastic Network.
Proposal Author	Lens Chain
Proposal Sponsor:	Cyfrin
Date Created:	24 February 2025
Version	v1
Summary of Action	Include Lens Chain in the Elastic Network
Link to contracts	https://github.com/matter-labs/era-contracts/pull/1287

[ZIP-7] Lens Chain inclusion on Elastic Network

Summary

Lens Chain is a high performance chain built leveraging ZKsync and Avail. The Lens Labs team and Matter Labs have collaborated in the creation of the chain, and the migration of user profiles, followers and publications from Lens V2 on Polygon to Lens Chain.

Since the state including the migration data will be applied on genesis, we need to request the inclusion of the chain on the Elastic Network.

Abstract

The deployment of Lens Chain, with its significant state changes at genesis, requires approval through ZKsync’s governance system. This critical step ensures transparency and community validation of the migration process.

The implementation of this governance process, combined with our active data synchronization, represents a methodical approach to launching Lens Chain while maintaining the trust and engagement of our user community.

As far as we are aware, this is a first-time occurrence in the Elastic Network ecosystem of applying such large genesis state.

Motivation

Lens v2 has built a thriving community with over 600,000 profiles and unique handles. The protocol maintains strong engagement with 45,000 weekly active users who have collectively created 31 million publications.

When Lens Chain launches, all existing user data will be automatically deployed at genesis. This means users can immediately start using Lens Chain at launch without taking any migration steps — their profiles, connections, and content will be ready and waiting for them.

This seamless migration process, developed in partnership with Matter Labs, represents a groundbreaking technical achievement in both blockchain and ZK technology. It is the first time a blockchain ecosystem has executed such a comprehensive automated migration at genesis.

Specification

We will be applying a genesis state on block 0 which includes:

• Profiles - 645_408
• Profile Managers - 588_371
• Handles - 639_296
• Apps - 359
• Unlinked Handles - 2_421
• Follows - 27_944_873
• Root Posts - 11_756_025
• Comments Depth 1 - 3_613_497
• Comments Depth 2 - 563_735
• Comments Depth 3 - 101_472
• Comments Depth 4 - 36_221
• Quotes - 308_217
• Quotes Comments - 153_784

Mirrors will not be migrated and any comments greater depth then 4 will not be migrated either.

All Momoka publications will be migrated if they fall in the criteria above.

While the vote is happening we will be syncing Lens v2 Polygon data onto Lens v3 on Lens Chain.

Contracts migration specification

In order to ensure the security of the migration process, it will consist of the following stages:

• Preparation before the vote. During this stage, the governance over the network will be given to the ProtocolUpgradeHandler from the ZIP5 upgrade. To be more concrete, the ownership will be transferred to the following contract. An intermediate owner for contracts is required since most of our contracts are Ownable2Step, so the Token Assembly will accept the ownership later during the vote. The deployed chain will have no bridging initialized and it will be expected to have 0 balances over all tokens. This is needed to ensure that no assets will have to be migrated.
• During the vote. The chain will exist on a separate ecosystem, while the fact that the ownership has been transferred in the previous step will ensure that this temporary ecosystem is fully compliant with the main one (all state transitions are valid and verified by the same zero-knowledge circuits as the main ecosystem, etc).
• The network inclusion process. The ProtocolUpgradeHandler will execute the following operations:
  • Accept ownership over the old ecosystem.
  • Register it in the current ecosystem via calling the registerAlreadyDeployedHyperchain function in the state transition manager.
  • Register the chain in the Bridgehub via the createNewChain method.
  • To ensure that the storage of the chain is fully compliant with the storage of the ZK chains that were registered via the standard process, the executeUpgrade function will be called upon the chain. It will use the Migrator contract, the main job of which would be to set the correct ecosystem contracts’ addresses.

Relation to ZIP-6

The upgrade is expected to land on the mainnet after ZIP-6 has been executed on L1 (and so the v26 upgrade is available for chains), but before the second stage of the upgrade is executed (and so operating on the v26 version will not be mandatory yet).

This means that the chain will upgrade to v26 in the same manner as any other ZK chain. But it also means that the parameters for the Migrator contract need to be careful and contain the address of the ValidatorTimelock that is equal to the one from v25 and not v26.

Rationale

We aim to provide a seamless transition to Lens Chain while preserving users’ existing Lens profiles, including their social connections and content history.

This ensures users can use Lens Chain and Lens V3 without any manual effort while maintaining their established social presence.

Backwards Compatibility

NA - this is a request to include Lens Chain in the Elastic Network and there are no potential breaking changes.

Security Considerations

The technical implementation has been done in collaboration with the Matter Labs team, and security reviews have been performed on their end and on our end.

Alongside all state validation has been confirmed as correct, with verification tasks run and other forms of validation.

Other Information

• A migration blog will go into more in-depth detail of how we migrated the state - stay tuned
• Lens Website - lens.xyz
• Developer Docs - https://dev-preview.lens.xyz/docs/chain/overview