As an industry, we’ve come a long way in scaling blockchains. We took to L2s to scale Ethereum and have established other L1s like Solana and Sui that scale the base layer. Rollups gave us cheaper and faster transactions, but we’ve had to compromise on liquidity with a fragmented user experience. Most L1s, like Solana, Sui, Sei, and Aptos scale vertically by having more work done within the same set of nodes with the help of parallel execution. While Sui scales vertically, it is also on the path to scale horizontally by employing execution and consensus upgrades, which could open up new scaling possibilities beyond typical L1 architectures while laying the ground for decentralization.

Sui was founded in 2021 when Mysten Labs was established by Meta’s former blockchain team from Project Diem. Sui mainly differentiates its technical approach in two ways:

1. Sui has a novel object-centric global storage model, parallel execution of transactions that touch distinct objects, and Mysticeti consensus for optimal latency
2. Sui leverages the Move programming language, allowing developers to write smart contracts with strong safety guarantees. The combination of these built-in protections and Sui objects prevents many common hacks and exploits, such as reentrancy attacks and missing permission checks. Move objects also improve the overall developer experience, enabling powerful features like programmable transaction blocks that allow developers to compose Move calls directly from frontend code.

Mysten Labs, the original contributors to Sui, brings together a team with extensive experience in software language compilers, static analysis, distributed systems, cryptography, and cloud computing. This wealth of expertise from companies like Apple, Oracle, Microsoft, R3, and Meta has been channeled into the development of Sui, to create a blockchain platform that can scale to meet global demands.

In this report, we will dive into Sui’s architecture, economics, and innovations and look at how its ecosystem is shaping up.

Sui’s Architecture

Sui’s Object-Centric Global Storage Model

Distributed ledgers work as state machines. They process inputs (transactions, accounts, contracts) to change the state and create an output representing the current status of all accounts, balances, and data on the network. The “state” is a snapshot of all the data within a blockchain. The state grows as more transactions are processed, introducing new accounts, contracts, and changes, which must be stored and referenced in the future. This growing state increases storage needs and the complexity of computations over time.

Ethereum employs an account-based model where the global state is represented as a collection of accounts, each with its balance and storage. To facilitate authenticated reads, this state is stored in a Merkle tree without accounts at the leaves. However, this tree is very expensive to update, particularly as it grows larger and larger–this is the so-called “state bloat” problem.

Sui’s object-centric data model can serve authenticated reads without building a global Merkle tree. This addresses the state bloat problem by allowing Sui to use an off-the-shelf database to storage objects efficiently and scale out as the state grows. As a result, Sui storage is much cheaper than Ethereum (>1000x cheaper) or Solana (>100x cheaper).

Objects are the fundamental units of state and ownership on Sui. They can represent tokens, NFTs, and packages (smart contracts), among other things. Each of these objects is a distinct unit with a unique identifier (UID) and specific attributes such as “type,” “version,” “owner,” and associated data that allow them to be stored and retrieved from global storage.

Objects are flexible and composable pieces of state that can be categorized into the following:

1. Owned objects: These are controlled by a single address and can only be modified by transactions signed by the owner. An object can also be owned by another object, enabling complex hierarchical structures. Owned objects do not require consensus for state changes.
2. Shared objects: Multiple users can access and modify these, requiring consensus for state changes.
3. Immutable objects: Once created, these objects cannot be modified.

Native object ownership information helps Sui process transactions strategically faster. Transactions that only touch owned objects can bypass consensus, as they don’t require global ordering and only modify their own state. These transactions can be processed in parallel without conflicts. Transactions touching one or more shared objects require consensus sequence reads and writes to each shared object. But transactions touching distinct shared objects can be processed in parallel, and the runtime can detect conflicts in advance because of the object data model. In addition, the object data model enables local, per-object fee markets to prevent global congestion. If too many transactions want to access a single shared object, fees and latency for the transactions touching these objects may increase, but all other transactions are unaffected. This allows congestion to be localized to the problematic state only rather than cascading to the whole system (as in, e.g., Ethereum).

Move packages (smart contracts on Sui) are immutable objects. We can look at the most used packages based on data from Artemis.

Most active addresses across packages are related to consumer-based applications. Over 45% of average daily active addresses are from RECRD, a consumer application similar to TikTok that allows users to monetize their content with a decentralized ad revenue system. Wave Wallet, a telegram-based wallet, has over 20% of average daily active addresses. Coming third is a game application called BIRD, with 17.2% of average daily active addresses. With 8.4%, FanTV, another application similar to TikTok, rewards users with tokens as they watch and create short-form videos.

Mysticeti

Conventional consensus schemes have a single leader that proposes a linear sequence of transactions. This means consensus can only proceed as quickly as the leader and faulty leaders can create performance issues. Sui’s Mysticeti consensus is a DAG where all validators can propose blocks of transactions in parallel. These blocks connect to earlier blocks, creating a web of interconnected transactions. This setup allows Sui to leverage all validators to make progress simultaneously rather than blocking on a single leader. Initially, Sui used protocols such as Narhwal and Bullshark to process transactions but has now transitioned to utilizing Mysticeti as its consensus protocol.

Mysticeti was implemented on Sui to improve transaction processing efficiency further and reduce latency. Mysticeti can commit transactions in only three message rounds compared to other consensus protocols below.

This improvement is a step up over Sui’s previous certified DAG-based approach with Bullshark, which required six message rounds to commit transactions. Sui’s consensus is now more streamlined by skipping the need for explicit block certifications.

An implicit but major improvement to be highlighted is how Mysticeti reduces CPU overheads for validators. The certification process in protocols like Narwhal and Bullshark consumes significant computing resources and involves sizeable signature generation and verification. Mysticeti’s uncertified DAG approach eliminates this overhead, freeing up CPU capacity. The official Sui validator requirements remain the same, but this marks a step on the road to decentralization. It is essential to have lower validator hardware requirements as it enables greater participation.

