Sui Name Service (SuiNS) is not just decentralizing, it’s ensuring that those who are actively involved are rewarded. The goal of the transition to a decentralized governance model is to ensure that control of the protocol’s major decisions are in the hands of the community. The NS token plays a crucial role, allowing users to directly shape the platform’s future through governance.

While the ability to govern is important, it alone cannot sustain the level of activity required for a protocol that is so vital to the entire network’s experience. Incentives that encourage broad engagement are crucial for ensuring the success of SuiNS. Community participation in shaping the future of SuiNS is not only valued but rewarded.

Fostering community engagement

SuiNS has allocated 5% of the total NS token supply specifically for governance voting rewards. This commitment highlights SuiNS’s dedication to fostering an active and engaged community.

The NS token distribution allocates 5% of the total number of NS tokens towards governance rewards.

Each governance proposal will have a specific amount of NS tokens allocated to be distributed for rewards once the voting period is complete. Each individual NS token used in voting counts as one vote. So, a voting transaction from a wallet holding 100 NS tokens counts for at least 100 proposal votes. Governance rewards are distributed equally across all votes. 

For example, assume that 50,000 NS tokens in total are rewarded once a proposal’s voting period is closed and  2,000 NS token holders participate in voting, casting a total of 500,000 votes. A user that casts a vote worth 100 of the total proposal votes would receive 10 NS tokens as a reward for governance participation.

Understanding governance proposals and voting

Major decisions on SuiNS, including changes to contracts and certain disbursements from the DAO protocol treasury, will be put up for a community vote following their proposal. All NS token holders will have the power to vote Yes, No, or Abstain on each proposal. The SuiNS Foundation itself will not be able to vote at the outset, ensuring that the community drives the decision-making process.

Voting requirements

Voting on SuiNS governance proposals will have a few requirements for the votes and proposals to be considered valid. Votes made by NS token holders must be completed through the official channels, details to be shared in the near future, and must be placed within the designated voting period for the proposal. A proposal’s voting period is established during the creation of the proposal and will be clearly defined. 

Additionally, there will be a minimum required number of NS tokens participating in voting to reach quorum for a proposal’s outcome to be considered valid. 

Token locking increases voting power

By default one NS token is worth one governance proposal vote. For those interested in increasing their voting power, there will be an option to lock NS tokens from one to twelve months. Each month that tokens are locked, they gain 10% increase in voting power.

A token locked for one month will have a voting power of 1.1 and a token locked for two months will have a voting power of 1.21.

Consider the previous example where 50,000 NS tokens are allocated as a reward pool for a governance proposal, and the total voting power that participated is 500,000. A user who voted with 100 NS tokens would receive 10 NS tokens as a reward, assuming their tokens were not locked.

However, if the user locked their 100 NS tokens for two months, their voting power would increase to 121. With this higher voting power, the user would earn an extra 2.1 NS tokens, for a total of 12.1 NS tokens.

This system not only encourages long-term commitment to the platform but also ensures that those who are long-term aligned with SuiNS are rewarded appropriately.

Embracing a decentralized future with SuiNS

SuiNS is setting a new standard for governance on Sui, that will eventually put  governance control of the protocol in the hands of its community through the NS token. With 5% of the token supply allocated to governance rewards and major decisions made transparently, SuiNS empowers users to drive the platform’s evolution.

As we look ahead, stay tuned for the first governance vote happening this fall, where the community will have the opportunity to take the initial step in shaping the future of SuiNS!

Sui Builder House: Singapore just wrapped up, and the community showed up big time! The event was buzzing with exciting announcements, fun-filled activities, and endless conversations among community members and key industry leaders. 

In just one day, more than 600 people from across various communities and industries gathered in Singapore, all on the hunt for alpha. Big announcements from Circle, Decrypt, DeLorean Labs, and One Championship took center stage and turned heads. But it wasn’t just the announcements—some of the activities managed to steal the spotlight at times too.

Sui Builder House: Singapore housed over 600 people across three floors filled with activities, presentations, and networking opportunities.

“Sui is a next-generation blockchain driving the internet revolution from Web2 to Web3,”Adeniyi Abiodun, Mysten Labs CPO and co-founder, said as he kicked off the event. With industry leading performance, one of the fastest growing Web3 ecosystems, and groundbreaking innovations like Walrus, Sui is establishing itself as the global coordination layer for the new internet.

As we look back, here are the top five standout moments that made Sui Builder House Singapore truly unforgettable.

Circle announces native USDC is coming to Sui

Jeremy Allaire, CEO of Circle, shaped his presentation around the current landscape and future potential of stablecoins, while teasing that he’d drop some exciting news. As the presentation drew to a close, Allaire made the big reveal: USDC, one of the most trusted and transparent digital dollars, is coming to Sui.

Jeremy Allaire, CEO of Circle, announced that USDC is coming to Sui very soon.

USDC is already live on Sui Testnet and will soon launch on Mainnet, boosting liquidity and reducing stablecoin fragmentation across the ecosystem. Shortly after, the Cross-Chain Transfer Protocol (CCTP) will be integrated with Sui, enhancing interoperability with other networks, like Solana and Ethereum. Allaire’s endorsement of Sui’s technology and community signals the strength of this partnership and sets up the next stage of growth for Sui.

“We work with a number of different chains, and what we’ve seen from this community, and Sui itself as a technology, is super impressive.” – Jeremy Allaire, CEO of Circle

Walrus Whitepaper dropped

The future of decentralized storage took a big step forward with the release of the Walrus Whitepaper and the upcoming launch of the WAL token. As the decentralized web grows to include more rich media—like text, audio, video, and data archives—traditional blockchains can’t handle these storage requirements at scale. Walrus is positioning itself to be the go-to decentralized storage solution, offering cost-effective, scalable, and programmable storage, reinforcing Sui's position to be the global coordination layer.

The WAL token will play a crucial role in powering the Walrus network, enabling delegated proof-of-stake and ensuring reliable data storage through novel attestation challenges. The Walrus Testnet is launching soon, inviting developers to explore the possibilities that Walrus helps bring to life. 

Decrypt to store all media content on Walrus

Decrypt, a leading Web3 media outlet, is posting its entire content library to Walrus. As Ilan Hazan, Decrypt CPO and co-founder said, “We use Web3 to cover Web3,” and now they’re showcasing that commitment by storing 100% of their content on Walrus. This transition underscores Decrypt’s dedication to leveraging the best decentralized storage solution available.

Decrypt, one of the largest Web3 media companies, will be storing all of their content on Walrus.

Each article on Decrypt will link to its Walrus-stored counterpart, offering a clear example of how Walrus will revolutionize content management for media companies. 

DeLorean Labs and Sui accelerate innovation

DeLorean Labs is building on Sui, creating NFTs that represent build slots for the new DeLorean EV, granting the flexibility to the owners to interact with and even trade their DeLorean build slot. The DeLorean NFTs will remain tied to the car for its lifetime, unlocking a range of capabilities. NFT holders will even be able to drive their DeLorean in the Motorverse adding exciting layers of utility for enthusiasts.

In addition, DeLorean Labs is also offering the chance to mint your own DeLorean time capsule, with one lucky minter winning a brand-new DeLorean!

One Championship punches up sports media with Sui

ONE Championship, a combat sports media leader, is bringing their fan engagement into the Web3 era by building on Sui. By leveraging Sui’s user-friendly onboarding tools like zkLogin, ONE Championship aims to make it easier for their Web2 audience to cross into the world of Web3.

Fans will soon be able to engage with a manga series featuring ONE athletes, powered by Walrus. As part of this experience, fans can participate in a free-to-play pick’em game, with opportunities to win rewards, alongside phygital collectibles blending physical and digital elements.

Honorable Mentions

SUI & SuiPlay0X1 Giveaways

One of the exciting extras at the event was the SUI giveaways through NFC Stashed cards, with participants receiving up to 100 SUI per card. Every seated attendee was given a card, and more could be earned through event activities. Additionally, two attendees walked away with a SuiPlay0X1 pre-order, adding an extra layer of excitement to the day!

Attendees earned scratch off cards allowing them to redeem an award of up to 100 SUI through Stashed. Networking and Activities

The event’s venue spanned three stories, with networking and discussions buzzing on two floors alongside interactive partner booths and activities. Teams like Aftermath, NHN, Shinami, Studio Mirai, SuiLend, Lucky Kat, Tradeport, and many more helped energize the space with conversations, product demos, and more, creating an engaging atmosphere for all attendees

The excitement carried into the next day, with Steve Aoki headlining Move with Sui at Marquee and giving attendees a night to remember.

Over 2,400 guests turned out for the afterparty where legendary DJ, Steve Aoki, lit up the room. Only 1% done

Sui Builder House: Singapore was a huge success, but the excitement doesn’t end here. With all the announcements, partnerships, and the community’s incredible engagement, Sui is continuing to push the boundaries of what’s possible in Web3.

Whether you’re a builder, creator, or just someone excited about the future, there’s so much more to come. Stay tuned, Sui’s journey is just hitting its stride, and the best is still ahead!

Note: This content is for general educational and informational purposes only and should not be construed or relied upon as an endorsement or recommendation to buy, sell, or hold any asset, investment or financial product and does not constitute financial, legal, or tax advice.

As a testament to Sui's DeFi strength, native USDC will launch on the network soon. USDC has become one of the fastest growing, regulated, fully reserved digital dollars. 

USDC is issued by Circle, a global financial technology firm that enables businesses of all sizes to harness the power of digital currencies and public blockchains for payments. As of September 17, USDC now stands at more than $35 billion and has supported about $1.4 trillion in transactions over the past year. Today, Circle's open and programmable platform and APIs are giving rise to a new generation of financial services and commerce applications. 

Integrating USDC on the Sui Network immediately enhances Sui’s utility and interoperability for users and developers, adding liquidity, streamlining transactions, and improving market efficiency across the ecosystem. Additionally, Sui’s thriving DeFi environment, which as of September 17, 2024 boasts over $650 million in total value locked, over $350 million in stablecoin market cap, and consistently ranks near the top of all blockchains in weekly DEX trading volume, provides a key foundation for USDC to continue to scale.

Note: This content is for general educational and informational purposes only and should not be construed or relied upon as an endorsement or recommendation to buy, sell, or hold any asset, investment or financial product and does not constitute financial, legal, or tax advice.

3DOS, a manufacturing innovator, announced it will integrate its expansive 3D printing network with Sui. This integration enables users, 3D printers, and manufacturers to connect across a global, accessible, decentralized network. 

Unlocking the full power of decentralized 3D printing depends on precise, real-time coordination. Acting as the universal coordination layer, Sui synchronizes users, 3D printers, and manufacturers into an efficient, unified network. By orchestrating these interactions, Sui ensures that production resources and manufacturing needs align perfectly in real time.

The 3DOS vision

As it builds the world's largest peer-to-peer 3D printing network, the 3DOS vision allows anyone to access 3D printers anywhere in the world, with Sui acting as a coordination layer, so products are made on-demand locally: no waste, no inventory, no international shipping. 

Through its technology and integration with Sui, 3DOS will revolutionize manufacturing. The expansion of this domain and the increase in accessibility has the potential to transform the manufacturing industry and empower local economies worldwide.

Billions of people around the world rely on manufactured products.

Millions of businesses use and pay for manufacturing capacity globally.

Coordination is a huge problem with high latency and large costs.

The $15.6 trillion global manufacturing market is shifting to decentralized localized production.

Together, Sui and 3DOS address these challenges by streamlining coordination, reducing costs, and coordinating decentralized production

The collaboration between Sui and 3DOS decentralizes the $15.6 trillion manufacturing market, using Sui’s coordination technology to empower local producers. By connecting idle 3D manufacturing capacity to millions of users globally, 3DOS allows individuals to tap into the broader manufacturing market and even create new opportunities in areas where traditional manufacturing is impractical or unfeasible.  

3DOS' founders invented one of the world's first 3D printing operating systems, with over 500,000 users, 4.2 million parts, over 15 million CAD designs, manufactured across more than 120 countries with customers such as John Deere, Google, MIT, Harvard, CalTech, Berkeley, Bosch, the British Army, US Navy, US Air Force, and NASA. 

Powering decentralized manufacturing

The partnership between 3DOS and Sui marks a significant step towards realizing the vision of one-click manufacturing, where anyone can upload a design and manufacture it globally. As the world moves towards decentralized production and accessible finance, the collaboration promises to unlock unprecedented opportunities for innovation and economic empowerment.

At the heart of a high-throughput blockchain is its ability to handle numerous transactions swiftly and securely. However, when transactions in Sui involve writing to the same shared object, they must be executed sequentially. This can translate to longer checkpoint times which may reduce state synchronization efficiency.

The first goal of shared object congestion control is to improve efficiency in checkpoint execution. By controlling the number of transactions touching a congested, or hot, shared object within each checkpoint, the system ensures that processing times remain consistent, preventing delays.

This mechanism also promotes transaction fairness by ensuring that transactions with higher gas fees are prioritized in checkpoint inclusion. Users will expect more costly transactions to process more quickly.

