You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Receive native currency only from native currency wrappers: The contract is payable, but it will only receive the native network currency from native currency wrapper contracts, maybe this can be a requirement in the contract.
line 280 tokens[i] -> nativeCurrencyAddress.
Short unnecessary names in line 294 tokenBal and line 551, there is no problem with using long variable names.
Remove the function that removes a supported DEX, we have a setSupportedDex function, and the set function is commonly used to add/remove.
_getFeeAndTransferTokens is only used once, remove the function and place the code of it where it is used.
Comment is wrong in line 453, the fee is removed if the protocol fee is higher than zero and the sender address is not whitelisted.
Proposed refactor to affiliate fees, with the fee being applied over the total amount, like the protocol fee. Also, each affiliate can have its specific fee (it cant be higher than the protocol fee), a deadline for the fee too. So the affiliate status can be removed, the affiliate fee can be applied independently from the protocol fee and it has a deadline. The idea here would be to sell special fee services to other dexes. Dexes can pay X amount of money to have a special fee enabled till a certain date.
The transferResidual can be based on an amount, like transferResidualTokenA and transferResidualTokenB, and if the token residual is higher than the specified amount send the residual to the swap executor. This is better than using a boolean and having to estimate the transfer residual that will be left, with this you can specify and only do it when you know you won't spend more gas on the residual transfer than needed. Also, the transferResidual is not tested.
Tests against other dexes: Flattened code from other dexes factories and router can be added and generic tests can be run over them.
Tests with USDT and KNC tokens. There is a comment on the contact where USDT and KNC tokens are mentioned in line 637, write tests that prove the need for that double approve.
No complete tests coverage, more tets should be added to have ~100% tests coverage.
The text was updated successfully, but these errors were encountered:
On commit 821e7ea
The text was updated successfully, but these errors were encountered: