CRYPTO DEV

🔍 Smart Contract Security Researcher
Hunting bugs in DeFi, Solidity & Move ecosystems
PoC-driven vulnerability analysis | Audit learner
Responsible disclosure

[CRYPTO DEV @crypto_devEH]

Security disclosure note on Flex:

Users of Flex (@flexmeow) need to be extremely careful when interacting with this market.

I privately reported a reproducible lender-accounting issue involving liquidation callback ordering and bad-debt PPS updates.

The team dismissed the issue as 'not a problem' and claimed it had been handled in recent audits. They also asserted that this bug was previously reported by other researchers and rectified during the latest audit, which is a blatant lie, as I actually began my research after reading those very reports.

However, I reproduced the same behavior on the current public master branch with a Foundry PoC.

PoC result:
- liquidation receiver callback entered
- Lender share redeem attempted
- Lender share redeem succeeded
- PPS before forced bad-debt report: 1.000000
- PPS after forced bad-debt report: 0.933512
- measurable avoided loss shifted to remaining lenders

So the claim that this behavior is already fully rectified does not match the current public code behavior I tested.

The issue is not that PPS never updates. It does update after liquidation. The concern is that the callback executes before the forced bad-debt report, allowing stale-PPS redemption in that window.

After I challenged the dismissal and referenced the audit/fix gap, my Telegram DM was deleted / I was banned from their Telegram Group.

I am not publishing exploit code while funds may be at risk, but I’m preserving:

- PoC logs
- screenshots
- git diff
- affected test files
- live on-chain context

Flex users/lenders should ask the team directly whether in-callback Lender redemption before bad-debt reporting is intended, documented, and accepted risk. @0xsadikbaba

[CRYPTO DEV @crypto_devEH]

@omgcorn @flexmeow https://t.co/P4UTOhumgz

[CRYPTO DEV @crypto_devEH]

Security disclosure note on Flex:

Users of Flex (@flexmeow) need to be extremely careful when interacting with this market.

I privately reported a reproducible lender-accounting issue involving liquidation callback ordering and bad-debt PPS updates.

The team dismissed the issue as 'not a problem' and claimed it had been handled in recent audits. They also asserted that this bug was previously reported by other researchers and rectified during the latest audit, which is a blatant lie, as I actually began my research after reading those very reports.

However, I reproduced the same behavior on the current public master branch with a Foundry PoC.

PoC result:
- liquidation receiver callback entered
- Lender share redeem attempted
- Lender share redeem succeeded
- PPS before forced bad-debt report: 1.000000
- PPS after forced bad-debt report: 0.933512
- measurable avoided loss shifted to remaining lenders

So the claim that this behavior is already fully rectified does not match the current public code behavior I tested.

The issue is not that PPS never updates. It does update after liquidation. The concern is that the callback executes before the forced bad-debt report, allowing stale-PPS redemption in that window.

After I challenged the dismissal and referenced the audit/fix gap, my Telegram DM was deleted / I was banned from their Telegram Group.

I am not publishing exploit code while funds may be at risk, but I’m preserving:

- PoC logs
- screenshots
- git diff
- affected test files
- live on-chain context

Flex users/lenders should ask the team directly whether in-callback Lender redemption before bad-debt reporting is intended, documented, and accepted risk. @0xsadikbaba

[CRYPTO DEV @crypto_devEH]

The project team actually cheated me after I reported a real vulnerability that could drain funds from its vaults. I softly introduced the matter in their Telegram group, and the owner quickly DM'ed me, offering a bounty if it was meaningful. But after reading my PoC, he started making excuses, saying this was already reported by others and fixed in their recent audit. What? Then how does this real bug still exist on the mainnet?

In simple words, an attacker can cause a loss of more than 6% to lenders with each attempt and drain significant funds. Yet, the vague reply of the team was that they don't have an issue with it. Then they suddenly deleted all private DMs and banned me from the Telegram group. Moral of the story: day one of a Whitehat becoming a Blackhat.

[CRYPTO DEV @crypto_devEH]

The project team actually cheated me after I reported a real vulnerability that could drain funds from its vaults. I softly introduced the matter in their Telegram group, and the owner quickly DM'ed me, offering a bounty if it was meaningful. But after reading my PoC, he started making excuses, saying this was already reported by others and fixed in their recent audit. What? Then how does this real bug still exist on the mainnet?

In simple words, an attacker can cause a loss of more than 6% to lenders with each attempt and drain significant funds. Yet, the vague reply of the team was that they don't have an issue with it. Then they suddenly deleted all private DMs and banned me from the Telegram group. Moral of the story: day one of a Whitehat becoming a Blackhat.

