The Step Finance Case: The Human Factor in Security

Recently, Step Finance, a major DeFi platform on the Solana network, made headlines with a significant security breach.

On January 31st, Step Finance announced on their social media accounts that approximately $40 million worth of assets were stolen after their admin team’s devices were compromised.

Thanks to swift action, about $4.7 million of that was recovered.

What caught my attention in this breach wasn’t a smart contract vulnerability or a design flaw in the protocol, but rather the fact that it happened through the compromise of devices belonging to authorized personnel.

I think this distinction is important because when we talk about security vulnerabilities in the Web3 world, we still mostly discuss smart contracts, code quality, and algorithmic gaps.

Yet, the operational and day-to-day aspects, the layers involving access and authorizations, aren’t talked about enough. In other words, the human factor in security processes is still not much of a focus in the Web3 world.

When you think about the emergence and philosophy of Web3 and the blockchain world, where individuals are expected to take responsibility for their assets, it tends to push actions like taking precautions in this layer to the background. While I understand this perspective, I believe that for systems holding many people’s assets, every layer and every factor should be considered and safeguarded, including the human factor.

It’s hard to see the Step Finance incident as entirely separate from other examples we’ve seen in Web3 security history. Take the Bybit attack from about a year and a half ago, one of the largest breaches on record. The technical methods were different, but the root cause pointed to a similar issue: access permissions, operational decisions, and the human factor. Technology changes, attack vectors evolve, but the question of who can access critical systems, under what conditions, and how, remains one of the most fragile points of security in both centralized and decentralized structures.

This topic isn’t new for Web3 or for me. I’ve previously discussed in the newsletter how Web3 security should be viewed not only through the lens of technology but also through the human factor, mentioning that transparency doesn’t automatically equate to security.

The Step Finance case brings this discussion from theory back to practice.

Here, the issue isn’t whether the data on-chain is visible or not. The issue is how the people managing this data, operating the systems, and holding critical access work. Topics like access management, separation of duties, and operational discipline, long discussed in the Web2 world, are inevitably making their presence felt in Web3.

Incidents like these make it increasingly difficult to reduce Web3 security to just “have we been hacked?” The real question is becoming: Who operates these systems, with what permissions, and how?

It’s no coincidence that regulatory discussions are intensifying at this point. For institutions, security is not just about technical resilience but also directly tied to predictability and accountability. And unfortunately, the use of open-source code doesn’t mean that processes are mature, especially in environments where the financial impact can be so significant.

Perhaps we should view these incidents not as isolated security breaches but as operational realities and structural outcomes that Web3 faces as it grows. As automation and financial scales increase, the impact of small human errors also grows.

This brings us back to the fundamental question: What makes these systems trustworthy?

Code, transparency, and automation answer part of this question. The rest, as always, is determined by the structures people build.