Mysticeti also accounts for faulty validators. Its commit rule is designed to detect and exclude crashed validators from consensus, allowing the network to maintain high performance even when some validators are unresponsive.

Implementing Mysticeti also changes how transactions are processed on Sui in two ways.

1. Rather than batching transactions into certified blocks, validators propose uncertified blocks in each round. The DAG is constructed through validators referencing blocks from previous rounds. Consensus is achieved through each validator independently interpreting their local view of the DAG, eliminating the need for additional communication overhead during consensus.
2. Mysticeti introduces a multi-leader commit rule, allowing more blocks to be committed directly in each round. The protocol’s pipelined design enables a leader block to be committed every round, further reducing latency.

The use of multiple leaders has been a major topic of discussion even in other ecosystems, such as Ethereum and Solana, as it helps enhance censorship resistance and reduces centralization.

Further Upgrading Mysticeti with Adelie, Mahi-Mahi & Obelia

Mysticeti’s design already improved latency by skipping the time-consuming step of certifying each transaction block, which enabled faster transactions but opened up potential vulnerabilities to malicious participants.

Adelie is a potential extension under development for Mysticeti. It can address Mysticeti’s shortcomings. Mysticeti relies on validators actively proposing blocks to facilitate transaction processing. While this makes Mysteiceti more performant than Bullshark, it is vulnerable to manipulation by malicious validators who might intentionally delay their block proposals for strategic advantages, such as capturing MEV, potentially impacting the order and inclusion of transactions.

To address this potential vulnerability, Adelie introduces the “critical block” rule, which dictates that a block is only valid if its “critical block,” which is a validator’s most recent block, up to two previous rounds is referenced by a quorum of stake in the network. This rule allows Adelie to incentivize validators to maintain consistent and active block proposals to ensure they are active and prevent any potential fairness issues caused by validators intentionally withholding blocks.

Mahi-Mahi and Obelia (SIP-39) are potential extensions to Mysticeti. They are designed to improve different aspects of its performance. Mahi-Mahi is an optimized iteration of Mysticeti, designed to reduce latency and increase throughput by accelerating block dissemination across a wider network of validators. It achieves this by applying a direct commit/skip rule, where it anticipates whether a block is likely to receive sufficient votes in time. When a block shows a high probability of reaching the required vote threshold, Mahi-Mahi directly commits it, bypassing the usual waiting time. On the other hand, if a block is unlikely to gather enough votes, Mahi-Mahi skips it, minimizing unnecessary delays and the use of computing resources. This proactive approach streamlines consensus by focusing only on high-likelihood blocks, shortening the time to finality. According to Mysten Labs, Mahi-Mahi demonstrates significantly lower latency compared to asynchronous consensus protocols like Tusk.

Taking Obelia or SIP 39 live would mark a significant step in the decentralization of Sui. It focuses on increasing validator participation in the consensus process by introducing a two-tier validator system that accommodates both high-stake core validators and lower-stake auxiliary validators. While core validators’ function continues as it is, auxiliary validators operate outside the transaction critical path, contributing to block building without impacting consensus speed. This mechanism allows for a more inclusive and potentially more decentralized system where stakeholders with varying levels of stake and different geographies can participate in securing the network. Based on Mysten Labs’ empirical testing, Obelia can scale to hundreds of validators without noticeable effects on performance, even when some auxiliary validators are faulty or offline.

Sharded Execution With Pilotfish

Mysten Labs is further working on scaling execution on Sui. Sui currently runs on a single-machine execution model. This single machine alone is burdened with fetching data required to process transactions and handle the entire state on limited memory and storage.

Instead of running all operations on a single machine, it splits the validator into three distinct components:

1. The Primary: This single machine handles consensus, ensuring that all validators agree on the order of transactions.
2. SequencingWorkers (SWs): Multiple SWs can exist, each responsible for storing transactions and dispatching them for execution. They act as intermediaries between the consensus layer and the execution layer.
3. ExecutionWorkers (EWs): These machines store portions of the blockchain state and perform the actual execution of transactions. Multiple EWs can operate in parallel, increasing throughput.

The key to Pilotfish’s scalability lies in its sharding approach. Rather than having each machine handle all aspects of every transaction, Pilotfish distributes the workload:

• Each transaction is assigned to a specific SequencingWorker.
• Each blockchain object (a piece of state) is assigned to a specific ExecutionWorker.

This distribution allows for parallel processing, but it introduces a challenge: what happens when a transaction needs to access objects stored on different EWs? Pilotfish solves this through a coordinated data exchange system. When an EW needs data from another shard to execute a transaction, it requests data on demand. This approach maintains the benefits of parallelization while allowing for complex, cross-shared transactions.

This works well with Sui’s “lazy” design, where consensus is reached on transaction batch metadata rather than full transaction data. Pilotfish’s execution pipeline distributes transaction data from SequencingWorkers to relevant ExecutionWorkers, which then schedule and execute transactions in parallel while maintaining consistency.

In benchmarks, Pilotfish demonstrated significant performance improvements, processing up to 10x more transactions than Sui’s baseline execution engine when using 8 ExecutionWorkers for compute-intensive workloads. By integrating Pilotfish, Sui can effectively scale its execution capacity to match available hardware resources, ensuring that all resources are sufficiently utilized.

Remora is another upcoming development to scale transaction execution. More details on Remora are yet to be published.

Economics of Sui – Value Accrual & Tokenomics

Anyone can permissionlessly submit transactions to blockchains and modify the shared state. More than two-thirds of network validators by stake must independently verify and execute a transaction to be accepted. Processing transactions requires computing and storage resources. This is why validators have specific hardware requirements.