[CRYPTO DEV @crypto_devEH]

Security disclosure note on Flex:

Users of Flex (@flexmeow) need to be extremely careful when interacting with this market.

I privately reported a reproducible lender-accounting issue involving liquidation callback ordering and bad-debt PPS updates.

The team dismissed the issue as 'not a problem' and claimed it had been handled in recent audits. They also asserted that this bug was previously reported by other researchers and rectified during the latest audit, which is a blatant lie, as I actually began my research after reading those very reports.

However, I reproduced the same behavior on the current public master branch with a Foundry PoC.

PoC result:
- liquidation receiver callback entered
- Lender share redeem attempted
- Lender share redeem succeeded
- PPS before forced bad-debt report: 1.000000
- PPS after forced bad-debt report: 0.933512
- measurable avoided loss shifted to remaining lenders

So the claim that this behavior is already fully rectified does not match the current public code behavior I tested.

The issue is not that PPS never updates. It does update after liquidation. The concern is that the callback executes before the forced bad-debt report, allowing stale-PPS redemption in that window.

After I challenged the dismissal and referenced the audit/fix gap, my Telegram DM was deleted / I was banned from their Telegram Group.

I am not publishing exploit code while funds may be at risk, but I’m preserving:

- PoC logs
- screenshots
- git diff
- affected test files
- live on-chain context

Flex users/lenders should ask the team directly whether in-callback Lender redemption before bad-debt reporting is intended, documented, and accepted risk. @0xsadikbaba

[Sadik @0xsadikbaba]

This is exactly why black hats keep winning.

@v12sec responsibly reported a critical loss-of funds bug to @THORChain $30M+ TVL, $150M FDV.

They silently patched it, said bounty program “permanently retired,” and offered him $0.

Suppose to Offer him $150k–$300k minimum now. But they chose to Ignore him and you’ll likely lose millions more just like the recent $10M+ exploit.

Whitehats get punished, protocols get drained.

When will teams learn?
Quote this if you are tired of the same broken cycle

Bookmark if you hunt bugs or run a protocol.

[CRYPTO DEV @crypto_devEH]

@AppKaskad Thanks for the response. I have sent the email to the provided address. I have intentionally avoided sharing technical details publicly for safety. Please confirm receipt and the responsible disclosure / bug bounty review process by email.

[CRYPTO DEV @crypto_devEH]

@AppKaskad Please check your DM as I found a potential high/critical issue affecting one deployed Kaskad Igra mainnet contract. If you are silently ignoring Whitehat alerts , your protocol will not run for longer.

[CRYPTO DEV @crypto_devEH]

@AppKaskad @DefiLlama @Igra_Labs Please check your DM as I I found a potential high/critical issue affecting one deployed Kaskad Igra mainnet contract.

[CRYPTO DEV @crypto_devEH]

@ibrahimatix0x01 @immunefi Congrats! Can you check your DM?

[CRYPTO DEV @crypto_devEH]

The bug bounty ecosystem has a serious trust problem.

Yesterday, I submitted a report with a clear runnable PoC against an in-scope asset, only for the platform to close it as “out of scope” without proper technical justification.

Last week, I responsibly disclosed another vulnerability with a fully reproducible PoC according to the program rules, complete silence from the project team.

I also found a critical issue in another protocol without a public bounty program. This time I withheld the sensitive exploit details and contacted them privately first. They acknowledged the email and promised a response. Nothing since then.

What’s frustrating is that many teams hesitate to pay a whitehat even a relatively small bounty for responsible disclosure. But when an actual exploit happens, the same teams suddenly offer hackers 10% recovery deals worth millions.

If protocols continue ignoring researchers, dismissing valid reports, or hiding behind vague “out of scope” claims, they are incentivizing silence instead of responsible disclosure.

In the end, everyone loses: the users, the protocols, and the security researchers trying to help before real attackers do.

[Sadik @0xsadikbaba]

Black hats always win

Whitehat spends weeks on a PoC, gets it accepted, saves the project $800M walks away with ~$4k.

Meanwhile, the Verus bridge attacker drains $11.58M, returns $8.5M after negotiation, and pockets $2.8M as bounty with no charges.

The system is not fair enough.

[CRYPTO DEV @crypto_devEH]

The bug bounty ecosystem has a serious trust problem.

Yesterday, I submitted a report with a clear runnable PoC against an in-scope asset, only for the platform to close it as “out of scope” without proper technical justification.

Last week, I responsibly disclosed another vulnerability with a fully reproducible PoC according to the program rules, complete silence from the project team.

I also found a critical issue in another protocol without a public bounty program. This time I withheld the sensitive exploit details and contacted them privately first. They acknowledged the email and promised a response. Nothing since then.