Addressing Sui's earlier limitations

Sui previously managed shared object congestion through its transaction manager. This system monitors the total number of transactions that are pending execution, waiting for the required objects to become available. If pending transactions exceeded a threshold, the transaction manager would stop accepting new requests for transaction signing or execution.

The previous mechanism, though effective in certain scenarios, fell short in several areas. For example, it often led to partial transaction rejections and object lockups due to inconsistencies across validators. It did not accurately estimate the execution times for sequences of dependent transactions, leading to inefficiencies and potential congestion in processing. Finally, when an object congested, the previous solution rejected all incoming transactions until the current transactions were executed, meaning that there was no ability to prioritize inclusion using gas payments.

A closer look at congestion control 

The new Consensus Handler design introduces a more nuanced approach to managing execution dependencies across hot shared objects. This includes two new functions added to validator logic:

The ability to defer transactions: The consensus handler now has the capability to defer transactions to future consensus commits, managing execution dependencies in checkpoints more effectively.

Active transaction cancellation: Validators can now actively cancel transactions that have been deferred excessively. When a transaction is canceled, it is still processed but with a command to the execution engine to stop immediately. Once it receives this instruction, the execution engine releases any objects it has locked and quickly sends back a cancellation error to the client without completing the transaction.

The Consensus Handler sorts and manages transactions. This diagram uses colored circles to represent transactions with different gas amounts.

When the Consensus Handler receives a consensus commit, it first merges the transactions in the commit with any that were previously deferred, sorting them by gas price. It then examines each transaction one by one, creating a per-object execution dependency graph that outlines the crucial steps needed for checkpoint execution. This process ensures that transactions are handled efficiently and in order of their cost.​

To add a transaction to the dependency graph, the handler evaluates all the shared objects involved in the transaction. It identifies the object with the longest queue to start the transaction’s execution, aligning the queues of all involved objects to this maximum length. The transaction’s cost is then added to each object’s queue, updating the execution order.

The dependency graph provides an estimate of execution latency for each object based on the longest queue, which also indicates the overall latency for the consensus commit. There is a maximum limit for queue length in each consensus commit. If a transaction exceeds this limit, it’s deferred to a future commit. If deferred repeatedly exceeding a certain threshold, a transaction is canceled and removed from processing. This typically occurs when a transaction targets a highly demanded object but offers a gas price too low to be competitive.

The new design increases efficiency by monitoring execution dependencies and limiting transactions that involve highly demanded shared objects within each consensus commit, thus protecting checkpoint execution. Crucially, transactions that do not involve these high-demand objects are not affected by these limits.

Solving previous challenges

As mentioned, the previous system struggled with tracking transaction queues for each object, leading to inefficiencies. The shared object congestion control mechanism not only tackles these challenges but also introduces significant improvements to streamline the process. The new approach ensures uniform decision-making among all validators on whether to execute, defer, or cancel a transaction. This change effectively eliminates the problems associated with locked objects and allows for the quick release of objects held by transactions of lower priority.

The congestion control mechanism also enhances accuracy by tracking the full transaction dependency graph within each consensus commit. This means it carefully notes the sequence and dependencies of transactions, providing a much clearer view of the actual time it takes to execute checkpoints. By doing so, it addresses complexities and inefficiencies that were previously overlooked.

Additionally, by deferring transactions and incorporating them with new ones in subsequent consensus commits, the new method supports local fee markets. This setup benefits transactions with higher gas prices, ensuring they have a better chance of being processed during busy periods. Users gain the ability to pay for inclusion, which can be especially powerful for DeFi activities.

Finally, the new approach tends to achieve a better performance in hot shared object workload before any degradation in checkpoint execution occurs. This improvement stems from the consistent and collective decision-making by validators, which leads to more efficient transaction processing and increased overall network throughput. This uniformity ensures that the system can handle more transactions before any performance issues arise.

Sui clears the path

The implementation of shared object congestion control is more than a technical upgrade, it’s a strategic enhancement that significantly improves the scalability and efficiency of Sui.  With this foundation, users and apps on Sui can now enjoy greater transaction efficiency and reliability. The streamlined congestion control mechanism provides a springboard for deploying more complex and responsive applications, further expanding the ecosystem’s capabilities.

Over the next decade, estimates peg the number of internet-enabled devices to grow to nearly 40 billion. Whether it’s tracking the movement of ride-sharing vehicles, improving food traceability, monitoring manufacturing facilities, or securing someone’s home, the Internet of Things (IoT) is now a critical technology for businesses and consumers alike. 

But as the number of devices increases, so does their incompatibility. Silos exist between IoT devices from different manufacturers, forcing users to hop from application to application. And it becomes more challenging to use different devices in tandem to gain greater, collective value from the hardware. 

Chirp has set out to solve this problem. Backed by a user-driven, decentralized physical infrastructure network (DePIN), its ecosystem works across many different radio protocols. Beyond just providing the network, Chirp also gives users access to a growing ecosystem of tools designed to help decentralized projects involved in real-world assets (RWAs) go live faster. 

“We aim to simplify IoT by enabling devices from different manufacturers to communicate with each and the blockchain seamlessly, thereby connecting every IoT device under one platform," said Chirp founder and CEO Tim Kravchunovsky. 

"IoT can be complex and time-consuming, which is why we provide all the tools necessary for companies to bring their applications to market faster. Essentially, the RWAs are IoT devices that need to communicate with each other and the internet, and we believe that projects shouldn't have to deal with the intricacies of IoT. Instead, they should be able to focus on delivering their use case. 

“That’s why dozens of projects are already building with Chirp – from decentralized farming applications to ride-sharing, electric car charging, vehicle tracking, and property management. Chirp handles everything from connectivity to the IoT complexities so that they don’t have to.”

Chirp is rolling out its IoT technology on a global scale.

For Chirp to execute its vision, the company needed a blockchain partner that offered low, predictable costs, as well as fast and reliable speeds. With throughput capable of speeds up to 297,000 transactions per second, as well as consensus latency down to around 390 milliseconds, Sui provided the foundation for Chirp to pursue its goal of supporting millions to billions of IoT devices and gathering data from all the different hardware to unlock new use cases. 

“When you're launching a token on the blockchain, it becomes the backbone of any project,” said Kravchunovsky. “It’s very important to select a quality partner because you’re partially putting your success in their hands.” 

Community-driven 

Unlike a large, centralized telecommunications company, which requires users to connect to antennas the company owns and operates, Chirp relies on a community-driven model. Users buy and install antennas that join to create Chirp’s radio-agnostic network.

Chirp's Blackbird antennas connect multiple IoT devices using disparate radio protocols, bringing these devices together into one coherent network.

There are numerous IoT connectivity technologies, each used for different purposes. Some allow devices to connect while conserving energy, while others enable the transfer of large amounts of data, such as video transmission. Unfortunately, no ecosystem enables the devices from different manufacturers to communicate with each other. Manufacturers often design their devices to work exclusively with their proprietary apps, creating an incredibly fragmented space. 

"IoT is the biggest creation from the inception of the internet. Yet the space is difficult and extremely fragmented," said Kravchunovsky. "At Chirp, we aim to unite IoT and create an ecosystem that will power the future. It doesn't matter which protocol is trending; users can choose the one that works best for their RWA use case, and that’s only possible with Chirp."

RWA made easy - Dashboards, visualizations, and more 

Connectivity is just the first step. The company’s suite of IoT tools helps RWA projects build apps more cost-effectively and increases the speed they can go to market. This means they don’t have to focus on sensor compatibility, but can rather focus on developing their apps. Chirp is developing the following tools for projects working on RWAs:

Connectivity: Chirp provides a community-owned radio access network to connect IoT devices. Additionally, Chirp partners with telecoms, allowing their clients to use Chirp's network, but also extending Chirp's reach.

Visualization Engine: Devices transmit data in computer code, so visualization is needed to understand what the device is sending.

Data Normalization: There is no universal standard for sensors from different manufacturers, as they often design devices to work with proprietary apps. In decentralized ride-sharing, for example, a company would either need to modify the code for each car tracker model or use Chirp's normalization engine to obtain a unified data file.

Rules Engine: Before the Chirp network, devices from different manufacturers couldn’t communicate. The project’s Rules Engine allows users or projects to create rules that trigger actions across devices or blockchains. This includes temperature sensors in supply chain management, for instance. Installed in temperature-sensitive transportation, these sensors send a command to a smart contract to release automatic payment because temperature requirements were met during the transportation.

Alerting Engine: IoT devices send data, and users need to be notified when critical events occur. In the decentralized ride-sharing example, if a car is stolen, the system can alert the responsible party, or police, and remotely disable the engine.

Blockchain Engine: Chirp is the first project to connect IoT device data with blockchain. This creates trusted, immutable data, unlocking new possibilities in supply chain management, insurance, and law enforcement, among other fields.

“All projects need to do is build an app, and we provide them with everything else. At Chirp we unite the Web2 and Web3 worlds” said Kravchunovsky. 

An IoT dashboard allows users to easily connect any supported devices that can be purchased on the internet. Users can visualize the data packets transmitted by the devices, as well as normalize the data coming from all the devices of different manufacturers.

The Chirp dashboard lets users easily connect IoT devices to automate their home or business and use the network. Tokenizing IoT

Chirp is in the process of minting 300 million $CHIRP tokens that it plans to release on Sui. Half of this stockpile is dedicated to network participants. Users who install an antenna are rewarded with $CHIRP tokens, which will be tradable on centralized exchanges. The company is also working on a DePIN game with real-world utility that turns smartphones into miners, letting players earn $CHIRP tokens.

A mining dashboard makes it easy for users to manage their rewards and to expand the community-owned Radio Access Network by connecting a miner to the network.

The Chirp dashboard lets community participants view stats about their mining activities.

The overall strategy Chirp takes is to protect the rewards of antenna operators (aka ‘Keepers’) by issuing fewer tokens and limiting the number of miners on the network. Smart contracts will analyze the area, and when it becomes overly saturated with miners, it will be closed for further installations. This allows users to participate in other areas, effectively spreading coverage rather than accumulating it in one geographical location, which provides no benefit to clients. 

“Chirp's goal is to provide carrier-grade network connectivity, so Keepers must abide by stringent installation rules. This reduces the number of miners needed, safeguards their rewards, and ensures a high quality of service for clients using the network," said Kravchunovsky.

Coined by Ethereum co-founder Vitalik Buterin, a Soulbound token (SBT) is an NFT designed to be permanent and non-transferable. Unlike typical NFTs, which can be freely traded, SBTs remain bound to their original account, much like how skills or accomplishments in a game are tied to an individual user or account and cannot be transferred or traded. SBTs are useful in representing a person's identity, credentials, or achievements in the digital world.

The potential applications for SBTs are vast, ranging from verifiable credentials and reputation systems to more nuanced forms of governance and asset management. By providing a way to represent non-transferable attributes onchain, SBTs could revolutionize how we approach digital identity, professional certifications, and even social credit systems in decentralized environments.

Technical implementation of SBTs on Sui

To make an NFT non-transferrable on Sui, thereby creating an SBT, developers can leverage Sui's object-centric data model. The primary step to create an SBT on Sui is to remove the

store

ability from the NFT structure. This crucial modification prevents the token from being freely transferred to other addresses using Sui's standard transfer functions.

When an object lacks the

store

ability, only the module that defined the object can transfer it, using the sui::transfer::transfer function. This restriction allows developers to implement custom transfer rules, providing fine-grained control over how and when the token can be transferred, if at all. By combining these features, developers can create tokens that exhibit the non-transferrable nature characteristic of SBTs, while still maintaining flexibility in defining specific behaviors as required by their use case.

Sui allows SBTs to evolve

One of the standout features of SBTs on Sui is their ability to incorporate dynamic properties through Sui's dynamic fields. This functionality allows Sui NFT attributes to be modifiable after initial creation. As a result, SBTs can evolve based on creator decisions, user actions or achievements, changes in a user's status or credentials, and adapt to new use cases without requiring a new token. This dynamic capability enhances the utility of SBTs, making them more relevant and valuable over time.

Sui's object display standard complements SBTs by providing opportunities for enhanced visualization and interaction with these non-transferrable tokens. The display standard can be utilized to create custom visualization logic for SBTs, ensuring that their unique properties and dynamic nature are accurately represented in user interfaces. By combining these features, developers can create SBTs on Sui that are not only non-transferrable but also dynamic and adaptable, opening up new possibilities for various use cases.

Case studies of SBTs on Sui

Token allocations: DeepBook and NS

DeepBook, Sui's native liquidity layer, and SuiNS, the premier name service on Sui, have both utilized SBTs as a way to provide clear token allocations to users before token generation.

DeepBook's DBClaimNFT serves as a soulbound claim ticket for the upcoming DEEP token launch. This innovative approach ensures that early supporters and community members have a verifiable, non-transferable right to claim tokens upon launch. Similarly, SuiNS employed SBTs for its upcoming plans to decentralize, further establishing the use of SBTs as a valuable tool for distribution strategies.

