This release contains the latest update from August 21st and all additional content of the Legendary Edition.
For the reason explained below, we noticed that two of the 38 included fighters (Gorilla and Robin) can have some small delays/micro freezes when executing certain attacks. The slower your cpu, the more noticeable the lags are on these two.
Even though the game isnt exactly new anymore, there are still a lot of bugs left in the legit version.

Some Denuvo Techtalk:

For example when Robin does one of his special attacks, throwing a smoke bomb on the ground, Denuvo starts writing a private key to the memory from 000000014C113692:

      000000014C113692  | 44 88 07                  | mov byte ptr ds:[rdi],r8b
      000000014C113695  | 5F                        | pop rdi
      000000014C113696  | 50                        | push rax
      000000014C113697  | 21 C0                     | and eax,eax
      000000014C113699  | 9C                        | pushfq
      000000014C11369A  | 44 01 C1                  | add ecx,r8d
      000000014C11369D  | 4C 89 F0                  | mov rax,r14
      000000014C1136A0  | 48 89 C1                  | mov rcx,rax
      000000014C1136A3  | 48 C7 C0 00 00 00 00      | mov rax,0
      000000014C1136AA  | 48 09 D0                  | or rax,rdx
      000000014C1136AD  | 48 83 C1 01               | add rcx,1
      000000014C1136B1  | 49 89 CE                  | mov r14,rcx
      000000014C1136B4  | C1 C1 08                  | rol ecx,8
      000000014C1136B7  | 9D                        | popfq
      000000014C1136B8  | 58                        | pop rax

Then it fills the buffer at: 000000014779F593.

When everything is filled and the key is obtained by Denuvo itself, it starts executing anti-tamper checks from 000000014774C37E:

      000000014774C37E  | 41 89 7D 00               | mov dword ptr ds:[r13],edi
      000000014774C382  | 48 29 F3                  | sub rbx,rsi
      000000014774C385  | 41 54                     | push r12
      000000014774C387  | C1 CB 0D                  | ror ebx,D
      000000014774C38A  | BE D4 72 4D 3E            | mov esi,3E4D72D4
      000000014774C38F  | 4C 8D 25 4F B5 06 FE      | lea r12,qword ptr ds:[1457B78E5]
      000000014774C396  | 4C 33 24 24               | xor r12,qword ptr ss:[rsp]
      000000014774C39A  | 48 8B 1C 24               | mov rbx,qword ptr ss:[rsp]
      000000014774C39E  | 4C 21 E3                  | and rbx,r12
      000000014774C3A1  | 4C 09 24 24               | or qword ptr ss:[rsp],r12
      000000014774C3A5  | 0F BA F8 06               | btc eax,6
      000000014774C3A9  | 0F BA F6 0D               | btr esi,D
      000000014774C3AD  | 48 29 1C 24               | sub qword ptr ss:[rsp],rbx
      000000014774C3B1  | 4C 89 E3                  | mov rbx,r12
      000000014774C3B4  | 48 23 1C 24               | and rbx,qword ptr ss:[rsp]
      000000014774C3B8  | 4C 0B 24 24               | or r12,qword ptr ss:[rsp]
      000000014774C3BC  | 49 29 DC                  | sub r12,rbx
      000000014774C3BF  | C3                        | ret

Here it gets the addresses of the various functions inside the Denuvo code from r13 register and forces the original bytes, a single DWORD per cycle, essentially overwriting any potential patches that were applied to these functions before.

The way our crack works is that it reads a huge amount of encrypted code, (including the code that the anti-tamper tries to overwrite) and therefore patching the required place causes some slowdowns thanks to Denuvo and the devs.