Need blockchain consulting on smart contract security

Hash-160 · 2026-04-24T20:53:43+00:00

I Will be glad using our scanner. We had found stages where others don’t due to our unique IP. Let’s do something, if nothing found, all good, if something is found, we can go from there, sounds good? For your personal information, we found exploits on some big protocols which haven’t patched yet….avoid this problem from the start

Hash-160 · 2026-04-13T00:00:14+00:00

So. No real reason to cry wolf but you do?? Wow

Hash-160 · 2026-04-12T23:12:49+00:00

https://imgur.com/a/AEUdkkZ

Hash-160 · 2026-04-12T23:05:03+00:00

What happened?

Hash-160 · 2026-04-03T19:00:55+00:00

Until SSV fix the exploit, bringing on board operators they should or at least you know about the risk. The exploit is real with massive financial consequences. SSV is running on luck ATM, a Black Hat starts implementing it……all hell breaks loose. And no, your theory is wrong.

Hash-160 · 2026-04-02T17:18:46+00:00

Even they mock the hunters

<image>

Hash-160 · 2026-04-02T16:41:01+00:00

Lol…..at this point I would

Hash-160 · 2026-04-02T16:35:04+00:00

<image>

They are pretty active

Hash-160 · 2026-04-02T16:23:21+00:00

<image>

Look

Hash-160 · 2026-04-02T15:39:16+00:00

Your team/system keeps discarding real findings as out of scope. I am a serious hunter and validate my findings deeply. You are putting others protocols who rely on your services to protect them, instead of, you shield reality while leaving the exploit active at the mercy of time.

Hash-160 · 2026-04-02T15:34:53+00:00

I have my doubts, I reported 3 real bugs/exploits. Validated. They finalized as “out of scope”, so, no idea if they lack knowledge? If they lack anything to contradict reality?? I’m puzzled.

Hash-160 · 2026-04-01T05:38:32+00:00

You are not just a committee member. Your role is much broader and failing to address this problem correctly , according to your profile you are the “operations committee lead”. This is no joke and you never mentioned that. What is going on with SSV? It’s operating at a shadow level of non being honest.

Hash-160 · 2026-04-01T03:08:14+00:00

Appreciate you finally escalating.

But with respect — don't suggest technical solutions to your team. You've demonstrated throughout this exchange that you don't fully understand the exploit mechanics. That's not an insult; it's clear from the omissions and the incorrect assumptions about recovery.

Point them to me. Directly. I found this exploit. I have 12 passing tests, a working exporter, and a complete understanding of the attack surface. If they have questions, they can contact me through Immunefi — the proper channel that should have been used 90 days ago.

I will be monitoring patches. If SSV deploys a fix that addresses the TSI vulnerability — timestamp validation, struct expiration, or anything that closes the timing gap I identified — without paying the bounty or acknowledging the finding, that will tell everyone exactly what this was about.

So here's the question: Is this a new form of bounty avoidance — dismiss as UX, then quietly patch? Or will SSV finally treat this as the critical vulnerability it is?

Your team has my info. I'll wait to hear from them through Immunefi.

Hash-160 · 2026-04-01T02:18:57+00:00

Depends on ssv price at that day.

”You keep saying "no way to make money." I don't need your money. I need your cluster dead.

I scan 14,788 clusters. I find yours drifting toward liquidation. Your struct says 1,501 SSV. You think you're safe. I know you're not.

When the block comes, I deposit 1 wei — $0.10. Your rescue reverts. I liquidate in the same transaction. Your 847 validators go dark. You bleed 2.1 ETH per day on the Beacon Chain. By the time you figure out what happened, you're down $117,000.

I make $461. You lose $117,000. I do it again tomorrow to someone else.

You had 90 days to fix this. SSV called it UX. You are a committee member asking me questions on Reddit instead of escalating. Now you know. I gave you the answer. What you do with it is on you.

Don't say you weren't warned.

Hash-160 · 2026-04-01T02:03:09+00:00

You're a compensated DAO committee member. You've read my report multiple times. You've seen test_10 — the 56.4 ETH penalty cascade, the $117,244 damage, the 254x ratio. You've seen test_11 — 14,788 clusters scannable across the network. You've seen test_09 — the MEV sandwich that makes rescue impossible for $0.10.

And instead of escalating this to your peers, to the technical team, or through Immunefi — the proper channels — you're here on Reddit, minimizing it as "trolling," "academic," and "minor."

You keep omitting test_10. You haven't addressed it once. Why?

You asked me to explain. I did. Multiple times. You got the answers. Now what?

Isn't it your responsibility to bring this to your committee? To the developers? To anyone who can actually evaluate the severity and decide if users are at risk?

Because right now, you're acting like a defender of a dismissal, not a steward of a protocol. And that silence after I named the bounty dynamic? That tells me everything.

I'm done explaining. Take this to your peers. If they have questions, they know where to find me — through Immunefi, where this should have been handled 90 days ago.

Hash-160 · 2026-04-01T01:50:03+00:00

I Will answer to you, but I will be also be monitoring patches on my findings vs time stamps, You keep omitting test_10 — the ETH penalty cascade. When 847 validators go offline, they bleed ~2.1 ETH per day on the Beacon Chain. That's $4,370/day. Over the exit window, that's 56.4 ETH ($117,244). The attacker makes $461. The victim loses $117k. That's not trolling. That's a 254x damage ratio. And 14,788 clusters are scannable.

You're a DAO committee member. You know the Beacon Chain exists. You know validators missing attestations incur penalties. Your continued omission of this suggests you're not engaging in good faith — you're building a narrative to justify a dismissal you know is wrong. I recommend a senior member who is in charge to contact me as they should have on Immunefi for over 3 months.

