On April 29, 2026, PeckShield's warning sounded twice on the same day: Two unrelated DeFi events on-chain were marked as "abnormal," yet pointed to the same keyword—authorization. The first involved a user related to Alchemix's Yearn yvVault whose yvWETH position was quietly transferred away, fully drained of approximately $1 million in equivalent assets following a "mistaken authorization"; the second was a treasury named YieldCore-3rd-deal, which was entirely liquidated in a single operation, with around $398,000 funds exploited due to the contract lacking a caller authorization check, being emptied in one go by the attacker.

Superficially, these appear to be two completely different attack paths: on one end is the ordinary user, who easily relinquished control over their yvWETH by interacting with an unverified contract, laying the groundwork for subsequent attacks; on the other end is the treasury itself, which left a gap in its permission design, allowing anyone to "make decisions for the treasury" without authorization. The first case was attributed to "user's mistaken authorization leading to asset theft," while the second was defined as "the protocol treasury contract vulnerability being exploited." This contrasting group exposed on the same day quickly attracted media attention and went viral.

This was not a minor incident that could be easily dismissed: on one side was a million-dollar personal position, and on the other side was nearly $400,000 of treasury funds, one stemming from user behavior and the other from protocol code, yet both revealed "authorization" as the most easily overlooked hidden bomb in the DeFi ecosystem. The following narrative will revolve around "authorization equals risk," tracing the real cost behind each click of "allow," while dissecting the structural shortcomings in permission design between treasuries and strategy contracts. Additionally, it will re-examine the role of security agencies like PeckShield between proactive prevention and post-incident disclosure in these two cases.

A Mistaken Authorization Costing Alchemix Users Millions

For that Yearn yvVault user utilizing Alchemix, "authorization" started as just an ordinary click action.

About ten days before the funds were transferred, an unverified contract quietly appeared on-chain. Its source code was not made public on the browser, and its logic was not widely examined by the community; it simply existed as a string of address. Subsequently, this user actively interacted with it and granted it a crucial right—allowing the contract to operate their yvWETH position within the Alchemix-related Yearn yvVault.

On the surface, everything unfolded as per the usual script: the user called the contract through the frontend, a wallet pop-up requested authorization, and after clicking "allow," the contract acquired operational rights over the user's yvWETH assets. Once authorization is written onto the chain, the protocol layer treats it as a given signal: as long as the caller complies with the permission rules, the treasury typically executes transfers and position changes.

The real danger hid within that contract logic, which no one had seen or verified. A post-event research brief pointed out that this unverified contract had a vulnerability that could be used to execute arbitrary calls. For ordinary users, such a description feels abstract and distant; for attackers, it means that controlling this contract equates to possessing a universal key to substitute the already authorized user and initiate a series of "legitimate" operations on the yvVault.

At some point before April 29, 2026, the attackers finally twisted this key. They exploited the contract's "arbitrary call" vulnerability, initiated a call, and transferred this user's yvWETH assets from the Alchemix yvVault. Ultimately, the yvWETH that was transferred away was valued at approximately $1 million—from the on-chain execution process, every step adhered to the contract rules, with the only issue being: everything hinged on that authorization of the unverified contract.

This is exactly the high-risk yet commonly underestimated daily operation within the DeFi context: granting authorization to an unfamiliar contract whose code has not been verified. In this model, "authorization" is not a one-off payment but a continuously valid permission—so long as the authorization exists, the contract can initiate asset operations on behalf of the user at any future point in time. If the contract itself has vulnerabilities or is exploited by malicious actors, this authorization will immediately turn from a convenient tool into a "spare key" in the hands of the other party.

Many users mistakenly believe the risk stems from "seemingly suspicious projects" while overlooking the fact that as long as there’s a contract address that can be invoked by the frontend, an authorization request can be initiated. Unverified contracts lack publicly available and widely scrutinized code, making reliance on "everyone has seen it," a form of social consensus, untenable. Therefore, during what seemed like a harmless interaction, users inadvertently handed over control of their yvWETH position to a contract whose logical details no one could delineate.

It is worth emphasizing that multiple analyses do not point fingers at the core contracts of Alchemix or Yearn. PeckShield, along with various Chinese crypto media that followed up, distinctly attributed the root cause of the incident to the user's mistaken authorization of the unverified contract: the core treasury merely responded to the call according to existing permission rules, without exposing any severe vulnerabilities that were directly compromised. The genuine gap stemmed from the user's seemingly ordinary yet, in reality, highly risky authorization history.

Missing Authorization Check, YieldCore Treasury Emptied

If the previous Alchemix user handed the key over to a stranger, the issue with the YieldCore-3rd-deal treasury lies within the lock itself—the lock cylinder was empty from the very beginning.

In PeckShield's monitoring records, the abnormal transfer from YieldCore-3rd-deal occurred with unusual brevity: the attacker invoked critical transfer logic within the treasury contract to transfer all funds out in one go, leaving only a series of "successful execution" transaction receipts on-chain. Subsequent media, including PANews, estimated the treasury was emptied of approximately $398,000, a loss substantial enough to be lethal for a single treasury.

The technical conclusion provided by the research brief is not complicated: the YieldCore-3rd-deal contract lacked a caller authorization check. In simpler terms, the contract's code failed to confirm "who has the right to issue this instruction" when designing key transfer functions—so long as someone initiated a call, the contract obediently executed the transfer of funds from the treasury. It neither verifies whether the caller is the designated administrator nor checks if any internal authorization process has been passed; the attacker exploited this loophole, accomplishing the fund transfer without ever receiving internal authorization from the contract.

This type of "caller authorization check" typically constitutes the most basic gate in permission design: any function that touches treasury assets must first ask, "Who are you?" and "Do you have the qualifications to do this?" Without this inquiry, so-called "treasuries" devolve into public wallets that anyone can open. The research brief identified this as the primary cause of the attack, meaning that this incident was not a complex zero-day vulnerability but rather a fundamental mistake almost outlined on the first page of a textbook—yet in 2026, it was still enough to wipe nearly $400,000 from a contract.

Discussions surrounding this incident quickly extended to rumors that YieldCore-3rd-deal might be associated with the Trading Protocol ecosystem. Some opinions suggest this treasury might have been created under an "unpermissioned listing" open model—allowing anyone to deploy strategies and connect to liquidity pools, while the protocol itself might struggle to timely cover permission designs for every new treasury. However, the research brief also clearly emphasized that the formal relationship between the treasury and the Trading Protocol core protocol, as well as whether it was created through "unpermissioned listing," remain in a state of confirmation and cannot be treated as established facts.

Security research accounts like ExVul and media accounts like defiprime have also provided their interpretations of the technical causes and severity of this incident, with some further refining the issues down to specific checks in withdrawal logic, while others simply described it as "missing authorization checks leading to the treasury being emptied, which is profoundly tragic even in 2026." But these statements were collectively marked as "unverified information" in the brief and can only serve as reference perspectives; the core reason for the theft remains encapsulated in that simple conclusion—a treasury contract lacking the most basic caller authorization check hardly qualifies as a treasury on the blockchain.

Coexistence of Misoperation and Vulnerability, DeFi's Two Defensive Lines Breached

If we place these two attacks on a timeline, it’s hard not to view them as two defensive lines collapsing one after the other within the same security system: one end is the user holding signing authority, and the other is the protocol written into the contracts.

In the first Alchemix-related Yearn yvVault incident, the problem is distinctly categorized on the "user behavior" side in the brief. About ten days before the theft occurred, an unverified contract was deployed on-chain with a vulnerability that could be utilized to execute arbitrary calls. Subsequently, the user holding the yvWETH position interacted with it and personally granted the authorization to operate their yvWETH within the Alchemix yvVault to this contract. What the attacker needed to do was simplified: waiting for the right moment, utilizing this piece of vulnerable code, and transferring approximately $1 million worth of yvWETH using this contract. The one passively bearing the consequences here is that seemingly ordinary yet ultimately fatal authorization action—rather than the Alchemix or Yearn's official treasury code itself.

The second incident involving the YieldCore-3rd-deal treasury points instead to the entirely opposite end. The brief categorizes it under "protocol design vs security audit": the treasury contract itself lacked a caller authorization check. In other words, within the logic of this contract, who calls and whether they have authorization do not constitute preconditions for executing transfers. The result is that an attacker can initiate a transfer of the entire treasury funds without obtaining any internal authorization from the contract, causing a loss of about $398,000. There’s no occurrence of some careless user clicking "confirm" on a suspicious address; even the most cautious user cannot prevent a treasury that fundamentally relinquished the basic authorization checks from being emptied "with one click."

These two events have made the "two defensive lines" in DeFi security, often counted abstractly, more tangible. The first defensive line is on the user end: when you click to confirm, to whom you grant authorization, what the authorization amount is, and whether you periodically clear old authorizations; the second defensive line is on the protocol end: whether the contract strictly checks callers, whether permissions are reasonably allocated, and whether "who can move money" is written as an unbypassable hard rule. The first event proved a brutal fact: even if the mainstream treasury codes on the protocol end have no direct vulnerabilities, as long as the user-end defensive line is breached due to a mistaken authorization of an unverified contract, funds can still be siphoned away through that seam. The second event, conversely, illustrates that when the protocol end flatly lacks the most basic caller authorization checks, a user’s extreme caution in not interacting with unknown contracts and careful management of their authorization list cannot stop the entire treasury from being "emptied in one swoop."

