[ZIP-7] Lens Chain inclusion on Elastic Network

Protocol Development Archived ZIPs
1
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 TBC

[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.

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 - Lens Chain | Lens Documentation
12 Likes
2

State correctness checks and bytecode hashes for Lens Chain

  1. Retrieve the bytecode hashes from the dump used for custom genesis calculation: select bytecode_hash from factory_deps.
  2. For Era contracts, refer to GitHub - matter-labs/era-contracts at 46d75088e7ddb534101874c3ec15b877da1cb417.
  3. To compile system-contracts with Foundry, run the following command: yarn preprocess:system-contracts && forge build --zksync && yarn preprocess:bootloader && forge build --zksync.
  4. To compile l2-contracts with foundry: forge build --zksync.
  5. For Lens contracts, refer to GitHub - lens-protocol/lens-v3 at migration-genesis-branch.
  6. Compile Lens contracts with hardhat by running: yarn compile.
  7. Utilize the provided Python3 script to compute the hashes from artifact files.
import sys
import json
import hashlib
import binascii

def main():
    artifact = json.loads(open(sys.argv[1]).read())
    bytecode = artifact['bytecode']
    try:
        bytecode = bytecode['object']
    except:
        bytecode = bytecode[2:]
    bytecode = bytearray.fromhex(bytecode)
    s256 = hashlib.sha256()
    s256.update(bytecode)
    hash = bytearray(s256.digest())
    hash[0] = 1
    hash[1] = 0
    hash[2:4] = int(len(bytecode)/32).to_bytes(2)

    print(
        "Bytecode hash is '{}'".format(binascii.hexlify(hash).decode())
    )

if __name__ == "__main__":
   main()
  1. For hardhat-compiled code refer to artifacts from the artifacts-zk folder; for foundry-compiled code refer to artifacts from the zkout folder.
  2. Compare the computed hashes with the hashes from the dump (step 1); the result should resemble the one provided below.

0x010008e15394cd83a8d463d61e00b4361afbc27c932b07a9d2100861b7d05e78 → Bootloader proved_batch (foundry)
0x01000523eadd3061f8e701acda503defb7ac3734ae3371e4daf7494651d8b523 → system-contracts/DefaultAccount (foundry)
0x010001a534cf6fb51adc913f018346157c628e1e3dce73d821193b9c677260e0 → system-contracts/SystemContext (foundry)
0x01000013344fb47b40c38eddb93142d381a1716cdb99a76aca64b31a3f83c7e5 → system-contracts/Ecrecover (foundry)
0x01000f1df321417e6094bb72944163e3e3f6073c4a08723bcd75851a4af87cd7 → system-contracts/EcPairing (foundry)
0x010000d37eee65e48f78b3a13cb1275f4cfd544b89c9b37cd9639c4f2b10ef24 → system-contracts/NonceHolder (foundry)
0x010000172dd8b6099b59bc284647851340b609bcb9514fa1fad85aa64dedbbc1 → system-contracts/SHA256 (foundry)
0x010000859ed3467fe4da584e9d993f04d8df6c1d1e078db908cbaac1b6b9d84a → system-contracts/EcAdd (foundry)
0x0100076b02c0e679c0e83d070ed7f6ff5532c930b1b7748fb0566f1b36bfb79a → system-contracts/BootloaderUtilities (foundry)
0x01000069e50493ee2ad3fea7b10ef3a53773e26d87e32e8fdbfcfe0de926c914 → system-contracts/KnownCodesStorage (foundry)
0x01000035f23ba7d91b3191912012168ac3a69fcb8726f54d19559faec798494b → system-contracts/ImmutableSimulator (foundry)
0x010002774db547957ecefc324ef21a0924c035e4b4a18635f32e7f6f0cced998 → system-contracts/L1Messenger (foundry)
0x0100000f40b6e168450d59aaf4283e70c5a26deb4b396a49e3a014b3f7433267 → system-contracts/P256Verify (foundry)
0x010000230498c3128f0f86bd5cebbce502948ae06b526559d7ed432312ea5673 → system-contracts/CodeOracle (foundry)
0x0100005b80fea460f866f332e63e156cc7d530e368a0ccec3deaf2f0f5064cea → system-contracts/MsgValueSimulator (foundry)
0x010000f944d515550036966157f647ed03ec2077f85ec1094ef83773587d3877 → system-contracts/L2BaseToken (foundry)
0x010000175f50060e9307a151fac7759407acd83eff7b387dce4e24814a09cb9f → system-contracts/EventWriter (foundry)
0x01000059c04f4ecc1ed23e31ab67883d9dff1361999d3c81e430c0f483eb60d2 → system-contracts/AccountCodeStorage (foundry)
0x010001496b20d289682ad11151a3cd36e8a923c85bcc58de7c3cfd5bd25f897f → system-contracts/Compressor (foundry)
0x01000007b277e41e5ab639f2b48118e5a319c4db0b0a340c6d71446ffd2ce2cc → system-contracts/EmptyContract (foundry)
0x010000410c5303a6159d33ae6891b5132f6b1bc0381f981b5077188b67a42c1f → system-contracts/PubdataChunkPublisher (foundry)
0x0100004989ca64648afadd5c4822e8118a5c0b11848196d69ad9ec53e4e51a22 → system-contracts/ComplexUpgrader (foundry)
0x01000455d9b8aaaf10834a1668dd9fea9f9649010f4f73f43e848a6e3bca7a42 → system-contracts/ContractDeployer (foundry)
0x0100021d3a3ef108715c685dbb3202c3ea9b12dd25dd5ce52263438403bf6e6c → lens-v3/contracts/migration/factories/MigrationNamespaceFactory.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x0100000f9c77ddf3e1baef9df0c1a497858d24b0ea1cf76f04c9fe3f8b323098 → system-contracts/Keccak256 (foundry)
0x01000041f6bedd74e707fbdbe34d8296acf0222ba645924fdf02531bc2122eb0 → system-contracts/Create2Factory (foundry)
0x010000bb45be5491bfa96eac012e6edbcd393863c753de44e1ddf364e490d2e5 → system-contracts/EcMul (foundry)
0x0100014b59e19fe847eb5ddcf4374481fe69c279952e3d1eff5dfb190861d763 → l2-contracts/TransparentUpgradeableProxy (foundry)
0x01000205c3ad9e399c8db6e2bc08e78296592503aaccbd1c25cbf6ba0cb78733 → l2-contracts/Multicall3 (foundry)
0x010005152f803759332c0f3ea192b621fc557a20ede973e02feab92c3c30dff5 → l2-contracts/ConsensusRegistry (foundry)
0x010001d72f0e77512239ce8a27223caadf1a4da805a96abb02f07d753b57c043 → @openzeppelin
0x01000109c8a507bf58b44e3f00317f386957d415b6600b6af6337ff9252a431f → l2-contracts/BeaconProxy (foundry)
0x0100001d651f9e236c91c296396485c901f0b58d8bfa5462dbe305a15df92659 → l2-contracts/TimestampAsserter (foundry)
0x010000671cd3bc8e9004e810149e420caf34b8f2b62fcc233c56fa5c46b1be7f → l2-contracts/UpgradeableBeacon (foundry)
0x0100045502b6893bb5ae674cb9423766b812ed2a227f766305b82768a270584b → l2-contracts/L2StandardERC20 (foundry)
0x0100005b49f6f7bd0111ba27da7c6e967bce9e3810190d65f96ba66810140c7f → l2-contracts/ForceDeployUpgrader (foundry)
0x010001f55b911983696bf1762e5b07ebd1a6f6883deb53908e07b953691da91a → Multicall (hardhat)
0x010000e9235de2012d8a55635778a6e713af014ea1b8ec9cf7cd870f1b92bdeb → lens-v3/contracts/core/upgradeability/Lock.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x0100087d952acc25731b5ee48801bd755f87dd048b35250303869cf315f16f18 → lens-v3/contracts/migration/primitives/MigrationApp.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x010004db8e49fd5d3dc642be50109df2967d0735dc736681ce489f72aa63df5b → lens-v3/contracts/migration/primitives/MigrationAccount.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x01001101860f2977401f15cdb5294b245001d8574da437a1656644723bcfd62c → lens-v3/contracts/migration/primitives/MigrationFeed.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x01000a3ffabc8a13ec60392d39f431921d7c50b70728793591e7f1b53d9d41ce → lens-v3/contracts/migration/primitives/MigrationGraph.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x010009f3f41874b9ccb9f42a278b1609d0fa8448c01d7eff0c9b4eab39a14575 → lens-v3/contracts/core/primitives/group/Group.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x010015c35d64ec8f7f4b485f5deb3e4e32eb4b254dcfbddf90832b2e54d81ad1 → lens-v3/contracts/migration/primitives/MigrationNamespace.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x010000fb799cf0ba852b1caf74860f7c7178e36ebbe76d8858c3affd27a6e4bc → lens-v3/contracts/core/upgradeability/Beacon.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x010001fdc0b1a5dd88130f5aaaf77913217b32237238041b2df75a32983c3aeb → lens-v3/contracts/extensions/access/OwnerAdminOnlyAccessControl.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x01000105f54acff7f6b90a3481278642dbed2b5ee81d6a96ab04cf40398e229a → lens-v3/contracts/migration/factories/MigrationAccessControlFactory.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x0100013707b8f7501be6433983f2351501bf5403d0bf6192a6aa30b041e18755 → @openzeppelin/contracts/proxy/transparent/TransparentUpgradeableProxy.sol (hardhat)
0x010000cb48299a339f34bc81020e00d215ee3028091a3576201f0ba8a4b10454 → lens-v3/contracts/core/upgradeability/ProxyAdmin.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x01000155f66491daa99fa97065b64ee60faa4153f0b1a805839a1922c55aa130 → lens-v3/contracts/core/upgradeability/BeaconProxy.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x010001a152c0f3b5ac75d7f1acf42d53f7819dcd429de43ff11b3fede4a5d7a1 → lens-v3/contracts/migration/factories/MigrationAccountFactory.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x0100018965ff7d58360953a45a82c9725b92ddf09c9eb077b7f6675a5d90545d → lens-v3/contracts/migration/factories/MigrationAppFactory.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x010001cf176e5c715e9e95870df97b2eaca6e33b635671ded7371bc4b918d0f4 → lens-v3/contracts/migration/factories/MigrationGraphFactory.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x010001e3819e2a31f15ac488f49f20335e8df95fb5164ef22470e9471a0171cf → lens-v3/contracts/extensions/factories/GroupFactory.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x01000019c82ee9e6f1efd013cf739c089597033d7e0fc0a546a69c1d17497ae6 → lens-v3/contracts/extensions/access/PermissionlessAccessControl.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x010001cf2358835fe4dae971d2f1e9ac461e1de77d0eaf5d55febb8c7802243e → lens-v3/contracts/migration/factories/MigrationFeedFactory.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x01000421b7bc1918cf99fef171c01c2dac680e96c04f818ce85d0e6bd330f9b8 → lens-v3/contracts/core/primitives/namespace/LensUsernameTokenURIProvider.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)
0x0100098165fc6beb40e97b5e35a2d7d9974ff89b2348bfd4adbbc29a7ee1a1e6 → lens-v3/contracts/migration/factories/MigrationLensFactory.sol at migration-genesis-branch · lens-protocol/lens-v3 · GitHub (hardhat)