The use of SBTs for token allocations opens up exciting possibilities for project governance and community engagement before a token's official launch. For example, projects could use SBTs to grant early governance rights, allowing token holders to participate in a formal decision-making process and shape the project's direction even before a token is live.

SuiLink 

SuiLink leverages SBTs to create cross-chain identity verification. By issuing SBTs on Sui, SuiLink establishes a direct, verifiable link between a user's Ethereum or Solana address and their Sui address. This implementation of SBTs creates an onchain representation of user identities across multiple blockchain ecosystems. This approach shows the potential of SBTs in enhancing interoperability, potentially facilitating more secure and reliable cross-chain interactions.

SuiPlay0X1 purchases

SuiPlay0X1 leveraged SBTs to represent pre-order purchases of their physical devices. This application demonstrates how SBTs can bridge the gap between digital and physical assets while ensuring certified reservation and uniqueness onchain. Each pre-order is represented by an SBT, creating a digital twin of the physical device reservation.

Notably, the first 1,000 pre-order customers received special edition SBTs with distinct visual representations, adding an extra layer of exclusivity. Furthermore, each SBT is sequentially numbered to correspond with the order of purchase, so the 1,001st buyer received an SBT prominently displaying "#1001". This numbering system not only verifies the order of purchase but also creates a sense of community and status among early adopters.

The appearance of SuiPlay0X1 NFTs varies based on whether they are among the initial 1,000 or not.

By using SBTs for these pre-orders, SuiPlay0X1 ensures that each reservation is uniquely tied to its original purchaser, preventing unauthorized transfers or resales of pre-order rights. This approach highlights how soulbound tokens can add value and significance to digital representations of physical items, especially in contexts where the non-transferability of the right or reservation is crucial to maintaining fairness and authenticity in the distribution process.

SBTs for tomorrow

Unlike static SBTs on other platforms, Sui's implementation allows these tokens to evolve over time, adapting to changing circumstances and user interactions. This flexibility opens up exciting possibilities beyond the uses currently seen with DeepBook, SuiNS, SuiLink, and SuiPlay0X1.

Looking ahead, we can envision SBTs impacting areas such as event ticketing, gaming achievements, and intellectual property protection. As the broader ecosystem grows, the dynamic capabilities of SBTs on Sui will play a crucial role in shaping new forms of digital identity and ownership, paving the way for innovative apps that we've yet to imagine.

Following Agora's earlier announcement in May, the AUSD stablecoin is now live on Sui. AUSD adds a key dimension to Sui’s surging list of native assets.

Building on its prior successes on Ethereum and Avalanche where nearly $60 million worth of the token has been minted so far, AUSD’s integration into the Sui Network immediately enhances its utility, accessibility, and interoperability. The integration has already begun improving liquidity and market efficiency within Sui’s rapidly expanding DeFi ecosystem, which currently boasts over $600 million in Total Value Locked (TVL) and consistently ranks among the top chains in weekly DEX trading volume.

AUSD joins a growing number of stablecoins on Sui, which drive the development of robust DeFi applications and expand the adoption of blockchain technology. By leveraging Sui’s scalable, high-performance network, these stablecoins contribute to a high-performance environment where developers and users can innovate and focus on delivering superior experiences without being restricted by the technological limitations that have constrained other networks. Agora's integration with Sui also continues to expand the reach of AUSD and furthers the growth of the global AUSD network and liquidity. 

Note: This content is for general educational and informational purposes only and should not be construed or relied upon as an endorsement or recommendation to buy, sell, or hold any asset, investment or financial product and does not constitute financial, legal, or tax advice.

Sui Name Service (SuiNS), the leading naming service on Sui, enhances onchain interactions by replacing complex wallet addresses with user-friendly, memorable names. Through its previous two years, the service has undergone refinements and improvements to better serve its mission of creating easy, human-readable identities.

Drawing on its common usage in social media, SuiNS takes it a step further and by incorporating the ‘@’ symbol, making Web3 identities even more intuitive. Users familiar with tagging friends on social platforms will find SuiNS’s @name format familiar, facilitating easier transfers. 

SuiNS extends its utility with the introduction of subnames, enabling the creation of even more unique identities. This feature is especially beneficial for companies, DAOs, and other organizations seeking to create vanity names or usernames that clearly and efficiently represent their presence on the blockchain. 

Now SuiNS is about to take another huge step with community governance. Ensuring that the community takes the helm of decision making is crucial for a naming service to become a true public good. As SuiNS embraces a decentralized model, it's an ideal moment to reflect on its journey and look at what lies ahead.

SuiNS milestones

September 2022: SuiNS FoundedSuiNS was established, setting the foundation for a user-friendly naming service tailored for the Sui blockchain, with a focus on simplifying onchain interactions.

October 2022: SuiNS Live on TestnetThe first iteration of the SuiNS website launched, allowing early users to explore and interact with the service on Sui Testnet. This moment allowed the community to begin providing essential feedback and played an active role in shaping its development.

December 2022: SuiNS Mobile Site LaunchedSuiNS developed a mobile site enabling users to manage their names conveniently on the go.

January 2023: Surpassing 100,000 FollowersSuiNS attracted more than 100,000 followers on Twitter and Discord, highlighting its growing influence within the Sui community.

January 2023: SuiNS and Frens AMAs Reach 3,000 Audience MembersThe “SuiNS and Frens” AMAs attracted over 3,000 participants, fostering deeper community engagement and interest.

February 2023: 300,000 Unique Wallet InteractionsSuiNS introduced Sui.id, enabling users to bridge their Web3 persona to Web2 devices, which contributed to surpassing 300,000 unique wallet interactions on the platform.

May 2023: SuiNS Goes Live on MainnetSuiNS made its official debut on Sui Mainnet, featuring an auction system that allowed all users to have a fair chance at acquiring their preferred names.

June 2023: 3,000 Live Auctions AchievedWithin a month of the Mainnet launch, SuiNS conducted over 3,000 live auctions, demonstrating strong demand for the name service.

July 2023: Integration with Over 20 PartnersSuiNS was integrated by more than 20 partners and is an integral part of the Sui explorers, enhancing its utility across the Sui network.

October 2023: Full Discount and Couponing Mechanism BuiltSuiNS introduced a discount and couponing system, allowing users opportunities to acquire SuiNS names at discounted rates.

March 2024: Integration into DeFi Apps and LeaderboardsSuiNS began integrating with DeFi apps and leaderboards so that users could easily identify which account they are using on an app and recognize each other on leaderboards.

June 2024: SuiNS Refresh and New FeaturesSuiNS refresh introduced a suite of new features, including subnames and a new @ naming standard, complemented by a freshly redesigned website and user experience. 

August 2024: Transition to Decentralization AnnouncedSuiNS announced its transition to a decentralized model, ushering in a new era of development and empowering the community to have a direct impact on its future direction.

Every milestone in the SuiNS timeline has brought SuiNS a step closer to its goals of removing friction and enabling powerful identity management solutions. As SuiNS embraces the next stage of its evolution, the focus now shifts to empowering the community in shaping the future of SuiNS. Together, the community will steer SuiNS towards achieving new goals in this next chapter.

Future vision and goals

The next significant milestone for SuiNS is the launch of the $NS token, a crucial element in the governance of the SuiNS platform. NS token holders will have the ability to directly influence decisions that shape the future of SuiNS, ensuring that its development is driven by those who use and value it the most. 

The community will have the power to vote on new features that enhance the platform’s usability and customization options. Among the many initiatives that the community may dream up, there are some obvious natural next steps:

The ability to register shorter names (one to two characters) or use emojis in a SuiNS name

Introduce static USD pricing for name registrations

Introduce an NFT avatar generator that allows users to create custom profile pictures for their SuiNS names 

Increased homepage functionality including dynamic trade-aware widgets and name lookup search

Auctioning system for existing names

Referral system

SuiNS subnames widget

SuiNS fiat on-ramp and payments in tokens other than SUI

Linktree style functionality for SuiNS

These potential updates will be shaped by community input, ensuring that SuiNS evolves in alignment with user needs.

In a move toward greater transparency and collaboration, the SuiNS front-end codebase will become open source. Developers from around the world will be able to contribute, driving continual innovation and improvement to the platform.

The road ahead

Looking ahead, the vision of SuiNS is clear: to harness the power of its community to continually redefine the standards of onchain identity management, ensuring it remains easy, secure, and user-centric. With the introduction of the $NS token and commitment from the community to ongoing enhancement, SuiNS is poised to not only maintain its importance with the Sui ecosystem, but also play a pivotal role in growing the Sui community. 

As SuiNS transitions into a decentralized governance model, it emphasizes the important role that each community member plays in providing their valuable feedback and opinions to shape the development of the protocol. If you haven’t already, join the community, use SuiNS, and help shape the future of onchain identity.

Note: This content is for general educational and informational purposes only and should not be construed or relied upon as an endorsement or recommendation to buy, sell, or hold any asset, investment or financial product and does not constitute financial, legal, or tax advice.

Following hints earlier this year, the first handheld Web3 gaming device takes the stage during Korea Blockchain Week. SuiPlay0X1, with native support for Sui games along with Steam and Epic game libraries, ushers in a new era of gaming, combining the excitement of AAA gameplay and new features around digital assets enabled by blockchain technology. 

And better yet, SuiPlay0X1 lets gamers play wherever they happen to be. Ready, Sui, Play!

Sui, with its scalable network and industry leading transaction speeds, realizes the promise of Web3 gaming, where players gain a highly personalized experience through their owned digital assets. Rather than game makers needing to build in-game markets, Sui natively supports tradable assets with a high degree of customization available. Unlike other blockchains, Sui's object data structure supports in-game items that players can easily personalize and swap. 

0:00 / 0:34 1×

Sui native features such as zkLogin mean that players don't need any knowledge of Web3 to set up an account and start playing. 

No other blockchain supports Web3 gaming like Sui.

Sui in your hands

SuiPlay0X1, the first Web3 handheld gaming device, uses premium hardware, giving gamers both a pleasing handheld experience as well as high performance. The body includes a 7-inch bezel-less screen, trigger, buttons, joystick, USB-C, headphone jack, and a TF Card slot for external memory. 

Inside the device, an AMD Ryzen 7 7840U CPU provides the power to run the thirstiest games. Dual six-axis gyroscopes capture motion while an onboard 512 gigabyte SSD provides ample storage. 

With its sleek profile and premium hardware, SuiPlay0X1 is a top-tier gaming companion.

SuiPlay0X1 runs Playtron OS, a lean operating system designed specifically for gaming.

As a dedicated gaming device, players will be able to dive into the latest Sui games and be the first to experience a new paradigm with in-game items taking on new life and the potential for rewards. In addition, players will also have their Steam and Epic games on hand, giving them the best of all worlds.

The combination of a premium device, the industry's most performant and user-friendly blockchain, and a streamlined operating system deliver an unparalleled experience, which will transform mobile gaming and bring open Web3 to everyone.

Reserve yours today

Players can reserve SuiPlay0X1 beginning today for $599, with deliveries expected in 2025. Payment can be made using SUI, SOL, or ETH. Fiat currencies are not accepted during this early reservation period.

The tokenization of Real World Assets (RWAs) is reshaping how traditional physical assets are managed and traded digitally. By bringing these assets onchain and integrating them into DeFi ecosystems, tokenized RWAs provide more accessibility, efficiency, and functionality for assets such as real estate, commodities, and fine art.

Beyond the general advantages of onchain assets, Sui uniquely supports RWAs through powerful primitives and its unique object-oriented architecture that enable innovative approaches to bridge the gap between traditional finance and DeFi.

What are real world assets?

In the context of a Web3, the term RWA refers to assets that naturally exist outside of blockchain ecosystems. They are often physical or tangible assets that have been digitized and represented onchain. These assets are tokenized or converted into digital tokens that can be bought, sold, and transferred within DeFi ecosystems. 

Tokenization of RWAs brings the transparency, security, and efficiency attained in DeFi to assets with deep levels of liquidity and wide reach. This process can make traditionally illiquid assets, like real estate or fine art, more accessible to a broader audience by more easily enabling fractional ownership. Additionally, RWAs can offer more straightforward and faster transactions, as they reduce the need for intermediaries like brokers or escrow agents. RWAs also benefit from a proven chain of ownership, ensuring that at least the digital version maintains clear and verifiable provenance throughout its lifecycle. This is particularly important for assets like art or collectibles, where ownership history significantly impacts authenticity and value.

Examples of RWAs

The concept of tokenizing assets can apply to a wide range of sectors. Here are a few examples that illustrate the diversity and potential of RWAs:

Real estate: One of the most interesting examples of RWAs is real estate tokenization. By converting property ownership into onchain assets, individuals can buy and sell fractional shares of real estate, making property investment more accessible to those who may not have the capital to purchase an entire property. In the case of full-ownership purchases, real estate RWAs streamline processes eliminating some of the traditional costs of purchasing a home while also providing instant ownership transfers. 

