Asset balance migration solution post NEO2 shutdown

[ixje]

In April this year a notice for the shutdown of the Neo Legacy network was posted on the neo.org website. It urges people to migrate their assets to N3 with the shut down date set for the end of this month (31st of October 2025).

For a lot of people the following statement from that post is worrying (rightfully so)

All assets and smart contracts remaining on Neo Legacy, TestNet and MainNet, must be migrated to Neo N3 before the official shutdown. Otherwise, they will be permanently lost.

I've come to understand that the last statement of that sentence is no longer valid and that a post N2 shutdown migration solution is being discussed behind closed doors.

1. I believe NEO should put out a new post/statement covering this migration solution to take a way some of the fear/frustrations from people currently trying to migrate but not receiving their funds because migration progressing is currently slow.
2. I believe the migration solution should be discussed publicly. I'll share my thoughts on possible solutions below to start the discussion

Migration solution ideas

All solutions start from the premise that the Neo legacy network has shutdown.

Solutions that require wallets to interact with N2 are not considered because most (if not all) wallets are light wallets and thus rely on the RPC server of a node for information. We have to assume no N2 infrastructure will be available after the shutdown or else what's the point of the shutdown.

1. Snapshot balances into N3 contract, migrate all at once

I had a error in my logic around this idea. The script hash stored in N2 is different from N3 and therefore cannot be used to derive the N3 address.

~~The N2 asset balances per account can be read directly from LevelDB and stored in a smart contract on N3. The smart contract can have a migrate function that will transfer all balances to all users in one go. Using the flexibility of the VM the funds transfer from NEO to the smart contract and calling the migration function can be done in a single transaction to eliminate any concerns around holding a large amount of tokens on the contract (if there were any).~~

~~The key benefit of this approach is that it requires no interaction from the users, no updates on wallets and no continuous manual administration of migration requests. The user simply uses their private key on N3 and they're ready to go.~~

~~The source code to the program reading the N2 account balances should be made public such that anyone can take the final N2 snapshot, run it and see what the state on the N3 contract should have been at a given height (the StateService can be used to obtain that N3 contract state). Ideally, the tool should also perform the validation against the N3 contract storage. This gives full transparency, just like the current migration path gives.~~

2. Snapshot balances into N3 contract, migrate on request

This is a slight variation of approach 1. where the balances are stored on a N3 smart contract (same as before). Instead of a single migrate to all, a user can request to have their funds migrated by calling a specific function on the contract e.g. migration_request. Signing of the transaction proves they are the owner of the account. A NEO admin will have to request the list of pending migrations from the contract and process them manually.

To keep it easily auditable it should be the contract that sends the funds to the user and deletes the storage record. The contract should also pay for the transaction that calls the migration_request function, because many users will have no GAS on N3 to pay for creating this transaction.

Compared to 1. we can already see some downsides

1. wallets will have to update/create migration flows to use this new approach

2. the smart contract must hold GAS to pay for migration_request transactions

3. requires continuous admin time from NEO to monitor and process pending migrations

   At the time of writing this there are 113139 NEO balance records and 439938 GAS balance records remaining on N2 to be migrated. To me that sounds like it will take years of monitoring before that's all migrated.

@erikzhang @shargon

[Jim8y]

if user is active and still want for a migration, easist way of solving this would be sending a message to neo foundation and sign the message with the private key. but, i am not sure neo fundation still have the legacy chain data available.

[ixje]

i am not sure neo fundation still have the legacy chain data available

According to the post linked they should

"A final snapshot of the Neo Legacy network will be taken before the shutdown. This snapshot will archive essential data and preserve the historical state of the network for reference. "

I assume this snapshot will live on NeoFS

[roman-khimov]

@ixje, have you tried to analyze remaining address verification scripts? Do we have any irregular ones, not using CHECKSIG/CHECKMULTISIG?

[vncoelho]

🔥 burn not migrated tokens. I think it is time to end legacy.

[vncoelho]

But @Jim8y comment is also possible and maybe a good direction.

[ixje]

@ixje, have you tried to analyze remaining address verification scripts? Do we have any irregular ones, not using CHECKSIG/CHECKMULTISIG?

@roman-khimov I have not. I don't seem to recall this information being stored in the DB either.

[ixje]

🔥 burn not migrated tokens. I think it is time to end legacy.

@vncoelho the above accounts hold the below number of tokens (migration address not included)

Account with NEO balance
Range <1: 0 (total 0)
Range <10: 68076 (total 219469)
Range <100: 37733 (total 1077545)
Range <1000: 6750 (total 1575108)
Range <10_000: 537 (total 1196173)
Range <100_000: 34 (total 830423)
Range >100_000: 9 (total 46114740)

Account with GAS balance
Range <1: 343594 (total 37070.72)
Range <10: 72419 (total 233940.17)
Range <100: 20973 (total 586704.4)
Range <1000: 2733 (total 685981.44)
Range <10_000: 197 (total 527261.94)
Range <100_000: 17 (total 388265.38)
Range >100_000: 5 (total 6516794.5)

