Migration Plan From Lens V2

This guide will walk you through how data will be migrated from Lens v2 on Polygon to Lens v3.


Lens V2 is currently live on Polygon and we will be migrating all the data for Lens V3 onto the Lens network. We want to apply the migration on the initial creation of Lens Network mainnet and in turn make it automatic and seemless as possible for everyone. Below we walk through all the data we will migrate and how we are going to approach it please note that these migration plans are still work in progress and can change as we get feedback from people.

Profiles > Accounts

Lens V2 Profiles which are now called accounts on Lens V3 will be migrated automatically, the big difference between Profiles and Accounts is that Profiles are an NFT and accounts on Lens V3 are a smart wallet. The flow of the migration will be this:

1

The Profile is owned by an EOA

If the Profile is owned by an EOA then we will deploy a new Account and give ownership to that EOA.

2

The Profile is owned by a Safe

If the Safe has a 1/1 signer and that signer is EOA we will deploy a new Safe and assign the same 1/1 signer up, we will then deploy a new Account and give ownership to that Account to the Safe.

3

The Profile is owned by an unknown Contract

If this is the case we will mint the Account on your behalf and have way via the Lens API you can claim it by signing if possible, if not possible we can work with you to prove ownership then change ownership of the Account over to you.

Handles > Usernames

Lens V2 Handles which are now called Usernames on Lens V3 will be migrated automatically. We will follow a similar process for how we will go about migrating Profiles onto Lens V3. Usernames can have many namespaces so all of the below will happen on the lens namespace.

1

The Handle is owned by an EOA

If the Handle is owned by an EOA then we will deploy a new Account and give ownership to that EOA. If that EOA has deployed an Account we will send the username to the Account smart wallet.

2

The Handle is owned by a Safe

If the Safe has a 1/1 signer and that signer is EOA we will deploy a new Safe and assign the same 1/1 signer up, we will then mint the username and give ownership to that username to the Safe. If the Safe has already been deployed when migrating the Account we will send the username to the Account smart wallet.

3

The Handle is owned by an unknown Contract

If this is the case we will mint the Username on your behalf and have way via the Lens API you can claim it by signing if possible, if not possible we can work with you to prove ownership then send the Username over to you.

Profiles Linked To Handles > Username Linked To Accounts

On Lens V2 Profiles were also linked to Handles we will automatically apply this link if exists.

Profile Managers > Account Managers

On Lens V2 we had Profile managers which could do stuff onbehalf of the Profile, in Lens V3 we have Account Managers which can control aspects on the Account. We also have Lens API Profile managers who enabled signless for the user.

1

The Profile manager is owned by Lens API

In this case we will generate a new Lens API dispatcher so you can still do signless on Lens V3. With Lens V3 dispatchers are now 1 of 1 this means each dispatcher is not shared with anyone else but you.

2

The Profile manager is an EOA

We will assign this EOA as Account manager

3

The Profile manager is a Contract or Safe

If the current Profile manager is a contract or a safe we will not assign it and will need to be added again.

Blocked Profiles > Blocked Accounts

Any Profiles you blocked on Lens V2 will be applied to Lens V3.

Follow connections

On Lens V3 we now have multiple graphs so we will migrate all the follows on Lens V2 and apply them on the global graph automatically.

Profile Follow Modules > Follow Rules

On Lens V2 you could set paid to follow if that is the case we will enable that follow rule on your account but it will be applied as GHO and be the exchange rate at the time of migration.

Publications > Posts

On Lens V3 we now have multiple feeds so we will migrate all the publications to posts on the global feed.

Post/Account Metadata Storage

This is relevant for post Account metadata and Post metadata.

We now have ability to edit and delete posts and also Lens Storage Nodes so we will be migrating the metadata storage location if we can.

1

Stored on IPFS

If the metadata link is an IPFS one we will automatically migrate it to Lens Storage Nodes and post it with the lens contentURI.

2

Stored on Arweave/Irys

If the metadata link is an Arweave or Irys we will automatically migrate it to Lens Storage Nodes and post with the lens contentURI.

3

Centralised Storage

We know apps who use S3 to store the metadata and may be doing that for their own reasons so we will use the centralised link on this case to not break any application logic.

Publication Actions > Post Actions

We will not auto set any Post Actions for the Account, the Lens V3 supports editing Posts so if you want to enable that action on Lens V3 you can edit and set it up. This includes collect actions.

Collects

Collects are NFTs which live on within the network itself in this case Polygon so we will not be deploying any collections from Lens V2.

Centralised Data

All centralised data like reactions, reports, recommendations will be migrated.

ML trainned algos

All machine learning modals will be migrated and supported on Lens V3.

Future of Lens V2

After the launch of Lens Network and the migration of Lens V2 data onto Lens V3 we will slowly start deprecating Lens V2 protocol infrastructure support for the protocol which we run including The Lens API. Below is a list of actions we will do, timelines of us deprecating this is open, we want to support the apps migrating over and one of the main reasons we have done a dev preview first.

Gas Sponsorship

As the Lens API pays for most the gas costs for the users on behalf of the apps we firstly will bring this limit down slowly to 0. This includes Momoka publications which we will slowly also bring down the amount of limits people can post using it. The slow down of the gas paying will start instantly on mainnet launch.

Lens API and Indexers

The Lens API and indexers powers most of the applications built in Lens in some way, on launch of Lens Network we will decrease the server sizes for the API which in turn will mean it will be slower then it is now for queries. Over time we will completely turn this off.

Public Big Query

The Lens indexers publishes all the indexed data to public big query to allow anyone to query it. This will be supported until we turn off the Lens API and indexers.

SNS

SNS powers some apps by doing push notifications when events are indexed. This will be supported until we turn off the Lens API and indexers.

Direct DB access

If you have a read replica of the Lens DB this will also be scaled down on launch of the Lens Network and revoked access after a short period of time. We can work with the apps to work out the timescale which makes sense for them.

General Bug Fixing / Support

On launch of the mainnet for Lens Network with Lens V3 we will not maintain or support bugs and give developer support on the old protocol, we will also not add any new features. The only way we will react is if the bug is a critical and users funds/identities are at risk.