#02: Why Move Matters

Premise: Where does the value of money truly come from?

What gives our money its worth today?

Not the weight of metal. Not the thickness of paper. But something far more abstract — trust.

Trust in the systems we’ve built: governments, central banks, institutions. In that sense, money is nothing more than a shared belief, perhaps even a collective illusion, held by countless strangers.

In 2009, this idea took a radical turn with the birth of Bitcoin. A network with no borders, no central issuer, no authority to place your faith in — and yet, it managed to amass a staggering market value. What holds Bitcoin together isn't a nation or a name. It's the architecture of decentralization, the strength of cryptography,

and the silent precision of code that governs it all.

In Web3, “Code is law” is not just a slogan. It’s a quiet truth: a few lines of logic can determine the movement, the existence, and even the destruction of assets.

But can we truly trust that code?

The reality is harsh. Countless projects have fallen — not because of bad intentions, but because of fragile code. A missed access control. A re-entrancy vulnerability. A bridge bug, small in appearance but devastating in effect. Tiny cracks that led to losses in the tens of millions. This is not the exception — this is the landscape.

And the burden? It falls, again and again, on the shoulders of developers. They don’t want to write security patches. They want to build. To turn vision into form.

That’s what developers do — it’s not just their work, it’s their instinct, their joy.

And yet, instead of creating freely, they are forced to build walls, review every edge, anticipate every failure. Freedom has become a maze of precautions.

1. A Language Closest to What Smart Contracts Were Meant to Be

A smart contract should be, at its core, a promise — one that holds human intent and trust. Move is the language that comes closest to embodying that promise with integrity.

The question posed in the title of this article — “Why Move Matters” — is one I can answer without hesitation.A smart contract is not just a script for automation. It moves assets, transfers rights, and executes decisions that cannot be undone. If a flaw exists in its logic, the consequences may be irreparable — financial losses, shattered trust. These are not abstract fears; they are lessons we’ve already learned, again and again.

Move was designed to confront that reality head-on. Rather than celebrating everything that can be written, it focuses on what shouldn’t be written. It takes responsibility — not just through patterns or tools, but at the level of the language itself — for handling code that governs value and trust.

Why was this language created in the first place? What kind of thinking shaped its design? And why is it now evolving into a new form as Sui Move?

Let’s walk through that story, one step at a time.

2. Rethinking “Security” in Blockchain

2-1. The Blind Spot in the Blockchain Trilemma

One of the most cited frameworks in evaluating blockchains is the “Blockchain Trilemma,” proposed by Ethereum co-founder Vitalik Buterin. It argues that decentralization, security, and scalability cannot all be fully achieved at the same time — that any system must sacrifice one to preserve the others. Many developers and projects have accepted this premise, and shaped their designs around which aspect to prioritize. (Though to be honest, I’m not sure how useful this debate still is today.)

Still, there’s a critical blind spot in this trilemma: it only addresses the consensus layer. It’s a meaningful way to think about network-level issues — node distribution, block times, consensus algorithms — but it says nothing about the vulnerabilities we most often see in real-world crypto history. Those happen at the application layer.

So, when someone claims, “This blockchain is secure because its validator set is decentralized,” or “Token distribution ensures safety,” they are speaking only to one narrow aspect. Most actual risks arise in areas where decentralization alone offers no protection. To understand why validator decentralization is only part of the picture when it comes to smart contract platforms, let’s look at some data.

2-2. What the Data Tells Us

CertiK is a security research and audit firm known for its reporting on blockchain-related threats. Every quarter and year, they publish detailed reports that shed light on real-world vulnerabilities and trends across the Web3 ecosystem.

In their 2024 annual report, Ethereum accounted for 50% of all recorded hacking losses. When you include other EVM chains such as Arbitrum and BNB Chain, that figure rises to 87%. By contrast, attacks targeting Solana — which uses Rust — made up just 3%, despite the network experiencing significant growth in users and development activity throughout the year.