Fee markets play a pivotal role in helping allocate these scarce resources based on transaction fees. They also help the network price transactions based on demand and activity. They can be designed to deter bad actors from abusing the network by spamming transactions and performing DDoS attacks.

Sui uses a multi-dimensional reference gas price mechanism. It separates fees into two main components: computation fees and storage fees.

Computation Fees

Computation fees cover the cost of processing transactions and consist of two parts. First is the reference price, determined at the beginning of each epoch (24-hour period) through a Gas Price Survey that determines the reference gas price. The purpose of this novel mechanism is to maintain a stable dollar-denominated cost for transactions even as the price of SUI fluctuates. This predictability is very valuable for product builders. In the survey, each validator submits their reservation price (the minimum gas price they will accept). The protocol then selects the 2/3 percentile of these prices, weighted by each validator’s stake, as the reference price. This ensures that the reference price is acceptable to most validators. The reference gas price sets a floor on the price the network will accept, but users can specify higher prices for priority access to congested state.

Storage Fees

As previously mentioned, Sui Objects live onchain and directly relate to accounts, tokens, NFTs, and smart contracts (packages). This is the second component of fees that users pay. Storage fees are calculated as Storage Fee = Storage Units × Storage Price. Storage Units represent the amount of storage a transaction requires, while the Storage Price is the cost (in SUI) of storing one data unit.

Sui uses a Storage Fund to manage storage fees. All collected storage fees are deposited into this fund and generate stake rewards. A portion of these rewards is paid to current validators to compensate for storage costs, while the remaining portion is reinvested in the fund to ensure long-term sustainability. This ensures that future validators are also compensated for carrying the state weight established by past users. Users can delete their data and receive a partial refund of their initial storage fees. Only data, such as metadata, event data, such as auctions, and tickets that have occurred in the past, can be deleted. Transaction history would still remain intact. Ethereum, Solana & Aptos also consider storage fees in addition to execution fees.

Pruning

Similar to Ethereum, Sui validators also prune their nodes to reduce disk usage from storing transaction and object history. Live objects are never pruned, and historical data is available via archival nodes. They can follow two types of pruning policies.

1. Aggressive Pruning is where validators remove old object versions and metadata as soon as possible. This approach minimizes disk usage and is suitable for nodes that do not need to retain historical data.
2. Epoch-based Pruning is where nodes can retain data for a specified number of epochs before pruning.

Staking

As per Staking Rewards, Sui has 108 validators, with 93 active validators having +30M SUI staked. Staked Sui has an annual reward rate of 2.8%, which is down from 4.5% a year ago in November 2023. For better context, staked Ethereum’s APY is 3.2%, and staked Solana’s APY is 6.48%. Unlike Ethereum and Solana, Sui does not subsidize staking rewards via inflation–Sui has a fixed token supply of 10B.

Thus, for staked Sui yield to increase, a rise in network activity is essential. This would drive more transactions and boost the fee competition, generating more revenue for validators and stakers. While there is MEV potential on Sui, it requires more sought-after DeFi assets that encourage more inflows and volume, like how memecoins impact Solana and the returns its validators make.

As mentioned, Sui has a total token supply of 10B SUI, with 2.8B SUI in circulation. Over 7.7B tokens or 77% % of all the tokens, are currently staked. The 7.7B SUI tokens are staked across 108 Validators.

Tokenomics

As of December 2nd, 2024, the SUI token trades for $3.26 with a circulating market cap of $9.5 Bn. While the circulating supply is 2.93Bn, the total supply of Sui tokens is 10Bn, resulting in a fully diluted valuation of $32.5 Bn at the current Sui price.

Sui’s token supply is capped at 10Bn tokens and is distributed across stakeholders in the following share.

 

• Unlocked Post 2030 (52%) – This refers to the remaining tokens in each allocation unlocking post 2030.

• Series A & Series B (14.1%) – Tokens allocated to Series A & Series B investors.
• Community Reserve (11%) – The use of tokens from this allocation is split across the following causes.
  • Delegation Program: Aimed at bootstrapping a community-run validator set and promoting fair stake distribution across third-party validators aligned with Sui.
  • Grants Program – Aimed at compensating developers, community ambassadors, and other contributors who build on Sui and make it accessible to a wider audience.
  • Research & Development – Aim to support the development of the Sui protocol to ensure Sui technology remains at the forefront.
• Stake Subsidies (9.5%) – Tokens set aside to subsidize early validators’ stake rewards.
• Early Contributors (6.1%) – Tokens allocated to early contributors who helped build and take Sui live on mainnet.
• Community Access Program (5.8%) – Tokens here are distributed to the community members who may have contributed in the following ways.
  • Discord community members who’ve participated in the server by offering suggestions, participating in discussions, and interacting with ecosystem-related projects
  • Members who have taken on roles as testers and moderators have attended Builder Houses and key events, helping to organize and run them.
• Mysten Labs Treasury (1.6%) – Tokens allocated to Mysten Labs.

The chart below depicts $SUI token’s vesting schedule across different allocations until 2030—post which a major part, 52% of SUI’s supply will be allocated.

Innovations on Sui

MoveVM and The Move Programming Language

The majority of the team that built the Move programming language at Meta (Facebook) continues to work on Move at Mysten Labs. In particular, the creator of Move, the designer of the Move bytecode format, and the author of the Move compiler are at Mysten. Sui has enhanced the Move language with support for the object data model, which has unlocked many new features.

Traditional blockchain programming languages like Solidity, which is used on Ethereum, were instrumental in the growth of the blockchain industry at large. Over the years, its developer base has grown so much that emerging ecosystems like Monad and L2s such as Aribtrum, Optimism, ZK L2s, etc, try to be EVM compatible. This makes it easier to port applications and users into their ecosystems from the larger EVM ecosystem. This has led to the development of cryptographic libraries and developer tooling for the EVM ecosystem.