Commodities: Commodities such as agriculture, precious metals, and oil are common assets of interest for tokenization. Tokenized commodities offer individuals a convenient and secure way to gain exposure to these markets, allowing for fractional ownership and more efficient trading, without the logistical challenges and costs associated with traditional methods.

Fine art: Physical art pieces can be tokenized to enable fractional ownership, allowing multiple investors to own a portion of a masterpiece. This democratizes access to the fine art market and provides liquidity for art investors, who can buy and sell their shares onchain. For example, ArtFi is building for this vision, leveraging Sui technology to provide access to fine art onchain in a sophisticated way.

Being onchain assets, RWAs provide interesting DeFi opportunities as well. Assets onchain benefit from composability with DeFi protocols and other assets. For example, tokenized real estate can be used as collateral to borrow funds in DeFi lending platforms. Imagine leveraging a tokenized home deed onchain to quickly access liquidity in the event of an emergency, such as covering unexpected medical expenses or making urgent home repairs. This capability allows traditionally illiquid assets to become accessible financial instruments.

Sui uniquely supports RWAs

Thanks to the distinct architecture of Sui and its powerful primitives, Sui uniquely supports the tokenization and utilization of RWAs. Using Sui’s dynamic NFTs, Sui Kiosk, and Closed-Loop Tokens (CLTs), builders are able to design more sophisticated RWA platforms.

Sui’s dynamic NFTs allow RWAs to be represented in a way that can evolve and update over time, capturing changes like property improvements or shifts in valuation. This capability ensures that the digital token remains aligned with the current state of the asset, enhancing both transparency and accuracy.

Sui Kiosk plays a crucial role in simplifying transactions involving RWAs. As a user-friendly platform for buying, selling, or leasing tokenized assets, Sui Kiosk reduces the barriers to accessing and trading these assets, making the process more intuitive and accessible for users. Sui Kiosk's ability to apply automatically enforced royalties comes in especially useful for fine art and collectibles, where the creator can benefit from secondary sales.

In addition, Sui’s CLTs provide a higher level of control and customization, which is particularly important for RWAs that require strict compliance with regulatory standards or specific usage restrictions. CLTs enable issuers to enforce rules on how and where tokens representing RWAs can be used, such as limiting transfers to verified users or restricting usage to certain jurisdictions.

By combining these features, Sui delivers a unique platform for the tokenization and management of RWAs, offering enhanced security, compliance, and accessibility. These features not only enhance security and compliance but also improve the overall usability and accessibility of tokenized assets.

A digitized future

While the tokenization of real-world assets is still in its early stages, the potential applications and benefits are vast. As the technology matures and regulatory frameworks evolve, RWAs will likely become a cornerstone of the global financial system, offering new opportunities for investment, liquidity, and asset management.

Note: This content is for general educational and informational purposes only and should not be construed or relied upon as an endorsement or recommendation to buy, sell, or hold any asset, investment or financial product and does not constitute financial, legal, or tax advice.

Asif Kamal wants everybody to be able to own a Picasso — or at least a piece of one.

The global art market sees $65 billion to $70 billion in sales annually, primarily filtering through six major institutions, including Sotheby’s, Christie’s, and Bonhams. Investing in blue-chip art can be lucrative. However, it has been impossible for regular people who don’t have the ability to spend millions of dollars on a single piece of art.

Kamal thinks it’s time for that to change. Over the decades, Kamal points out, it’s become possible for individuals to invest relatively small amounts of money in commodities like precious metals, bonds, securities, and equity. The goal behind his company, Artfi, is to turn high-end art into another asset class that’s accessible to the masses.

Artfi, which launched earlier this year, is using the blockchain to democratize art investing. By leveraging Sui’s unique object-oriented data structure, zkLogin, Kiosk, and other technologies, Artfi is transforming the way art investment works and is bringing Web3 capabilities to a historically low-tech industry.

“Sui's unique object-oriented mechanism not only makes the process super fast and smart but also ensures safety for all parties involved while maintaining immutability,” said Kamal. “In addition, the Move programming language enhances the security, efficiency, and functionality of smart contracts and digital assets on Sui.”

The Artfi platform lets anyone review original artworks and buy an NFT that serves as the title to an identifiable portion of that work. Imagining an art investment renaissance

Kamal has been in the art business since he was 19 years old and living in New Delhi, India. Over his career, he’s worked in galleries, run auctions, hosted exhibitions, cataloged artworks, and promoted artists, primarily focusing on the South Asian modern contemporary art segment.

In that time, one thing always bothered him: Investing in high-end artworks was highly exclusive. It was only feasible for people who already had a great deal of wealth and was out of reach for regular folks trying to diversify their portfolios. 

When the Covid-19 pandemic struck in 2020, Kamal had been following the evolution of blockchain technology. But as physical art galleries and exhibitions suddenly shut down, it gave him time to consider how the blockchain could be used in a new way — not just for cryptocurrency and NFT trading, but to address some of the inequities in art investing.

“If you look at the new era of technological advancement that we are witnessing, I think a lot can be achieved for the art business at large,” said Kamal. “By fractionalizing blue-chip art, we can make it accessible for regular people who never imagined they could participate in this lucrative and luxurious asset class.”

Artfi's innovative investment platform allows people to buy shares of high-end artworks they wouldn’t be able to buy outright as individuals. It uses NFTs to represent real world assets, tokenizing and fractionalizing an art piece into 10,000 different fractions. Each fraction has its own coordinates and fraction number, which is minted as an NFT and stored in an investor’s wallet. This NFT, representing a portion of an artwork with verifiable worth, can then be showcased or sold on the secondary marketplace. 

Investors on Artfi claim areas of an artwork from a grid, personalizing the concept of investing as people can choose the part of the work they like the most.

A third-party foundation handles and preserves the physical artworks, and works with galleries and museums that can showcase them for the public. Collectors who buy fractional art via Artfi become part of a DAO that can collectively decide what to do with the piece and whether to sell it in the future.

Artfi focuses on blue-chip works from artists with a history of strong monetary appreciation. Artworks sold on the site have included pieces from world-renowned artists such as Pablo Picasso, Salvador Dali, Claude Monet, Banksy, and Jean-Michel Basquiat, as well as many of the biggest names in South Asian art, including Salman Khan, Raja Ravi Varma, and Jamini Roy.

This system benefits investors, who can buy a portion of an artwork they couldn’t otherwise afford. But it also benefits art owners in a few ways. First, it gives them the ability to sell off fractions of an artwork they feel will keep appreciating and that they don’t want to let go of entirely. In addition, when an owner consigns a piece through Artfi, they become part of the royalty structure of the art. Sui Kiosk supports writing royalty policies that automatically send a specified percentage of an NFT's secondary sale to the address of its original creator. Automatically enforced royalties on Sui ensure the artist benefits as their work increases in value, and its fractionalized NFTs become hot commodities.

Democratizing art investments with Sui

Artfi was initially built on Polygon, but recently transitioned over to Sui.

Kamal identified Sui as the best fit for Artfi because “its object-oriented approach makes the fractionalization of real-world assets more practical, secure, and efficient, providing a robust platform for managing digital ownership of physical assets,” he said.

zkLogin lets new users log in and create a digital wallet with the simplicity of a traditional, Web2-style log-in process. Through zkLogin, Artfi can appeal to users who have no interest in learning about Web3 and blockchains, but just want to appreciate art and participate in an ownership community.

Artfi works with emerging and established artists, such as Sacha Jafri, who has exhibited in the world’s most prominent museums.

Using NFTs, which on Sui are programmable data objects which use an image file to represent themselves, Artfi can easily divide ownership of the physical assets into fractions, enabling more people to invest in and own portions of these highly lucrative and valuable works. When an investor clicks the Buy button under an artwork on Artfi, they are presented with an image of the artwork overlaid with a grid. The investor can select the exact part of the artwork they want to purchase, creating a connection with the original work.

Sui's highly performant network also means that transactions and changes in ownership or updates to the digital object can be executed quickly and efficiently compared to the onerous methods in the traditional art world.

Each NFT on Sui can be programmed to represent specific attributes of the physical artwork it represents. The dynamic nature of NFTs on Sui means they can be given updates to ensure that the digital representation accurately reflects the current state of the physical asset. 

As Sui records every transaction in its ledger, it maintains an unalterable ownership record for each artwork, guaranteeing provenance.

Advancing art through technology

Kamal sees Artfi as a natural evolution in the art industry, which he notes has benefited from other technological advancements in previous decades. He points to breakthroughs in websites, apps, and virtual reality, which have all helped bring massive amounts of exposure to lesser-known artists, break down geographical barriers in art appreciation, enhance visitor experiences at galleries and museums, connect people with artists personally and give fans a glimpse into the artistic process, and even allow people to bid in art auctions on their phones.

Through Artfi, they can now invest in artistic masterworks. And soon they’ll be able to do even more. Artfi's upcoming protocol, Artinals, creates a no-code experience for users, letting them exert fine control over their digital assets. Through its interface, users will be able to set royalties, letting them benefit from asset resales, and ensure compliance. Leveraging Programmable Transaction Blocks, which batches multiple actions into a single transaction on Sui, Artfi will ensure low fees and efficient resource usages.

The real world assets segment of the blockchain industry has incredible potential, and Artfi is an early adopter in the field. Its democratization of fine art investing dovetails perfectly with the overarching theme of decentralization on Sui.

Move 2024 beta now includes

macro

functions! 

Macro functions in Move are similar to regular functions: you define the parameters, return type, and logic that determines how your macro functions operate, and then you can then call your macro functions from anywhere in your code. Unlike regular functions, however, the compiler expands those functions in place to execute the defined operations inline.

The main differences that separate macro functions from normal functions are: 

Macro function syntax extensions

Move compiler expansion and call semantics

Lambda parameters

Syntax extensions: Move syntax specifies how to define macro functions, their arguments, and their invocation. These rules not only help the compiler differentiate macros from normal functions, but also provide a visual differentiation between normal and macro functions during usage.

Compiler expansion and call semantics: Move eagerly evaluates normal function arguments. In other words, the runtime fully evaluates the arguments you pass to a normal function, whether necessary to the function logic or not. In contrast, macro functions directly substitute the expressions for their arguments during expansion, and the runtime won’t see the macro call at all! This means that arguments aren’t evaluated at all if the macro body code with the argument is never reached. For example, if the argument is substituted in an if-else expression and the branch with that argument is never taken, the argument will not be evaluated.

Lambda parameters: In addition to normal expressions, Macro functions allow you to supply parameterized code as higher-order function arguments. This is made possible with the introduction of the lambda type, allowing macro authors to create powerful and flexible macros. 

For more details on how to define macro functions, see the official reference in the Move book.

Anatomy of macro functions

The Move compiler expands macro functions during compilation, enabling expressiveness not available in normal functions. To indicate this special substitution behavior, macro functions have their type parameters and expression parameters prefixed with a

$

character. Consider a Move function titled `my_assert` that behaves like the compiler primitive assert! (without clever errors). 

macro fun my_assert($cond: bool, $code: u64) {     if (!$cond) abort $code. }

The Move compiler substitutes the arguments to type parameters and expression parameters during expansion. This behavior creates the lazy evaluation process for arguments mentioned in the previous section. As the code shows, the `my_assert` macro checks the condition passed to it, aborting the program if the condition `$cond` resolves to

false

(or not `true`) with the `$code` passed as a second argument. 

To invoke the

my_assert

macro function, the programmer uses a ! character after the function name to visually indicate that the arguments are not eagerly evaluated:

my_assert!(vector[] == vector[], 0); my_assert!(true, 1 / 0); // will not abort! '1 / 0' is not evaluated.

As you might notice, the

$code

value passed to the macro in the second invocation includes a division by zero operation. Although a bit contrived, its purpose is to show that the compiler will not evaluate the expression because control flow will never reach its execution due to the provided true condition.     

Macros with lambda arguments

The addition of macro functions includes the introduction of an entirely new feature: lambda. Using parameters with lambda types, you can pass code from the caller into the body of the macro. While the substitution is done at compile time, they are used similarly to anonymous functions, lambdas, or closures in other languages.

For example, consider a loop that executes a lambda on each number from

0

to a number n that the code provides.

public macro fun do($n: u64, $f: |u64| -> ()) {     let mut i = 0;     let stop = $n;     while (i < stop) {         $f(i);         i = i + 1;     } }

The lambda parameter (

$f

) is the second argument to the do macro. The lambda’s type is defined as |u64| -> (), which takes a u64 as input and returns (). The return type of () is implicit, so the argument could also be written simply as $f: |u64|. 

Your program logic could then use this macro to sum the numbers from

0

to 10 using the lambda parameter:

let mut sum = 0; do!(10, |i| sum = sum + i);

Here, the code snippet `|i| sum = sum + i` defines the lambda for the macro invocation. When it is called in the macro’s body, its arguments are evaluated and bound in the body of the lambda. Note that, unlike macro calls, lambdas will completely evaluate their arguments before executing the lambda body.

