Swaylend's Invite-Only Program is a form of Boost which is exclusively accessible to a select group of security researchers who have submitted at least 1 valid report during Fuel Attackathon event. These researchers will share a flat reward pool for every valid bug found.
Live
Triaged by Immunefi
PoC required
Whitehat Educational Resources & Technical Info
Documentation can be found at: 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 ERC20 / ERC721 / ERC777 / ERC1155 token standards are supported? Which are not?
The lending market smart contract supports Fuel's native assets - SRC-20 tokens. Both base assets and collateral assets are SRC-20.
Where do you suspect there may be bugs? Useful aspects of this question are:
- Which parts of the code are you most concerned about?
- What attack vectors are you most concerned about?
- Which part(s) of the system do you want whitehats to attempt to break the most?
- Are there any assumed invariants that you want whitehats to attempt to break?
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
What external dependencies are there?
There is one external dependency, which is an oracle that provides up-to-date prices for the tokens. In the current version, we use the Pyth oracle network to provide this data. Pyth oracle smart contract can be found at https://github.com/pyth-network/pyth-crosschain/blob/main/target_chains/fuel/contracts/pyth-contract/src/main.sw
Where might whitehats confuse out-of-scope code to be in-scope?
There are additional smart contracts in the GitHub repository used for internal testing, but they are not within the scope. The only assets within scope are listed in the table above. External dependencies, such as the actual core implementation of the Pyth oracle, are also not in scope for this IOP.
Are there any unusual points about your protocol that may confuse whitehats?
Swaylend is a monolithic lending protocol, meaning all functionalities are encompassed in a single smart contract. The lending positions of users are directly recorded in the smart contract, with no derivative tokens minted, as seen in some other lending protocols.
Liquidations of undercollateralized positions occur through two steps: first, absorbing the collateral assets into the protocol, and then, in the next step, purchasing the collateral assets from the protocol in exchange for the market's base asset.
What is the test suite setup information?
The test suite for the smart contracts is included in the GitHub repo (https://github.com/Swaylend/swaylend-contracts/tree/main/contracts/market/tests ). Tests are written in Rust, and they should cover all functionalities of the lending protocol.
Public Disclosure of Known Issues
There are no known open issues at the moment
Previous Audits
Swaylend’s completed audit reports can be found at https://www.halborn.com/audits/swaylend .USD. Any unfixed vulnerabilities mentioned in these reports are not eligible for a reward.
Asset Accuracy Assurance
Bugs found on assets incorrectly listed in-scope will be considered valid and be rewarded.
Private Known Issues Reward Policy
Private known issues, meaning known issues that were not publicly disclosed, are valid for a reward.
Known Issue Assurance
Swaylend commits to providing Known Issue Assurance to bug submissions through their program. This means that Swaylend will either disclose known issues publicly, or at the very least, privately via a self-reported bug submission.
In a potential scenario of a mediation, this allows for a more objective and streamlined process, in order to prove that an issue is known. Otherwise, assuming the bug report is valid, it would result in the report being considered as in-scope, and due a reward.
Primacy of Impact vs Primacy of Rules
Swaylend adheres to the Primacy of Rules, which means that the whole bug bounty program is run strictly under the terms and conditions stated within this page.