7 Likes
3

A small note for the outside observers: governance vote for the Lens chain inclusion is needed only because it will migrate with a custom genesis state for the greater efficiency of migrating the users’ data.

Adding chains that do not have a custom genesis state does not require a special governance vote.

10 Likes
4

Sound incredibly promising… Gooo Elastic Chain

1 Like
5

Welcome to Elastic Network. :raised_hands:

The ZIP draft is very well-structured and clear. I am in favor of supporting custom migration so it is more effective.

I do have a more general question and request. Once Lens Chain is live, what are your expectations from ZK Nation (DAO)? What kind of support would make the most sense for you? Grants for builders? Onboarding new users? Tech support?

In the long run, it would also make sense for you (or anyone from Avara) to attend our governance calls. Your feedback and insight would benefit us a lot in understanding the builders’ side of things.

2 Likes
6

As the creator and maintainer of Hey.xyz, a platform running on Lens Protocol, I fully support the proposal to migrate from Polygon to Lens Chain. A dedicated chain for Lens ensures better scalability, performance, and alignment with the ecosystem’s long-term vision. Excited to see this evolution!

2 Likes
7

Voting yes to this. (these are extra words added to meet the minimum character limit for posts)

8

This proposal has been submitted onchain as ZIP-7.

Voting will start in 7 days.
View the proposal on Tally.

