Rethinking Blockchain Architecture for Financial Systems

Finance requires architecture specifically designed for parallel processing, composable primitives, and institutional compliance

The crypto industry faces significant infrastructure challenges because many financial systems are built on blockchains that aren’t designed for financial transactions. This article explores the need for a more suitable blockchain architecture optimized for finance, focusing on parallel processing, composable primitives, and compliance capabilities for institutional participation.

Key Takeaways

Current blockchain architectures are often ill-suited for the demands of finance.
Financial systems require parallel processing to avoid bottlenecks.
Composable infrastructure allows for integration and innovation among protocols.
Institutions need regulatory compliance features in decentralized systems to participate.
Specialized blockchain architectures for finance can lead to superior financial outcomes.

Understanding the Infrastructure Problem

The crypto sector is grappling with an infrastructure issue that is frequently overlooked: we are constructing financial systems using blockchains that were not initially designed for financial purposes. This necessitates a reevaluation of blockchain architecture.

I first recognized this dilemma while developing Momentum. Typically, protocols launch as stand-alone products—a decentralized exchange (DEX), a lending market, a staking solution—treating each as an independent element instead of parts of a connected ecosystem. This fragmentation indicates a significant architectural mismatch. The blockchain layer available simply isn’t equipped to meet the demands of finance, such as parallel processing at scale, composable building blocks, and dependable infrastructure for other protocols.

This isn’t just a theory; it’s evident in transaction errors during high demand, inefficient capital in liquidity markets, and an ecosystem where protocols operate individually rather than collaboratively.

Blockchains Are Not Designed for Finance

When we opted for a platform to build our DEX, the choice seemed clear to me, yet many found it counterintuitive. A common question was: Why not use Ethereum? The explanation highlights my perspective on infrastructure.

The key difference lies in how Ethereum and Sui process transactions. Ethereum’s sequential execution model necessitates that each transaction be processed in order, which results in bottlenecks under heavy loads. This isn’t a flaw but rather reflects Ethereum's original intention as a general-purpose computing platform.

In contrast, financial activities often operate independently. For instance, when Alice swaps tokens and Bob stakes assets, their transactions don’t impact each other. Sequential processing leads to unnecessary congestion, making parallel processing essential—not just as an enhancement but as a fundamental requirement.

Sui, on the other hand, was meticulously designed with parallel execution and an object-centric architecture using the Move programming language. This decision not only speeds up processing but also facilitates the creation of an entirely new range of scalable financial products.

We saw proof of this rapid scaling sooner than we anticipated. In just six months, our DEX grew from zero to $500 million in liquidity and $1.1 billion in daily trading volume, amassing a staggering $22 billion in cumulative trading volume while accommodating 2.1 million users without significant congestion. Achieving such metrics without transaction failures is a testament to architectural integrity—try attaining similar results on a sequential-executing blockchain to understand the importance of design.

The Importance of Composability in Financial Infrastructure

There’s another crucial issue I’ve come to recognize: financial products should serve as composable building blocks rather than isolated entities.

An effectively designed financial infrastructure should allow different protocols to build on shared components. If each protocol is required to develop its own treasury management, staking solution, and liquidity infrastructure, the ecosystem becomes fragmented. Developers end up duplicating efforts, tackling the same problems rather than innovating new ones. I have observed this pattern repeatedly across various chains.

This is a common pitfall for protocols. They often excel at creating one product, but as the ecosystem forms around them, it becomes rigid. Each new protocol essentially starts from square one.

When we created our protocol, we intentionally decided not to develop just a DEX. We built foundational infrastructure components that other protocols would logically choose to use instead of recreating. MSafe, our treasury management solution, now protects hundreds of millions for the Move ecosystem—not through forced adoption, but by addressing a genuine need more effectively than alternatives.

Having more protocols utilize shared infrastructure results in greater integration, enhanced composability, and increased overall value for everyone involved. This only holds true if the foundational components are indeed effective. Advanced liquidity market-making technology with aligned incentives fosters capital efficiency that traditional automated market makers (AMMs) cannot replicate. Liquid staking yielding collateral that is simultaneously productive and multi-signature treasury management enhance protocol governance by minimizing friction.

These aspects aren’t merely luxury add-ons; they determine whether an ecosystem can compound value or fall into fragmentation. This is precisely how Momentum provides infrastructure that other protocols realistically prefer to utilize rather than rebuild.

Institutional Challenges in Crypto

The crypto space has long struggled to attract institutional investment. The usual explanation points to regulatory uncertainty or poor user experience. However, the actual bottleneck is simpler: institutions are unlikely to engage with decentralized infrastructure lacking compliance capabilities.

This does not justify a shift toward centralization. Rather, it indicates the necessity of building the right layer atop decentralized systems. By offering permissioned compliance as an optional module, institutional users can verify their identity and trade transparently while maintaining permissionless base infrastructure. This approach resolves the issue without compromising principles.

Institutions are hesitant to invest significant capital in systems that lack provisions for regulatory auditing, Know Your Customer (KYC) verification, or compliance documentation. These are not just features—they represent essential conditions for institutional engagement. Recognizing this is not gatekeeping; it is a reflection of reality.

A Fundamental Argument

What I’m proposing, independent of specific protocols, is that blockchains primarily designed for general computation cannot effectively serve as financial infrastructure. The world of finance necessitates architecture that is explicitly crafted for parallel processing, composable building blocks, and institutional compliance. Over time, protocols will gravitate toward blockchains that exhibit these characteristics—not due to trends, but because the economic benefits of operating on superior infrastructure are simply undeniable.

This isn’t a claim that “Sui is better than Ethereum.” Ethereum can and should continue to evolve, and Layer-2 solutions represent valid pathways. My argument is that financial systems necessitate a different architectural foundation than that required for general-purpose computing.

The inverse is subtler: if a blockchain is specifically built for financial applications and achieves significant adoption, it naturally becomes the foundation for financial innovation. This happens not because of marketing, but because other protocols sensibly choose to operate there.

The pressing question for the industry is not which blockchain will prevail. It instead revolves around whether we are ready to accept that a one-size-fits-all blockchain architecture was never a suitable approach, and that specialized infrastructures lead to better financial results.

This realization has profound implications for how we should build protocols and select deployment platforms. It has shaped my thinking about Momentum, and it should influence your considerations for future projects as well.