In a broader industry context, these two defensive lines have also been structurally pushed into a high-pressure state. Typical DeFi interactions rely on the ERC-20 allowance model; users often choose to grant contracts unlimited allowances to avoid the hassle of repeated authorizations, and once authorization is successfully granted, there’s rarely a habit of actively revoking it. Meanwhile, high-frequency interactions and complex contract combinations surrounding various treasuries, aggregators, and routers continually add to the "authorization objects"—each additional strategy integrated, every router used, leaves behind a potentially exploitable path in one’s history.

In such an environment, the history of authorizations itself gradually becomes the largest invisible attack surface for DeFi users: those authorization records that have long been forgotten and initially seemed unimportant may suddenly link together to form an attack chain one day. In the first incident, the unverified contract that was created only ten days before the attack and had never been verified serves as a typical example; in the second incident, the YieldCore-3rd-deal treasury lacking an authorization check serves as a reminder: even if user-side treats every authorization as a high-risk operation, as long as there exists a treasury that can be “unpermissioned listed” without proper permission design, the protocol side's defensive line remains breached.

The brief therefore emphasizes "authorization equals risk" not only to warn users against easily granting access to unknown contracts but also to communicate to protocol sides: the user and protocol sides operate as a linked defense system; any carelessness on one side will nullify all efforts made on the other.

PeckShield Sounds the Alarm, Security Firms on the Frontline

Outside of this "user-protocol" joint defense system, the first to react promptly on April 29 was actually an on-chain security company. On April 29, 2026, PeckShield's monitoring system first detected an abnormal operation within the Alchemix-related Yearn yvVault: a user's yvWETH position was entirely transferred out, with an estimated loss of about $1 million. Almost at the same time, the treasury named YieldCore-3rd-deal was also found to have its funds entirely emptied, with approximately $398,000 being withdrawn from the treasury contract in the same manner.

Both incidents were first "seen" on-chain by PeckShield before being "realized" by the outside world. On April 29, it sequentially released abnormal information about these two independent events through social media and alert channels, providing an approximate loss amount and preliminary cause assessment. Subsequently, several Chinese crypto media quickly followed up, using PeckShield's on-chain data as the main framework for their reports: in the Alchemix yvVault incident, the media almost verbatim replicated its analytical conclusion, categorizing the root cause as "the user's prior authorization of an unverified contract," referencing its approximate loss of $1 million; in the YieldCore-3rd-deal treasury incident, the figure of about $398,000 came directly from citations of PeckShield and PANews.

From the timeline, PeckShield's role in these two incidents extends beyond "post-incident review." Its primary responsibility was real-time monitoring: before the protocol sides publicly voiced concerns and users had a chance to react, the monitoring system had already filtered out abnormal transactions in the on-chain flow, bringing fundamental information such as "where did the problem occur?" and "what is the estimated loss?" to the forefront. Following that was technical tracing: in the Alchemix incident, it deconstructed the attack path down to "the unverified contract was created about 10 days before the attack, and the contract contained a vulnerability that could be used for arbitrary calls, plus the user was granted operational permission over the yvWETH assets"; in the YieldCore-3rd-deal incident, the research brief quoted its analysis, defining the primary reason as the lack of caller authorization checks in the treasury contract, enabling attackers to directly transfer funds without any internal authorization.

Once these technical conclusions are adopted by the media, they rapidly transform into the public version of the "official statement." In the Chinese context, security companies often simultaneously write the first paragraph of the incident report and the first sentence of post-incident discourse—"This was a theft resulting from users authorizing unverified contracts" and "This was a treasury being emptied because of missing basic permission checks in the contract." For ordinary users, this clear characterization makes the events more comprehensible; for protocol parties, it serves as a public incident report, pointing out where the vulnerabilities lie and categorizing the problems into different accountability areas of "user operation" or "code design."

This concentration of focus also makes the role of on-chain security companies in DeFi incidents multifaceted:
● First, they serve as an ongoing on-chain sentinel, providing the first alert "before project announcements" for the entire ecosystem through their monitoring systems;
● Second, as tech forensic experts, they connect seemingly chaotic transaction data into a narrative through deconstructing attack paths and permission designs;
● Third, they act as risk pointers for both users and protocols—reaffirming the "high danger of authorizing unverified contracts" and translating seemingly abstract design flaws like "contracts lacking caller authorization checks" into concrete consequences.

However, as more and more media heavily rely on such institutions' data and characterizations in incident reports, a reality also emerges: who is crafting the narrative for each security incident? The research brief mentions that within the community, there is no lack of debate regarding how confidently security companies should disclose information, how promptly they should provide characterizations, and their position concerning incident discourse. On one hand, security research accounts and media like ExVul and defiprime attempt to express opinions concerning technical details and seriousness after incidents, but these contents are still labeled as unverified information overall; on the other hand, specific evaluations and criticisms regarding PeckShield's disclosure behavior currently lack enough confirmed facts to support any clear conclusions.