1 Like
9

Welcome! Nice and clear proposal. Finally making this official and going live soon. Very glad to see a social-first (and successful) project join the Elastic Chains. Fully supportive of this proposal.

2 Likes
10

First of all, we’re super happy to see this proposal and to be one step closer to having Lens as an elastic chain!

Given the complexity of this migration, something never experienced before by an elastic chain, we have a few questions we’d like to drop here. Our first questions are meant to provide more context on the implications of this migration:

  • If we end up in an adverse migration scenario, how could this impact ZKsync?

  • Could you also break down the trade-offs of this migration?

Then, our next questions are more about the security measures during the migration process:

  • Will Matter Labs be providing support throughout the migration?

  • Will any third-party security firms be involved during the migration?

To wrap up, @theshelb, would it be possible to invite someone from Matter Labs or Lens, maybe during next week’s governance call post-Denver, to go over these points? It would definitely help bring more clarity to everyone about this complex but exciting update!

2 Likes
11

As an early Lens and t2.world user I am more than excited for this. Lens Chain as an app-chain makes perfect sense, keeping gas fees low and allowing Lens to tailor Chain characteristics to it’s specific use case.

12

Very excited about this, I think it’s a huge step not only for Lens, but also for ZK Nation and the whole Elastic chains network. I’m curious to see how it will perform and also what kind of integrations (if any) may be possible with other chains and dApps within the Elastic ecosystem.

