Incident,
Source: De.Fi incident database.
- Audits before it
- 36.
- Audits since
- 6, the latest dated 2 Jul 2026.
As of 30 Oct 2026, 1inch Network has 42 audit reports by 13 security firms on Trustblock; the latest is by Hexens, dated 2 Jul 2026. Those reports list 2 open critical findings. It also holds 1 deployed contract on 1 chain and 1 incident (latest 6 Mar 2025).
Record last updated . It holds audits and findings, contracts and incidents up to Oct 2026. Trustblock does not review code.
Newest first
| Audit | Security firm | Date | Scope | Critical findings | Report |
|---|---|---|---|---|---|
| 1inch security review | Security firm: Hexens | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| 1inch security review | Security firm: Hexens | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| 1inch Crosschain security review | Security firm: Hexens | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| 1inch Crosschain security review | Security firm: Hexens | Date: | Scope: Not recorded (see the report) | 1 critical finding, fixed | Open · GitHub |
| 1inch Crosschain security review | Security firm: Hexens | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| 1inch Fusion | Security firm: Quantstamp | Date: | Scope: Files named in the report | No open critical findings | Open · certificate.quantstamp.com |
| 1inch Sol security review | Security firm: Hexens | Date: | Scope: Not recorded (see the report) | 1 critical finding, fixed | Open · GitHub |
| Cross Chain Swaps Audit | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | No open critical findings | Open · blog.openzeppelin.com |
| 1inch Settlement Refactor Audit | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | No open critical findings | Open · blog.openzeppelin.com |
| 1inch Limit Order and Aggregation Protocols Diff A | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | No open critical findings | Open · blog.openzeppelin.com |
| 1inch Limit Order Protocol Diff Audit | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | No open critical findings | Open · blog.openzeppelin.com |
| 1inch Aggregation Protocol Diff Audit | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | No open critical findings | Open · blog.openzeppelin.com |
| 1inch Limit Order Settlement Audit | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | No open critical findings | Open · blog.openzeppelin.com |
| 1inch Fusion V2 audit | Security firm: Decurity | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| 1inch Cross Chain Swaps audit | Security firm: Decurity | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| 1inch security review | Security firm: Hexens | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| 1inch Limit Order Settlement Phase II audit | Security firm: ABDK Consulting | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| 1inch Limit Order Settlement audit | Security firm: ABDK Consulting | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| 1inch Fusion v1 | Security firm: OXORIO | Date: | Scope: Repository at commit f975e2e | No open critical findings | Open · audits.oxor.io |
| 1inch – Limit Order | Security firm: ChainSecurity | Date: | Scope: Files named in the report | No open critical findings | Open · chainsecurity.com |
| 1inch – Delegation | Security firm: ChainSecurity | Date: | Scope: Files named in the report | No open critical findings | Open · chainsecurity.com |
| 1inch – ERC20 | Security firm: ChainSecurity | Date: | Scope: Files named in the report | No open critical findings | Open · chainsecurity.com |
| 1inch Aggregation Router V5 audit | Security firm: ABDK Consulting | Date: | Scope: Not recorded (see the report) | 2 critical findings, fixed | Open · GitHub |
| 1inch Smart Contract Review (2nd iteration) | Security firm: Zokyo | Date: | Scope: Files named in the report | No open critical findings | Open · IPFS |
| 1inch Exchange AggregationRouter V5 | Security firm: Consensys | Date: | Scope: Files named in the report | No open critical findings | Open · diligence.security |
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 2 | 0 | 5 |
| High | 3 | 19 | 22 |
| Medium | 17 | 29 | 43 |
| Low | 50 | 136 | 148 |
The report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
The report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The `_callGetter()` function on line 330 is meant to return a `makerAmount` when given `takerAmount` data and similarly return a `takerAmount` when given `makerAmount` data. However, if `getter.length == 0`, it actually returns an amount that is of the same type as the input. ```solidity=330 function _callGetter(bytes memory getter, uint256 orderAmount, uint256 amount) private view returns(uint256) { if (getter.length == 0) { // On empty getter calldata only exact amount is allowed require(amount == orderAmount, "LOP: wrong amount"); return orderAmount; ```
The report gives no description here.
The report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe protocol allows the maker to set the `native_dst_asset` flag during order creation to indicate that they want to receive the native SOL token in exchange for their source tokens. The `fill()` function considers this flag when paying out to the maker; however, it does not do the same for the protocol fee. This means the protocol fee will always be in the destination token, regardless of `native_dst_asset`. This can create issues since, when a maker sets this flag, they might not provide proper values for the destination token account.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The `notifyFor` function is meant to be used to allow any address to force a status update of another `address` arbitrarily to ensure the stakes states are kept in sync. However, the second argument passed to the `_notifyFor` function is the balance of the `msg.sender` instead of the account to-be-notified, causing an incorrect balance to be reported for it and potentially for as many accounts as a particular `msg.sender` wants.
In the function `fillOrderTo()`, the function makes a call to `order.makerAsset`. ```solidity=273 _makeCall( order.makerAsset, abi.encodePacked( IERC20.transferFrom.selector, uint256(uint160(order.maker)), uint256(uint160(target)), makingAmount, order.makerAsset ) ); ``` However, if we understood the `Order` struct correctly, the `order.makerAsset` at the end of the `abi.encodePacked` should instead be `order.makerAssetData`.
The linked code blocks link to function implementations within `ReferralFeeReceiver` that do not conduct any sanitization on the input `mooniswap` variable and invoke functions on it.
The report gives no description here.
The report gives no description here.
The report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The project imposes `require` checks on multiple functions, like L255 of `_doTransfers`, to ensure that zero value swaps etc. are prohibited. The `withdrawFor` function fails to impose such a check as it merely ensures that the `value` is greater-than-or-equal to `minReturns[i]` which itself could be `0`.
The linked mathematical operations utilize their `SafeMath` counterpart implementation whereas it is completely reudndant for the operations of L31 and L34 as well as potentially redundant for the operation of L30.
The linked statement conducts a `SafeMath` subtraction operation on the `_totalSupply` variable based on the amount burned from the `_balances` mapping. As the contract level variables of the contract are `private`, they cannot be altered by derivative implementations and as such, the `_totalSupply` is kept in perfect sync with the amount of total balance held in the `_balances` mapping. As a result, if a `SafeMath` subtraction operation succeeds on the _balances mapping it is guaranteed to succeed in the `_totalSupply` variable as well, rendering its use redundant gaswise.
The linked statements all conduct `SafeMath` operations whilst the safety of their operations is guaranteed by the system either via `if-else` clauses or constant variable utilizations
The linked statements both contain redundant operations as they are nested within an `if-else` block that guarantees their validity
The linked statements conduct `SafeMath` operations when their safety may be guaranteed by the system for the first and last linked statements and is fully guaranteed for the middle statement.
In OrderMixin contract, result.length is checked to be greater than 0 in: - simulateCalls() function at line 115. - _makeCall() function at line 285. We recommend verifying that result.length is not less than 32 before decoding it to bool variable.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The initial minting process of a Mooniswap appears to be disproportionate in the sense that it does not rely on the initial deposit, meaning that a user can simply deposit only a single unit and acquire a mint equal to `_BASE_SUPPLY.mul(99)` as only a `Math.max` operation is used on L145.
The linked documentation block is meant to explain the calculations carried out in `_getReturn` , however the variable naming conventions of the function block do not conform to what is laid out in the documentation and the documentation itself appears inconsistent with the statements of the function.
Whenever an out-of-gas exception occurs and the user is not using a Chi token as a substitute for gas, the `reason` variable will be empty (0x).
The `Swapped` event is indexing the source token, however, the destination token remains unindexed
The report gives no description here.
The report gives no description here.
The `decodeBool()` function does not check if the bytes input is 0 or 1, but rather if it is non-zero. Any non-zero data will be decoded into `true`.
The report gives no description here.
In the function `fillOrderRFQTo()`, the function checks whether the order is valid near the end of the function call. ```solidity=139 require(order.allowedSender == address(0) || order.allowedSender == msg.sender, "LOP: private order"); bytes32 orderHash = _hashTypedDataV4(keccak256(abi.encode(LIMIT_ORDER_RFQ_TYPEHASH, order))); require(SignatureChecker.isValidSignatureNow(maker, orderHash, signature), "LOP: bad signature"); ``` It might be more optimal to locate these checks at the start of the function call so extraneous calculations are not performed.
The linked `_beforeTokenTransfer` hook incorrectly sanitizes burn operations by evaluating whether the `from` instead of the to variable is different than the zero address for the ternary operator used on the balanceTo assignment.
The naming convention utilizing `tax` alludes to a tax being imposed on the balances, however L323 assigns the addition instead of the subtraction of the tax from the `srcBalance`.
The boundary check of the `len` variable is meant to ensure that the `len` variable can fit within a single 8-bit slot by ensuring its within its valid range. However, the upper bound specified is incorrect.
The linked code invokes `uniTransferFrom` for an amount equal to `maxAmounts[i]` and consequently assigns that value to `receivedAmounts[i]` even if a token imposes fees on the transaction.
The report gives no description here.
The linked functions are meant to conduct sensitive operations on the contract and utilize its full balance to conduct a swap. Even though the target of a given `swap` operation will always be the `rewards` address specified during construction time, a malicious path can lead to multiple pairs being exchanged artificially increasing volume and diminishing the final output sent to the `rewards` address.
The report gives no description here.
The error message alludes that ETH transfers are completely forbidden to the contract whereas transfers from contracts are allowed.
The following function affects the status of sensitive variables and should be able to emit events as notifications: - `OrderRFQMixin.cancelOrderRFQ()` to cancel an RFQ order.
One of the error messages in the function `fillOrderTo()` is misspelled. ```solidity=202 require(remainingMakerAmount != 1, "LOP: remaining amoint is 0"); ``` The error message should instead be "LOP: remaining amount is 0".
The `isExtraEthAllowed` flag alludes to a "permittance" rather than an enforcement, which the `require` condition of the linked line does.
The linked line performs an on-chain conversion from the `address` low-level representation to its human-readable hexadecimal representation.
The contract does not permit Ethereum transfers from contracts in contrast to `GovernanceFeeReceiver` .
The `if` conditional that precedes those two statements already evaluates whether the vote is the default one, meaning a literal can be passed here instead.
The `swap` function in the `OneInchExchange` contract makes multiple calls to the isETH function from the `UniERC20` contract and the `isPartialFill` and `isDiscountChi` functions in the `OneInchFlags` library, which is inefficient compared to storing their results in intermediate local variables and referencing those instead.
The functions of the Mooniswap contract accept statically sized arrays of 2 members whereas the `withdraw` prefixed functions accept dynamically sized arrays whose size is ensured to be `2` within their respective code block.
The linked mathematical statement conducts a `SafeMath` operation whilst its safety is guaranteed by the preceding `if` clause.
The linked statement conducts a `SafeMath` subtraction operation on the _totalSupply variable based on the amount burned from the `_balances` mapping. As the contract level variables of the contract are `private` , they cannot be altered by derivative implementations and as such, the `_totalSupply` is kept in perfect sync with the amount of total balance held in the `_balances` mapping. As a result, if a `SafeMath` subtraction operation succeeds on the `_balances` mapping it is guaranteed to succeed in the `_totalSupply` variable as well, rendering its use redundant gaswise.
The linked code block is meant to collect an epoch's share by calculating the percentage of shares a user has proportionate to the total supply of shares of a given epoch and multiply the resulting percentage with the total inch balance of the epoch.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The linked variables contain user-defined getter functions that are equivalent to their name barring for an underscore ( `_` ) prefix / suffix.
The `getMakerAmount()` function gives the floor of `swapTakerAmount * orderMakerAmount / orderTakerAmount`, while `getTakerAmount()` gives the ceiling of `swapMakerAmount * orderTakerAmount / orderMakerAmount`. For users that partially fill orders with small amounts, they may potentially lose money. For example, suppose `orderMakerAmount = 10` and `orderTakerAmount = 3`, so the ratio between maker tokens and taker tokens is 10:3. If a user planned to exchange 1 taker token, then they would receive `getMakerAmount(10,3,1) = 3` maker tokens, due to a floor rounding, resulting in a loss of 0.33 maker tokens. If a user instead wished to obtain 1 maker token, then they would have to pay `getTakerAmount(10,3,1) = 1` taker token, due to the ceiling rounding, resulting in an overpay of 0.7 taker tokens.
The linked code lines contain a mispelling of the `default` word as `defaul` , leading to mistyped variable names.
The linked `for` loop ensures that the elements in the `path` are whitelisted, however the first element is assumed to be whitelisted whilst it is not guaranteed so in the `require` checks of the function.
Attached through a shared contract address. Our incident data ends in Oct 2026.
Source: De.Fi incident database.
| Address | Chain | Source code |
|---|---|---|
| 0x1111…c3020x111111111117dc0aa78b770fa6a738034120c302 | Chain: Ethereum | Source code: Verified source |
Is this your project? Show this record on your own website. The label states what the record holds, links to this page and updates by itself. It is free and needs no sign-in.
Automatic: the three strongest facts of this project’s own record (its last audit and two more), highlighted. They update with the record. Picking a fact turns Automatic off.
<head><script src="https://widget.trustblock.run/project-widget.min.js" defer></script></head><body><divdata-tb-project-widgetdata-tb-project-slug="1inch"></div></body>
Paste the code where the label should appear. It uses no API credit and updates by itself.
Something wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us