# Yo Protocol's Unseen Dangers: Why Code Audits Aren't Enough

*A Deep Dive into Centralization Risks, MEV Vulnerabilities, and Critical Bug Bounty Gaps in DeFi's Yield Optimizer.*

By [Parlan@Paragraph](https://paragraph.com/@parlan) · 2025-09-16

#yoprotocol, #deepdive, #securityaudit, #blockchain, #defi

---

Beyond the Green Light: Unmasking Yo Protocol's True Security Challenges
------------------------------------------------------------------------

The security audits for the [Yo Protocol](https://www.yo.xyz/), conducted by [Hunter Security](https://www.huntersec.co/), [Offbeat Security](https://offbeatsecurity.com/), and [Spearbit](https://www.spearbit.com/), initially brought good news: **no critical or high-severity vulnerabilities were identified** in its code. However, a deeper analysis, informed by the protocol's own documentation on [docs.yo.xyz](http://docs.yo.xyz) and architectural overview on [deepwiki.com/yoprotocol/core](http://deepwiki.com/yoprotocol/core), reveals significant potential vulnerabilities. These risks are particularly concerning given Yo Protocol's pivotal role as a **multi-chain yield optimizer deeply integrated with numerous other DeFi protocols.** This widespread integration amplifies the potential impact of any flaw, making a comprehensive understanding of its security posture paramount for the entire blockchain ecosystem. This article, therefore, gains substantial importance, as it sheds light on risks that could have cascading effects across a significant portion of the DeFi landscape. If exploited in real-world use, these hidden risks could lead to substantial financial losses for users and the various integrated protocols alike.

### Scrutinizing Audit Firm Credibility: A Note on Hunter Security

While the Yo Protocol engaged external firms for its security audits, a closer look at the public presence of these auditors offers a point for consideration regarding transparency. Hunter Security, one of the auditing firms, notes in its report that security audit inquiries can be directed to their lead on X (formerly Twitter) at `@georgehntr`. However, at the time of this analysis, attempts to access this account reveal that "This account doesn't exist." While acknowledging and respecting the work of lead security researcher [@deadrosesxyz](https://x.com/deadrosesxyz), the **absence of a verifiable public presence for a named founder or key contact of an auditing firm, especially for direct inquiries, can subtly detract from overall public credibility and transparency in the highly trust-dependent DeFi space.** For a blockchain ecosystem that thrives on verifiable assurances, the public accessibility and consistent presence of audit teams are increasingly vital for fostering confidence.

![](https://storage.googleapis.com/papyrus_images/5c987a64a563bf0b676bca755297cfbea3df08a6f4361c9c0607ef1127568bd0.png)

@GeorgeHNTR - Founder of Hunter Security

Let's now dive into the often-overlooked vulnerabilities within the Yo Protocol itself and explore the crucial solutions needed to fortify its defenses.

### Yo Protocol's Role in the DeFi Ecosystem: A Hub of Trust and Technology

Yo Protocol positions itself as a multi-chain yield optimizer, actively integrating with a diverse array of DeFi protocols to source yield, enable rebalancing, looping, lending, liquidity provision, and other critical functionalities. This extensive network of integrations showcases the technological trust placed in Yo Protocol to manage and route capital efficiently across the blockchain ecosystem.

Its integrations span several crucial categories:

*   **Yield Sources (Protocols Yo Routes Capital To for Optimized Yield):** These are core integrations where Yo allocates user deposits to generate risk-adjusted returns, including major players like [Aave (Umbrella)](https://aave.com/), [Aerodrome](https://aerodrome.finance/), [Arcadia](https://arcadia.finance/), [Convex](https://www.convexfinance.com/), [Curve](https://curve.fi/), [Euler](https://www.euler.finance/), [Harvest](https://harvest.finance/), [IPOR](https://iporlabs.com/), [Morpho](https://morpho.xyz/), [Pendle](https://www.pendle.finance/), [Reserve](https://reserve.org/), [Tokemak](https://tokemak.xyz/), and [Yearn](https://yearn.finance/). The inclusion of such prominent protocols underscores the significant trust placed in Yo Protocol's yield-routing capabilities.
    
*   **Rebalancing and Cross-Chain Tools (For Asset Movement and Optimization):** Yo leverages protocols like [Across](https://across.to/), [Enso](https://www.enso.finance/) (which powers swaps for yoEUR and cross-chain deposits), [Everclear](https://www.everclear.org/), and [Odos](https://odos.xyz/) to enable its automated rebalancing across various chains. This demonstrates its ambition to provide seamless multi-chain operations.
    
*   **Platforms Supporting Yo for Looping, Lending, LP, or Points Earning:** A number of platforms have integrated Yo's `yoTokens` or vaults to enhance user features, often including Yo Points multipliers. These include 0xFluid (for LP with `yoUSD`/`yoETH`), Axal (integrating `yoUSD` for lending), [Balancer](https://balancer.fi/) (for LP `yoTokens`), [CoW Protocol](https://cow.fi/) (as a proposed liquidity source), [Extra Finance](https://extra.finance/) (with `xLend` supporting `yoUSD`/`yoETH`), Fluid (for LP `yoTokens`), Mitosis (for depositing `ETH`/`USDC`), [Velvet Capital](https://velvet.capital/) (listing Yo vaults like yoETH, yoBTC, yoUSD, yoEUR for one-click access on Base), and [Zerion](https://zerion.io/) (listing `yoVaults` for DeFi interactions). These integrations highlight Yo Protocol's composability and its ability to extend its utility across a broad user base.
    
*   **Analytics and Additional Mentions:** Platforms like [DeFiLlama](https://defillama.com/) track Yo Protocol metrics such as TVL, fees, and revenue, featuring a "Yo Score" likely referring to risk scoring powered by [Exponential DeFi](https://www.exponential.fi/).
    

With over 55 yield sources across more than 18 protocols, and a focus on non-custodial, automated yield with ERC-4626 standards for composability, Yo Protocol is clearly interwoven into the fabric of the DeFi ecosystem. **This extensive web of integrations is precisely why a thorough security analysis of Yo Protocol is critical.** Any vulnerability, especially those not immediately apparent from code audits, could have far-reaching implications, affecting not only Yo Protocol's direct users but also all the protocols and users interacting through these integrations.

### 1\. Operator/Admin Key Compromise and Centralization Risks

The most critical overarching vulnerability is the **extensive control granted to the vault operator**, coupled with an authorization mechanism that doesn't verify if an authorized caller is allowed to send Ether (ETH) value along with a function call. The `AuthUpgradeable` contract, as described in the [DeepWiki](https://deepwiki.com/yoprotocol/core), "provides role-based access control throughout the protocol" and "ensures that only authorized addresses can perform privileged operations." This means if an attacker compromises _any_ address that has been granted authorization to call _any_ function through the `manage()` function (e.g., via phishing, malware, or a private key leak), they could exploit this privilege to drain the vault's entire ETH balance. Spearbit's review further highlighted that an **operator can change the share-to-asset exchange rate** at their discretion during `fulfillRedeem()`, reinforcing the significant power vested in these centralized roles. Furthermore, Spearbit identified that **inflation griefing attacks are possible** for initial depositors due to the default `_decimalsOffset()` not being overridden. While Yo Protocol acknowledged this primarily affects the very first user and is mitigated by private deployment scripts, it points to a design vulnerability in extreme conditions. The protocol's reliance on highly trusted operators who can "execute arbitrary calls with vault's assets" implies that the security of the entire system ultimately hinges on the impeccable security of these few operators. While the [Yo Protocol documentation](https://docs.yo.xyz/) states it is "fully decentralized, meaning you’re always in control of your assets", this appears to refer to user custody rather than core protocol governance and operational control, which remains centralized in critical aspects.

#### Lessons from Past Exploits

These aren't hypothetical scenarios; **platforms like** [**rekt.news**](http://rekt.news) **frequently report on such incidents**. Consider the [BTCTurk private key leak](https://rekt.news/btcturk-rekt), which resulted in $55 million, then $51.7 million, being stolen. Or the [Venus Protocol](https://venus.io/) founder falling for a [malicious Zoom link](https://rekt.news/phished-founder-liquidated-thief), leading to a $13 million loss. The [Swissborg $41.5 million loss](https://rekt.news/swissborg-rekt) due to a trusted partner ([Kiln](https://www.kiln.fi/)) being "API-owned" further underscores the cascading risk when centralized control points are compromised.

#### Enhancing Operational Security

It's crucial to **document this behavior clearly** in the code and external documentation, as highlighted in security reviews. Authorization must **only be granted to highly trusted addresses**. Furthermore, the protocol should **consider implementing additional controls and restrictions** to reduce these centralization risks over time as it matures, as recommended by security auditors. This includes potentially implementing multi-signature requirements or time-locks for critical operations, and implementing checks to ensure `fulfillRedeem()` only processes shares and assets in correct proportions.

### 2\. MEV (Miner Extractable Value) / Sandwich Attacks

The Yo Protocol's mechanism for updating underlying balances creates predictable arbitrage opportunities. This is primarily due to its system of updating the total market value across all chains approximately once per day through the `onUnderlyingBalanceUpdate()` function. The [DeepWiki](https://deepwiki.com/yoprotocol/core) notes that the vault can "fetch and update underlying balances from an external oracle", and that it has "Pausability" in case of "significant balance discrepancies detected through oracle updates." This creates **discrete jumps in asset valuation** instead of smooth price changes, a point raised in all audit findings. Spearbit explicitly stated that `onUnderlyingBalanceUpdate` **can be sandwiched**, directly confirming earlier reports. Additionally, Spearbit found that **depositors can exploit incorrect price ratios from yield gains to get more shares**, where yield accrual between a redemption request and fulfillment can skew the total asset-to-share ratio, allowing new depositors to mint more shares than intended.

An attacker (or an MEV bot) can continuously monitor the blockchain mempool for these `onUnderlyingBalanceUpdate()` transactions. When they see a transaction that will increase the aggregated balance, they can **front-run** it with a large deposit into the vault at the current, lower price. Once the balance update completes (increasing the price), they can **back-run** with an instant redemption of their shares at the new, higher price, effectively capturing the yield increase that would have otherwise gone to legitimate long-term holders. While the profit per individual attack might be "bounded by the size of the yield 'jump'," consistent exploitation can significantly erode the yield for legitimate users and make the protocol less attractive over time. Yo Protocol has acknowledged this issue and stated they are using private RPCs to mitigate this specific sandwich attack vector.

#### MEV in Action: Real-World Exploits

This is a classic MEV attack vector. **Rekt.news** has highlighted how [Coinbase lost $550K](https://rekt.news/drained-by-design) after an MEV bot exploited ERC-20 approvals to drain tokens, and [Odin.Fun hemorrhaged $7 million](https://rekt.news/odin-fun-rekt) through "basic AMM manipulation".

#### Strategies to Combat Arbitrage

A key recommendation from audits is to **ensure that the** `aggregatedUnderlyingBalances` **is always updated within the same transaction** when funds are leaving the vault's balance. Additionally, given the complexity of handling jumps in accumulated rewards, the protocol should **consider implementing a more gradual approach to updating underlying asset balances** or **adding cool-down periods before withdrawals** to prevent sandwich attacks. Furthermore, for the specific issue of depositors exploiting incorrect price ratios, auditors recommend updating total shares and total assets to reflect reserved pending redemption amounts, as these assets are essentially locked in a predetermined ratio.

### 3\. Precision and Balance Tracking Errors

Seemingly minor accounting and rounding errors can lead to significant financial discrepancies.

*   **Total pending assets not accounting for fees:** The `totalPendingAssets` variable is updated with the net asset amount (assets _after_ fees) instead of the total amount including fees. This leads to an overestimation of the actually available balance, as identified in Hunter Security and Offbeat Security reviews. Spearbit further found that the **results of** `pendingRedeemRequest()` **are misleading** because they store the expected `assetsWithFee` without subtracting fees, and fees can change. Consequently, if a user initiates a large redemption, the system might believe more funds are available than truly exist, allowing other users to "jump the queue" and withdraw funds meant for the pending redemption, potentially causing a temporary liquidity crunch or a failed redemption for the initial user.
    
*   **Precision loss in fee calculations:** Fees are calculated twice (once during request, again during withdrawal), which can introduce rounding errors and lead to small, unrecoverable "dust" amounts accumulating within the contract, as noted by Offbeat Security. While individually negligible, this trapped value could either be exploited by a clever attacker or simply represent unrecoverable funds for the protocol.
    
*   **Revert on zero** `totalSupply()`**:** Spearbit also identified that `onUnderlyingBalanceUpdate()` **could revert on** `totalSupply()` **of 0**, making it impossible to call `_pause()` in such a scenario. While fixed in PR, it highlights a potential robustness issue related to the vault's underlying state.
    

#### Precision Matters: Past Vulnerabilities

The [Bunni protocol's $8.4 million loss](https://rekt.news/bunni-rekt) due to a "basic rounding bug" serves as a stark reminder that even seemingly minor precision issues can have catastrophic financial consequences in DeFi. Similarly, [BetterBank lost $5 million](https://rekt.news/betterbank-rekt) due to a "simple incentive flaw" in its reward logic, demonstrating how mathematical miscalculations can quickly turn into catastrophic losses. The [Cyfrin Solodit](https://www.solodit.xyz/) comprehensive database of smart contract vulnerabilities can be an invaluable resource for developers and auditors to study past exploits and prevent similar issues in their own protocols.

#### Recommendations for Impeccable Accounting

To address the first issue, `totalPendingAssets` should be **increased by the** `assetsWithFee` instead of just `assets` in the `requestRedeem` function, as recommended by auditors. For precision loss, the recommendation is to **store the** `assetsWithFee` **amount** instead of the fee-subtracted assets, and **modify** `_withdraw()` **to handle fee calculations in a single place**, ensuring consistent calculations and preventing dust accumulation. For misleading `pendingRedeemRequest()` results, auditors recommend either subtracting fees and adding a comment that fees can change, or explicitly locking in fees at the time of request.

### 4\. EIP Compliance and User Experience Deficiencies

Issues related to standard compliance and user control can lead to unexpected financial outcomes or operational friction. The [DeepWiki](https://deepwiki.com/yoprotocol/core) highlights "ERC4626 Compliance" and "Asynchronous Redemption" as key features of the protocol.

*   **EIP-4626 non-compliance:** The `requestRedeem` function does not fully comply with the EIP-4626 standard for redeem flows and `previewWithdraw` functions, as it does not support approvals or account for withdrawal fees, a point raised in both Hunter Security and Offbeat Security reports. Spearbit also highlighted that `maxDeposit`, `maxMint`, `maxWithdraw`, and `maxRedeem` functions should **return 0 when the contract is paused** to properly comply with ERC4626 paused state expectations.
    
*   **Inability to cancel withdrawal requests:** Users cannot cancel their own pending redemption requests, as noted in the audit findings. This exposes users to market risk, as they might be forced to redeem at a significant loss if asset prices change unfavorably during the delay before fulfillment.
    
*   **Cancelled redemption shares returned to receiver instead of owner:** When a redemption request is cancelled, the shares are returned to the `receiver` address specified in the original request, not necessarily the `owner` who initiated it. This was an informational finding from Offbeat Security and confirmed as a low-risk issue by Spearbit, noting that **tokens may not be going to respective wallets**. If the owner and receiver are different, this can lead to unintended transfers or disputes. If the receiver address is compromised or malicious, they could unjustly claim shares intended for the original owner.
    
*   **Informational Issues:** Other minor but critical issues identified across audits include allowing `address(0)` as a receiver (which could lead to assets being permanently locked or burned), passing `msg.sender` instead of `receiver` in `_withdraw` (sending funds to the wrong party), misleading comments, and EIP-4626 non-compliance for `maxDeposit` and `maxMint` when the protocol is paused. Spearbit further pointed out that the **return value of** `requestRedeem()` **is not optimal** and that there are **different patterns to update** `_pendingRedeem[]`, leading to code inconsistency. Additionally, Spearbit recommended considering **using** `block.timestamp` **instead of** `block.number` **to track balance updates** on L2 networks like Arbitrum, where `block.number` can reflect L1 block numbers, potentially causing timing discrepancies. They also noted **two ways to transfer shares** being used inconsistently. A low-risk finding related to code quality from Spearbit was that the `__Context_init()` function isn't called, a fix for future-proofing. Lastly, a low-risk finding highlighted that a `deposit` might **coincide with an** `updateDepositFee` causing a user to receive slightly less shares than expected, suggesting users specify a maximum acceptable fee.
    

#### User Experience and Protocol Standards

External dApps or aggregators that integrate with Yo Protocol, expecting full EIP-4626 compliance, might receive incorrect `previewWithdraw` values (not accounting for fees) or be unable to execute certain approved redemption flows. This can lead to users being misled about the final withdrawal amount, causing financial disappointment, or hindering interoperability, limiting the protocol's adoption. A user stuck with an unfulfillable redemption due to adverse market changes faces direct financial loss, a significant user experience failure.

#### Improving EIP Compliance and User Control

![](https://storage.googleapis.com/papyrus_images/ab8f87f20da4daa50a774f9371ebd625c662597308d3e819ac5c83a2656fd6c8.png)

Yo Protocol GitHub Repo: Makes us remember Anchor / Terra.

The protocol should **override** `previewWithdraw()` **to accurately account for fees**, or, if only asynchronous withdrawals are supported, follow EIP-7540 and revert, as recommended by security reviews. To improve user control, **consider allowing users to cancel their own redeem requests** or **introducing a deadline parameter** for redemptions. For cancelled redemptions, either **implement owner tracking** (though this requires significant architectural changes) or, at minimum, **update code comments and external documentation** to clearly reflect that shares return to the designated receiver. All **typographical mistakes, non-critical issues, and centralization vulnerabilities** enumerated in the informational findings should be addressed, including preventing `address(0)` as a receiver and ensuring correct use of `msg.sender` versus `receiver`. Additionally, the documentation in the [yoprotocol/yield-server GitHub repository](https://github.com/yoprotocol/yield-server) should **replace the** [**Anchor Protocol**](https://app.anchorprotocol.com/#/earn) **example with one from a currently successful and stable protocol** to foster greater trust and confidence in the project's adherence to best practices and learning from past industry events. General code quality improvements like **adding input validation sanity checks**, addressing **shadowed state variables**, and **improving documentation around trust assumptions and operator privileges** are also vital, as suggested by Offbeat Security.

### The Critical Role of Bug Bounties: An Incentive Alignment Challenge

Beyond initial code audits, a robust bug bounty program is a cornerstone of continuous security in DeFi. The Yo Protocol has an active bug bounty program hosted on [Immunefi](https://immunefi.com/bounty/yoprotocol/), a leading Web3 security platform.

Currently, Yo Protocol offers a **maximum bounty of $10,000 for critical smart contract vulnerabilities**, with a minimum payout of $5,000. The reward calculation is stated as **10% of the funds directly affected, up to this $10,000 maximum**. The program also requires Proof of Concept (PoC) and KYC information for payout processing. Yo Protocol employs a "Primacy of Impact" approach for critical and high-severity issues, encouraging researchers to report any in-scope impact regardless of affected assets.

However, when viewed through the lens of the [**rekt.news article "Cutting Corners"**](https://rekt.news/cutting-corners)**,** Yo Protocol's bug bounty structure raises significant concerns regarding incentive alignment. The article vividly describes how **"exploitation now pays orders of magnitude more than disclosure"** when bounties are capped too low. Protocols are depicted as "pinching pennies on security, then act shocked when someone finds the vulnerabilities they refused to pay for."

#### The Economics of Exploitation: Insights from _rekt.news_

The "[Cutting Corners](https://rekt.news/cutting-corners)" article highlights that the [Immunefi](https://immunefi.com/) CEO, Mitchell Amador, advocates for bounties around **10% of funds at risk** to make disclosure more profitable than exploitation. For example, protecting $10 million should ideally involve a bounty of up to $1 million. Yo Protocol explicitly acknowledges "substantial financial losses" as a potential outcome from its vulnerabilities, such as a compromised operator key leading to the draining of the "vault's entire ETH balance." If the vault were to hold, for instance, $1 million in ETH, a 10% bounty would be $100,000. Yet, Yo Protocol's **$10,000 cap** for critical smart contract bugs means that even if a whitehat discovers a vulnerability capable of draining millions, their maximum reward would be fixed at this relatively low amount.

This discrepancy creates a **misaligned incentive structure**, as argued in the **rekt.news** article. The article points out that [Cork Protocol](https://www.cork.tech/) (audited by [Cantina](https://cantina.xyz/))'s $100,000 bounty cap couldn't prevent a $12 million hack, demonstrating that a cap significantly below the funds at risk is an invitation for exploitation. Similarly, [SuperRare's](https://superrare.com/) $730,000 loss was attributed to having no public bug bounty program. Given the potential for "substantial financial losses" in the Yo Protocol, a $10,000 maximum bounty might be insufficient to motivate top-tier security researchers to dedicate the extensive time and effort required to uncover complex vulnerabilities, especially when a malicious actor could potentially gain far more by exploiting them. This positions Yo Protocol among the platforms that **rekt.news** warns are "racing toward the bottom" with "discount security." The current structure, according to the rekt.news thesis, risks creating a "death spiral that benefits no one except malicious actors."

#### Aligning Incentives for Robust Security

To genuinely align incentives and effectively safeguard user funds, Yo Protocol should **significantly increase its maximum bug bounty payout** for critical vulnerabilities. The bounty should reflect a more substantial percentage of the actual funds at risk, especially considering the "vault's entire ETH balance" could be compromised. Protocols like [LayerZero ($15 million)](https://layerzero.network/), [MakerDAO/Sky ($10 million)](https://makerdao.com/), and [Wormhole ($5 million)](https://wormhole.com/) set industry benchmarks by offering rewards that make disclosure unambiguously more profitable than exploitation, leading to stronger security outcomes. Revisiting this cap to be commensurate with the potential impact of vulnerabilities, rather than a fixed low amount, is crucial for fostering robust, continuous security. Lessons from GMX and [KiloEx](https://kiloex.io/), which offered substantial _recovery_ bounties after being hacked, reinforce that the funds are available—the choice lies in proactive prevention versus reactive damage control.

### Conclusion: Beyond the Code

While code audits by reputable firms like [Hunter Security](https://www.huntersec.co/), [Offbeat Security](https://offbeatsecurity.com/), and [Spearbit](https://www.spearbit.com/) are a fundamental step in smart contract security, and the Yo Protocol has transparently shared its design on [DeepWiki](https://deepwiki.com/yoprotocol/core) and [official documentation](https://docs.yo.xyz/), this case clearly demonstrates that **they are just the beginning, especially for a protocol so deeply embedded in the DeFi landscape.** The most critical vulnerabilities often lie beyond immediately exploitable code bugs, residing instead in **centralized operational control, critical design choices, and subtle logic flaws**. For a protocol that acts as a bridge and optimizer for numerous other platforms, ensuring robust measures against these risks is not just about Yo Protocol itself, but about safeguarding a significant segment of the blockchain ecosystem. This makes a comprehensive security strategy, beyond just fixing code bugs, crucial for the long-term security and trustworthiness of the Yo Protocol and, by extension, its many integrated partners.

For protocols seeking to go beyond basic audits and implement comprehensive, continuous security solutions, platforms like [**Sherlock**](https://www.sherlock.xyz/) offer advanced security suites, audit contests, and bug bounties powered by top security researchers. With a track record of finding over 1,500 critical vulnerabilities and securing over $100 billion in TVL, **Sherlock** provides solutions from early development to scaling, ensuring protocols are prepared for the threats ahead. By embracing a holistic approach to security, including rigorous design reviews, continuous monitoring, and community-driven bug bounties with properly aligned incentives, protocols can build truly resilient and trustworthy systems.

The ultimate goal of analyses like this is to contribute to a safer and more transparent blockchain ecosystem. We urge the Yo Protocol development team to provide regular updates to the community regarding the status of the issues identified in their audit reports and the steps being taken to address them. We wish the Yo Protocol every success in its journey towards achieving truly robust security for its users and its integrated partners.

* * *

**Endnote from the On-chain Analyst:**

This analysis represents a deep dive into the Yo Protocol's architecture and security posture, drawing on multiple sources and highlighting potential risks that extend beyond initial audit findings. The effort involved in synthesizing this information and drawing actionable conclusions is considerable. If you find this kind of detailed on-chain reporting valuable for understanding the true risks in the DeFi ecosystem, please consider supporting my work;

You can directly support this ongoing research and reporting by **minting an NFT of this article**. Your support helps make the blockchain a safer place for everyone.

For those interested in exploring **Yo Protocol** firsthand, you can use my referral link: [https://app.yo.xyz?ref=parlan](https://app.yo.xyz?ref=parlan). This referral system allows me to earn 10% of the points accumulated by those I refer, while referred users receive a 10% boost to their own points. Please remember that investing in innovative DeFi protocols involves inherent risks, and it is crucial to only invest amounts you are comfortable losing.

Donations and support enable me to continue dedicating the necessary time and resources to these comprehensive investigations.

**Address for donations and support:** bparlan.eth 0xaD5d1F9e5B07ea8ABD262Ed16aAF21cfa9C8EB18

---

*Originally published on [Parlan@Paragraph](https://paragraph.com/@parlan/yo-protocols-unseen-dangers-why-code-audits-arent-enough)*