Galileo Protocol

QuillAudits25 Dec 2024Files named in the report

Audit · firm’s term: audit report

QuillAudits reviewed Galileo (Galileo Protocol) on 25 Dec 2024: 6 findings, 0 critical; 5 marked fixed, 1 open.

No open critical findings

Open the report Open Galileo’s security record

Report hosted on quillaudits.com.

Trustblock does not review code.

Findings6

Statuses are the security firm’s own, from its report.

Severity	Open	Fixed
Critical	0	0
High	0	0
Medium	0	2
Low	1	3

MediumChain ID is not used in the signature, allowing replay attacks on other EVM chainsFixed

The _recover function uses EIP-712 typed data hashing to generate a digest for recovering the signer from a provided signature. However, the chain ID is not included in the hashed data. This omission allows the same signature to be reused (replayed) on other EVM-compatible chains that share the same contract address and data structure, potentially causing unintended actions.

MediumStake function allows staking NFTs with token ID 0Fixed

The _stakeTokens function allows users to stake NFTs with a token ID of 0. However, unstaking of token ID 0 is disallowed, leading to an inconsistency in the staking logic. If a user stakes a token with ID 0, they might face issues retrieving their NFT later, as the unstaking functionality does not account for this scenario

LowIncorrect comment in configureNewCollection regarding maxLeox validationFixed

The comment in the configureNewCollection function inaccurately describes the logic of the if block. Specifically, it states: // Ensure that maxLeox does not decrease compared to the previous tier However, the implementation actually enforces that maxLeox values must decrease (i.e., be in descending order) compared to the previous tier. This discrepancy between the comments and the logic leads to confusion, as it contradicts the intention verified in the written tests.

LowNo check for emergency state in the _stakeTokens and stakeLeoxTokens functionsFixed

The current implementation of the stake and _stakeTokens functions does not verify whether an emergency state has been declared. If the contract is in an emergency state, allowing users to stake tokens may result in undesirable behavior, such as locking funds in an unsafe environment or exposing the protocol to additional risks. Adding a check to ensure that staking is not permitted during emergencies would enhance security and user protection.

LowThe ‘already staked’ check can be bypassed in stakeLeoxTokens by passing tokenId as 0Fixed

The stakeLeoxTokens function checks if the token is already staked by verifying the tokenId. However, this check can be bypassed by passing 0 as the tokenId. Since the tokenId field in the StakePerCitizen struct defaults to 0, the condition stakePerCitizen.tokenId != tokenId will evaluate as false, allowing the function logic to proceed. This creates an inconsistency and can potentially lead to staking logic being executed for an invalid token.