However, the EVM faces several limitations that hinder scalability, security, and user experience. The EVM cannot inherently process transactions in parallel. There is no way of identifying before execution which transactions have the same state dependencies. As we’ve discussed Sui’s object-oriented model, MoveVM can differentiate between transactions that touch the same state vs transactions that have no same state dependency.

Solidity is known for its history of hacks and reentrancy attacks. Move uses a resource-oriented approach and has strict type systems designed to prevent issues like reentrancy attacks or resource duplication, which have been problematic in Solidity.

To prevent reentrancy attacks and other vulnerabilities, Move makes a trade-off of flexibility for security with static dispatch compared to Solidity, which supports dynamic dispatch. With static dispatch, smart contracts (programs) undergo preliminary checks before executing, preventing reentrancy attacks at the source.

Account Abstraction

Sui supports native account abstraction and is also exploring ways to improve account ownership with keyless recovery, multi-account authorizations, and custom payment rules. We will also go into PTBs, zkLogin, sponsored transactions, and Bugdar.

Programmable Transaction Blocks – PTB

PTB, or Programmable Transaction Blocks on Sui, is a developer primitive that can execute up to 1024 transactions or unique operations in a single execution instead of 1024 single executions. This reduces the execution cost on an already low-cost chain and increases transaction throughput.

For example, a user could trade on Deepbook, after which they could deposit X asset on Suilend and borrow Y asset to make a trade-in Y/Z pool on another DeFi protocol, all in a single PTB executed simultaneously.

Here is an example of a PTB and all of its actions

Sponsored Transactions

This feature is natively available on Sui, unlike other ecosystems like Ethereum, where gassless or sponsored transactions aren’t inherently available. With sponsored transactions, applications cover the gas costs for users. Sui aims to make gas invisible by enabling developers to create “Sui Gas Stations” to manage gas payments on behalf of users.

Sui Gas Stations operates as backend infrastructure, allowing application developers to pay their users’ gas fees rather than requiring users to pay directly. Developers can utilize Gas Stations to support several types of sponsored transactions, including subsidizing user-initiated transactions, directly transferring gas fees to users, and giving users pre-funded “GasData” objects, similar to blank checks, for gas fees.

AI-Powered Security Audits – BugDar

Sui announced its partnership with Google Cloud’s AI platform called Vertex AI to build Bugdar. Bugdar, trained in developer languages, will help developers on Sui to debug code and augment code generation that would help create Web2-Web3 SDKs. It will also help identify vulnerabilities in Rust, Typescript, and Solidity.

Cryptographic Extensions

Sui has been working on several cryptographic advancements to improve user experience and increase developer/application utility.

Advanced Cryptographic Support Sui Move has evolved to support cryptographic APIs. The mainnet supports Groth16 Zero Knowledge Proofs and bilinear pairing elliptic curve pairing APIs, while verifiable delayed functions (VDFs) and Poseidon ZKP-friendly hash functions are currently in the testing phase on devnet. With the continued focus on cryptography, Sui can support optional confidentiality onchain, allowing developers to build privacy-preserving applications with verifiable computing. SuiLink, zkLogin, and zkSend are examples we will cover in this report.

Strategic Partnerships for ZKP Solutions:

Athens Stock Exchange is exploring working with Sui for its Electronic Book Building. Book building is the process of gathering bids from potential investors during Initial Public Offerings (IPOs) to determine the optimal price for a security2. Traditionally, this process involves banks and brokerage firms collecting price indications from their clients and funneling the data through an EBB platform2. ATHEX’s current EBB solution has facilitated over €10 billion in issuances, encompassing IPOs, secondary offerings, and corporate bond issuances. Mysten Labs designed a custom Zero Knowledge Proof (ZKP) system for the Athens Stock Exchange’s market operations.

Mysten Labs has worked on several in-house cryptographic solutions. We will look into zkLogin, user authentication, and using cryptographic schemes to improve application design and utility.

zkLogin

For the most part, in crypto, it has not been the easiest experience for users to manage their wallets and application sign-ins. Users have been burdened with storing their own private keys safely. This has led to several security issues, hacks, and wallet drains. In web2, the average person today only has to use one-click logins using SSO (Single-Sign-Ons), which allows them to access multiple applications with a single sign-in.

zkLogin is an authentication framework that allows users to sign in to crypto applications with their web2 login credentials. It differentiates itself from traditional SSO solutions by protecting user data. It leverages two components: Auth 2.0 and ZK Proofs.

OAuth 2.0 is an industry-standard protocol for authorization. It allows users to grant websites or applications access to their information on other websites without giving them their passwords. For example, when you use your Google account to log into a third-party app, you use OAuth 2.0.

Zero Knowledge Proofs, or ZKPs, are cryptographic methods that allow one party (the prover) to prove to another party (the verifier) that a statement is true without revealing any information beyond the validity of the statement itself.

zkLogin uses OAuth 2.0 to allow users to authenticate with familiar Web2 providers like Google or Facebook, obtaining a JWT (JSON Web Token) containing identity claims. It then leverages zero-knowledge proofs to verify the authenticity of this JWT without revealing the user’s specific identity details. This ZK proof demonstrates that the user has successfully authenticated with a valid provider while deriving a blockchain address that isn’t directly linked to the user’s Web2 identity.

Here is what a zkLogin workflow looks like:

1. A one-time ceremony generates a Common Reference String (CRS) for zero-knowledge proofs for the setup.
2. The user initiates OAuth login with an OpenID Provider (e.g., Google). The app generates an ephemeral key pair and embeds the public key in the OAuth nonce. After successful OAuth, the app receives a JWT (JSON Web Token).
3. The app retrieves a user-specific salt from a salt service using the JWT. A ZK Proving Service generates a zero-knowledge proof using the JWT, salt, and ephemeral public key. This proof verifies the JWT’s validity and the correctness of the user’s Sui address derivation.
4. The app computes the user’s Sui address based on JWT claims and the user’s salt.
5. The user signs a transaction with the ephemeral private key. The transaction is submitted to Sui with the ephemeral signature and ZK proof.
6. Sui validators verify the ZK proof against stored provider public keys. They also verify the ephemeral signature. If both verifications pass, the transaction is executed.

This process allows users to interact with Sui using OAuth credentials. It eliminates the need for users to manage long-term private keys without compromising security.

zkSend – Stashed

zkSend, running on the frontend Stashed, simplifies sending tokens on Sui. It allows users to create a unique link or QR code representing a specific amount of tokens they want to send. This link can be shared through any communication channel, such as email, messaging apps, or printed on physical media. The sender doesn’t need to know the recipient’s wallet address.

This is where zkLogin and zkSend work together. When the recipient receives the zkSend link, they can claim the SUI tokens by clicking it. If they don’t already have a Sui wallet, they can quickly create one using zkLogin, which leverages existing credentials from services like Google or Twitch. The sender retains control over the funds until they are claimed, with the ability to reclaim them if needed. This system effectively removes barriers to entry for new users and simplifies token transfers. Stashed supports multiple tokens and NFTs on Sui.

Beyond zkLogin and zkSend, which are on mainnet, Sui is working on providing developers with flexibility and enabling passkey support for FaceID, which is currently in devnet. Mysten Labs is also working on supporting EdDSA and ECDSA keys. Adding these keys will allow Sui to add support for assets like Bitcoin, Ethereum, and Solana. Additionally, Sui is exploring new schemes that will soon enable post-quantum safe signatures and private authenticators.

SuiLink

SuiLinks are soulbound NFTs verifying the ownership of a Sui address linked with an Ethereum or Solana address. This connection allows developers to get creative with how they choose to incentivize users on Ethereum and Solana to use applications on S’ui.

Suppose a DeFi protocol on Ethereum or Solana launches on Sui. In that case, it can incentivize its existing users to use the protocol on Sui with SuiLink NFTs to verify their addresses across both ecosystems.

Decentralized Storage with Walrus

Walrus is a decentralized storage network built on top of Sui. Walrus can store data related to NFTs or applications, data sets and model weights for AI applications, and even the long-term archives of blockchain history. Walrus can also be used as a data availability layer for Layer 2s, similar to Celestia and EigenDA. It can also host websites and other data, similar to how IFPS is used.

Walrus uses Sui for metadata management and governance but does not burden Sui nodes with data storage. Instead, it uses a separate committee of storage nodes to handle the actual data.

Walrus uses an encoding protocol called Red Stuff. Encoding protocols transform data into a format that can be efficiently stored and transmitted, ensuring its integrity and resilience against data loss. Unlike traditional encoding methods codes, Red Stuff encodes large files in a single pass. Red Stuff’s two-dimensional encoding further enhances efficiency, allowing for the recovery of lost data using bandwidth proportional to the amount of data lost and protecting against malicious actors.

Walrus nodes are encouraged to act honestly and reliably through rewards and penalties by staking WAL tokens. Nodes earn rewards for correctly responding to storage challenges, facilitating data writes, and participating in data recovery. On the other hand, they face penalties, including slashing their staked tokens, if they fail to meet their responsibilities.

Internetless Transactions

Mysten Labs is also working on making transactions without traditional internet connectivity happen. Early proof-of-concept (PoC) systems have demonstrated how Sui transactions can be completed via SMS, LoRa Mesh Networks, NFC cards, and even underwater. Mysten Labs published research on how internetless transactions with Sui can help conserve biodiversity and be used for various use cases in remote areas without connectivity.

Bringing Liquidity to Sui

Based on Artemis’s Ecosystem Flow tool, we can see that Sui has had massive inflows from other chains, with $3.01Bn year-to-date. The represented volume considers major bridges such as Wormhole, Across, Synapse, and each network’s own native bridge.

The presented volume does not include volume processed by Sui Bridge, which supports ETH and WETH transfers between Ethereum and Sui. The chart below depicts the flow of liquidity from other ecosystems into Move-based chains.

Ecosystem

Sui’s DeFi Landscape

Sui has been live on Mainnet since May 2023, processing $21Bn in DEX volume. Sui’s TVL crossed $1Bn in October 2024.

Cetus protocol and Aftermath Finance have led DEX volume, while NAVI protocol and Suilend lead lending/borrowing activities.

Suilend was created by the team behind SAVE(Solend), a lending protocol on Solana that had accumulated a +800M pre-FTX collapse. Suilend recently launched its liquid staking product called SpingSui and will be launching AMM called Steamm in Q1 2025.

 

Studio Mirai launched its own LST, mSUI, using SpringSui. Users are rewarded with Studio Mirai’s token staking Sui. They’re a consumer-driven venture studio that has created NFT collections such as Prime Machines.

Aftermath Finance is building a host of different DeFi solutions ranging from CFMM pools, a DEX aggregator, perpetuals exchange, an NFT AMM, MEV infrastructure, and a liquid staking product.

Sui currently processes 1.5-5% of DEX volume among all major L1s. Sui’s DeFi ecosystem has been gradually shaping up. Circle launched native USDC on Sui on September 17th, 2024.

Deepbook – Sui’s DeFi Liquidity Layer

Deepbook was created as a public good and is a decentralized CLOB (Central Limit Order Book). Unlike most DeFi protocols, it does not have a user interface. Instead, it sits under several DeFi protocols that have been integrated with it. All activities, such as order routing, matching, and settling, are executed onchain.

