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 contract `SwellAuraVault` the role `_owner` has authority over the functions shown in the diagram below. Any compromise to the `_owner` account may allow the hacker to take advantage of this authority and change the `platformFee` value to send 100% of the `tokenBalance` collected in the contract from a call to `auraBaseRewardPool.getReward()` to the `owner()`. 
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportThe report gives no description here.
Open the reportFunctions that affect state variables should emit events as notifications.
Open the reportThe contract is serving as the underlying entity to interact with one or more third party protocols. The scope of the audit treats third party entities as black boxes and assumes their functional correctness. However, in the real world, third parties can be compromised and this may lead to lost or stolen assets. In addition, upgrades of third parties can possibly create severe impacts, such as increasing fees of third parties, migrating to new LP pools, etc. ```solidity IRewards immutable auraBaseRewardPool; ``` - The contract `SwellAuraVault` interacts with third party contract with `IRewards` interface via `auraBaseRewardPool`. --- ```solidity auraDeposit = IDeposit(auraBaseRewardPool.operator()); ``` - The contract `SwellAuraVault` interacts with third party contract with `IDeposit` interface via `auraDeposit`.
Open the reportThe functions `_beforePositionChange()` and `_afterPositionChange()` are called through the `ERC4626` functions `withdraw()` and `deposit()` respectively. In these functions, it is the `msg.sender` whose assets are deposited and whose shares are burned. However, in the functions cited above, the address `tx.origin` is the address that receives any rewards earned. When `tx.origin` is the same as `msg.sender`, this is not an issue; however, if a contract is set up to interact with this vault, the immediate `msg.sender` address may be different than the initiator of the transaction, `tx.origin`. In such a case, the `tx.origin` would benefit from the calculated reward being added to their `record.unclaimedRewards` running sum. This is possible if `tx.origin` initiates a call to `deposit()` since the address will have a recorded balance in the `userRecords` mapping. In the case where `tx.origin` is different from `msg.sender` but `tx.origin` does not have a balance, no one receives a reward update to their record, since reward calculations are based off the balance of the `tx.origin` address.
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