What can be confirmed is that during sudden incidents like those on April 29, security companies like PeckShield have become the "third tier" within the joint defense system: bridging the cognition gap between users and protocols through real-time monitoring and technical tracing, helping to define whether the cause is "user-side authorization risk" or "protocol-side permission design flaw." They cannot replace careful authorization nor can they substitute secure and robust contract design, but at the moment of incident onset, they are often the first hand to press the alarm button.

Authorization Equals Life-and-Death Agreements, The DeFi Security War Is Far From Over

In these two incidents highlighted by PeckShield, approximately $1.4 million evaporated overnight: on one side, a single user was wiped out of about $1 million position because of rash authorization to an unverified contract; on the other side, a treasury lost approximately $398,000 in its entirety due to missing the most basic caller authorization check. Whether it’s "one address" or "one treasury," as long as there’s been a single oversight in the security chain, the losses are measured in the millions.

For ordinary users, "authorization" is not a routine pop-up; it is akin to signing a life and death agreement. If it's possible to sign less, do not sign more, and adhere to a few basic principles:

● Avoid interacting with unverified contracts whenever possible. The unverified contract in the first incident gained operational authorization over the yvWETH position shortly after deployment, which was subsequently exploited by an attacker. The most conservative approach toward any contract whose source is unclear, newly emerged, or hard to track is: don’t authorize, don’t interact.
● Control authorization amounts and frequency. If it is possible to authorize only the amount necessary for one transaction, do not click "maximum allowance" for convenience; for those requiring long-term authorization, a regular review should take place to revoke permissions from applications that are no longer used.
● Develop a habit of "regularly cleaning up historical authorizations." Many old applications and strategies have long since been forgotten yet still hold the keys for asset withdrawals. Set a fixed period (e.g., monthly, quarterly) to examine item by item using authorization management tools or blockchain explorers, and turn off permissions that can no longer be clearly explained.

From the perspective of protocols and developers, these two incidents expose another layer of oversight. The incident with the YieldCore-3rd-deal treasury fundamentally stemmed from the lack of caller authorization checks in the contract—this represents a basic threshold during contract writing that should theoretically have been caught during regular security audits or formal verification phases, yet ultimately manifested on the mainnet at the cost of $398,000. For any contract involving custodial assets, permission design must adhere to a "default deny" mindset:
● Assume all external calls are malicious unless explicitly authorized in the code;
● Never allow functions that "anyone can call" to directly touch funds;
● Use multiple checks and permission layers to minimize the impact radius of single-point failures.

Equally requiring reflection are those protocols that permit treasuries or strategies to "listed without permission." Following the second incident, the research brief suggested that between "openness" and "security," there must be a discussion of costs along with narratives: when anyone can list a treasury or strategy, long-tail risks will dramatically amplify; even if the main protocol is secure, a vulnerability in its margins can drag the entire ecosystem down. For project developers, this means:
● While maintaining openness, introduce stricter templates, risk control rules, and listing thresholds;
● Use audits, continuous code reviews, and bug bounties to cover long-tail strategies rather than merely focusing on "flagship treasuries";
● Acknowledge at the design level that "bad treasuries will always sneak in" and isolate them from core assets using permission isolation and risk grading mechanisms.

In the DeFi world of 2026, professional security agencies like PeckShield and active research communities are sounding alarms and examining causes in real-time. However, these two incidents also illustrate that relying solely on reactive monitoring cannot eliminate systemic risks. As the scale of on-chain assets continues to expand, the incentives for attacks will only grow stronger, and methods will become more sophisticated; similar incidents will most likely become more frequent rather than diminish naturally.

What truly determines whether DeFi can step onto the mainstream financial stage is not the next market cycle but rather the slowly constructed elements happening today:
● Safety education aimed at ordinary users, making "authorization equals risk" an instinctive response;
● Security infrastructure and industry standards for protocols ensuring that the most basic authorization checks and permission isolations become inviolable bottom lines;
● Incentives and constraints mechanisms for the entire ecosystem ensuring that the benefits of discovering and fixing vulnerabilities outweigh the temptations of making quick money by exploiting them.

Every current loss measured in millions serves as a reminder to everyone: the freedom and openness of the on-chain world must always be counterbalanced by safety awareness and engineering discipline. Every authorization signed by users and every line of permission code written by developers ultimately determine whether this industry remains a "high-risk experimental ground" or qualifies as serious financial infrastructure.

Join our community, let’s discuss and become stronger together!
Official Telegram community: https://t.me/aicoincn
AiCoin Chinese Twitter: https://x.com/AiCoinzh
OKX Benefits Group: https://aicoin.com/link/chat?cid=l61eM4owQ
Binance Benefits Group: https://aicoin.com/link/chat?cid=ynr7d1P6Z

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。