Fluidkey is a protocol that automates operations on multiple blockchain networks. It uses a modular architecture enabling authorized relayers to trigger automated operations through a Safe module.<\/p>\n
The system implements comprehensive security measures, including signature verification for transaction initiation and authorization checks for all operations. The protocol\u2019s infrastructure is built to handle automated asset management tasks while maintaining strict security requirements.<\/p>\n
Our review process combined automated analysis using Wake<\/a> and manual review of the codebase. For testing purposes, we utilized the Wake<\/a> testing framework.<\/p>\n During the review, we paid special attention to:<\/p>\n The first audit was performed on commit The second review was done on the given commit The classification of a security finding is determined by two ratings: <\/span>impact<\/b> and <\/span>likelihood<\/b>. This two-dimensional classification helps clarify the severity of individual issues. Issues which would be rated as <\/span>medium<\/span><\/i> severity, but which would be likely discovered only by the team, are typically decreased by the likelihood factor to the <\/span>warning<\/span><\/i> or <\/span>informational<\/span><\/i> severity ratings.<\/span><\/p>\n Our review resulted in 9 findings<\/strong>, ranging from Informational to High severity. The most severe was H1, which describes a possible replay attack on the protocol. M1 poses a risk of exceeding the No critical severity issues were found.<\/p>\n H1: Cross-chain replay attack vulnerability<\/span><\/p>\n M1: No low severity issues were found.<\/p>\n W1: Unchecked return value<\/span><\/p>\n W2: Module installation allows empty configuration<\/span><\/p>\n W3: Misleading event in I1: Variable can be immutable<\/span><\/p>\n I2: Incorrect usage of immutable instead of constant<\/span><\/p>\n I3: Misleading documentation<\/span><\/p>\n I4: Unnecessary external call<\/span><\/p>\n Users must trust the Safe module implementation to handle deposits securely and not contain vulnerabilities that could compromise funds. The protocol relies on authorized relayers to initiate automated deposits, requiring trust in their behavior and key management. The integrated ERC4626 vaults must be trusted to properly manage deposited assets.<\/p>\n\n
SCOPE<\/span><\/h2>\n
6aca8f<\/code> and the scope was src\/FluidkeyEarnModule.sol<\/code><\/p>\n665108<\/code>. The Fluidkey team had fixed all issues reported in the previous revision.<\/p>\nFINDINGS<\/span><\/h2>\n
MAX_TOKENS<\/code> limit potentially leading to unexpected behavior.<\/p>\nCritical severity<\/span><\/h3>\n
High severity<\/span><\/h3>\n
Medium severity<\/span><\/h3>\n
MAX_TOKENS<\/code> limit bypass via setConfig<\/code> leads to unintended module persistence<\/span><\/p>\nLow severity<\/span><\/h3>\n
Warning severity<\/span><\/h3>\n
deleteConfig<\/code><\/span><\/p>\nInformational severity<\/span><\/h3>\n
TRUST MODEL<\/span><\/h2>\n
CONCLUSION<\/span><\/h2>\n