Deepboook’s Design

Users interact with Deepbook through a “Balance Manager,” a shared object responsible for managing their account balances and enabling them to perform actions such as depositing, withdrawing, placing orders, and staking. The trading activities occur within “Pools” of asset pairs that comprise three components. The “Book” is for managing the order book and executing trades, the “State” is for maintaining user data, trading volumes, and governance parameters, and the “Vault” is for settling funds after order execution.

DEEP Token

Staking DEEP tokens opens up incentives for both makers and takers. While staking DEEP does not explicitly give out rewards, it qualifies stakers to participate in maker and taker incentives that reduce fees.

Deepbook utilizes a dynamic fee structure to encourage active trading and liquidity provision. Taker fees gradually decrease as a trader’s volume increases over an epoch, while wallets staking a minimum amount of DEEP tokens receive further fee reductions. Makers, or liquidity providers, start off at higher levels and then gradually decrease as LPs consistently provide liquidity over epochs relative to other liquidity providers. This means that LPs are encouraged to provide incremental liquidity when liquidity is low.

Wash Trading Resistance

Deepbook has set measures to combat wash trading and malpractice, where artificial trading is used to inflate volumes and extract rewards.

• Tokens collected in an epoch can never be less than tokens distributed
• Each pool has a liquidity threshold; when crossed, the rewards given to makers for trades will be less than the fee collected for those trades.

This prevents traders from gaming Deepbook and extracting incentives maliciously.

Governance Capture Prevention

Staking DEEP tokens grants users governance rights, allowing them to participate in pool governance by submitting and voting on proposals to adjust pool parameters.

Traders with a higher percentage of stake could potentially collude to manipulate fees and introduce monopolistic pricing that may impact traders with smaller stakes by changing a pool’s parameters.

To account for these instances, Staking DEEP tokens gives governance rights, but governance rights increase with staking at sub-linear rates beyond a threshold. This also makes Deepbook resistant to Sybil’s wallet attacks.

Deepbook provides a wholesale liquidity venue for DeFi protocols on Sui, which is especially useful to aggregators. Deepbook is basically a direct competitor to AMMs on Sui.

More details on how maker and taker fees are adjusted are available in the Deepbook whitepaper.

Demystifying MEV in Sui

Before diving into MEV on Sui, let us take a moment to review MEV on Ethereum to help us better grasp the concept.

Blockchains are transparent systems that function with participation & contribution from multiple different parties. They work by sufficiently disseminating transaction information across a network of validators until a consensus is reached on ordering those transactions. For example, on Ethereum, proposers have control over transaction ordering, inclusion, or exclusion. They may choose to reorder transactions in a block and include them in a way that allows them to capture MEV. While a proposer on Ethereum ultimately decides on the ordering and inclusion of a block, searchers and block builders also have some influence. Searchers are entities that search the mempool for valuable transactions and create bundles to submit to block builders. Block builders are entities that build blocks based on transactions they receive from various sources, such as searchers and mempools, both private and public.

Here are some forms of MEV that predominantly exist on most blockchains

Arbitrage: Prices on Centralized Exchanges (CEX) and Decentralized Exchanges (DEX) change continuously. On DEXs, prices change every block and may not keep up with prices on CEXs for the same asset. There is a price difference for the same asset between different exchanges, creating an opportunity for arbitrageurs to profit by buying from the cheaper avenue and selling where the price is higher.

Liquidations: In DeFi lending protocols, users can borrow assets by putting up collateral. If the value of the collateral falls below a certain threshold, a liquidation occurs, allowing anyone to repay the loan and seize the collateral at a discount. A searcher could see a pending liquidation transaction and insert their transaction ahead of it to profit from the liquidation.

Sandwich Attacks: A searcher could see a user’s transaction to buy a token and insert two transactions of their own—one before and one after the user’s. The first transaction buys the token, driving up the price, and the second transaction sells the token to the user at an inflated price, squeezing profit from the user’s trade.

As Sui is a DAG-based network, multiple proposers are required to create blocks in a given round. The idea of using multiple concurrent proposers has been a topic of discussion within Ethereum’s and Solana’s ecosystems to increase throughput and decentralization. Sui and Aptos use MCP in production as of today.

Sui initially used Bullshark as its consensus protocol and has now transitioned to using Mysticeti. This affects how transactions are disseminated and the consensus is reached.

Emerging networks like Sui attract searchers because the level of competition tends to be lower initially, and fewer people have figured out how MEV can be extracted. Sui transitioned from using Bullshark to Mysticeti as its consensus mechanism and has several other upcoming changes in development that influence how transactions are executed and the consensus is reached.

To understand how MEV can be extracted in Sui, we need to understand

• What participants are involved in Sui’s transactions life cycle, and what role do they play?
• How is a transaction executed on Sui?

The Participants

Full Node: The role of full nodes is to store the entire Sui state and, optionally, history. They validate transactions across checkpoints and epochs. However, they do not sign transactions or participate in consensus. There is no stake requirement either.

Validator: The role of validators includes everything a full node does, including signing transactions, participating in consensus, voting on blocks, and monitoring the performance of other validators (as with Reference Gas Pricing). Unlike full nodes, validators have higher hardware requirements and require a minimum stake of 30M SUI (in the process of lowering to 1M). DeFi teams on Sui, such as Cetus, Aftermath, Suilend, and Kriya DEX, also run their own Sui validators. While a stake of 30M SUI is the current requirement, with SIP-39, Sui will gradually reduce the required stake to 1M SUI. At this point, it will be easier to view pending bundles and capture MEV.

The Transaction Lifecycle

