As of 30 Oct 2026, Swell has 10 audit reports by 6 security firms on Trustblock; the latest is by CODESPECT, dated 17 Apr 2025. Those reports list no open critical findings. It also holds 2 deployed contracts on 1 chain.
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 |
|---|---|---|---|---|---|
| Swell - Repricing Oracle Update | Security firm: CODESPECT | Date: | Scope: 1 address on Ethereum | No open critical findings | Open · IPFS |
| Swell - Withdrawal Update | Security firm: CODESPECT | Date: | Scope: 1 address on Ethereum | No open critical findings | Open · IPFS |
| swBTC Smart Contracts | Security firm: ChainSecurity | Date: | Scope: Files named in the report | No open critical findings | Open · chainsecurity.com |
| Symbiotic-Aera Adapter | Security firm: ChainSecurity | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · chainsecurity.com |
| Swell L2 Pre Deposit security review | Security firm: Hexens | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Swell security review | Security firm: Hexens | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Swell Audit Report | Security firm: Cyfrin | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Swell security review | Security firm: Hexens | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Barracuda security review | Security firm: Sigma Prime | Date: | Scope: Not recorded (see the report) | No open critical findings | Open · GitHub |
| Swell Network Addendum | Security firm: CertiK | Date: | Scope: Files named in the report | No open critical findings | Open · skynet.certik.com |
Statuses are the security firm’s own, from each report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 1 | 1 |
| Medium | 0 | 0 | 6 |
| Low | 0 | 8 | 26 |
In the function `_registerDeposit()`, only the `balance` of a `_user` address is updated in the `userRecords` mapping. The struct variable `entryRPT` is not updated; this means that when the same `_user` address withdraws, their `record.entryRPT` will read as 0 (even if they deposited their tokens at a point in time when the sum was larger) and as a result, they will be privy to the all-time running sum `rewardPerToken` corresponding to the reward token address. Since their balance is updated, provided the `rpt` is positive, a user who goes through `_registerDeposit()` for their first deposit gets the full `rpt` value applied to the amount added to `unclaimedRewards`, either through a second deposit that goes through `_depositRewards()` or withdrawing through `_withdrawRewards()`. The function `_depositRewards()`, however, does not provide the same record-keeping for a first-time depositor. A user who deposits through `_depositRewards()` for the first time has an update to their `record.unclaimedRewards` that is 0 (since `record.balance` is 0 at that point). However, their `record.entryRPT` is updated to be the `rpt` value at the time of deposit. This means the next time this same user deposits or withdraws through `_depositRewards()` or `_withdrawRewards()`, their value for `record.unclaimedRewards` is only scaled by `rpt - record.entryRPT`, where `record.entryRPT` is nonzero. The issue appears to be that two users, both depositing for the first time, may have two different outcomes dependent upon whether the call to `auraBaseRewardPool.getReward()` yields a positive `tokenBalance` amount. It also appears possible that a user may both deposit tokens for a period of time and withdraw these tokens without ever receiving rewards. Such an instance appears to occur if the user happens to deposit tokens through the `_depositRewards()` function (in which case record.unclaimedRewards is still 0 after update), and then withdraws through the `_registerWithdraw()` function, where `record.unclaimedRewards` is also no updated for the user. Which functions are called is dependent upon whether `auraBaseRewardPool.getReward()` yields a nonzero `tokenBalance` for the contract.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe order of external call/transfer and storage manipulation must follow the check-effect-interaction pattern. - In `_beforePositionChange()`: The function `_withdrawFromAura()` makes an external call before the updates to state performed in `_rewardsBeforeWithdraw()`. - In `_afterPositionChange()`: The function `_depositToAura()` makes an external call before the updates to state performed in function `_rewardsAfterDeposit()`.
Open the reportIn functions `_registerWithdraw()` and `_withdrawRewards()`, the `record.balance` for the input address `_user` is updated to subtract away the `_amount` to be withdrawn. However, the logic for updating the `record.balance` is as follows: ```solidity record.balance -= _amount > record.balance ? record.balance : _amount; ``` which allows `_amount` to be larger than the value for `record.balance` without causing a revert of the transaction. While in most cases, a user calling `withdraw()` with a higher value for `assets` than they own will cause a revert, if there is a difference in `msg.sender` and `tx.origin`, this facilitates `tx.origin` in using a call for a withdrawal transaction that may be larger than the recorded `record.balance` for `tx.origin` to gain rewards.
Open the reportThere is no check that the input `_params.platformFee` for the constructor is in an acceptable range for its use as `platformFee` within the `SwellAuraVault` contract. Similarly, there is no check that the input `fee` for function `configurePlatformFee()` is within an acceptable range for its use as `platformFee`.
Open the reportAddresses should be checked before assignment or external call to make sure they are not zero addresses. ```solidity=38 _params.asset; ``` - `_params.asset` is not zero-checked before being set.
Open the report| Address | Chain | Source code |
|---|---|---|
| 0xc94c…09360xc94cffd5249df4008a043ee61e13f19af16d0936 | Chain: Ethereum | Source code: Verified source |
| 0xd5a7…e9590xd5a73c748449a45cc7d9f21c7ed3ab9eb3d2e959 | 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="swell-network"></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