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.
The system implements comprehensive security measures, including signature verification for transaction initiation and authorization checks for all operations. The protocol’s infrastructure is built to handle automated asset management tasks while maintaining strict security requirements.
METHODOLOGY
Our review process combined automated analysis using Wake and manual review of the codebase. For testing purposes, we utilized the Wake testing framework.
During the review, we paid special attention to:
- ensuring the arithmetic of the system is correct;
- detecting possible reentrancies in the code;
- ensuring access controls are not too relaxed or too strict;
- checking the signature verification;
- writing comprehensive unit tests using Wake framework;
- looking for common issues such as data validation
SCOPE
The first audit was performed on commit 6aca8f and the scope was src/FluidkeyEarnModule.sol
The second review was done on the given commit 665108. The Fluidkey team had fixed all issues reported in the previous revision.
FINDINGS
The classification of a security finding is determined by two ratings: impact and likelihood. This two-dimensional classification helps clarify the severity of individual issues. Issues which would be rated as medium severity, but which would be likely discovered only by the team, are typically decreased by the likelihood factor to the warning or informational severity ratings.
Our review resulted in 9 findings, 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 MAX_TOKENS limit potentially leading to unexpected behavior.
Critical severity
No critical severity issues were found.
High severity
H1: Cross-chain replay attack vulnerability
Medium severity
M1: MAX_TOKENS limit bypass via setConfig leads to unintended module persistence
Low severity
No low severity issues were found.
Warning severity
W1: Unchecked return value
W2: Module installation allows empty configuration
W3: Misleading event in deleteConfig
Informational severity
I1: Variable can be immutable
I2: Incorrect usage of immutable instead of constant
I3: Misleading documentation
I4: Unnecessary external call
TRUST MODEL
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.
CONCLUSION
Ackee Blockchain Security recommends Fluidkey to:
- fix the MAX_TOKENS validation in setConfig function;
- implement proper cleanup during module uninstallation;
- add chain ID to signature verification;
- address all other reported issues.
Ackee Blockchain Security’s full Fluidkey audit report can be found here.
We were delighted to audit Fluidkey and look forward to working with them again.