13

The voting period for ZIP-7 is open. Vote on Tally HERE.

1 Like
14

This comment is posted on behalf of the Treasure Delegate Council (TDC).

Welcome! The TDC is excited to see Lens Chain being one step closer to joining the ZKsync ecosystem! The approach you’re taking—seamlessly including all existing Lens V2 data in the genesis state—is both innovative and user-friendly. Eliminating manual migration steps for users while ensuring a smooth transition is a great example of the consumer friendliness ZKsync and its Elastic Chain partners are also working hard towards, and how blockchain adoption should be handled.

We look forward to seeing Lens thrive on the Elastic Chain, and to future collaboration between Lens and Treasure.

15

On behalf of Dedaub, the proposal seems fine

16

Welcome!! nice to see more chains joining. Voting “for” and exited to see Lens Chain.

17

Welcome to the Elastic Chain! We are really excited to see what the future holds!

We will support this proposal because it delivers a seamless, automated migration of Lens V2 data to the new Lens Chain on the Elastic Network, ensuring that users retain their profiles and content without disruption.

18

Easy “for” vote from the Cyfrin team.

19

Voted FOR: it will make the move to Lens Chain easy for all users. Everyone’s profiles, posts, and connections will be ready from the start, so no one has to do anything extra. Fine!

20

Easy yes for including Lens Chain on the Elastic Network. Thanks for including block 0 specifications.