Incident,
Source: De.Fi incident database.
- Audits before it
- 36.
- Audits since
- 6, the latest dated 2 Jul 2026.
As of 29 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.
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.
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.
The `src` and `dst` arguments of the `swapFor` function are not guaranteed to be equal to the supported tokens of the exchange. While `_doTransfers` will simply yield 0 for the `confirmed` variable on unsupported tokens, this can lead to incorrect reward minting on `_mintRewards` as the confirmed balance is simply utilized during reward calculation
The report gives no description here.
The report gives no description here.
The report gives no description here.
The `_unpause` function in the `Pausable` contract is not exposed, meaning that an accidental invocation of the `pause` function is irreversible.
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.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
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 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 `require` statements could instead be coded in a small `internal` or `private` function that is invoked by a corresponding `modifier` to reduce the gas footprint of the contract.
The linked code block creates a new in-memory `bytes` array and assigns each byte sequentially to it via a loop from the `data` array
The linked Babylonian Square Root implementation can be further optimized by omitting the final `else` block as Solidity returns zeroed out values by default regardless of whether the return variable has been explicitly named or not. Additionally, we highly advise that the new, more optimized Babylonian Method from ABDK Consulting is evaluated as an optimized alternative which has already been integrated in Uniswap.
The report gives no description here.
The report gives no description here.
The `rescueFunds` function allows the owner of the contract to transfer an arbitrary amount from an arbitrary IERC20 token to themself in order to retrieve funds accidentally sent to it: ```solidity function rescueFunds(IERC20 token, uint256 amount) external onlyOwner { token.uniTransfer(msg.sender, amount); } ```
The discountedSwap function in the OneInchExchange contract does not incorporate the whenNotPaused modifier as the swap function does.
The report gives no description here.
The linked functions are declared as `external` or `public`, contain array function arguments and are meant to be mostly invoked by external parties.
The report gives no description here.
The report gives no description here.
The report gives no description here.
The linked code block contains four `for` loops to ultimately conduct all operations necessary on the 2-member `maxAmounts` and `realBalances` arrays.
The linked `require` statements ensure that the `maxAmounts` provided to the contract at the start are greater-than ( `>` ) zero, yet they are evaluated mid-way through.
The `flags` variable could be reduced in size to be tight-packed with the address declaration that follows it by setting its size to `uint96` permitting 96 different flags. This would reduce the total storage cost of the `SwapDescription` to 7 from 8 if we do not factor in the `permit` variable.
The report gives no description here.
The function `_toHex` is implemented twice utilizing function overloading, however the middleware implementation accepting an `address` argument is only used once.
The `vote` library is meant to be utilized on Data structs that contain only a single `uint256` value.
The report gives no description here.
The report gives no description here.
An unlocked compiler version in the source code of the contract permits the user to compile it at or above a particular version. This, in turn, leads to differences in the generated bytecode between compilations due to differing compiler version numbers. This can lead to ambiguity when debugging as compiler-specific bugs may occur in the codebase that would be hard to identify over a span of multiple compiler versions rather than a specific one.
The `uniBalanceOf` function can skip the `else`-block implementation and directly return the specific value after the `if`-condition is not me
The report gives no description here.
The report gives no description here.
The `swap` function in the `OneInchExchange` contract contains the usage of the if-revert pattern over using a require clause, which may be deprecated in the future: ```solidity if (!desc.flags.isDiscountChi()) { revert(RevertReasonParser.parse(reason, "Swap failed: ")); } ```
The report gives no description here.
The report gives no description here.
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