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 Smart Contract Review | Security firm: Zokyo | Date: | Scope: Files named in the report | No open critical findings | Open · IPFS |
| 1inch – Farming | Security firm: ChainSecurity | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · chainsecurity.com |
| 1inch Fixed Rate Swap Audit | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | No open critical findings | Open · blog.openzeppelin.com |
| 1inch Limit Order Protocol Audit | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | No open critical findings | Open · blog.openzeppelin.com |
| 1inch - Limit Order | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| 1inch Order Mixin audit | Security firm: ABDK Consulting | Date: | Scope: Not recorded (see the report) | 1 critical finding, fixed | Open · GitHub |
| 1Inch Limit Order Protocol | Security firm: Pessimistic | Date: | Scope: Files named in the report | No open critical findings | Open · GitHub |
| 1inch Aggregation Router audit | Security firm: ABDK Consulting | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| 1inch Fixed Rate Swap | Security firm: Ackee Blockchain Security | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| 1inch Limit Order Protocol audit | Security firm: ABDK Consulting | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| 1inch Exchange Aggregation Protocol v3 | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| 1inch Liquidity Protocol Audit | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | No open critical findings | Original removed |
| 1inch Mooniswap v2 | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| 1inch Liquidity Protocol | Security firm: Consensys | Date: | Scope: Files named in the report | 2 open critical findings | Open · diligence.security |
| 1inch Exchange | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
| 1inch Exchange Audit | Security firm: OpenZeppelin | Date: | Scope: Files named in the report | No open critical findings | Open · blog.openzeppelin.com |
| 1INCH / DEX | Security firm: Hacken | Date: | Scope: 1 address on Ethereum | No open critical findings | Open · hacken.io |
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.
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 `_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; ```
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 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.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportIn 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`.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe `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.
Open the reportThe 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.
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.
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 `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`.
Open the reportIn 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.
Open the reportThe following function affects the status of sensitive variables and should be able to emit events as notifications: - `OrderRFQMixin.cancelOrderRFQ()` to cancel an RFQ order.
Open the reportOne 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".
Open the reportThe `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.
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 reportIn 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.
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 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`.
Open the reportThe 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.
Open the reportThe 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.
Open the reportThe 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
Open the reportThe linked statements both contain redundant operations as they are nested within an `if-else` block that guarantees their validity
Open the reportThe 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.
Open the reportThe 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.
Open the reportThe 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.
Open the reportThe `Swapped` event is indexing the source token, however, the destination token remains unindexed
Open the reportThe 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.
Open the reportThe 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`.
Open the reportThe 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.
Open the reportThe 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.
Open the reportThe 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.
Open the reportThe error message alludes that ETH transfers are completely forbidden to the contract whereas transfers from contracts are allowed.
Open the reportThe linked line performs an on-chain conversion from the `address` low-level representation to its human-readable hexadecimal representation.
Open the reportThe contract does not permit Ethereum transfers from contracts in contrast to `GovernanceFeeReceiver` .
Open the reportThe `if` conditional that precedes those two statements already evaluates whether the vote is the default one, meaning a literal can be passed here instead.
Open the reportThe 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.
Open the reportThe linked mathematical statement conducts a `SafeMath` operation whilst its safety is guaranteed by the preceding `if` clause.
Open the reportThe 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.
Open the reportThe 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.
Open the reportThe linked variables contain user-defined getter functions that are equivalent to their name barring for an underscore ( `_` ) prefix / suffix.
Open the reportThe linked code lines contain a mispelling of the `default` word as `defaul` , leading to mistyped variable names.
Open the reportThe 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.
Open the reportWhenever 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).
Open the reportThe `isExtraEthAllowed` flag alludes to a "permittance" rather than an enforcement, which the `require` condition of the linked line does.
Open the reportThe `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.
Open the reportAttached 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