Spectra is an EVM-centric protocol for interest rate derivatives with an easy-to-use flagship app. The Spectra protocol is permissionless, meaning its services are entirely open for public use. Anyone can create new markets at will, swap yield derivatives, or become a liquidity provider.
For more information, please visit about Spectra Finance
Evaluating
Triaged by Immunefi
Step-by-step PoC Required
Select the category you'd like to explore
Assets in Scope
Impacts in Scope
Build commands, Test commands, and instructions on how to run them:
The project uses Foundry as a development framework.
To build the project and install all the dependencies run: forge build
For running tests run: forge test
For running specific test cases please refer to foundry documentation or run: forge test --help
What ERC20 / ERC721 / ERC777 / ERC1155 token standards are supported? Which are not?
The Router handle any ERC20 tokens and ERC4626 vaults
What emergency actions may you want to use as a reason to downgrade an otherwise valid bug report?
Contracts can be paused and upgraded
Which chains and/or networks will the code in scope be deployed to?
Ethereum Mainnet, Optimism, Arbitrum, Sonic, Base
Is this an upgrade of an existing system? If so, which? And what are the main differences?
This audit covers the integration of Curve NG and Curve Stableswap NG pools into Spectra’s core protocol. Spectra is currently using Cryptoswap pools, and this audit concerns the migration to these two new sets of pools. All other Spectra features remain intact, including the implementation of the Principal Token and the Yield Token. Below is a high-level overview of the integration tasks: Integration of Cryptoswap NG pools
- The next generation of Curve pools on which Spectra is currently based.
- Integration of a new type of pool: oracle-based Stableswap NG pools
- Upgradeable rate oracles for Stableswap NG pools that reports the rate of the PT in underlying based on its initial price
- Deployment of Spectra with Stableswap NG pools through a new factory
- Registration of rate oracles in a new dedicated registry
- Addition of previews and interaction execution with the new pools in the router
Where do you suspect there may be bugs?
The main focus should be the StableSwap NG integration. correctness, robustness and resilience of the rate adjustment oracles for the Principal Token should be thoroughly examined. Secondly, the new commands of the router should be examined.
What external dependencies are there?
Curve smart contracts and Open Zeppelin libraries.
Stableswap-NG documentation at [(https://docs.curve.fi/stableswap-exchange/stableswap-ng/overview/)]
Open Zeppelin v5 at [(https://docs.openzeppelin.com/contracts/5.x/)]
Where might Security Researchers confuse out-of-scope code to be in-scope?
Security problems related to the implementation of Curve Finance pools and their internal oracle manipulations. Only Spectra’s rate oracle implementation and its influence on Stableswap’s pricing shall be considered in scope, besides Spectra’s core components.
What addresses would you consider any bug report requiring their involvement to be out of scope, as long as they operate within the privileges attributed to them?
Any address controlled by the Spectra DAO
Previous Audits
Spectra’s completed audit reports can be found at https://docs.spectra.finance/security/audits?utm_source=immunefi. Unfixed vulnerabilities mentioned in these reports are not eligible for a reward.
Direct theft of any user funds, whether at-rest or in-motion, other than unclaimed yield
Permanent freezing of funds
Protocol insolvency
Permanent freezing of unclaimed yield
Theft of unclaimed yield
Temporary freezing of funds for at least 24 hour
Smart contract unable to operate due to lack of token funds
Block stuffing
Griefing (e.g. no profit motive for an attacker, but damage to the users or the protocol)
Contract fails to deliver promised returns, but doesn't lose value
Security best practices
Code Optimizations and Enhancements
Out of scope
Smart Contract specific
- Incorrect data supplied by third party oracles
- Not to exclude oracle manipulation/flash loan attacks
- Impacts requiring basic economic and governance attacks (e.g. 51% attack)
- Lack of liquidity impacts
- Impacts from Sybil attacks
- Impacts involving centralization risks
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 (including, but not limited to: governance and strategist contracts) without additional modifications to the privileges attributed
- 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
- Impacts requiring phishing or other social engineering attacks against project's employees and/or customers