Jump to content
Main menu
Main menu
move to sidebar
hide
Navigation
Main page
Recent changes
Random page
Help about MediaWiki
Matthews Lab
Search
Search
Appearance
Log in
Personal tools
Log in
Pages for logged out editors
learn more
Contributions
Talk
Editing
Synthetix
(section)
Page
Discussion
British English
Read
Edit
Edit source
View history
Tools
Tools
move to sidebar
hide
Actions
Read
Edit
Edit source
View history
General
What links here
Related changes
Special pages
Page information
Appearance
move to sidebar
hide
Warning:
You are not logged in. Your IP address will be publicly visible if you make any edits. If you
log in
or
create an account
, your edits will be attributed to your username, along with other benefits.
Anti-spam check. Do
not
fill this in!
== Bad engineering practices == A cursory glance of the Synthetix solidity code shows poor coding practices. For instance: there are multiple places within the code that try to hide errors and anticipate what the user wants rather than crashing (with potentially disastrous consequences.) One such example of this is the code used to check balances for exchanges. You would expect that if a user doesn’t have enough funds to cover the conversion that the software would crash with some kind of error. But Synthetix defaults to using all of their remaining balance. This is bad because the user might have made a mistake like accidentally getting the order of the pairs backwards or putting a decimal in the wrong place. [hide_error] <pre class="solidity"> // when there isn't enough supply (either due to reclamation settlement or because the number is too high) if (amountAfterSettlement > balanceOfSourceAfterSettlement) { // then the amount to exchange is reduced to their remaining supply amountAfterSettlement = balanceOfSourceAfterSettlement; }</pre> Another example is in the issuance code which seems to have some kind of weird logic to detect edge cases where users were ‘accidentally’ allocated more than they should have from an exchange (WTF?) Much of the code is a mind-fuck moment in general. You can see that the price quotes are divided up into discrete time periods. It wasn’t my job to do a code audit for this project – I only glanced where there was ambiguity – but I have a feeling that the settlement logic around these price periods / edge-cases may be directly vulnerable. [edge_case] <pre class="solidity">// and deduct the fee from this amount using the exchangeFeeRate from storage uint amountShouldHaveReceived = _getAmountReceivedForExchange(destinationAmount, exchangeEntry.exchangeFeeRate); // SIP-65 settlements where the amount at end of waiting period is beyond the threshold, then // settle with no reclaim or rebate if (!_isDeviationAboveThreshold(exchangeEntry.amountReceived, amountShouldHaveReceived)) { if (exchangeEntry.amountReceived > amountShouldHaveReceived) { // if they received more than they should have, add to the reclaim tally reclaim = exchangeEntry.amountReceived.sub(amountShouldHaveReceived); reclaimAmount = reclaimAmount.add(reclaim); } else if (amountShouldHaveReceived > exchangeEntry.amountReceived) { // if less, add to the rebate tally rebate = amountShouldHaveReceived.sub(exchangeEntry.amountReceived); rebateAmount = rebateAmount.add(rebate); } }</pre> <span id="misleading-claims"></span>
Summary:
Please note that all contributions to Matthews Lab may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see
Matthews Lab:Copyrights
for details).
Do not submit copyrighted work without permission!
Cancel
Editing help
(opens in new window)