Swaylend is a leading lending protocol on the Fuel network, based on a fork of Compound V3.
For more information, visit: https://swaylend.com/
IOP | Swaylend Frontend focuses on Web2 attack vectors. Please review the in-scope impacts.
Swaylend rewards are provided in USDC, denominated in USD.
Live
Triaged by Immunefi
PoC required
Select the category you'd like to explore
Assets in Scope
Impacts in Scope
Whitehat Educational Resources & Technical Info
Documentation: https://docs.swaylend.com/
Is this an upgrade of an existing system? If so, which? And what are the main differences?
Swaylend is the port of Compound V3 lending protocol and architecture in the Sway programming language for the Fuel Network.
What external dependencies are there?
The frontend uses many external libraries, the most important dependencies related to smart contracts are:
- Fuel libraries for handling wallet connections, contract types and calling of smart contract methods.
- @fuel-ts/contract
- @fuels/connectors
- @fuels/react
- fuels
- Pyth libraries for handling fetching of price updates from their Hermes network and load Pyth contract ABI types.
- @pythnetwork/hermes-client
- @pythnetwork/pyth-fuel-js
- Other larger libraries used are:
- Next.js 14
- Tailwind
- @tanstack/react-query
- Zustand
What ERC20 / ERC721 / ERC777 / ERC1155 token standards are supported? Which are not?
Only SRC-20 are supported, which are similar to ERC-20 standard but on the Fuel Network
Where might whitehats confuse out-of-scope code to be in-scope?
Bugs found inside external libraries related to contract calls, specifically Fuel and Pyth libraries. Wrong usage of the above libraries, still counts as in-scope.
Are there any unusual points about your protocol that may confuse whitehats?
Pyth is used as a pull oracle by Swaylend. Pyth pull oracle information: https://docs.pyth.network/price-feeds/pull-updates
Where do you suspect there may be bugs?
Swaylend is the lending protocol that offers functionalities like other lending protocols, i.e., supplying base assets (in our case, USDC) and borrowing base assets in exchange for providing collateral assets. The most critical things that should be tested are:
- Withdrawing only assets that you supplied
- Borrowing only the amount you're allowed (based on supplied collateral asset and collateral factor)
- Repaying the borrowed amount before withdrawing collateral asset
Public Disclosure of Known Issues Bug reports covering previously-discovered bugs (listed below) are not eligible for a reward within this program. This includes known issues that the project is aware of but has consciously decided not to “fix”, necessary code changes, or any implemented operational mitigating procedures that can lessen potential risk.
There are no known public disclosures for frontend
Previous Audits
Swaylend’s completed audit reports can be found at https://www.halborn.com/audits/swaylend. Any unfixed vulnerabilities mentioned in these reports are not eligible for a reward.
Taking down the application/website
Taking and/modifying authenticated actions (with or without blockchain state interaction) on behalf of other users without any interaction by that user, such as:
- Changing registration information
- Commenting
- Voting
- Making trades
- Withdrawals, etc.
Direct theft of user funds
Subdomain takeover with already-connected wallet interaction
Malicious interactions with an already-connected wallet, such as:
- Modifying transaction arguments or parameters
- Substituting contract addresses
- Submitting malicious transactions
Injection of malicious HTML or XSS through metadata
Injecting/modifying the static content on the target application without JavaScript (persistent), such as:
- HTML injection without JavaScript
- Replacing existing text with arbitrary text
- Arbitrary file uploads, etc.
Subdomain takeover without already-connected wallet interaction
Changing non-sensitive details of other users (including modifying browser local storage) without already-connected wallet interaction and with up to one click of user interaction, such as:
- Changing the first/last name of user
- Enabling/disabling notifications
Redirecting users to malicious websites (open redirect)
Injecting/modifying the static content on the target application without JavaScript (reflected), such as:
- Reflected HTML Injection
- Loading external site data
Changing details of other users (including modifying browser local storage) without already-connected wallet interaction and with significant user interaction, such as:
- Iframing leading to modifying the backend/browser state (must demonstrate impact with PoC)
Out of scope
These impacts are out of scope for this bug bounty program.
All Categories:
- Impacts requiring attacks that the reporter has already exploited themselves, leading to damage
- Impacts caused by attacks requiring access to leaked keys/credentials
- Impacts caused by attacks requiring access to privileged addresses (governance, strategist) except in such cases where the contracts are intended to have no privileged access to functions that make the attack possible
- Impacts relying on attacks involving the depegging of an external stablecoin where the attacker does not directly cause the depegging due to a bug in code
- Mentions of secrets, access tokens, API keys, private keys, etc. in Github will be considered out of scope without proof that they are in-use in production
- Best practice recommendations
- Feature requests
- Impacts on test files and configuration files unless stated otherwise in the bug bounty program
Websites and Apps
- Theoretical impacts without any proof or demonstration
- Impacts involving attacks requiring physical access to the victim device
- Impacts involving attacks requiring access to the local network of the victim
- Reflected plain text injection (e.g. url parameters, path, etc.)
- This does not exclude reflected HTML injection with or without JavaScript
- This does not exclude persistent plain text injection
- Any impacts involving self-XSS
- Captcha bypass using OCR without impact demonstration
- CSRF with no state modifying security impact (e.g. logout CSRF)
- Impacts related to missing HTTP Security Headers (such as X-FRAME-OPTIONS) or cookie security flags (such as “httponly”) without demonstration of impact
- Server-side non-confidential information disclosure, such as IPs, server names, and most stack traces
- Impacts causing only the enumeration or confirmation of the existence of users or tenants
- Impacts caused by vulnerabilities requiring un-prompted, in-app user actions that are not part of the normal app workflows
- Lack of SSL/TLS best practices
- Impacts that only require DDoS
- UX and UI impacts that do not materially disrupt use of the platform
- Impacts primarily caused by browser/plugin defects
- Leakage of non sensitive API keys (e.g. Etherscan, Infura, Alchemy, etc.)
- Any vulnerability exploit requiring browser bugs for exploitation (e.g. CSP bypass)
- SPF/DMARC misconfigured records)
- Missing HTTP Headers without demonstrated impact
- Automated scanner reports without demonstrated impact
- UI/UX best practice recommendations
- Non-future-proof NFT rendering
Prohibited Activities:
- Any testing on mainnet or public testnet deployed code; all testing should be done on local-forks of either public testnet or mainnet
- Any testing with pricing oracles or third-party smart contracts
- Attempting phishing or other social engineering attacks against our employees and/or customers
- Any testing with third-party systems and applications (e.g. browser extensions) as well as websites (e.g. SSO providers, advertising networks)
- Any denial of service attacks that are executed against project assets
- Automated testing of services that generates significant amounts of traffic
- Public disclosure of an unpatched vulnerability in an embargoed bounty