What’s frustrating is that many teams hesitate to pay a whitehat even a relatively small bounty for responsible disclosure. But when an actual exploit happens, the same teams suddenly offer hackers 10% recovery deals worth millions.

If protocols continue ignoring researchers, dismissing valid reports, or hiding behind vague “out of scope” claims, they are incentivizing silence instead of responsible disclosure.

In the end, everyone loses: the users, the protocols, and the security researchers trying to help before real attackers do.

[CRYPTO DEV @crypto_devEH]

Last week, I completed deep security research on two DeFi protocols and identified serious exploitable vulnerabilities including fund drains and other critical risks during my analysis. I provided a full Proof of Concept (PoC) and detailed findings to the project teams via email. Their response? Utter silence.

For the first protocol, I am currently holding back the PoC while awaiting an update from the team. However, the report for the second protocol will soon be published right here on my account. Follow me to stay informed, avoid vulnerable protocols, and secure your funds. If I don't hear back, I will publish my findings and tag the projects' X handles later.

[CRYPTO DEV @crypto_devEH]

@CryptoLakhan @grass @grass I suggest everyone report this account. He is a scammer. The official Grass website does not show a "new wallet card" section; this user is faking the interface and impersonating the project. Please stay vigilant and avoid the daily misinformation he is posting.

[CRYPTO DEV @crypto_devEH]

Recently identified and validated a potential precision-loss/accounting issue during independent security research involving Loopscale collateral valuation logic.

The research included technical analysis and working PoC validation related to unsafe bigint → number conversions, precision drift, and valuation inconsistency scenarios that may affect protocol accounting behavior under certain conditions.

A full responsible disclosure report was already submitted privately to [email protected] following the official bug bounty/disclosure process documented by the project.

I have not yet received acknowledgment, so tagging the founders here simply to help ensure the report reaches the appropriate internal security team for review.

Responsible disclosure matters when protocol security and user funds are involved.

[CRYPTO DEV @crypto_devEH]

Recently identified and validated a potential precision-loss/accounting issue during independent security research involving Loopscale collateral valuation logic.

The research included technical analysis and working PoC validation related to unsafe bigint → number conversions, precision drift, and valuation inconsistency scenarios that may affect protocol accounting behavior under certain conditions.

A full responsible disclosure report was already submitted privately to [email protected] following the official bug bounty/disclosure process documented by the project.

I have not yet received acknowledgment, so tagging the founders here simply to help ensure the report reaches the appropriate internal security team for review.

Responsible disclosure matters when protocol security and user funds are involved.

@Loopscale @marygooneratne @Luketruitt

[CRYPTO DEV @crypto_devEH]

Recently identified and validated a potential precision-loss/accounting issue during independent security research involving Loopscale collateral valuation logic.

The research included technical analysis and working PoC validation related to unsafe bigint → number conversions, precision drift, and valuation inconsistency scenarios that may affect protocol accounting behavior under certain conditions.

A full responsible disclosure report was already submitted privately to [email protected] following the official bug bounty/disclosure process documented by the project.

I have not yet received acknowledgment, so tagging the founders here simply to help ensure the report reaches the appropriate internal security team for review.

Responsible disclosure matters when protocol security and user funds are involved.

@Loopscale @marygooneratne @Luketruitt

#Web3Security #SmartContracts #DeFi #BlockchainSecurity

[CRYPTO DEV @crypto_devEH]

Last week, I completed deep security research on two DeFi protocols and identified serious exploitable vulnerabilities including fund drains and other critical risks during my analysis. I provided a full Proof of Concept (PoC) and detailed findings to the project teams via email. Their response? Utter silence.

For the first protocol, I am currently holding back the PoC while awaiting an update from the team. However, the report for the second protocol will soon be published right here on my account. Follow me to stay informed, avoid vulnerable protocols, and secure your funds. If I don't hear back, I will publish my findings and tag the projects' X handles within the week.

[CRYPTO DEV @crypto_devEH]

The developers of these projects are also to blame for such pathetic drains and the permanent shutdown of their protocols. Many recently exploited platforms were reportedly alerted in advance by elite security researchers, but the administrators hesitated to offer meaningful bounties, which ultimately resulted in the loss of all their funds.
Recently, an elite hacker discovered a vulnerability, provided a partial proof of concept (PoC), and requested a $25,000 reward along with remediation guidance. Instead of acting quickly, the owners delayed the process and tried to bargain.

Consequently, the protocol was drained of more than $10 million, effectively destroying the project. A simple hesitation to pay $25,000 ended up costing them over $10 million.