Now, the transaction life cycle on Sui with Mysticeti needs to be understood to understand how transactions are executed on Sui.

1. A user creates a transaction and signs it with their private key. The signed transaction is picked by a Sui Full node running the Sui client.
2. The client sends the transaction to a quorum validator for signing.
3. Each validator performs validity checks on the transaction, including signature verification, ownership verification, object existence, and gas sufficiency. This is where validators that sign transactions have the required information to front-run/back-run users.
4. Validators sign the transaction, and the client collects signatures from a quorum of validators to form a transaction certificate. Then, the client broadcasts the transaction to all validators for potential submission to consensus and execution.
5. A. Owned Object transactions that do not have conflicting state changes are executed immediately by validators after receiving certified owned objects (5.A). As for shared object transactions, they are included in blocks proposed by each validator (5.B). Mysticeti deterministically orders them into blocks in the DAG. This means that blocks in Mysticeti do not contain 2f + 1 references to quorum certificates but instead reference blocks directly.
6. Transaction finality for shared objects is achieved after a validator signs the transaction, indicating the transaction is irrevocable.
7. Validators execute the transactions in the order determined by Mysticeti’s commit rule and post-commit processing.
8. Once a quorum of authorities executes the transaction certificate, its effects are final. Clients can collect a quorum of authority responses to create an effects certificate, which proves the transaction settlement.

Sui has no public mempool, unlike Ethereum. Still, based on Sui’s transaction life cycle, we can see that full nodes and validators have visibility on transactions before they are executed.

Validators see the majority of transactions but at roughly the same time as every other validator. This means that any delay in including a transaction often results in that transaction being picked up by another validator, potentially committed before the MEV-seeking validator has a chance to include its own MEV transaction. To increase their odds of winning the opportunity, validators could prepare transaction certificates beforehand and sign them as soon as they identify an MEV opportunity.

As for full nodes, they only see a small fraction of transactions, which limits their ability to capture MEV. Searchers, on the other hand, rely on spamming transactions as a strategy to deal with the unpredictability of transaction ordering due to non-deterministic factors, meaning that searchers cannot be sure if their transaction will be included first. Without knowing what user transactions might arrive or when, searchers blindly spam multiple transactions in hopes that one will either land and be included ahead of other searchers, increasing their odds of capturing MEV.

To atomically execute their strategies, searchers rely on PTBs (Programmable Transaction Blocks). PTBs can execute 1024 actions in a single execution operation. This also reduces the execution costs. Example PTB below.

Another example of a PTB could look like this: a user takes a flash loan of X on Scallop and swaps it for Y on Aftermath. They then sell the Y on KriyaDEX, exploiting a price discrepancy. Finally, they repay the flash loan with a small fee, securing a profit from the arbitrage—all within a single PTB.

On Sui, Arbitrage and liquidations are more commonly seen than sandwiches. Although it is possible to perform sandwich attacks, it requires greater access to the critical path of transactions on Sui, which is accessible to full node operators (or applications) or by running validators with a high stake requirement of 30M SUI, worth $60M, at the current token price of ~$2.

Data from Sentio shows an average of $18,000 in Arbitrage profits made by searchers over the past month. These figures do not include liquidations and sandwiches.

https://dash.sentio.xyz/dashboard/ye/sui-mev-analysis

MEV on any chain needs monitoring and governance. Otherwise, it may lead to privileged users abusing their abilities to extract value from the chain and its users. Across ecosystems where MEV is a focus, we have R&D organizations working on reducing negative externalities caused by MEV. Flashbots on Ethereum and Jito on Solana are examples. Application-specific sequencing is another design philosophy being adopted by DeFi protocols to mitigate/capture MEV and redistribute it to the applications and users.

On Sui, we have Shio and Aftermath Finance focusing on building infrastructure to help redistribute MEV back to users on Sui. Both Shio and Aftermath Finance plan on using auctions to build out their MEV solutions.

Auctions allow value exchange between those who own a commodity (sellers) and those willing to pay for it (bidders). In an auction, the commodity is sold to the bidder willing to pay the highest price. An auctioneer holds a significant influence over an auction as they host the auction, collect bids, select a winning bidder, and may even facilitate the transfer of the commodity to the winner.

Such auctions are held at several points in the Ethereum transaction supply chain. Sellers here are ultimately users who originate transactions (users, DeFi protocols), the commodity being valuable transactions, and the bidders are searchers and block builders. In these auctions, bidders compete to capture profits by winning the right to include their version of the transaction bundle into blocks that would dictate the future state of a blockchain. Let’s go over what Shio and Aftermath have in store for Sui.

Shio – OFAs on Sui

Shio is building order flow auctions on the Sui at the beginning of the transaction supply chain. This will allow searchers to compete over MEV opportunities, with the goal of redistributing those profits back to Shio’s users. Historically, most of this value has flowed to block builders and validators on Ethereum and Solana. This has led to major vertical integration and centralization issues. After much trial and learning, DeFi protocols on Ethereum have also begun moving in a similar direction with Application Specific Sequencing (ASS), which is aimed at giving users and protocols more autonomy over transaction sequencing and the ability to direct MEV extraction.

In Shio’s auction design, when a user initiates a transaction, it gets forwarded to Shio’s auction server, which simulates the transaction to determine if there are any MEV opportunities. If an opportunity exists, an auction is held, and searchers submit bids containing their back-run transactions that attempt to capitalize on the MEV opportunity. Searchers must specify a bid amount and transfer it by the end of the transaction block. Shio’s auction server selects the winning bids and bundles them with the original user transaction, which is then sent to validators for signing, after which it can be finalized.

SIP-19: Soft Bundles

Sui’s PTBs (Programmable Transaction Blocks) help execute a series of different operations at once. But there are two caveats: all the transactions must be signed by the same signer, and all transactions must be executed; if there are some transactions that don’t execute, the whole PBT is reverted.