Macro functions are hygenic, so the i in the lambda is not the same as the i in the do. See the Move reference for more details .)

Macros in the Move standard library

With the addition of macros, the

move-stdlib

library introduces a number of macro functions to capture common programming patterns.

Integer macros

For

u64

and other integer types, the move-stdlib library provides a set of macro functions that simplify common loops. This post examines the u64 type, but the same macro functions are available for u8, u16, u32, u128, and u256. 

You have already seen one example, as the do function code is a macro function in std::u64. 

The full list of currently available macro functions for integer types are:

public macro fun do($stop: u64, $f: |u64|)

Loops applying $f to each number from 0 to $stop (exclusive).

public macro fun do_eq($stop: u64, $f: |u64|)

Loops applying $f to each number from 0 to $stop (inclusive).

public macro fun range_do($start: u64, $stop: u64, $f: |u64|)

Loops applying $f to each number from $start to $stop (exclusive).

public macro fun range_do_eq($start: u64, $stop: u64, $f: |u64|)

Loops applying $f to each number from $start to $stop (inclusive).

For a simplified example of applying the defined macro functions, consider the following loop:

let mut i = 0; while (i < 10) {     foo(i);     i = i + 1; }

You could rewrite this loop by implementing the

do

macro function for std::u64 as:

10u64.do!(|i| foo(i));

Similarly, you could make the following loop more concise using the

u64::range_do_eq macro function

:

let mut i = 1; // loop from 1 to 10^8 by 10s while (i <= 100_000_000) {     foo(i);     i = i * 10; }

The result of the rewrite:

1u64.range_do_eq!(8, |i| foo(10u64.pow(i)));

While this is potentially easier to read, it will take more gas to execute.

vector

macros

In a similar spirit to integers'

do

macro, you can iterate over the elements of a vector using the do function.

vector[1, 2, 3, 4, 5].do!(|x| foo(x));

This is equivalent to:

let mut v = vector[1, 2, 3, 4, 5]; v.reverse(); while (!v.is_empty()) {     foo(v.pop_back()); }

The expanded code shows that this process consumes the vector. Use the

do_ref

and do_mut macros to iterate by reference or by mutable reference, respectively.

fun check_coins(coins: &vector<Coin<SUI>>) {     coins.do_ref!(|coin| assert!(coin.value() > 0));     /* expands to     let mut i = 0;     let n = coins.len();     while (i < n) {         let coin = &coins[i];         assert!(coin.value() > 0);         i = i + 1;     }     */ } fun take_10(coins: &mut vector<Coin<SUI>>) {     coins.do_mut!(|coin| transfer::public_transfer(coin.take(10), @0x42));     /* expands to     let mut i = 0;     let n = coins.len();     while (i < n) {         let coin = &mut coins[i];         transfer::public_transfer(coin.take(10), @0x42);         i = i + 1;     }     */ }

In addition to iteration, you can modify and create vectors with macros.

vector::tabulate

creates a vector of length n by applying a lambda to each index.

fun powers_of_2(n: u64): vector<u64> {     vector::tabulate(n, |i| 2u64.pow(i))     /* expands to     let mut v = vector[];     let mut i = 0;     while (i < n) {         v.push_back(2u64.pow(i));         i = i + 1;     };     v     */ }

vector::map

creates a new vector from an existing vector by applying a lambda to each element. While vector::map operates on a vector by value, the map_ref and map_mut macros operate on a vector by reference and mutable reference, respectively.

fun into_balances(coins: vector<Coin<SUI>>): vector<Balance<SUI>> {     coins.map!(|coin| coin.into_balance())     /* expands to     let mut v = vector[];     coins.reverse();     while (!coins.is_empty()) {         let coin = coins.pop_back();         v.push_back(coin.into_balance());     };     v     */ }

Similar to map,

vector::filter

creates a new vector from an existing vector by keeping only elements that satisfy a predicate.

fun non_zero_numbers(numbers: vector<u64>): vector<u64> {     numbers.filter!(|n| n > 0)     /* expands to     let mut v = vector[];     numbers.reverse();     while (!numbers.is_empty()) {         let n = numbers.pop_back();         if (n > 0) {             v.push_back(n);         }     };     v     */ }

See Table A at the end of this article for a list of currently available macro functions for vectors.

option

macros

While

Option

is not a collection with more than one element, the type has do (and do_ref and do_mut) macros to easily access its value if it is some.

fun maybe_transfer(coin: Option<Coin<SUI>>, recipient: address) {     coin.do!(|c| transfer::public_transfer(c, recipient))     /* expands to     if (coin.is_some()) transfer::public_transfer(coin.destroy_some(), recipient)     else coin.destroy_none()     */ }

destroy

performs the same action as do, but perhaps a more useful macro is destroy_or which provides a default expression, which is evaluated only if the Option is none. The following example chains map, which applies the lambda to the value of the Option if it is some, and destroy_or to concisely convert an Option<Coin<SUI>> to a Balance<SUI>.

fun to_balance_opt(coin: Option<Coin<SUI>>): Balance<SUI> {     coin.map!(|c| c.into_balance()).destroy_or!(Balance::zero())     /* expands to     let opt = if (coin.is_some()) Option::some(coins.destroy_some().into_balance())               else Option::none();     if (opt.is_some()) opt.destroy_some()     else Balance::zero()     */ }

See Table B at the end of this article for a list of currently available macro functions for Option.

Wrap up

Macro functions can simplify your code by converting common patterns into reusable macros. The hope is that macro functions can replace many, if not all, of your common loops (loop and while). Keep an eye out for more macro functions in the move-stdlib library, and soon the sui framework.

For more details on how macro functions work, see the Move book.

Table A: Currently available macro functions for vectors

Prepend

public macro fun

to each line below:

tabulate<$T>($n: u64, $f: |u64| -> $T): vector<$T>

Create a vector of length

n

by calling the function f on each index.

destroy<$T>($v: vector<$T>, $f: |$T|)

Destroy the vector

v

by calling f on each element and then destroying the vector. Does not preserve the order of elements in the vector (starts from the end of the vector).

do<$T>($v: vector<$T>, $f: |$T|)

Destroy the vector

v

by calling f on each element and then destroying the vector. Preserves the order of elements in the vector.

do_ref<$T>($v: &vector<$T>, $f: |&$T|)

Perform an action

f

on each element of the vector v. The vector is not modified.

do_mut<$T>($v: &mut vector<$T>, $f: |&mut $T|)

Perform an action

f

on each element of the vector v. The function f/ takes a mutable reference to the element.

map<$T, $U>($v: vector<$T>, $f: |$T| -> $U): vector<$U>

Map the vector

v

to a new vector by applying the function f to each element. Preserves the order of elements in the vector, first is called first.

map_ref<$T, $U>($v: &vector<$T>, $f: |&$T| -> $U): vector<$U>

Map the vector

v

to a new vector by applying the function f to each element. Preserves the order of elements in the vector, first is called first.

filter<$T: drop>($v: vector<$T>, $f: |&$T| -> bool): vector<$T>

Filter the vector

v

by applying the function f to each element. Return a new vector containing only the elements for which f returns true.

partition<$T>($v: vector<$T>, $f: |&$T| -> bool): (vector<$T>, vector<$T>)

Split the vector

v

into two vectors by applying the function f to each element. Return a tuple containing two vectors: the first containing the elements for which f returns true, and the second containing the elements for which f returns false.

find_index<$T>($v: &vector<$T>, $f: |&$T| -> bool): Option<u64>

Finds the index of first element in the vector

v

that satisfies the predicate f. Returns some(index) if such an element is found, otherwise none().

count<$T>($v: &vector<$T>, $f: |&$T| -> bool): u64

Count how many elements in the vector

v

satisfy the predicate f.

fold<$T, $Acc>($v: vector<$T>, $init: $Acc, $f: |$Acc, $T| -> $Acc): $Acc

Reduce the vector

v

to a single value by applying the function f to each element. Similar to fold_left in Rust and reduce in Python and JavaScript.

any<$T>($v: &vector<$T>, $f: |&$T| -> bool): bool

Whether any element in the vector

v

satisfies the predicate f. If the vector is empty, returns false.

all<$T>($v: &vector<$T>, $f: |&$T| -> bool): bool

Whether all elements in the vector

v

satisfy the predicate f. If the vector is empty, returns true.

zip_do<$T1, $T2>($v1: vector<$T1>, $v2: vector<$T2>, $f: |$T1, $T2|)

Destroys two vectors

v1

and

v2

by calling f to each pair of elements. Aborts if the vectors are not of the same length. The order of elements in the vectors is preserved.

zip_do_reverse<$T1, $T2>($v1: vector<$T1>, $v2: vector<$T2>, $f: |$T1, $T2|)

Destroys two vectors

v1

and

v2

by calling f to each pair of elements. Aborts if the vectors are not of the same length. Starts from the end of the vectors.

zip_do_ref<$T1, $T2>($v1: &vector<$T1>, $v2: &vector<$T2>, $f: |&$T1, &$T2|)

Iterate through

v1

and

v2

and apply the function f to references of each pair of elements. The vectors are not modified. Aborts if the vectors are not of the same length. The order of elements in the vectors is preserved.

zip_do_mut<$T1, $T2>($v1: &mut vector<$T1>, $v2: &mut vector<$T2>, $f: |&mut $T1, &mut $T2|)

Iterate through

v1

and v2 and apply the function f to mutable references of each pair of elements. The vectors may be modified. Aborts if the vectors are not of the same length. The order of elements in the vectors is preserved.

zip_map<$T1, $T2, $U>($v1: vector<$T1>, $v2: vector<$T2>, $f: |$T1, $T2| -> $U): vector<$U>

Destroys two vectors

v1

and

v2

by applying the function f to each pair of elements. The returned values are collected into a new vector. Aborts if the vectors are not of the same length. The order of elements in the vectors is preserved.

zip_map_ref<$T1, $T2, $U>($v1: &vector<$T1>, $v2: &vector<$T2>, $f: |&$T1, &$T2| -> $U): vector<$U>

 

Iterate through

v1

and v2 and apply the function f to references of each pair of elements. The returned values are collected into a new vector. Aborts if the vectors are not of the same length. The order of elements in the vectors is preserved.

Table B: Currently available macro functions for Option

Prepend

public macro fun

to each line below:

destroy<$T>($o: Option<$T>, $f: |$T|)

 

Destroy

Option<T>

and call the closure f on the value inside if it holds one.

do<$T>($o: Option<$T>, $f: |$T|)

 

Destroy

Option<T>

and call the closure f on the value inside if it holds one.

do_ref<$T>($o: &Option<$T>, $f: |&$T|)

 

Execute a closure on the value inside

t

if it holds one.

do_mut<$T>($o: &mut Option<$T>, $f: |&mut $T|)

Execute a closure on the mutable reference to the value inside

t

if it holds one.

or<$T>($o: Option<$T>, $default: Option<$T>): Option<$T>

 

Select the first

Some

value from the two options, or None if both are None. Equivalent to Rust's a.or(b).

and<$T, $U>($o: Option<$T>, $f: |$T| -> Option<$U>): Option<$U>

 

If the value is

Some

, call the closure f on it. Otherwise, return None. Equivalent to Rust's t.and_then(f).

and_ref<$T, $U>($o: &Option<$T>, $f: |&$T| -> Option<$U>): Option<$U>

If the value is

Some

, call the closure f on it. Otherwise, return None. Equivalent to Rust's t.and_then(f).

map<$T, $U>($o: Option<$T>, $f: |$T| -> $U): Option<$U>

 

Map an

Option<T>

to Option<U> by applying a function to a contained value. Equivalent to Rust's t.map(f).

map_ref<$T, $U>($o: &Option<$T>, $f: |&$T| -> $U): Option<$U>

Map an

Option<T>

value to Option<U> by applying a function to a contained value by reference. Original Option<T> is preserved. Equivalent to Rust's t.map(f).

filter<$T: drop>($o: Option<$T>, $f: |&$T| -> bool): Option<$T>

Return

None

if the value is None, otherwise return Option<T> if the predicate f returns true.

is_some_and<$T>($o: &Option<$T>, $f: |&$T| -> bool): bool

Return

false

if the value is None, otherwise return the result of the predicate f.

destroy_or<$T>($o: Option<$T>, $default: $T): $T

Destroy

Option<T>

and return the value inside if it holds one, or default otherwise. Equivalent to Rust's t.unwrap_or(default).

Note: this function is a more efficient version of

destroy_with_default

, as it does not evaluate the default value unless necessary. The destroy_with_default function should be deprecated in favor of this function.

When the team behind DARKTIMES began assessing which blockchain to enhance its newest game with cutting edge Web3 player engagement features, there could only be one answer: Sui. As a multiplayer brawler with RPG features and a dark sense of humor, DARKTIMES would need Sui's low latency and scalability to deliver the most satisfying experience for its players.

