// Proof of Superiority
Depth that outclasses.
Most audits are done sequentially - each firm reviews a different scope at a different time, making direct comparison impossible. But occasionally, a client submits the same commit to two firms simultaneously. These parallel audits provide the only objective measure of audit depth.
Below we share all our parallel audits - not cherry-picked - showing how our coverage consistently outclasses the competition on the same codebase, same deadline, same scope.
90
TRUSTSEC EXCLUSIVE FINDINGS
6
COMPETITOR EXCLUSIVE FINDINGS
39
SHARED FINDINGS
15.0
WIN RATIO
Select Case Study
1 / 9
Curvance - Lending Platform
vsSherlock
A multi-chain isolated lending protocol with dynamic interest rate models, position management for leveraged and deleveraged operations, oracle aggregation across multiple feed providers, and an auction-based liquidation system integrated with a third-party MEV-aware settlement layer.
17
TRUSTSEC EXCLUSIVE FINDINGS
0
COMPETITOR EXCLUSIVE FINDINGS
16
SHARED FINDINGS
∞
WIN RATIO
41 findingsLiquidation rounding allows debt manipulation and breaks market debt invariantShared
The isCollateral flag is true on first borrows which leads to mispricing in OracleManagerShared
The _checkTransfer() function uses wrong account for transferFrom()Shared
Unsafe Redstone default heartbeatShared
Duplicate accounts in liquidation allow to liquidate beyond closeFactorShared
Oracle deviation thresholds are not accounted forUnique
Stale interest accrual enables bad debt creation and incorrect liquidationsShared
Liquidating healthy account with unhealthy account allows to remove all debtsShared
Min/max price guards override oracle prices leading to bad debt and protocol insolvencyShared
BasePositionManager.onRedeem() doesn't support swapping through native assetsUnique
AuctionManager should deny oracles and selectors by defaultUnique
Borrowers may not experience delayed multiplier and interest rate updatesAck'd
AuctionManager.setAtlasCloseFactor() as a governor protected function is incompatible with requirementsUnique
Accumulated debt rounding creates unrecoverable protocol valueUnique
Native token address inconsistency causes incorrect token equality checksUnique
Missing accountPositions cleanup after liquidation can cause DoSAck'd
Interest rate manipulation via uncollateralized deposits and withdrawalsAck'd
The redeemPaused flag only applies to collateral removalsUnique
Memory corruption in Bytes32Helper can return wrong oracle pricesUnique
Base reserve is ignored in the interest rate calculationUnique
Effective adjustment periods are not 10 minutes and accrual paths behave differentlyShared
DynamicIRM doesn't cap the vertexMultiplier when vertexMultiplierMax is updatedUnique
AuctionManager does not support dynamic close factorUnique
RedStoneCoreAdaptor.addAsset() cannot handle native tokensUnique
Rounding of marketDebtIndex breaks invariantUnique
Debt repayment can be griefed in BasePositionManager and BaseZapperUnique
Transient liquidation configuration is not enforced to be used in isolationAck'd
Limited interest rate precision can cause significant rounding errorsUnique
Multiplying two token amounts should use full precisionUnique
Borrows below MIN_ACTIVE_LOAN_SIZE are possible due to repayments and exact liquidationsShared
Zappers lack validation to prevent callbacksAck'd
Single feed is more permissive than dual-feedAck'd
The transferEmergencyCouncil() and transferTimelockPermissions() functions don't update the roles in DAOTimelockShared
Non-atomic IRM upgrade can deny access to the protocolAck'd
Changing collateral into borrow position is not possible due to 1 wei rounding differenceShared
Missing interest rate accrual before interest rate parameter updateShared
VaultAggregator doesn't support decimal offsetShared
Heartbeat grace period of 60 seconds is too shortUnique
ERC4337 transactions can be denied due to callbacks, leading to DOS of the protocolAck'd
BorrowableCToken miscalculates new debt in borrowForPositionManager()Shared
Sanity check in depositAndLeverage() allows excessive slippageShared
Sherlock17 findings
Exact liquidations allow attackers to drain the protocolShared
BaseCToken::_checkTransfer does not check for correct ownerShared
Duplicated accounts during liquidation causing the user's entire debt to be liquidatedShared
Liquidating debt token should accrue interest on collateral token firstShared
Incorrect oracle price used for user's first borrowShared
Liquidators can selectively use a price that is more beneficial to themselves at the expense of the usersShared
Protocol will become an exit liquidity venue when the price drops below the Price Guard's minimum priceShared
Debt can be reduced without repaying the full amount by taking advantage of the rounding directionShared
Any random user can frontrun the atlas liquidation and skew the solver ordersOut of Scope
The slippage check in BasePositionManager::depositAndLeverage does not workShared
Previous outstanding debt is used to calculate the new borrowing rateShared
Debt can be reduced to less than MIN_ACTIVE_LOAN_SIZE making it unprofitable to be liquidatedShared
timelock.updateRoles() should be called after transferring EC in CentralRegistryShared
User cannot flip markets due to rounding issueShared
Incorrect price returned from aggregator if the underlying asset's decimals != vault's decimalsShared
Double accounting of new debt when leveragingShared
Accrue interest before updating dynamic IRM paramsShared
What the Competitor Missed
1 / 17
Oracle deviation thresholds are not accounted forHigh
Insight
Risk parameters were calibrated without factoring in the cumulative error margin introduced by oracle deviation thresholds, leaving the two configurations unvalidated against each other.
Impact
Unchecked oracle deviation thresholds can make liquidations unprofitable, cause denial of service from legitimate price movements, and allow bad debt to accumulate when risk parameters fall within oracle error margins.
Developer Takeaway
Deviation thresholds across multiple oracle sources must be validated against liquidation incentives and risk parameters, as configurations that are individually reasonable can combine to create exploitable economic conditions.
Summary
TrustSec identified the full spectrum of critical risk in this codebase — from oracle misconfiguration paths that silently undermine liquidation economics, to precision and rounding flaws that erode solvency invariants over time, to callback-based griefing vectors that can freeze user funds entirely. Its unique findings spanned interest rate model inconsistencies, emergency pause bypasses, native token handling gaps, memory safety issues in oracle adaptors, and architectural mismatches in liquidation auction governance. Sherlock's coverage overlapped heavily on the highest-severity exploits but produced no unique Medium-or-above findings inside its scope boundaries. Where both reports surfaced the same vulnerability class, TrustSec consistently explored deeper exploitation chains and second-order economic consequences. TrustSec demonstrated substantially broader adversarial coverage and a more thorough understanding of cross-component interaction risks.
Same code. Same deadline. Different depth.
When the scope is identical, the only variable is the auditor. These parallel audits prove that TrustSec's hybrid approach catches what others miss.