As of 3 Nov 2026, ET Swap has 1 audit report on Trustblock, by CertiK, dated 7 Feb 2023. That report lists no open critical findings.
Record last updated . It holds audits and findings, contracts and incidents up to Nov 2026. Trustblock does not review code.
Newest first
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 0 | 1 |
| Medium | 0 | 0 | 0 |
| Low | 0 | 0 | 5 |
In the contract `UniswapV2Factory` the address `feeToSetter` has authority over the functions shown in the diagram below. Any compromise to the `feeToSetter` account may allow the hacker to take advantage of this authority and change `feeTo` and `feeToSetter` state variables. 
Open the reportState variables that never change should be declared as `constant` to save gas. ```solidity=36 address private feeHandAddress=0xA9CD480DB96cf1e8CA21545Fe9B3F68Dc43790d8; ``` - `feeHandAddress` should be declared `constant`.
Open the reportWe understand this is a fork of a DEX. On most DEX, this function only sends a small percentage of the fee to the protocol if the fee is turned on. ```Solidity mint(feeHandAddress, liquidity*5*320/1000); ``` However, this sends an additional fee to a centralized address. We are wondering the use case of this additional fee.
Open the reportThe ERC-20 `approve` function has a well-known race condition whereby an adjustment of an existing approval can be exploited to utilize the full amount of the previously set approval as well as the newly set approval by monitoring the transaction mempool. See also [ERC20 API: An Attack Vector on Approve/TransferFrom Methods](https://docs.google.com/document/d/1YLPtQxZu1UAvO9cZ1O2RPXBbT0mooh4DYKjA_jp-RLM/edit#heading=h.m9fhqynw2xvt)
Open the reportThere should always be events emitted in the sensitive functions that are controlled by centralization roles.
Open the reportThe `permit()` function performs the operation of deriving signer address from the signature values of `v`, `r` and `s`. The state variable `DOMAIN_SEPARATOR` that is used to calculate hash has a value of `chainId` that is derived only once in the constructor, which does not change after contract deployment. In the event of a fork cross-chain replay attacks can be executed. The attack scenario is that if a fork happens and two different networks have id of say `1` and `9`. The `chainId` coded in `DOMAIN_SEPARATOR` will be the same on contracts residing in both of the forks. If the `chainId` of `1` is stored in the contract, then a `permit` transaction signed for the chain with a `chainid` of `1` will be executable on both of the forks.
Open the reportThe reports name a repository or files. Open a report to see its scope.
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="et-swap"></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