So you're basically saying let's burn 51013458 NEO and 8976018,55 GAS that people paid for. I fail to interpret that any other way than stealing. Even if we assume that the accounts holding > 100K tokens are exchanges, then you're still suggesting to burn almost 5 million NEO and almost 9 million GAS.

[roman-khimov]

I don't seem to recall this information being stored in the DB either.

If these accounts have sent any transactions it's there, witness scripts have verification part corresponding to account. But I understand that it requires some tinkering to get this data, no tools readily available.

[vncoelho]

First of all we need a clear audit from NF, @ixje

I hope @erikzhang and @dahongfei will soon clarify that.

This document and report should make clear what will be burnt on legacy and everything that was migrated with sucess.

In terms of transparency on the migration from N2 to N3, this has been made clear since the launch of N3.

[ixje]

If these accounts have sent any transactions it's there, witness scripts have verification part corresponding to account. But I understand that it requires some tinkering to get this data, no tools readily available.

While I could do that, it won't cover accounts that only received funds e.g people who bought on an exchange and sent to cold storage. So not sure how valuable that information would be?

[vncoelho]

🔥 burn not migrated tokens. I think it is time to end legacy.

@vncoelho the above accounts hold the below number of tokens (migration address not included)

Account with NEO balance
Range <1: 0 (total 0)
Range <10: 68076 (total 219469)
Range <100: 37733 (total 1077545)
Range <1000: 6750 (total 1575108)
Range <10_000: 537 (total 1196173)
Range <100_000: 34 (total 830423)
Range >100_000: 9 (total 46114740)

Account with GAS balance
Range <1: 343594 (total 37070.72)
Range <10: 72419 (total 233940.17)
Range <100: 20973 (total 586704.4)
Range <1000: 2733 (total 685981.44)
Range <10_000: 197 (total 527261.94)
Range <100_000: 17 (total 388265.38)
Range >100_000: 5 (total 6516794.5)

So you're basically saying let's burn 51013458 NEO and 8976018,55 GAS that people paid for. I fail to interpret that any other way than stealing. Even if we assume that the accounts holding > 100K tokens are exchanges, then you're still suggesting to burn almost 5 million NEO and almost 9 million GAS.

Adding to that, burn does not mean it could not be mint or re-minted...but for now I support just burn.

That would bring transparency and a solid accountability. Future is future.

[roman-khimov]

it won't cover accounts that only received funds

Sure.

So not sure how valuable that information would be?

To me this can clarify our perspectives wrt auto-migrations of any kind. It's easy to generate N3 address corresponding to private key used in Legacy (like in https://github.com/nspcc-dev/neo-go/blob/master/docs/cli.md#convert-neo-legacy-wallets-to-neo-n3), it's possible to do that for multisig. But anything else is a mystery. And accounts lacking any verification script traces are also problematic.

Option 2 sounds OK in any event, if the network is stopped and one can prove he owns an old account --- minting on N3 side is rather easy. But if we have some irregular accounts affected — they're lost and it's a problem. We better not have them.

Anyway I agree that just burning tokens is not the thing to do. To me Legacy can still remain, maybe adjusted to accept migration transactions only with a limited set of nodes (CNs + RPC basically), but there should be some possibility for regular migration.

[shargon]

if user is active and still want for a migration, easist way of solving this would be sending a message to neo foundation and sign the message with the private key. but, i am not sure neo fundation still have the legacy chain data available.

Agree with @Jim8y

[ixje]

In terms of transparency on the migration from N2 to N3, this has been made clear since the launch of N3.

@vncoelho I don't know what you're referring to but please point me at it. Neither the post above or this one or this other one or the migration page seems to mention anything about transparency of the migrations (or perhaps what I expect from it).

[lllwvlvwlll]

@vncoelho Burning the assets will have a major product impact since it will negatively impact the total supply as well as the sentiment towards the project.

The negative PR associated with that approach would most likely destroy this ecosystem.

An auditable approach is ideal, but the value is somewhat diminished since the current solution is already not transparent.

There was also a hard deadline that was announced for this EoL so time needs to be a major consideration in whichever direction is taken here. Expecting a financial disclosure and transparent solution in 15 days is unrealistic.

[vncoelho]

@vncoelho Burning the assets will have a major product impact since it will negatively impact the total supply as well as the sentiment towards the project.

The negative PR associated with that approach would most likely destroy this ecosystem.

An auditable approach is ideal, but the value is somewhat diminished since the current solution is already not transparent.

There was also a hard deadline that was announced for this EoL so time needs to be a major consideration in whichever direction is taken here. Expecting a financial disclosure and transparent solution in 15 days is unrealistic.

As I said, Burning now does not mean it could not be later minted.

The point here to me is transparency and consolidation of the expected 100M NEO balance. NF should certain urge to release such report.