The team began developing DARKTIMES in 2021 with a vision to advance the state of the art in fast-paced multiplayer gaming. Rather than a battle royale, the team opted for what it calls a brawler royale, where characters begin as peasants and build up their skills and equipment to become champions. This RPG element gives players a sense of progression and identification with their characters.

Sui's low latency and ability to host transactions per second at the highest levels makes it the perfect environment for the kind of fast-paced action of DARKTIMES. In addition to its high performance, DARKTIMES leverages Sui's account abstraction features to give its players a seamless experience, with no knowledge of Web3 required.

An immersive, action-packed world

DARKTIMES features multiple maps anchored by deep lore, offering backstory not typically found in player-vs-player combat games. The Seven Realms have evocative names such as the Coast of Bones and the Golden Plain, each with its particular native populations, legends, and hazards. 

A description of the Vymar Delta mentions the warriors from that realm: "Fighting with the trident as their distinctive weapon, the Regent’s Army also employs round shields bearing the royal emblem and the blue cap that marks them out from civilians."

DARKTIMES features the Seven Realms, individual lands within the game each with their own unique history and populace.

The backstory for each realm includes the geography, character of the people, and the current political pressures instigating the game's combat.

In the game's first season, players choose between five characters: The Old Man, The Mammoth, The Huntress, The Noble, and The Exotic. More characters will be added in future seasons. As the players progress, the skills they choose and the equipment they acquire will individualize their characters. Along with melee combat, characters can use a magic system based on the elements.

Each game session begins with the player choosing a league to fight in, ranging from a beginner level to the Immortal League. The higher the level, the greater the potential rewards. 

Integrating Sui

Leveraging the unique properties of Web3 technology, DARKTIMES uses Sui to host digital assets, including the $TIMES token, which is integrated into the DARKTIMES ecosystem, Genesis NFTs, and various in-game character cosmetic items. In the Sui environment, all of these assets are written as objects, letting players own and trade them, or having the assets themselves mutate.

Although details have not been released, the $TIMES token will serve as the game's currency. Players will need to spend tokens to compete in higher level leagues. The token may also serve as the currency for item trades between players.

0:00 / 0:08 1×

Players will also acquire Genesis NFTs, which serve as tickets to enter higher prize pool levels.

The use of NFTs for cosmetic items in the game will provide personalization, letting players customize their characters' looks. There are many potential features of these NFTs on Sui, where some items may be more rare than others, and therefore command higher prices when trading. The mutable character of NFTs on Sui would also allow a crafting system, where players could customize their items, creating an even greater sense of ownership.

Most importantly, Sui's high performance network means that players will be able to swap and acquire NFTs items in subsecond times, as they would expect in any standard video game. Most blockchains suffer from longer latency, as they weren't designed to handle the performance needs of games.

An exciting release

DARKTIMES will run an early 20-day social engagement campaign called Rune Run beginning August 30, 2024, and plans to begin Alpha testing in November. The team will also be running a live playtest at Korea Blockchain Week. Early players will get a chance to acquire Genesis NFTs and experience the game's unique lands and player versus player combat.

To keep up with the latest information about DARKTIMES, follow its X account and Telegram. The DARKTIMES YouTube channel will showcase trailers and, eventually, gameplay video and dev content. The DARKTIMES community meets on its Discord channel.

DARKTIMES will be one of the first of a new genre of games featuring all the fun and action players crave, along with new features enabled by Sui.

DeepBook's newest incarnation, version 3, substantially lowers gas fees, introduces dynamic trading fees, and adds capital efficient order management for market makers. These new features represent just a few of DeepBook's improvements. One of its biggest developments centers around the previously announced DEEP token, which creates a new governance model for this native liquidity layer.

Launched in July, 2023, DeepBook was quickly adopted by DeFi protocols on Sui letting them tap into common liquidity pools and facilitating swaps across the network. Ongoing development delivered performance improvements to better support the quickly growing DeFi activity on Sui. 

With DeepBook version 3, DeFi protocols will find substantial improvements, letting them explore new mechanisms and give their users more efficient and flexible DeFi options.

Reduced transaction costs

Efficiency improvements in DeepBook make transaction costs 60 percent less than with the previous version.

New orders interface

With its new swap-like interface, DeepBook makes it easier for DeFi protocols to integrate it. 

Flash loans

Support for instant, zero-collateral borrowing facilitates arbitrage, liquidity provision, and risk management, all within DeepBook's highly performant environment. 

Dynamic fees

Through its new governance model and token, DeepBook stakers can propose changes to taker and maker fees, with votes held at every epoch.  

Shared liquidity across pools

Market makers can share capital between pools, reducing the risk of maintaining deep liquidity. 

Token utility

As a major milestone in its development, DeepBook will include its own token, DEEP. This token will incentivize DeepBook's many diverse participants to work together in offering ample and around-the-clock liquidity. Along with an initial airdrop, market makers will earn rebates in DEEP.

DEEP stakers will be able to participate in individual pool governance. Those with a stake in a pool will be able to vote on its trading fees. Although the quantity of stake will help determine the weight of each entity's vote, the governance structure includes a mechanism to keep any one entity from exercising outsize power.

Testnet to Mainnet

This new version of DeepBook deployed to Sui Testnet on August 21, 2024 with a planned two week run before Mainnet launch. Users can help test the new version by providing feedback and by clicking any of the following partner links:

7K Aggregator

FlowX

Kriya

Turbos

Follow DeepBook on Twitter for upcoming test links from Aftermath and Cetus.

Note: This content is for general educational and informational purposes only and should not be construed or relied upon as an endorsement or recommendation to buy, sell, or hold any asset, investment or financial product and does not constitute financial, legal, or tax advice.

Dollar-cost averaging (DCA) is an investment strategy wherein you set aside funds to be traded into a desired asset at a set frequency. This may seem like a mouthful, but the keyword here is frequency.

Automating these trades is essential. Performing them manually undermines the strategy’s effectiveness, as it demands constant availability to trade at the requested intervals. This leads to an obvious observation:

DCA fundamentally benefits from multiple parties having access to a shared state.

This problem isn’t unique to DCA either— most DeFi applications inherently require multiple parties to share access to onchain state. For instance, how could a lending protocol perform timely liquidations if a user’s position were only accessible to them at the time of liquidation? With DCA, however, you require a reduced set of entities with the ability to write to this shared state, specifically the user and a secondary address that transacts on the user’s behalf.

Shared custody

In an account-centric data model, the solution is simple: you just grant another contract or address the ability to access your funds (aka Token Allowance). However, with Sui’s object-centric data model, the process becomes less straightforward, leading to a variety of potential solutions, each with its own set of advantages and disadvantages.

Sharing is caring

The most direct way to implement a shared custody relationship on Sui is deeply ingrained in the object-ownership model: using Shared Objects. Naturally, if multiple writers need access to an object, it cannot be owned by a single address. If only one address owns an object and can invoke transactions with it, how can another address interact with it? The obvious solution is to share the object so both parties now have access to it.

While this solves our main issue of accessibility, it presents two entirely new problems:

Anyone can now interact with the object,

They can do so without restriction.

Well, that’s not quite what we wanted. By implementing a direct solution, you could resolve this with two steps:

1. Wrap the shared state (e.g., the funds that the end user wants to DCA from) into a custom object and share the custom object instead. This approach allows you to define a strict set of rules on how the custom object can be interacted with, such as how often funds can be pulled from it and how much can be withdrawn. In the context of DCA, we refer to this custom object as an Order — I’ll use this term from here on out.

/// Encapsulates a user's DCA order; holds the user's `Balance<CI>` until it is /// time to trade with it. public struct Order<phantom CI, phantom CO> has key { id: UID, /// The user's coin that is still remaining to be swapped into `Coin<CO>`. balance: Balance<CI>, /// Other relevant fields. ... } /// Creates, and subsequently shares, a DCA `Order` object to hold a user's funds. public fun new<CI, CO>( coin_in: Coin<CI>, ... ctx: &mut TxContext, ) { // i. Wrap the user's funds into the `Order` object. let order = Order<CI, CO>{ id: 0x2::object::new(ctx), balance: coin_in.into_balance(), ... }; // ii. Share the `Order` object to enable multiple writers to access it. 0x2::transfer::share_object(order); } /// Withdraw funds from the `Order`. Can only be called on a Sunday. public fun withdraw<CI, CO>( order: &mut Order<CI, CO>, clock: &Clock, amount: u64, ... ctx: &mut TxContext, ): Coin<CI> { let days_since_unix_epoch = clock.timestamp_ms() / 86400; }

Snippet 1: Custom Order object and associated constructor.

Snippet 1 shows an example implementation of (1) with a custom

withdraw

function that restricts when it can be called. To create an Order object, a user must pass in the funds they want to transact with. The provided Coin<CI> is then converted to a Balance<CI> and wrapped by the Order object before it is shared.

Although

withdraw

now ensures that it is being called under valid circumstances, we still need to address the issue of who is allowed to call it.

2. Create custom capability objects that grant their owners permission to interact with a specific

Order

(e.g., withdrawing funds when it is time to trade). Both parties would then receive one of these capability objects, thereby granting them exclusive permissioned access to the Order.

/// Capability object that grants the owner the ability to withdraw funds from a /// corresponding `Order` object. public struct OwnerCap has key { id: UID, /// The ID of the associated `Order` object. Allows validating that an /// `OwnerCap` is interacting with the correct `Owner` object. order_id: ID, } /// Creates a DCA `Order` object to hold a user's funds and subsequently shares /// it. Also creates two `OwnerCap` objects for the two entities that need /// permissioned access to the created `Object`. public fun new<CI, CO>( coin_in: Coin<CI>, other: address, ..., ctx: &mut TxContext, ) { // i. Wrap the user's funds into the `Order` object. let order = Order<CI, CO>{ id: 0x2::object::new(ctx), balance: coin_in.into_balance(), ... }; let order_id = order.id.to_inner(); // ii. Share the `Order` object to enable multiple writers to access it. 0x2::transfer::share_object(order); // iiia. Grant the user permission to interact with the `Order`. let owner_cap = OwnerCap { id: 0x2::object::new(ctx), order_id, }; 0x2::transfer::transfer(owner_cap, ctx.sender()); // iiib. Grant the `other` address permission to interact with the `Order`. let owner_cap = OwnerCap { id: 0x2::object::new(ctx), order_id, }; 0x2::transfer::transfer(owner_cap, other); } /// Withdraw funds from the `Order`. Can only be called on a Sunday. public fun withdraw<CI, CO>( order: &mut Order<CI, CO>, owner_cap: &OwnerCap, clock: &Clock, amount: u64, ..., }

Snippet 2: Extending the Order object with associated OwnerCap capability objects.

Snippet 2 extends the implementation of Snippet 1 by creating two

OwnerCap

capability objects during the creation of an Order and transferring them to the entities who will share custody of the Order. Now that the objects required by (1) and (2) are defined, you can create any desired permissioned function by accepting an Order and it’s associated OwnerCap as input. withdraw has been updated in this manner.

And voilà, you now have the desired setup where only the two parties have access to the shared state. This is simple, very straightforward, and easy to implement. So…

What’s the catch?

The way I see it, this design has two significant drawbacks, relating to gas and network congestion.

Gas: Three objects are needed to specify a simple two-person access control list for every DCA order created.¹ Managing these objects alone raises complexity, not to mention the increased gas cost from introducing another object as input to all DCA functions.² Intuitively, these objects would only need to exist during the lifecycle of the DCA order and should be destroyed afterward to reclaim their storage rebate. This can easily lead to a loss of SUI if any of the three objects are not destroyed. The whole point of DCA is to set it and forget it. As a user, I do not want to have to execute a follow-up transaction just to reclaim a storage rebate after the DCA order has ended.

¹ For this specific qualm, an easy rebuttal would suggest whitelisting all addresses who need to interact with the object, eliminating the need for the two capability objects. However, this approach is less flexible, still requires extra computation to verify correct addresses, and is a bit orthogonal to Sui’s object-centric nature. Moreover, it doesn’t address the next issue.

² You may be thinking this is just a marginal increase in gas costs. For one trade, you’re not wrong. But remember, we are not building products for a few users to use a few times. We are creating products for both retail users and institutions to use for years to come. Reducing gas on all DCA trades adds up to a substantial discount over time.

Congestion: Utilizing a shared object introduces another beast: consensus. Sui’s consensus fundamentally drives the scheduling of transactions involving shared objects; when two transactions affecting the same shared object are submitted for execution, consensus will determine their order. In (1), we created the custom

Order

object to hold the funds we want to trade, and in (2), we restricted how the object can be used. This ensures the safety over the object’s funds but does not limit how or where the object can be used as input. Anyone can create another move function that accepts a mutable reference to the custom object and spam calls to this function, creating inflated congestion on the now hot object. Although funds are not at risk, this can be used as a potential DDoS vector by delaying the ordering of the DCA transaction during consensus.³

It’s worth noting that this is not a problem unique to Sui; it exists in any decentralized, distributed environment (i.e., blockchain) where many parties need write-access to a shared state. There is no simple way around this, at least from an app developer’s point of view.