PTBs are not ideal for Shio because Shio’s execution sequence requires user transactions and searcher bids, signed by different parties, to be executed atomically within the same bundle. If a searcher’s bid fails, the user’s transaction should also fail, preventing unintended consequences. However, PTBs are designed for single-signer scenarios, and adding transactions from different signers would invalidate their signature.

This led to SIP-19 (Sui Improvement Proposal). Shio proposed having soft bundles on Sui. Soft bundles allow the bundling and execution of transactions from multiple signers (user, searcher) atomically. D Fi protocols and validators can opt into Shio’s auction.

Here is a break-down of Shio’s auction process

1. Session Start: Searchers connect to ShioAuctioneer for auction notifications.
   1. Transaction Submission: User or order flow originators submit transactions to Shio. Shio then checks whether or not to place a delay for the auction.
2. Pre-Auction Checks:
   • If there are no MEV opportunities, Shio forwards transactions to execute without delay.
   • If the auctioneer is in timeout or unreachable, transactions execute with a maximum 100ms delay.
   • If there is an MEV Opportunity, ShioAuctioneer sets a 500ms delay before execution for the auction to take place.
3. Auction broadcast: Auctioneer broadcasts MEV opportunity (effects and gas price) for a 400ms auction window.
4. Searchers submit bids: Searchers submit back-run bids matching gas prices with a commitment to pay using a “hot potato” mechanism.
5. Auction ends: Winning bids form a “soft bundle” with the user’s transaction and are sent to validators for signatures.
6. Authorities sign: Validators sign PTBs and return them to Shio.
7. Assemble certificates: Shio client assembles certificates with soft bundles and forwards for execution.
8. Execution: Transaction blocks are executed by validators
9. Fallback Execution: The original transaction executes if the auction fails, ensuring no transaction is left unprocessed.

Aftermath Finance

Aftermath Finance operates a genesis validator on the Sui network and is building a comprehensive suite of DeFi solutions. These include a DEX-AMM, a DEX aggregator, liquid staking derivatives, a perpetuals exchange, NFT AMMs, and more.

To tackle MEV, Aftermath is developing an out-of-protocol auction system with a proprietary client that validators can run to potentially increase their yields, similar to the approach of Jito on Solana. Aftermath is currently testing this client on its genesis validator in the testnet.

Aftermath goes into detail on how they view Mysticeti and how it influences fairness and MEV on Sui in their research here.

Suiflow is another team working on Sui MEV Infra and is in stealth mode.

Sui has many moving pieces on how its infrastructure is evolving, especially with Mysticeti FPC coming towards Q1 next year. As we previously noted, clients, full nodes, and validators participate in a transaction’s life cycle, but validators have higher visibility on Sui’s unconfirmed transactions. Auctions from Shio, Aftermath & Suiflow would help democratize this value to a broader audience.

A Break Into Gaming – SuiPlay0X1

Mysten Labs is working on a portable gaming device similar to the Nintendo Switch series or Sony’s PSP. S Play0X1s will not only support games from the Sui ecosystem but also games from Steam and Epic Games.

The device is powered by an AMD Ryzen 7 7840U CPU and 512 GB SSD storage, with a 7-inch display. It runs on PlaytronOS, which extends support to both PC and mobile games.

It integrates zkLogin to allow users to sync with Sui’s ecosystem without going through the complexities of wallet creation. Su Play0X1 is priced at $599 and is available for pre-order, with fulfilments starting in 2025.

Conclusion

Several competing layer 1s try to differentiate themselves across execution and consensus-related aspects. Sui has not only differentiated itself by working on shipping extensions and improvements to its infrastructure but has actively executed on developing its ecosystems. Mysten Labs has invested in Sui ecosystem projects and has a vested interest in the success of its ecosystem. The team has been leading innovations across cryptography and AI, and the resulting tooling will take developer and user experience a step further.

The long-term success of layer 1s or layer 2s comes down to some of these questions –

• Can its ecosystem gather enough organic attention from both users & developers?
• Can the chain handle high volumes of activity without halting or failing transactions?
• Does it allow developers to get sufficiently creative with applications to facilitate innovative use cases? Does it have a friendly user and developer experience?
• Is the chain actively working on decentralizing and being transparent?

With this report, you may have had a look into how Sui is tackling these questions.

Sui’s Object model and Move shifts how developers manage global state, compute resources, and accounts.

Sui has many moving pieces on how its infrastructure is evolving, especially with Mysticeti FPC coming towards the end of the year. As we previously noted, clients, full nodes, and validators participate in a transaction’s life cycle, but validators have higher visibility on Sui’s unconfirmed transactions. Auctions from Shio, Aftermath & Suiflow would help democratize this value to a broader audience.

Upgrades such as Obelia, Adelie, and Mahi-Mahi will further scale execution and consensus, allowing Sui to handle higher volumes while lowering latency and opening doors for Sui to decentralize.

Sui’s venture into gaming with SuiPlay0x1, AI with Google Cloud on Bugdar, and Cryptography with zkLogin and other cryptographic libraries adds to its versatility and growth potential.

References

• https://www.mystenlabs.com/blog/announcing-walrus-a-decentralized-storage-and-data-availability-protocol
• https://docs.walrus.site/
• Shio On Sui
• Sui Documentation
• Notions of Fairness in Mysticeti | Concurrent Research
• Mahi-Mahi White-paper
• Obelia White-paper
• Deepbook Docs
• A Study on Shared Objects in Sui Smart Contracts
• SIP-39: Lowering the Validator Set Barrier to Entry
• SIP-19: Soft Bundle API
• Pilotfish: Distributed Transaction Execution for Lazy Blockchains
• Suivision