This discrepancy can’t be explained solely by popularity or capital inflow. The difference likely stems from the programming languages themselves. Solidity, the language used on EVM chains, and Rust, used on Solana, offer fundamentally different models — especially in terms of type safety and ownership. These differences have a direct impact on the likelihood of security incidents. In fact, some analyses suggest that language-level design can lead to a tenfold difference in exploit risk.

Looking deeper into the causes of these incidents, phishing remains the most common, but just behind it are attacks that exploit code vulnerabilities, followed by failures in access control. All of these are concentrated in the application layer. What this tells us is clear: smart contract security can no longer be left to individual developers’ attention to detail. It must be built into the design of the language and execution environment itself.

3. The Origins of Move — What Libra Demanded of Code

In 2018, Facebook launched the Libra project with the ambition of building a global payments network. Though later rebranded as “Diem,” the core vision remained the same: to create a next-generation infrastructure that would allow over a billion Facebook users to exchange value simply and securely.

At the heart of this vision was a smart contract system. To entrust code with everything from everyday payments to financial instruments, identity, and rights management — all at the scale of billions — demanded a language of exceptional safety and predictability. Facebook’s engineering team began by evaluating existing programming languages. Solidity, Rust, Go, TypeScript, even functional languages suited for formal verification — all were considered. But they shared one fundamental limitation: none of them were originally designed for the realities of blockchain. 

What stood out most was how permissive these languages were, especially when it came to handling assets and rights — things that, once lost or corrupted, could not be undone. A developer could accidentally burn funds, duplicate them, or share contract state without realizing it — and none of these errors would trigger a compiler warning. It would simply compile, leaving everything to the developer’s vigilance. 

Facing this foundational flaw head-on was Sam Blackshear, who would later go on to co-found Mysten Labs. He set out to build something different — a language that could support a new kind of trust infrastructure, one in which “responsible code” would be enforced at the language level itself.

That effort gave birth to Move. In Move, digital assets are defined not as ordinary data, but as a distinct kind of value — resources. These resources behave differently: they cannot be copied, cannot be accidentally destroyed, cannot be silently shared. The language enforces these rules not through convention, but through its very syntax. Ownership and transfer are made explicit, and all interactions are statically verified by the type system before they ever reach the blockchain.

Formal verification was not an afterthought, but a design premise. In parallel with the language, the team developed a dedicated tool — Move Prover — to mathematically prove that a contract behaves as specified. This was not just about correctness; it was about creating an environment where developers could handle assets with peace of mind.

Though the Libra (Diem) project ultimately dissolved under political and regulatory pressure, Move survived. And it continued to evolve — not as a relic of a failed initiative, but as a smart contract language now shaping the future of blockchain.

Move is a language born to carry the full weight of assets, agreements, and accountability. At its core lies a quiet conviction: that trust should not be promised — it should be encoded.

4. Sui Move and the Object-Centric Architecture

4-1. Building the Ideal L1: The Birth of Sui and Sui Move

After the dissolution of the Diem project, several of its core technical members came together to found Mysten Labs, determined to build the public blockchain they had always envisioned. What emerged from that effort was the Sui Network.

Sui was never meant to be just a scalable blockchain. The team set out to address something deeper — a foundational question in Web3: Can a blockchain truly serve as an open platform for everyone? Not just for payments, but for games, NFTs, social applications — for all kinds of human interaction that demand both flexibility and trust. That was the ideal they pursued.

To support that ideal, Move itself had to evolve. And so, Sui Move was born. Move was already a language designed with safety at its core. But in Sui Move, that philosophy has crystallized at an even deeper level. The key to that evolution is what they call the object-centric model.

4-2. Embedding Ownership in Data: The Innovation of the Object Model

Most traditional blockchains rely on an account-based architecture. In this model, assets and data are tied to accounts, and every transaction must verify who owns what. But this approach has a fundamental weakness: every ownership check becomes a point of fragility. If a developer makes a mistake in how ownership is verified, it opens the door to exploitation.

