Return of frozen funds

Roadmap of process:

1 - Fixed the Classic marketing algorithm
2 - Collected data on current payments
3 - Development of an algorithm for calculating the correct payments
4 - Calculating the correct payouts
5 - Checking the results
6 - Debug results (bug fixes)
7 - Display frozen money data
8 - Payments stage 1 - users who wish to receive on the current account
9 - Payments stage 2 - users who want to receive to another wallet

Update for October 14

Calculations completed successfully!

It was a very difficult task. Time after time, we encountered obstacles, because of which we had to change the algorithm and start the process again.

But we did not give up and achieved the result. Now this data is being uploaded to the site, which will soon display it.

After that, it will be possible to proceed to the final stage.

Update for October 08

The calculations of accounts that were not in the "bot list" and that did not press the "withdraw" / "cancel" buttons, are almost ready.

The calculations from the other team, with a complete list, is already in the final stage.

We have come close to the seventh stage "Displaying cash".

Update for October 05

At this point, we are moving toward the seventh point (on the roadmap). The first team received a new block of correct data. At the moment, the accounts with the missing funds are being checked. The second team collected most of the data, but the script started to work incorrectly because of the high computational load. Our team quickly fixed the bug in the program. The script continues to collect data. Tomorrow a new database will be compiled, and we will start testing it.

The current situation 👇

Three teams are working on calculations, with each team using a different approach and different software.

The first team performs their work using Python, and their goal is to simulate the correct algorithm, using detailed step-by-step definitions of each operation, ultimately allowing them to detect and recognize errors/bugs quickly. All of the information gathered is then entered into a database.

The entire process is only marked as successful if the process completes without errors, or if errors are found when the system logic errors have been corrected.

This block of the algorithm requires careful analysis and refinement.

Currently, work is being done in two main directions:

1) adding calculation logic to the fragment of the algorithm where calculation discrepancies occur to continue calculations one at a time;

2) finalizing the functionality of the possibility of a global calculation to obtain approximate information about the freezing of all users.

The other two teams work using virtual blockchain technology and the Laravel framework. They use a method that compares results and detects the difference in counts of two values, the current data in the smart contract, and the correct calculations.

While analyzing the results of the performed tests, a critical data discrepancy is detected. The error was seen in the disparity of the structure construction of the accurate calculations. In the correct smart contract, auto-aggregation is successfully performed in situations where auto-aggregation did not occur in the actual smart contract. Currently, the synchronization phase of the auto-upgrade functions is being implemented.

A manual data check will be spot-checked to ensure the calculation results, and we will compare several methods of the resulting data.

What already done:

✔️ downloaded all the actual transactions from the blockchain, we have a complete picture of all registrations, switching (autoupgrade / autorecycle) and payments (to whom how much and when was sent by the production versions of the smart)

✔️ came to the conclusion in time that the calculation of payments using smart autotests will take a lot of time

✔️ switched to creating a simulation (recreate all transactions, structures and payouts using a python script)

✔️ got excellent speed (10k transactions in 5 seconds)

✔️ at the moment, we already take into account 2 types of errors in payments (freeze during recycling and freeze the penultimate payment)

✔️ most likely, there are 3-4 more types of errors left to fix

✔️ but there may be other errors in payments that were not known at all before

✔️ the script allows to take a complete snapshot of all participants, payouts and structures at the time of any transaction (very convenient for testing and further search for inconsistencies)

✔️ accelerated downloading from a smart contract hundreds of times

✔️ added a check not only for payments, but also for the structure