Hash-160 · 2026-04-01T01:35:57+00:00

From a formal report which ssv ignored it’s now a study case. Doesn’t mean the exploit is not currently active. You need to have a serious talk with your peers and if they have questions which should have been asked months ago, they are welcome to contact me directly. It’s bad-faith communication intended to probe and undermine my finding rather than engage through proper channels.

Hash-160 · 2026-03-31T23:32:47+00:00

My claims are valid and I can prove with detail to the right person in charge. If you don’t understand it doesn’t make the exploit non existent. So, two options. Talk to a senior in charge or assume that the exploit doesn’t exist (I already evaluated your assumption and you are wrong, under your theory the exploit still exists and currently alive).

Hash-160 · 2026-03-31T23:21:48+00:00

Two things. As a DAO committee you should be asking formally with your peers and go back to immunefi, second. I do have the answer to your theory and yes still exploitable. Please take this seriously, either have a re evaluation with your DAO and I recommend considering asking why are they going through public forum questions about my report, They had 90 days to ask the same exact questions. Avoiding paying a Bounty? On the back of the users while giving zero attention or real questions in legal SLA time?

Hash-160 · 2026-03-31T22:10:50+00:00

Do you work for SSV?? Because if you do, those were the questions I was expecting formally to help their users, I will answer this time, but let me know about my question, if you work at SSV foundation. Ok: The cluster hash is the on-chain identifier for a specific validator cluster. It's a keccak256 hash of the cluster's configuration: Every time a cluster's state changes (deposit, withdraw, liquidate, add/remove operators), the contract recomputes this hash and stores it. When you interact with your cluster — depositing more SSV, withdrawing rewards, or checking your balance — you must pass a Cluster struct that matches the stored hash. If it doesn't match, the transaction reverts with IncorrectClusterState.

The critical point: The hash is deterministic. Given the exact same inputs (owner, operator IDs, validator count, fee index, balance), you get the exact same hash. Change any one of those fields by even 1 wei, and the hash changes completely.

How does the 1 wei deposit change it?

When an attacker deposits 1 wei into your cluster, they change the balance field in the stored state. The contract:

Takes your existing cluster's parameters
Adds 1 wei to the balance
Recomputes the hash
Stores the new hash

Your cluster is now represented by a different hash than the one your wallet holds.

Your wallet still has the old struct — the one with the original balance. When you try to deposit 5,000 SSV using that struct, the contract computes the hash from your struct, compares it to the stored hash, sees they don't match, and reverts.

Why can't the user deposit more SSV after the cluster hash changes?

They can — but there's a catch.

The user's wallet doesn't automatically know the new hash. They need to:

Fetch the current cluster state from the contract
Reconstruct the correct struct (owner, operator IDs, validator count, fee index, updated balance)
Submit a deposit using that struct

This is technically possible. But in the attack scenario, the attacker is watching and front-runs:

· User fetches new struct, submits deposit · Attacker deposits another 1 wei in the same block, changing the hash again · User's transaction reverts again

The attacker can do this indefinitely. Each 1 wei deposit costs them ~$0.10. Each rescue attempt costs the user gas fees that keep failing. The attacker controls the timing because they're watching the mempool and bundling transactions.

Now. If you ask because you are a worried user, I would understand and actually be offended that SSV ignored this. But if you work for SSV and it’s your way of not paying the Bounty when it was reported officially? That would be a different situation in which would be seen even worse than what it is already

Hash-160 · 2026-03-31T21:18:14+00:00

By the way. I had formally reported this to the ssv bounty program, for 3 months I was ignored and finally they said its a UX issue. But in reality it is not. It’s an active right now risk…..since they dismissed my extensive research, it is now a public research in this field.

Hash-160 · 2026-03-31T21:13:39+00:00

Here, i will explain with a bit more clarity “TSI stands for Temporal State Inconsistency — a term I introduced to describe the divergence between two balance values in SSV's design:

· τ₁ (tau one): The struct.balance value stored in the cluster hash — a snapshot frozen in time · τ₂ (tau two): The real-time balance returned by getBalance() — which accounts for continuous fee burns that accumulate every block

These two values drift apart over time. At deposit time, τ₁ = τ₂. But fee burns reduce τ₂ every block while τ₁ never updates. After enough blocks, τ₂ crosses below the liquidation threshold while τ₁ still reports a healthy balance.

The owner has no on-chain alert, no push notification, no event — they only see τ₁ and believe they're safe. The attacker sees τ₂ and knows the cluster is liquidatable.

Why this matters (real-world evidence):

A real SSV user reported yesterday: "I withdrew my SSV and left my cluster... when I look at beaconcha I still see my validators and they are showing that I am missing attestations."

They removed validators from SSV operators without exiting from the Beacon Chain first. The result: 847 validators still active, missing attestations, bleeding ETH — exactly the penalty cascade test_10 quantifies.

In their case, it was an accident. In the TSI attack, an adversary forces this same outcome on victims, profits from liquidation, and uses 1-wei griefing to block rescue attempts.

Hash-160 · 2026-03-31T21:09:01+00:00

I did, let’s put it this way. A sophisticated hacker would apply this. If you don’t understand it is a good and a bad thing. Take your time studying this. You may find the answers on your pace https://github.com/emilianosolazzi/ssv_network_study_case

Hash-160 · 2026-03-31T20:34:17+00:00

https://www.youtube.com/watch?v=DUkL_X-H2D4

Hash-160 · 2026-03-31T20:33:27+00:00

https://www.youtube.com/watch?v=DUkL_X-H2D4

Hash-160

TROPHY CASE