The 2022 Wormhole hack is a textbook example. An attacker exploited a missing signature verification in a bridge connecting Ethereum and Solana, and minted 120,000 ETH — worth roughly $360 million — without proper authorization. At the root of this incident was a simple truth: the burden of safety had been left to the developer, when it should have been enforced by the code itself.

Sui Move seeks to change that — from the ground up. In the world of Sui, everything is an object. Tokens, NFTs, on-chain data — each exists as a discrete object with a unique ID, a clear owner, and a defined state. Ownership isn’t tied to accounts. It’s embedded directly in the data itself.

For developers, the implications of this are profound. There’s no longer a need to check “whose asset is this?” inside a smart contract — because that question has already been answered by the language’s design, outside the logic of the code. The result is simpler code, fewer bugs, and the freedom to focus on what matters. The safety isn’t something you add. It’s something you inherit.

Because objects are independent from one another, Sui can also analyze their relationships statically — and that makes parallel execution possible. The network’s high throughput and execution speed are not accidental. They are direct consequences of this data model. In contrast, account-based architectures require a serialized approach to transaction processing. Any state change can potentially affect the whole network. But Sui sidesteps this bottleneck — not by optimizing the system around the problem, but by redefining the problem at the level of data itself.

4-3. Designing Safety and Efficiency Through Structure

Safety and efficiency — not as add-ons, not as optional features, but as principles woven directly into the structure of the language. That is what defines Sui Move.

To me, this design reflects a clear philosophy: never assume human vigilance. Instead of asking developers to prevent mistakes, it reshapes the system so that mistakes are unlikely to happen in the first place.

In the long and difficult history of smart contract development — a history marked by constant vulnerabilities and costly errors — this represents something new. 

A quiet shift. A new standard, not of caution, but of structural care.

5. Responsibility by Design — Rethinking Safety and the Future of Blockchain

What does it really mean for a blockchain to be “secure”? 

As we come to the close of this article, I want to pause and return to this question. Ethereum is widely respected for the strength of its consensus mechanism. Node-level decentralization, the rigor of its agreement protocols, the fault tolerance of its network — on the foundational layers, from Layer 0 to Layer 1, Ethereum is without question a trustworthy system. 

But beyond that layer lies the ecosystem itself — its design, its applications — and these are left largely to individual projects and developers. “Ethereum is secure. If an app has bugs, that’s the developer’s fault.” This division of responsibility may seem logical at first glance. But I find the very premise questionable. From the user’s perspective, such logic means little. 

Blockchain is no longer just a distributed ledger. It is becoming an application platform — one that touches finance, gaming, identity, media, and much more. If that is the case, then the responsibility for safety must also extend beyond the consensus layer. We should be questioning not just the bugs themselves, but the very structure that allows those bugs to occur. That’s what I believe. 

Ethereum has defined what security means at the infrastructure level — and deserves the recognition it has received. But we are entering a new phase, one where the entire platform must be safe by design, where user error is minimized by thoughtful systems, and where developers are not forced to trade safety for usability. 

It’s no longer enough to say, “As long as developers don’t make mistakes, we’re fine,” or “It’s a matter of user literacy.” These assumptions are fragile. True safety comes from a structure that makes mistakes unlikely in the first place — and from a design that puts users at the center, not as afterthoughts, but as a starting point. Today, we’re beginning to see new possibilities. 

Solana, Aptos, and Sui — non-EVM chains that are rethinking the foundations of blockchain itself, approaching the same ideals from very different directions. Among them, Sui stands out as one of the few attempting to balance safety and performance at the level of the language. By embedding ownership into data structures, enabling parallel execution through object independence, and removing entire classes of smart contract risk at the architectural level, Sui is not merely showcasing technical skill. It’s expressing a quiet, essential vision: a blockchain that anyone can use — and trust — with confidence. 

The era when Ethereum was the only choice is over. From here on, it is how a blockchain is built — the design philosophy behind it — that will define why developers choose it. And watching the rise of Sui, I can say this with quiet certainty: That future has already begun.