Technical red flags

Technical red flags are potential vulnerabilities in a protocol’s code or system design – the kind that could be exploited, hacked, or misused. These risks come from how the smart contracts are written or how much control is centralized in the system architecture.

Because DeFi is powered entirely by code (and that code often holds millions in assets), even a small bug can lead to catastrophic losses. That’s why Shift maintains a detailed checklist of known technical risks, based on real-world exploits, audit reports, and incident analysis.

Common red flags include missing security checks, centralized admin privileges, outdated libraries, or contracts using dangerous patterns like delegatecall. Shift’s risk team reviews every protocol and asset for these issues before investing, using both internal reviews and third-party audits.

The key question here is simple: can this system be directly manipulated or broken through its code? If the answer is yes, Shift either avoids it or puts strong safeguards in place.

Common technical risk checks

Vector	Red flag	Key question to assess risk	Max rating
Centralization	Roles	Are there privileged roles in the contract?	BBB
Internal checks	Actions on behalf of other users	Can any function act on behalf of another user?	BB
Internal checks	Checks before operation	Are all critical checks performed before executing a function?	BB
Internal checks	Checks bypass	Can arguments or edge cases bypass security checks?	B
Math vulnerability	Complex math	Does the contract avoid unnecessary complex math operations?	AAA
Math vulnerability	Overflow / Underflow	Is the contract written in Solidity ^0.8.0+, uses SafeMath, or Vyper?	BBB
Other	Virtual simulations	Are there no simulations that adjust balances without real assets?	BBB
Other	Approve to other smart contract	Are approve() calls to external contracts avoided?	BBB
Re-entrancy Vulnerability	Checks-Effects-Interaction	Does the contract follow the checks–effects–interactions pattern?	A
Re-entrancy Vulnerability	Re-entrancy guard	Are external calls protected by a re-entrancy guard?	BBB
Smart-Contract Upgrade Threat	DELEGATECALL	Does the contract avoid using delegatecall for logic execution?	AAA
Smart contract can be halted	Stability	Does the contract avoid logic that can fail under malicious input?	BB
Swap / LP Issues	Slippage	Are slippage controls in place for trades and LP actions?	BBB
Swap / LP Issues	Trusted platforms used	Are swaps limited to known, trusted protocols and pools?	BBB
Re-entrancy Vulnerability	Vyper version	Is the contract built using a safe version of Vyper (not 0.2.15–0.3.0)?	B
Centralization issue	Pause	Is there no admin ability to pause critical functions?	AA

Example: Technical audit of Aave V3 (Ethereum)

Let’s look at how Shift evaluates technical risk in Aave V3 on Ethereum:

1. Centralization risk

   Certain key functions can be changed by an admin. While this introduces centralization, changes are delayed by a 1-day timelock, offering a degree of protection.

   Mitigation: a trigger is set to monitor all Aave V3 timelock transactions.

2. Upgradeability risk

   Aave uses proxy contracts and delegatecall to run logic from upgradeable contracts. This setup is managed by a timelock but still poses risk.

   Mitigation: another trigger monitors upgrade activity through the timelock.

3. Pause function risk

   The admin can pause core actions like collateral withdrawals. There are no built-in technical safeguards to prevent abuse of this function.

Despite these red flags, Shift applies protective triggers and balances this data with economic and governance factors. In Aave V3’s case, the technical risk is considered manageable, contributing to an overall risk rating of AA.