³ The impact of such an attack may seem trivial but grows during periods of high market volatility and as the amount of funds being transacted increases. Imagine a scenario where a whale is trying to DCA a large amount of a meme coin into a more stable asset while the price of the meme coin begins to drop. A malicious party can, after viewing the DCA order’s parameters from onchain, use this attack vector to delay the execution of the DCA trade long enough to sell their meme coin first. In any case, when a user decides to DCA, they trust that their orders will be executed at their specified frequency; any variance from this frequency deteriorates the trust between the user and protocol.

Can we do better?

This is a question we constantly ask ourselves, and in this case, we can. One of Sui’s many unique features is its fast path for transactions involving owned objects, currently being enhanced through Mysticeti, the new consensus engine. If your transaction involves only owned objects, you can bypass consensus using reliable broadcast for execution. The intuition here is that, since the state is only controlled and accessible by a single entity, consensus is no longer needed to order transactions that touch the owned object; the entity can suggest the sequence themselves. This enables a very unique property on Sui:

Owned objects avoid execution delays that arise from congestion queues.

Wouldn’t it be great if we could retain the benefits of owned objects while still allowing multiple entities to have permissioned access to an object?

Enter Aftermath’s solution

Let’s revisit a statement I made early on.

“Naturally, if multiple writers need access to an object, it cannot be owned by a single address.”

Technically, this is correct. Validators perform a series of validity checks on incoming transactions, including verifying that owned objects are indeed owned by the sender. If you attempt to execute a transaction involving an object owned by another address, it will not pass the validator’s checks. So, when multiple unique addresses need to interact with an object, that object cannot be owned by a single entity.

But hear me out: what if multiple entities had access to the address that owns the object? This way, you could retain the benefits of owned objects while eliminating the inefficiencies around gas and congestion outlined above, and enable a shared custody model. This may sound too good to be true. Fortunately, Sui provides a native primitive for exactly this: k-of-n multi-signature (multisig) transactions.

Multisig: Our solution to the shared custody problem now becomes very simple: no capability objects, no shared objects, just the singly owned object we specified in (1). After creating this object, we transfer it to a uniquely-derivable-per-address, 1-of-2 multisig where the two required entities — the end user and a secondary address — are equally-weighted signers behind the multisig.

Visualizing the 1-of-2 multisig model.

And voilà, you now have the desired setup where only the two parties have access to the shared state. This is simple, very straightforward, and relatively easy to implement. So, what’s the catch?

From the user’s perspective, there aren’t really any drawbacks; you get all of the benefits I’ve listed above with none of the disadvantages. Of course, this is a very naïve statement to make, as no design is without its limitations. What’s important with our design, however, is that the user experience isn’t affected or worsened at all.

From our point of view, there are a few complexities that we’ll need to address, which I will cover shortly. But first…

Is it safe?

As with all of our products at Aftermath, we prioritize user security and transparency. Regardless of the shared custody design we choose, we aim to ensure that nothing malicious can happen to our users’ funds. Our implementation, (2), and many other designs, reduce the scope of write access entities down to just the required two. However, from the user’s perspective, this may still be one too many for certain actions.

While those who know me can trust that I won’t act maliciously, I don’t want our users to have to make that assumption. This leads us to a core principle we embed in all of our products:

When interacting with a protocol, users should not have to assume trust; instead, functionality should be very clearly and transparently enforced onchain.

For this reason, we strongly restrict interactions with our custom

Order

object from (1). DCA trades can only be executed after user-defined intervals, funds are always sent to a user-defined address, and the Order object is soulbound to the multisig’s address, eliminating the risk of it being transferred outside of the user’s reach. Even with a domain like DCA that requires a largely offchain implementation, we can provide strict guarantees over the safety of our users’ funds by establishing a very transparent access control list onchain.

Design considerations

What complexities do we, as the implementers, need to address in our design?

Accessibility

It becomes crucial that the

Order

object remains owned by the multisig’s address. Transferring it to any other address could prevent the user and/or the secondary address from interacting with the object, potentially resulting in a complete loss of funds. We provide this guarantee in two different ways:

First, we derive the multisig address onchain — rather than including it as input passed in from offchain — to verify that the Order object is always transferred directly to the multisig address associated with the user.

Once the multisig owns the object, we need to ensure that it always remains within this address. On Sui, this is straightforward to support. Similar to (1), our custom object lacks the store ability, so it cannot be transferred unless a custom transfer function is provided. We do not provide a way for this object to be transferred; instead, a transfer would have to be mimicked by canceling the DCA order, transferring the underlying funds to a new address, and recreating it. It’s worth noting, though, that a transfer function can actually be provided (we have one, but it is not public⁴) as long as it derives the multisig address onchain, ensuring that the object always stays within the 1-of-2 multisig ecosystem.

With these two guarantees satisfied, the

Order

object becomes soulbound to the multisig address as soon as it is created.

⁴ We have opted to keep our transfer function private for an important reason. Transferring the

Order

object falls into the category of functions that the end user should have sole permission over. As we cannot distinguish between which of the two multisig signers signed the transfer, we cannot restrict this function to be initiated only by the end user. For this reason alone, we do not allow transfers.

Gas management

Given that each user has a uniquely associated multisig address, we would need to maintain a balance of SUI for gas fees across potentially infinitely many addresses. That is not 100 percent true, but you can see how this quickly becomes unmanageable. Our solution was to introduce a third Sui primitive to the mix: sponsored transactions.

By using sponsored transactions, we only have to maintain gas on a handful of addresses, as long as we use these addresses to sponsor each and every DCA transaction we execute. This significantly reduces the scope of accounts we need to actively manage down to a finite set and decreases the amount of SUI we need to reserve for gas at any given time. Although I’ve greatly simplified our solution here, understanding the role of sponsored transactions is what is most important.

Equivocation

Sui’s consensus-less fast path introduces a unique problem: what happens when one account initiates two conflicting owned-object transactions. In a consensus-backed approach, one transaction would be sequenced before the other.

Due to the lack of consensus in the fast path, you could end up with half of the validator set aware of and preparing for one of the two transactions, while the other half does the same for the second transaction. This results in the involved owned objects becoming locked until the equivocation is resolved during the epoch-change protocol.

This scenario is possible in our DCA implementation due to the migration to owned objects over shared objects. In practice, this will only occur if a user tries to cancel an

Order

at the same exact time a DCA trade has been invoked. Although the chances of this occurring are minimal, it is a problem we need to consider and mitigate on our side.

There are many different ways you can address the risk of equivocation, each producing a different level of mitigation. Our solution aims to eliminate this problem entirely in the common case: we involve our backend when the user wants to cancel their DCA

Order

. This allows us to check if the Order is currently being executed, and, if it is, delay submitting the cancel transaction until the Order becomes unlocked. If the Order is currently idle, we then lock it and proceed with the cancellation.

The way we’ve addressed these three considerations ensures our user experience remains safe, transparent, and efficient; exactly what we set out to achieve by deploying this shared custody model.

Conclusion

In short, by leveraging a few native primitives on Sui — multisig transactions, programmable transaction blocks, sponsored transactions, and Sui’s fast path — we are able to provide a safer, more efficient user experience. We aren’t reinventing the wheel; we are simply piecing together the primitives we have at our disposal.

This is an implementation detail I am particularly proud of, as I always had the assumption that DeFi applications, which naturally require shared access to onchain state, could not benefit much from Sui’s owned objects.⁵ In our case, the core object holding the shared funds remains completely owned and retains all benefits of being owned. While you won’t see this design extended to create the next AMM on Sui, it is yet another design pattern that Sui builders can utilize when they are facing the shared custody dilemma.

⁵ At least for the objects at the center of the apps that require multiple writers; e.g. pools, orderbooks, vaults, etc.

DCA is just the first of many products we will roll out wherein we apply this shared custody solution. We look forward to expanding this model to other domains in an effort to offer heightened levels of user security and the most transparent user experience in Web3.

Whether you’re looking to swap tokens, dive into the world of NFTs, or simply lend your assets to earn rewards, Sui’s DeFi ecosystem has something for you. Sui DeFi is filled with uniquely powerful applications, thanks to native Sui primitives. These primitives help DeFi apps on Sui address common challenges such as liquidity bootstrapping via DeepBook.

A healthy DeFi ecosystem is made of a few cornerstone app types such as borrow and lending protocols, decentralized exchanges (DEXes), and NFT marketplaces. Enabled by Sui’s powerful primitives, the security of the Move programming language, and the ingenuity of the Sui builder community, Sui DeFi offers experiences unlike anything else in Web3.

After getting started on Sui and learning about the role of staking in DeFi, it’s time to get an understanding of Sui’s DeFi landscape. 

DeFi on Sui

In other DeFi ecosystems, users often encounter friction points, especially when new to Web3. For example, submitting separate transactions to allow an app access to your assets can be cumbersome and requires gas fees. On Sui, there is no need for approval transactions, as a result of its object-oriented architecture, making DeFi activities smoother and more user-friendly.

Gas fees and transaction speed are crucial factors in DeFi. On Sui, gas fees are not only low but are also stable, ensuring predictability even during high demand thanks to Sui’s gas pricing mechanism that locks in rates each epoch. Additionally, Sui’s consensus mechanism, Mysticeti, finalizes transactions in under a second, offering the lowest latency in Web3 taking Sui DeFi to the next level.

How to DeFi

New DeFi users may find the first steps in interacting with an app to be a bit unfamiliar. Fortunately, most DeFi apps have very similar steps required. The first step is to connect your Sui wallet. There is a ‘Connect Wallet’ button usually found front and center or in the upper right corner of a webpage. When connecting a wallet, there will be multiple wallet options and you may even see the ability to login using a social account, such as Google, via zkLogin. After selecting the wallet app and specific account to connect, you're ready to start interacting with the app.

Turbos allows users to connect to their wallet directing from the trading interface.

If you have multiple accounts, switching between them varies by app and wallet. Some apps offer seamless switching and some require you to disconnect, switch accounts, and reconnect. You may also need to disconnect from your wallet as well.

In Sui Wallet, you can see what app it is connected to at the top center of the window.

Next, it’s important to understand the various factors that may be worthy of consideration. For example, when considering a swap, it’s helpful to be aware you may incur slippage and gas fees. Slippage is the difference between the expected and actual price of your swap, while gas fees are the costs of processing your transaction. If you’re exploring options like borrowing assets, it’s common that lending might be required first. Understanding these basic concepts can be helpful in navigating DeFi with more confidence but no matter what path you choose, doing your own research and consulting with your advisors is always encouraged.

Sui’s DeFi landscape

Borrow and lending protocols

Borrow and lending protocols enable users to lend digital assets in exchange for the ability to borrow other assets, offering a low-friction, accessible alternative to traditional financial systems. 

Driven by smart contracts, these protocols offer a fair and transparent avenue for a fundamental financial tool accessible worldwide.

Here is a list of popular borrow and lending protocols on Sui:

Bucket

Navi

Scallop

SuiLend

Decentralized exchanges

DEXes allow users to trade assets directly with one another, in a secure and featurefull manner. Leveraging smart contracts, DEXes can facilitate complex peer-to-peer transactions, in an autonomous manner.

Here is a list of popular DEXes and DEX aggregators on Sui:

7k

Aftermath

Cetus

FlowX

Hop

Turbos

Derivative exchanges

Derivative exchanges offer a way to trade derivatives, such as options, futures, and perpetual contracts. These exchanges enable traders to hedge against risks and access leverage, among other tools for sophisticated trading strategies.

Here is a list of popular derivative exchanges on Sui:

BlueFin

Kyria

Typus

Sudo

Yield aggregators

Yield aggregators help users optimize potential return on assets by automatically redistributing them across various yield-generating protocols. These tools offer a simple and efficient way for users to make the most out of the opportunities available in Sui’s DeFi ecosystem.

Here is a list of popular yield aggregators on Sui: 

Alpha Fi

Kai

Strater

NFT marketplaces

NFT marketplaces are platforms where users can buy, sell, and trade NFTs. These marketplaces provide access to a wide range of digital assets, from art and collectibles to NFTs representing real world assets and infrastructure, enabling builders, creators, and collectors to trade uniquely powerful NFTs on Sui.

Here is a list of popular NFT marketplaces on Sui: 

Hyperspace

TradePort

Liquid staking

Liquid staking protocols allow for users to obtain an asset that appreciates proportionally to SUI staking rewards while remaining liquid and transferable. These platforms and assets are foundational to an efficient DeFi ecosystem.

Here is a list of popular liquid staking protocols and their corresponding liquid staking token on Sui:

Aftermath (afSUI)

Haedal (haSUI)

Volo (vSUI)

Conclusion

Sui’s DeFi ecosystem stands out by offering powerful user-friendly experiences. The combination of low, stable gas fees, lightning-fast transaction speeds, and the elimination of traditional friction points makes Sui DeFi particularly accessible for newcomers.

Now that you’re up to speed on how to DeFi on Sui, it’s your time to explore and find what excites you the most! 

