Quantstamp reviewed Datachain (Datachain - App for Liquidity) on 27 Jan 2025: 20 findings, 0 critical; 15 marked fixed, 4 acknowledged, 1 open.
Report hosted on certificate.quantstamp.com.
Trustblock does not review code.
Statuses are the security firm’s own, from its report.
| Severity | Open | Acknowledged | Fixed |
|---|---|---|---|
| Critical | 0 | 0 | 0 |
| High | 0 | 0 | 2 |
| Medium | 1 | 1 | 3 |
| Low | 0 | 3 | 10 |
The `eqFee` is a fee applied when the destination pool's balance is lower than its target balance. It is currently calculated on the source pool using the balances stored in `PeerPoolInfo`. However, the accuracy of `PeerPoolInfo` is dependent time since the last received packet from the destination chain. The `PeerPoolInfo.balance` on the source chain will always be less than or equal to `PeerPoolInfo.lastKnownBalance` on the destination chain. It is possible that the destination pool's balance has been replenished while users continue to be charged an `eqFee` for an incorrect Balance Deficit Zone.
Current implementation only tracks transfers above `THRESHOLD`, allowing rate limit bypass through multiple smaller transfers. Allowing unlimited transfers below threshold. **Current Code**: ```solidity if (THRESHOLD < amount) { $._cancellableAmount = amount; $._currentPeriodAmount += amount; } else { $._cancellableAmount = 0; } ```
The `refuelAmount` is capped once received by the destination chain. The source chain validates that the `refuelAmount` is within bounds before sending out the message. However, the `refuelDstCap` can be updated at any time in `BridgeManager.setRefuelCap()`. If the chains fuel caps are ever desynchronized, a user may not have their full refuel amount transferred to them and the difference will be kept by the protocol.
The `_mintLPbyLD()` function in `Pool.sol` is responsible for minting LP tokens to users when they deposit liquidity into the pool. This function conditionally calls the `_deltaSourceUpdate()` function, which implements the Delta algorithm's rebalancing logic. The condition for calling `_deltaSourceUpdate()` depends on the `_batched` flag and the relationship between `_deltaCredit`, `_totalLiquidity`, and `_lpDeltaBP`. The `_deltaSourceUpdate()` function can be gas-intensive, as it involves iterating through all connected pools and potentially updating storage variables. Because the call to `_deltaSourceUpdate()` is conditional, some liquidity deposits will trigger it while others will not. This leads to unequal gas consumption for users performing the same operation (depositing liquidity). Users who happen to deposit liquidity when the conditions for triggering `_deltaSourceUpdate()` are met will incur significantly higher gas costs than those who deposit when the conditions are not met. This can be perceived as unfair and might discourage liquidity provision, especially when the pool is close to the threshold that triggers the update.
The report names a repository or files. Open the report to see its scope.
Repository and files the report names (47)
236 projects reviewed · 332 reports · latest Oct 2026
See Quantstamp’s auditsSomething wrong on this page? A missing report, a wrong date, a finding that was fixed since. Tell us and we check it against its source.
Tell us