If you notice some outdated information please let us know!
PASS
The final review score is indicated as a percentage. The percentage is calculated as Achieved Points due to MAX Possible Points. For each element the answer can be either Yes/No or a percentage. For a detailed breakdown of the individual weights of each question, please consult this document.
Very simply, the audit looks for the following declarations from the developer's site. With these declarations, it is reasonable to trust the smart contracts.
This report is for informational purposes only and does not constitute investment advice of any kind, nor does it constitute an offer to provide investment advisory or other services. Nothing in this report shall be considered a solicitation or offer to buy or sell any security, token, future, option or other financial instrument or to offer or provide any investment advice or service to any person in any jurisdiction. Nothing contained in this report constitutes investment advice or offers any opinion with respect to the suitability of any security, and the views expressed in this report should not be taken as advice to buy, sell or hold any security. The information in this report should not be relied upon for the purpose of investing. In preparing the information contained in this report, we have not taken into account the investment needs, objectives and financial circumstances of any particular investor. This information has no regard to the specific investment objectives, financial situation and particular needs of any specific recipient of this information and investments discussed may not be suitable for all investors.
Any views expressed in this report by us were prepared based upon the information available to us at the time such views were written. The views expressed within this report are limited to DeFiSafety and the author and do not reflect those of any additional or third party and are strictly based upon DeFiSafety, its authors, interpretations and evaluation of relevant data. Changed or additional information could cause such views to change. All information is subject to possible correction. Information may quickly become unreliable for various reasons, including changes in market conditions or economic circumstances.
This completed report is copyright (c) DeFiSafety 2023. Permission is given to copy in whole, retaining this copyright label.
This section looks at the code deployed on the relevant chain that gets reviewed and its corresponding software repository. The document explaining these questions is here.
1. Are the smart contract addresses easy to find? (%)
They can be found at https://github.com/1inch/limit-order-protocol#deployments--audits, as indicated in the Appendix.
2. How active is the primary contract? (%)
Contract LimitOrder (MATIC) is used over 100 times a day, as indicated in the Appendix.
3. Does the protocol have a public software repository? (Y/N)
https://github.com/1inch
4. Is there a development history visible? (%)
Their limit-order protocol has 433 commits, making this development history anything but limited.
5. Is the team public (not anonymous)?
Where we found the team is documented in our team appendix at the end of this report. Many of 1inch's team are public and confirm their contributions to the network.
This section looks at the software documentation. The document explaining these questions is here.
6. Is there a whitepaper? (Y/N)
Location: https://docs.1inch.io/docs/1inch-network-overview
7. Is the protocol's software architecture documented? (Y/N)
This protocol's software architecture is documented in words in their documentation.
8. Does the software documentation fully cover the deployed contracts' source code? (%)
There is full coverage of deployed contracts by software function documentation.
9. Is it possible to trace the documented software to its implementation in the protocol's source code? (%)
There is non-explicit traceability between software documentation and implemented code. There is strong association nonetheless and would be improved by links to exact locations in their GitHub repository.
10. Has the protocol tested their deployed code? (%)
Code examples are in the Appendix at the end of this report.. As per the SLOC, there is 176% testing to code (TtC). This score is guided by the Test to Code ratio (TtC). Generally a good test to code ratio is over 100%. However, the reviewer's best judgement is the final deciding factor.
11. How covered is the protocol's code? (%)
1inch document a code coverage of 77%
12. Does the protocol provide scripts and instructions to run their tests? (Y/N)
No scripts for testing are provided in their repositories.
13. Is there a detailed report of the protocol's test results?(%)
Test reports can be found in the CLI: https://github.com/1inch/liquidity-protocol/actions/runs/1871633909
14. Has the protocol undergone Formal Verification? (Y/N)
This protocol has not undergone formal verification.
15. Were the smart contracts deployed to a testnet? (Y/N)
This protocol has not been deployed to a testnet. However, they've deployed them to a private testnet and provide instructions for users on how to do so in that link.
This section looks at the 3rd party software audits done. It is explained in this document.
16. Is the protocol sufficiently audited? (%)
1inch's different iterations have all undergone audits. Each time, these were conducted before the code was deployed.
17. Is the bounty value acceptably high (%)
1inch does not offer a bug bounty. This was discussed for a short while, but it appears nothing has come from it. There appears to be infrastructure for this, but there is no clear monetary incentive documented for those disclosing bugs.
This section covers the documentation of special access controls for a DeFi protocol. The admin access controls are the contracts that allow updating contracts or coefficients in the protocol. Since these contracts can allow the protocol admins to "change the rules", complete disclosure of capabilities is vital for user's transparency. It is explained in this document.
18. Is the protocol's admin control information easy to find?
Admin control information was clearly documented at this location. This was quick to find.
19. Are relevant contracts clearly labelled as upgradeable or immutable? (%)
No contracts are clearly explained as being immutable or ownable in their documentation. This is indicated in code documentation, but this requires clarification.
20. Is the type of smart contract ownership clearly indicated? (%)
Ownership is clearly indicated in this location.
21. Are the protocol's smart contract change capabilities described? (%)
Smart contract change capabilities are identified in some but not all contracts. This could use further clarification.
22. Is the protocol's admin control information easy to understand? (%)
This information is not in software specific language - anyone can understand it.
23. Is there sufficient Pause Control documentation? (%)
This protocol's pause control is not documented.
24. Is there sufficient Timelock documentation? (%)
This protocol has clear timelock documentation which can be found at this location.
25. Is the Timelock of an adequate length? (Y/N)
The timelock is of a relevant length, as specified in this location.
This section goes over the documentation that a protocol may or may not supply about their Oracle usage. Oracles are a fundamental part of DeFi as they are responsible for relaying tons of price data information to thousands of protocols using blockchain technology. Not only are they important for price feeds, but they are also an essential component of transaction verification and security. These questions are explained in this document.
26. Is the protocol's Oracle sufficiently documented? (%)
The protocol's oracle source is documented. All contracts are identified as in scope, and there is software function documentation relating to it.
27. Is front running mitigated by this protocol? (Y/N)
This protocol documents good front running mitigation techniques at this location. However, 1inch pockets slippage differences, as identified here - users should be aware of this.
28. Can flashloan attacks be applied to the protocol, and if so, are those flashloan attack risks mitigated? (Y/N)
This protocol documents no flashloan countermeasures. However, since this protocol does not custody funds and uses chainlink, it is not susceptible to flashloan attack.
1// SPDX-License-Identifier: MIT
2
3pragma solidity ^0.6.12;
4pragma experimental ABIEncoderV2;
5
6import "@openzeppelin/contracts/access/Ownable.sol";
7import "@openzeppelin/contracts/token/ERC20/SafeERC20.sol";
8import "@openzeppelin/contracts/utils/Pausable.sol";
9import "./interfaces/IChi.sol";
10import "./interfaces/IERC20Permit.sol";
11import "./interfaces/IOneInchCaller.sol";
12import "./helpers/RevertReasonParser.sol";
13import "./helpers/UniERC20.sol";
14
15
16contract OneInchExchange is Ownable, Pausable {
17 using SafeMath for uint256;
18 using SafeERC20 for IERC20;
19 using UniERC20 for IERC20;
20
21 uint256 private constant _PARTIAL_FILL = 0x01;
22 uint256 private constant _REQUIRES_EXTRA_ETH = 0x02;
23 uint256 private constant _SHOULD_CLAIM = 0x04;
24 uint256 private constant _BURN_FROM_MSG_SENDER = 0x08;
25 uint256 private constant _BURN_FROM_TX_ORIGIN = 0x10;
26
27 struct SwapDescription {
28 IERC20 srcToken;
29 IERC20 dstToken;
30 address srcReceiver;
31 address dstReceiver;
32 uint256 amount;
33 uint256 minReturnAmount;
34 uint256 guaranteedAmount;
35 uint256 flags;
36 address referrer;
37 bytes permit;
38 }
39
40 event Swapped(
41 address indexed sender,
42 IERC20 indexed srcToken,
43 IERC20 indexed dstToken,
44 address dstReceiver,
45 uint256 amount,
46 uint256 spentAmount,
47 uint256 returnAmount,
48 uint256 minReturnAmount,
49 uint256 guaranteedAmount,
50 address referrer
51 );
52
53 event Error(
54 string reason
55 );
56
57 function discountedSwap(
58 IOneInchCaller caller,
59 SwapDescription calldata desc,
60 IOneInchCaller.CallDescription[] calldata calls
61 )
62 external
63 payable
64 returns (uint256 returnAmount)
65 {
66 uint256 initialGas = gasleft();
67
68 address chiSource = address(0);
69 if (desc.flags & _BURN_FROM_MSG_SENDER != 0) {
70 chiSource = msg.sender;
71 } else if (desc.flags & _BURN_FROM_TX_ORIGIN != 0) {
72 chiSource = tx.origin; // solhint-disable-line avoid-tx-origin
73 } else {
74 revert("Incorrect CHI burn flags");
75 }
76
77 // solhint-disable-next-line avoid-low-level-calls
78 (bool success, bytes memory data) = address(this).delegatecall(abi.encodeWithSelector(this.swap.selector, caller, desc, calls));
79 if (success) {
80 returnAmount = abi.decode(data, (uint256));
81 } else {
82 if (msg.value > 0) {
83 msg.sender.transfer(msg.value);
84 }
85 emit Error(RevertReasonParser.parse(data, "Swap failed: "));
86 }
87
88 (IChi chi, uint256 amount) = caller.calculateGas(initialGas.sub(gasleft()), desc.flags, msg.data.length);
89 chi.freeFromUpTo(chiSource, amount);
90 }
91
92 function swap(
93 IOneInchCaller caller,
94 SwapDescription calldata desc,
95 IOneInchCaller.CallDescription[] calldata calls
96 )
97 external
98 payable
99 whenNotPaused
100 returns (uint256 returnAmount)
101 {
102 require(desc.minReturnAmount > 0, "Min return should not be 0");
103 require(calls.length > 0, "Call data should exist");
104
105 uint256 flags = desc.flags;
106 IERC20 srcToken = desc.srcToken;
107 IERC20 dstToken = desc.dstToken;
108
109 if (flags & _REQUIRES_EXTRA_ETH != 0) {
110 require(msg.value > (srcToken.isETH() ? desc.amount : 0), "Invalid msg.value");
111 } else {
112 require(msg.value == (srcToken.isETH() ? desc.amount : 0), "Invalid msg.value");
113 }
114
115 if (flags & _SHOULD_CLAIM != 0) {
116 require(!srcToken.isETH(), "Claim token is ETH");
117 _claim(srcToken, desc.srcReceiver, desc.amount, desc.permit);
118 }
119
120 address dstReceiver = (desc.dstReceiver == address(0)) ? msg.sender : desc.dstReceiver;
121 uint256 initialSrcBalance = (flags & _PARTIAL_FILL != 0) ? srcToken.uniBalanceOf(msg.sender) : 0;
122 uint256 initialDstBalance = dstToken.uniBalanceOf(dstReceiver);
123
124 caller.makeCalls{value: msg.value}(calls);
125
126 uint256 spentAmount = desc.amount;
127 returnAmount = dstToken.uniBalanceOf(dstReceiver).sub(initialDstBalance);
128
129 if (flags & _PARTIAL_FILL != 0) {
130 spentAmount = initialSrcBalance.add(desc.amount).sub(srcToken.uniBalanceOf(msg.sender));
131 require(returnAmount.mul(desc.amount) >= desc.minReturnAmount.mul(spentAmount), "Return amount is not enough");
132 } else {
133 require(returnAmount >= desc.minReturnAmount, "Return amount is not enough");
134 }
135
136 _emitSwapped(desc, srcToken, dstToken, dstReceiver, spentAmount, returnAmount);
137 }
138
139 function _emitSwapped(
140 SwapDescription calldata desc,
141 IERC20 srcToken,
142 IERC20 dstToken,
143 address dstReceiver,
144 uint256 spentAmount,
145 uint256 returnAmount
146 ) private {
147 emit Swapped(
148 msg.sender,
149 srcToken,
150 dstToken,
151 dstReceiver,
152 desc.amount,
153 spentAmount,
154 returnAmount,
155 desc.minReturnAmount,
156 desc.guaranteedAmount,
157 desc.referrer
158 );
159 }
160
161 function _claim(IERC20 token, address dst, uint256 amount, bytes calldata permit) private {
162 // TODO: Is it safe to call permit on tokens without implemented permit? Fallback will be called. Is it bad for proxies?
163
164 if (permit.length == 32 * 7) {
165 // solhint-disable-next-line avoid-low-level-calls
166 (bool success, bytes memory result) = address(token).call(abi.encodeWithSelector(IERC20Permit.permit.selector, permit));
167 if (!success) {
168 revert(RevertReasonParser.parse(result, "Permit call failed: "));
169 }
170 }
171
172 token.safeTransferFrom(msg.sender, dst, amount);
173 }
174
175 function rescueFunds(IERC20 token, uint256 amount) external onlyOwner {
176 token.uniTransfer(msg.sender, amount);
177 }
178
179 function pause() external onlyOwner {
180 _pause();
181 }
Tests to Code: 1843 / 1048 = 176 %