Smart Contract Audit | Security Monitoring | AML/CFT (KYA/KYT) | Crypto Investigation | @Phalcon_xyz @MetaSleuth @MetaDockTeam 👉TG: https://teapawt.org/t.co/owokTLanv5
Joined December 2020
- Tweets2.3K
- Following154
- Followers27.3K
- Likes1.4K
Pinned Tweet
If your crypto gets stolen today, you usually have two options: pay a professional firm thousands of dollars, assuming they'll even take a small case, or just give up.
We built Trace AI to give you a third.
It runs on the same tracing tech behind @MetaSleuth, which our team has used on on-chain cases worth over a billion dollars. 8 chains, 10 languages, and it starts at $5.
youtube.com/watch?v=SdcAEE2c…
BlockSec retweeted
UPDATE: Our further investigation suggests that most of the profit came from approximately 33.06B TENDRIL acquired in total for less than $10K through a liquidity position in an attacker-created V3 pool before the attack. The substantial price gap between the V3 and V2 pools enabled the attacker to cash out, while the burn-sync mechanism appears to have contributed only $10K+ in additional profit.
This raises an interesting question: why were so many TENDRIL tokens sold into the V3 pool across multiple swaps at such low prices? A rug pull or phishing?
Related transaction: app.blocksec.com/phalcon/exp…
Our system detected an attack on the TENDRIL/USDT liquidity pool on #BNB Chain hours ago, resulting in ~$556K in losses. The root cause was unsafe sell-tax logic that allowed the pool’s TENDRIL balance to be burned and its reserves synchronized before the seller’s remaining tokens entered the pool. This left a near-zero TENDRIL reserve, allowing the subsequent swap to drain virtually all remaining USDT.
The attacker used approximately 30.64M USDT in flash-loan funds to buy TENDRIL and manipulate the pool’s price and reserves. A subsequent sale triggered the token’s 30% tax and a call to its tax-handling contract (_poolControl). That contract sold the tax tokens, returned part of the USDT proceeds to the pair, then invoked controlburn() and sync() to reduce the recorded TENDRIL reserve to nearly zero. The seller’s remaining tokens then entered the pair, enabling the subsequent swap to extract virtually the entire remaining 4.42M USDT reserve. The attacker repaid the flash-loan funds within the same transaction and transferred approximately 308.96K USDT in profit.
Attack TX: app.blocksec.com/phalcon/exp…
BlockSec retweeted
Our system detected an attack on the TENDRIL/USDT liquidity pool on #BNB Chain hours ago, resulting in ~$556K in losses. The root cause was unsafe sell-tax logic that allowed the pool’s TENDRIL balance to be burned and its reserves synchronized before the seller’s remaining tokens entered the pool. This left a near-zero TENDRIL reserve, allowing the subsequent swap to drain virtually all remaining USDT.
The attacker used approximately 30.64M USDT in flash-loan funds to buy TENDRIL and manipulate the pool’s price and reserves. A subsequent sale triggered the token’s 30% tax and a call to its tax-handling contract (_poolControl). That contract sold the tax tokens, returned part of the USDT proceeds to the pair, then invoked controlburn() and sync() to reduce the recorded TENDRIL reserve to nearly zero. The seller’s remaining tokens then entered the pair, enabling the subsequent swap to extract virtually the entire remaining 4.42M USDT reserve. The attacker repaid the flash-loan funds within the same transaction and transferred approximately 308.96K USDT in profit.
Attack TX: app.blocksec.com/phalcon/exp…
🛡️ We're excited to introduce our Payment Security Solution.
It helps payment institutions identify vulnerabilities, validate defenses, prepare for incidents, and detect emerging threats across fiat and digital asset payments.
🎙️Join our upcoming webinar to explore how payment institutions can protect funds in the AI era, and learn more about the solution.
We’d love to have you join the conversation!
📅 Nov 11 | 7:00 PM (UTC+8)
Learn more ↓
blocksec.com/blog/payment-se…
BlockSec retweeted
NEAR security doesn’t often get an in-depth discussion.
Drawing on our NEAR audit experience, we take a closer look at NEAR’s underlying mechanisms and how the NEAR Intents attack unfolded, then explore security considerations and best practices for project teams.
Read the analysis 👇
NEAR Intents Exploit: Refund Flaw and Security Lessons
blocksec.com/blog/near-inten…
Congratulations on the launch! 🎉
Great to partner with @safe to bring our threat detection capabilities to Safenet Aegis, helping protect users before transactions are executed.
We’ll continue advancing transaction security and building a safer Web3 ecosystem.
🔊 Introducing Safenet Aegis: the first production-ready and fee-generating release of Safenet, secured by $SAFE.
Safenet is a decentralized security protocol for self-custody.
💲 A user submits a transaction to Safenet for a small fee.
👓 Sentinels @OpenCover, @BlockSecTeam, @candidelabs, and @IntentGuard check every transaction and are accountable for their verdicts.
✅ Validators @gnosis_, @greenfield_cap, @SafeLabs_, and Core Contributors attest the verdict onchain.
💂 A formally verified Safenet Guard can enforce the attestation, back on the user @safe , defending against threats.
Safenet is live on @ethereum @arbitrum and @gnosischain and is coming soon to @SafeLabs_ multisigs.
📄 Read more: safefoundation.org/blog/safe…
🌐 Website: safenet.xyz
Multiple Binance (@binance) hot wallets across several chains, including Ethereum, Arbitrum and Avalanche, were reportedly compromised, with losses reported so far estimated at ~$5.6B—potentially the largest crypto hack on record.
For example, on Ethereum, Binance 14 (0x28C6c0) was delegated via EIP-7702 to an unverified sweeper contract (0x63e842), with 0x7c8601 hardcoded as its authorized operator. Dozens of assets (e.g., ETH, USDT, USDC) were swept through several batch calls to multiple addresses.
The pattern suggests compromised signing or privileged operator access, though the initial compromise remains unknown.
The incident is still under investigation. According to the cited @cz_binance update, Tether froze ~$971M and Circle froze ~$823M. USD1 also announced steps to freeze an additional $27M linked to the hack, bringing the total frozen to approximately $1.82B.
One of the attack TX: app.blocksec.com/phalcon/exp…
BlockSec retweeted
Our system detected a suspicious transaction targeting zkLink @zkLink_Official Nova, resulting in approximately $780K in losses. The root cause was flawed authentication-state verification in the Arbitrator, combined with a caller-controlled external call in the claim path.
The protocol uses an Arbitrator to claim authenticated messages from source-chain message services and forward them through destination gateways. During a legitimate claim, an authenticated gateway callback stores finalizeMessageHash, which the Arbitrator checks against the expected source gateway, value, and message.
However, the Arbitrator failed to clear finalizeMessageHash between claims. Since transient storage persists until the transaction ends, a second claim could reuse the first claim’s authentication hash without a fresh authenticated callback. The claim path also accepted a caller-supplied target and calldata, allowing the attacker to execute a privileged root update through the Arbitrator and then pass verification using the stale hash.
The attacker exploited this in five steps:
1. Called the publicly accessible SyncL2TxHashRelayer to claim a valid Linea message synchronizing two transaction hashes. The authenticated callback populated finalizeMessageHash, and the Arbitrator forwarded the legitimate message to the Ethereum Gateway.
2. Called the same entry point again within the same transaction, replacing the Linea message-service target with the Ethereum Gateway and supplying sendMessage() calldata to invoke syncBatchRoot(116409, attackerChosenRoot, 0).
3. The Ethereum Gateway accepted the call from the trusted Arbitrator. The zkLink contract then accepted the attacker-chosen root because the update came from its authorized Gateway.
4. The second claim triggered no fresh authentication callback. By supplying the same expected source gateway, value, and message as the first claim, the attacker passed the Arbitrator’s hash check using the remaining finalizeMessageHash.
5. Submitted 12 withdrawal proofs matching the newly installed root, withdrawing 22.4313 ETH and 11 ERC20 assets, including approximately 245.74 pufETH, 18,113.45 USDC, and 12.57 ezETH.
The funds came from the zkLink contract’s ETH holdings and the ERC20 Bridge’s token reserves. All 12 withdrawal proofs reconstructed the attacker-installed root; the failure occurred in authenticating the root update.
Attack TX: app.blocksec.com/phalcon/exp…
BlockSec retweeted
Who can approve transactions? Who controls privileged access? How does the team respond to incidents?
These are operational security questions.
BlockSec’s SEAL @_SEAL_Org Certification Assessment evaluates operational controls and supporting evidence against the SEAL framework, with scope determined by the team’s systems, responsibilities, and risks.
Explore the six modules and the assessment process 👇
blocksec.com/seal-certificat…
If your protocol is ready to get certified, these firms are accredited and taking clients now.
Already working with one of them? Ask about SEAL Certifications starting today.
@audit_wizard @BlockSecTeam @chain_security @Composable_Sec @ConsensysAudits @cyfrin @DefiSafety @hackenclub @HackenProof @SecurityOak @OpenZeppelin @opsek_io @Quantstamp @0xshield3 @sigp_io @statemindio @trailofbits @Wonderland @zellic_io @zeroshadow_io
Announcement: radar.securityalliance.org/s…
BlockSec retweeted
A few hours ago, a USDC tranche vault on Avalanche lost ~$1M due to inconsistent principal accounting in the fund-user claim path.
The vault has two roles: the fund provider, who deposits and withdraws principal, and the fund user, who borrows funds from the tranche and is responsible for repaying them. The attacker controlled both roles within the same tranche, allowing them to deposit funds as the provider and immediately borrow them as the user.
The claim function deducted borrowed but unmatured principal from total deposits, but ignored matured yet unrepaid principal. When the attacker claimed again after maturity, the function first processed maturity records using the current timestamp, moving the previously borrowed principal into the matured balance, then checked the available amount. Because the calculation omitted the matured balance, it incorrectly restored the full borrowing allowance, even though nothing had been repaid.
Flawed formula:
Available = Total deposited − Borrowed, not yet matured
Correct formula:
Available = Total deposited − Borrowed, not yet matured − Matured, not yet repaid
The fund-provider withdrawal function correctly deducts both balances, while the fund-user claim function omits matured but unrepaid principal.
Key attack steps:
1. The attacker created a tranche with the same address as both fund provider and fund user, setting its maturity shortly afterward.
2. Using an Aave flash loan, the attacker deposited 1,013,353.61 USDC as the fund provider, then borrowed the entire principal as the fund user in the same transaction. They used those funds to repay the flash loan, paying a 506.68 USDC fee.
3. After 163 blocks, once maturity had passed, the attacker called claim again. The incorrectly restored allowance let them borrow another 1,013,353.61 USDC without repaying the first tranche loan or making a new deposit.
The second borrowing was funded by other users’ principal deposits in the vault.
Attack TX: app.blocksec.com/phalcon/exp…
BlockSec retweeted
2/ Of course, none of this happens without our top-tier audit providers:
@ABDKconsulting, @AdevarLabs, @bailsecurity, @BlockSecTeam, @Certora, @chain_security, @ConsensysAudits, @cyfrin, @dedaub, @GuardianAudits, @hackenclub, @HackenProof, @HalbornSecurity, @Hashlock_, @hexensio, @immunefi, @KannAudits, @LeastAuthority, @lethalspoons, @MixBytes, @NethermindSec, @OpenZeppelin, @Quantstamp, @QuillAudits_AI, @rv_inc, @SecurityOak, @sherlockdefi, @spearbit, @statemindio, @Veritylab, @yAuditDAO, @zellic_io, and @zokyo_io 🤝
Huge thanks for continuing to fund this support for builders!
BlockSec retweeted
1/ 🔐 Extension secured!
185 applications. 60+ projects supported. $500k in subsidies allocated.
We’re excited to bring 3 more months of the Ethereum Security Subsidy Program to @ethereum builders.
Big thanks to @ethereumfndn and @NethermindSec for helping make the pilot program a success - let’s keep it going!
BlockSec retweeted
ALERT! Our system detected a suspicious transaction targeting @x100global on Ethereum, resulting in an estimated loss of $4.75M. The root cause stems from a governance design flaw that allowed the attacker to acquire two of three Senate seats using flash-loan-funded X tokens and immediately approve and execute a malicious treasury proposal within the same transaction.
The attacker purchased X tokens using flash-loaned funds, distributed them to two controlled contracts, and froze them in the Freezer to obtain Senate seats. The attacker then created and supplied liquidity to a PancakeSwap V3 X-USDT pool. Using the captured majority, the attacker executed a proposal directing the Freezer to swap 400,000 X tokens into that pool with the minimum output set to zero, receiving only about 35.68 USDT. Finally, the attacker withdrew the liquidity, sold part of the recovered X tokens through the existing Uniswap V3 X-USDT pool, and repaid the flash loan.
Attack TX: app.blocksec.com/phalcon/exp…
BlockSec retweeted
A few hours ago, a NEM liquidity pool on #BSC lost ~$820K in a price manipulation attack that exploited a flaw in the NEM token’s tax-settlement mechanism.
The vulnerability lay in _flushLpSellRecycle(), which calculated the burn amount using pendingLpSellRecycle and burned NEM directly from the liquidity pool’s balance. It then called sync() to update the reserves, allowing the pool’s NEM price to be manipulated.
The attack proceeded as follows:
1. Transferred NEM directly to the pool to simulate sells and increase pendingLpSellRecycle.
2. Invoked skim() to recover most of the transferred tokens, reducing the attack cost without reducing pendingLpSellRecycle.
3. Invoked flushLpSellRecycle() to burn NEM from the pool. The burn amount was calculated as 70% of the pending amount, subject to pool-balance caps. The subsequent sync() call reduced the recorded NEM reserve, increasing NEM’s price relative to USDT.
4. Repeated steps 1–3 to raise the price further, then swapped NEM for USDT to realize a profit.
Attack TX: app.blocksec.com/phalcon/exp…
BlockSec retweeted
🗓 Weekly Web3 Security Roundup | Oct 12 - Oct 18
🚨 Spotlight on 3 notable incidents | ~$3.87M lost this week
Featuring a vulnerability breakdown and in-depth analysis of selected key cases👇
blocksec.com/blog/web3-secur…
Give @MetaSleuth a try, a much more cost-effective option for on-chain analysis and fund tracing.
. @arkham now limits free users to the latest 100 transactions, with 1500 USD per month for the subscription.
Looking for an alternative? Try MetaSleuthh for address intelligence, fund flow analysis, risk screening and monitoring.
metasleuth.io/
BlockSec retweeted
. @arkham now limits free users to the latest 100 transactions, with 1500 USD per month for the subscription.
Looking for an alternative? Try MetaSleuthh for address intelligence, fund flow analysis, risk screening and monitoring.
metasleuth.io/
BlockSec retweeted
.@_Qubic_ was reportedly exploited due to weak wallet seed generation. The issue now appears to have been fixed: github.com/qubic/wallet/comm…
However, the vulnerability was reported as early as February and does not appear to have been properly addressed at the time. The current fix also appears to follow the recommendation in that report: replacing Math.random() with crypto.getRandomValues().
Reports affecting critical components such as wallet seed generation deserve timely attention and follow-up.
BlockSec retweeted
.@UNCX_token was exploited across multiple chains for ~$1.5M. The root cause was inconsistent accounting of _totalTokenShares between release() and cancel(). This variable tracks the total outstanding shares of all schedules for a token.
Specifically, after release(), a schedule with _depositedShares = D and schedule.released = R has only D − R shares remaining in _totalTokenShares. However, cancel() removes D − V, where V is the recalculated vestedShare.
This accounting assumption can be broken through a donation followed by a top-up, which increases schedule.totalAmount while minting very few new shares and pushes V below R. Consequently, D − V exceeds the schedule’s remaining D − R shares, causing cancel() to deduct shares already removed by release(). This reduces the shared _totalTokenShares denominator and inflates the payout from the schedule retained by the attacker.
The key attack steps are illustrated using this exploit transaction:
app.blocksec.com/phalcon/exp…
1. Set up three schedules: The attacker created schedules 5058, 5059, and 5060. They fully released 5059 and 5060 while retaining 5058 for the final withdrawal.
2. Donate: The attacker transferred tokens directly to the vesting contract, inflating the asset-per-share value without minting new shares.
3. Top up and cancel: The attacker topped up schedules 5059 and 5060 with future-vesting tokens. Due to the manipulated share price, the top-ups greatly increased schedule.totalAmount while minting very few new shares, pushing vestedShare below schedule.released. Cancelling the schedules then deducted previously released shares from _totalTokenShares again.
4. Extract profits: With _totalTokenShares artificially reduced, the attacker released schedule 5058 at an inflated redemption value and repaid the flash loan.
The attacker repeated this process to drain assets from the vulnerable contract.
UNCX Vesting V2: Security Incident Update
Following the security incident affecting our Vesting V2 contracts across several chains earlier today, we want to share an update on the measures taken, the affected tokens, and what comes next.
1. Security measures and containment
We have implemented several measures to prevent further exploitation of the affected contracts:
> Introduced substantial flat fees exceeding 1,000 ETH per lock.
> Removed all clients and contract interactions that previously allowed these fees to be bypassed.
> Increased token fees to the maximum permitted by the Vesting V2 contracts (5%), making repeated vesting top-ups economically unviable.
These measures are designed to prevent further exploitation through the identified methods. While our investigation and monitoring remain ongoing, we firmly believe we have taken the necessary steps available to us to contain the incident.
2. Scope of the incident
As previously communicated, all LP lockers remain unaffected, across every protocol and chain supported by UNCX.
The incident is isolated to UNCX Vesting V2. Our legacy vesting contracts are also unaffected and have undergone additional checks and review.
The incident currently involves 10 tokens across 4 chains:
Ethereum (6): $pepecoin, $EDGEN, $ZC, $X, $LO0P, $PAAL
Base (1): $IMO
BNB Chain (1): $BTCLE
Robinhood Chain (2): $CASHCAT, $RKST
3. Next steps for affected projects and communities
We are already in contact with most of the affected teams, communities or individuals impacted.
We expect to share further guidance and next steps with affected teams this week.
We will also publish a comprehensive incident report covering the technical findings, financials, and the details of our proposed recovery plan.
Important: For all impacted tokens, we strongly advise against trading in the affected pools until further guidance is provided by the respective token teams. We will be coordinating directly with those teams over the coming days.
4. Investigation and recovery efforts
Our investigation remains active, and we are coordinating with law enforcement and @seal911.
To date, no funds have been returned by the attackers (primary and copycats) on any affected chain. We strongly encourage the responsible party to contact us directly to discuss a resolution.
We understand the seriousness of this incident for affected projects, holders, and communities.
Our immediate priorities remain preventing further exploitation, establishing the full extent of the impact, and working closely with affected teams toward a recovery plan.
We will continue to communicate when any meaningful updates become available.
Thank you for your patience.
The UNCX Team
BlockSec retweeted
🗓 Weekly Web3 Security Roundup | Oct 05 - Oct 11
🚨 Spotlight on 1 notable incident | ~$542K lost this week
Featuring a vulnerability breakdown and in-depth analysis of selected key cases👇
blocksec.com/blog/web3-secur…