Note: This content is for general educational and informational purposes only and should not be construed or relied upon as an endorsement or recommendation to buy, sell, or hold any asset, investment or financial product and does not constitute financial, legal, or tax advice.

With only a wallet and some SUI, users can participate in securing the network and earn rewards at the same time. Staking can be done directly from most wallets and often only takes a few clicks. Within seconds, users can stake SUI and start earning rewards to fuel their adventures further into the Sui ecosystem.

What is staking?

Proof-of-stake (PoS) networks use a process called staking to prevent sybil behavior and maintain network liveliness. PoS ensures that the network continues to operate securely even if a significant number of validators, entities that participate in the consensus process, have become unresponsive or are colluding. PoS requires active validators to have a significant amount of SUI staked, creating an economic incentive that aligns with long-term success of the network. Staked SUI is illiquid until unstaked and subject to penalty if the sybil behavior is clearly observed by a validator. 

Any user can participate in the PoS mechanism to help secure the network and maintain the decentralized nature of Sui. Token holders can stake their SUI with a validator and, in return, earn staking rewards.

Staking is not only essential to the security of the network but also is important as a foundational source of rewards that feeds an onchain economy such as Sui’s. Staking rewards are often considered one of the more stable sources of rewards and is foundational for DeFi ecosystems.

How to stake

Any general wallet app should offer the ability to stake SUI. This example will show how a user can stake SUI from their Sui Wallet account. 

Within the wallet app, the portfolio section allows you to stake SUI, assuming they have SUI in their wallet. To begin, select ‘Stake and Earn SUI’. 

Next, you must select a validator to stake with. A scrolling window will populate with all active validators in a random order allowing you to browse, sort, and select validators. Validator details can be found on explorers, such as SuiVision or Suiscan, and websites like Staking Rewards.

Once you’ve selected a validator to stake with, you can then enter the amount of SUI that you’d like to stake, assess the relevant information, and select ‘Stake Now’.

The staking transaction should complete very quickly, leaving you with a message that covers information relevant to the transaction.

What is liquid staking?

Liquid staking is an innovative solution that allows users to stake their tokens while still maintaining liquidity. Unlike traditional staking, where tokens are locked up for a specific period, liquid staking solutions enable users to receive a derivative token representing their staked assets. These derivative tokens can be traded, transferred, or used in other DeFi applications, providing flexibility otherwise impossible with staked assets. Liquid staking tokens (LSTs) offer the benefits of earning staking rewards with the ability to stay liquid and participate in DeFi activities.

There are currently three liquid staking solutions available in the Sui ecosystem. In no particular order the LSTs available on Sui are afSUI, haSUI, and vSUI. Liquid staking solutions differ primarily in the selection of validators and the reward distribution method. While some liquid staking solutions allow users to select a specific validator to stake with, others may disperse staked SUI to a subset of the active validators, further helping to reduce centralization of staked SUI on any one validator. For example, using Haedal users can select a specific validator or choose to stake with a selected subset of validators, with inclusion criteria found in their documentation.  

It is important to consider what you want from a liquid staking solution and research which provider offers what you prefer.

How to access LSTs

There are two common ways to access LSTs: 1) Stake SUI directly through the liquid staking solutions app, or 2) to purchase the LST from a DEX.

The liquid staking solutions have their own apps where users can simply connect their wallet, choose the amount to liquid stake, select their validator preferences (if available), and stake. This gives users an easily accessible location where they can complete all actions around liquid staking.

Haedal’s liquid staking app allows users to stake with user-selected validators or to use the subset of validators that Haedal has approved.

The second option is to simply buy LSTs from a DEX. This option gives users the convenience to access LSTs from an app that they may frequently use. DeFi users interact with DEXes on a regular basis and may find it more seamless to simply purchase LSTs from a DEX that they are already familiar with.

Continuing the journey

Staking is more than just a way to earn rewards, it’s often a user's first step to active participation in Sui. By choosing the right staking approach for your needs, you not only earn staking rewards but also help to decentralize and secure the network as a whole. Understanding liquid staking and how to access LSTs allows you to begin to plan the next steps in your journey within Sui with a strong understanding of a foundational element of an onchain economy.

Note: This content is for general educational and informational purposes only and should not be construed or relied upon as an endorsement or recommendation to buy, sell, or hold any asset, investment or financial product and does not constitute financial, legal, or tax advice.

DeepBook launched on Sui last year as a native liquidity layer, serving as a launchpad for DeFi protocols. But its potential goes far beyond what we've seen so far, with use cases including perpetual futures, lending, and payments all possible in the near future.

Built as a permissionless central limit order book, DeepBook works as a neutral trading floor with a set of built-in mechanisms to enable DeFi on Sui. Protocols such as Cetus, Aftermath, Kriya, FlowX, and Hop Aggregator include DeepBook among their liquidity sources, creating vibrant markets for DeFi users.

Protocols find DeepBook's features and performance very compelling. Aftermath noted that its combination of transaction speed and reduced processing time enables a fully onchain trading environment rivaling centralized exchanges in terms of liquidity and user experience. 

Currently, DeepBook supports both market and limit orders. However, its fundamental structure lets it support far more advanced features. With further development, protocols using DeepBook can anticipate a wealth of new capability for their customers.

Perps

Perpetual futures, or perps, are currently offered by a number of Sui DeFi protocols, and have proven a popular trading mechanism. Building support for perps into DeepBook would require extending it to support assets other than SUI. As all assets on Sui, including SUI, are objects, this extension would be very feasible.

In a perp, a user enters into a contract to buy or sell an asset at a specified price sometime in the future. There is no expiration date on the contract, although the user needs to pay a funding rate to keep the contract alive. The advantage of a perp for the user is that they retain their capital until they decide to execute the contract, and they can wait until their preferred market conditions before executing. 

Perps on DeepBook would let the user, through a DeFi protocol, set the price they are willing to pay. Instead of a second party agreeing to the terms, as in a simple trade, DeepBook would need to hold the unfunded contract until the user who set it up decides to execute it.

Lending

Sui and other blockchains let asset holders easily engage in permissionless lending and borrowing, with far fewer hurdles than in traditional financial markets. DeepBook's ability to maintain and trade liquidity can be engineered to support a lending mechanism.

DeFi platforms facilitate lending on Sui, letting users earn interest from borrowers of their tokens.

Current lending protocols on Sui let users offer up their assets to others at an interest rate. This type of DeFi activity is popular because it gives asset owners an easy way to garner yields. Of course, unlike some other DeFi mechanisms, the loaner loses access to those assets until the loan is repaid. 

Support for lending on DeepBook would let DeFi protocols aggregate user assets into a pool and make it available to borrowers through DeepBook. Users on the same or other DeFi protocols looking to borrow assets could access that pool, repaying the loan with interest at the end of the loan term.

Sui Bridge integration

The recent launch of Sui Bridge, a new native bridge on Sui, makes it easy, quick, and inexpensive to move assets between Sui and Ethereum blockchains. Integrating Sui Bridge with DeepBook would be a logical extension to its liquidity.

Moving assets from one blockchain to another is a common practice, and bridges are a primary means of supporting these moves. Sui Bridge, slated to launch on Mainnet by the end of the year, converts SUI to ETH when moved from Sui to an Ethereum blockchain, and ETH to SUI when moving assets to Sui. 

Although the asset movement supported by Sui Bridge is not a DeFi activity in itself, integration with DeepBook would make it easier for users to access capital on another blockchain for use in a Sui DeFi protocol. A process that currently involves multiple parties could be compressed down to the user and the DeFi protocol using DeepBook.

Cross-chain aggregation

Similar to the potential of integrating Sui Bridge with DeepBook, cross-chain aggregation could also extend liquidity across other blockchains. Instead of moving tokens from one chain to another, cross-chain aggregation would require a mechanism where DeepBook could access liquidity pools on other blockchains.

With cross-chain aggregation, a DeFi platform can use a bridge to source liquidity from two different blockchains, greatly expanding the breadth of liquidity for users.

Various DeFi protocols specialize in aggregation within the Sui ecosystem, using routers to find the best swap rates among various liquidity sources, including DeepBook. Aggregators help users get the best available swap rates. 

Letting DeepBook access a significant amount of liquidity from other pools would greatly increase the ability for protocols to find the best swap rates. Users would find particular benefit in swapping native tokens. 

Payments

A really potent use case would see DeepBook powering a payment platform dealing in fiat currency. This scenario would likely require a financial partner with significant currency to back up payments.

To some extent, users can make fiat currency payments over Sui, but it requires onramps and offramps, and a number of steps. But given that a path exists, it can be programmatized, and using DeepBook as the basis would make sense due to its existing liquidity and efficiency.

A payments platform built on DeepBook would excel when it came to fiat currency exchange, as SUI or a bespoke digital asset could be the intermediary between different global fiat currencies. 

Focus on the future

As a liquidity layer serving any DeFi protocol on Sui that cares to use it, DeepBook offers powerful trading functionality, mirroring that offered in traditional financial markets. And DeFi protocols have leveraged DeepBook while offering their own trading mechanisms, such as lending and perps.

Integrating these features into DeepBook will make them more efficient, potentially serving end users at even better rates. Protocols can leverage these features alongside their own mechanisms and liquidity pools, continuing to give their customers the best experience. 

Note: This content is for general educational and informational purposes only and should not be construed or relied upon as an endorsement or recommendation to buy, sell, or hold any asset, investment or financial product and does not constitute financial, legal, or tax advice.

Sui offers a vibrant ecosystem of apps and digital assets, and you will need to understand how to access and manage assets to make the most of the network. If you're new to Web3 and Sui, we will familiarize you with concepts like wallets and on-ramps. And even if you're a Web3 veteran, you'll want to find out about the best options to get started on Sui.

SUI can be used for a variety of purposes, including paying for goods and services, purchasing unique digital assets, or engaging in DeFi activities. No matter your goals, the first step is setting up a wallet and accessing SUI to begin exploring the ecosystem. Wallets, on-ramps, and bridges are key tools to getting started on your journey into the Sui ecosystem.

Sui wallets

To interact with most Sui apps, you’ll need a wallet, which works like an account on the network. With a wallet, you can connect to apps and manage digital assets, such as SUI, NFTs, stablecoins, and other fungible tokens. Wallets are typically either a browser extension or a mobile app, offering different experiences and serving the needs of different users.

A typical wallet setup requires the creation of a new Sui account which can be accomplished one of two ways: creating a new passphrase account or creating an account using a Web2 login such as your gmail account via zkLogin. Those using a passphrase will need to secure their recovery phrase provided during setup. Make sure to save the recovery phrase and store it securely offline. If you lose access to your recovery phrase, you will not be able to access your wallet. If creating an account with a Web2 login, simply follow the prompts to sign in and ensure that access to the account used is restricted to only yourself. 

Here are some of the top wallets in the Sui ecosystem:

Suiet

Sui Wallet

Surf Wallet

Nightly

Wallets, such as Sui Wallet, allow users an easy way to manage assets and interact with apps within the Sui ecosystem. Sui on-ramps

With your wallet set up, you can now convert traditional fiat currency into SUI using an on-ramp. On-ramps are essential for new users, as they provide a simple and secure way to purchase SUI and other assets with fiat, such as USD or EUR. 

The most common type of on-ramps are centralized exchanges, such as Coinbase or Binance.  The second most common on-ramp types are payment processors. These on-ramps are very convenient as they are often embedded directly into wallets and may allow users to pay with credit or debit cards. 

The following is a list of payment processors that support SUI. Note that availability is dependent on the country you are in. 

MoonPay

Transak

Banxa

Coinbase Pay

Sui Wallet offers multiple on-ramp options allowing users to buy SUI using fiat currency directly from the wallet app. Sui bridges

Web3 veterans with assets on other networks can easily bridge into the Sui ecosystem. A bridge allows you to transfer digital assets between different blockchains, enabling you to bring your existing tokens into the Sui ecosystem. Typically, bridging requires users to connect both a source wallet and a receiving wallet to the same app and submit a transaction from the source wallet. Depending on the networks involved, bridging transactions can take up to 15 minutes to complete.

Currently, the Wormhole Portal Bridge is the primary option available on Sui Mainnet for transferring assets to Sui. Many DeFi apps within Sui also embed the Wormhole bridge, providing a convenient location to bridge assets when exploring DeFi.

Looking ahead, the native Sui Bridge (currently on Testnet) is expected to launch on Mainnet in September, offering another bridging option for the Sui ecosystem.

Begin the journey

With wallets, on-ramps, and bridges at your disposal, you are now equipped with the knowledge needed to access SUI and explore the ecosystem. These tools form the foundation of your journey into Sui. As the ecosystem continues to grow and more features are developed for these tools, the onboarding experience will become even more smooth. Sui strives to offer user experiences on par with traditional web apps, welcoming all users to the Sui ecosystem.

Note: This content is for general educational and informational purposes only and should not be construed or relied upon as an endorsement or recommendation to buy, sell, or hold any asset, investment or financial product and does not constitute financial, legal, or tax advice.