Trending
Discover the hottest posts.
Posts
2053- Article0xduckmove413ForSuiApr 08, 2025
👀 SEAL- I Think Web3 Data Privacy Is About to Change
👀SEAL is Live on Sui Testnet – I Think Web3 Data Privacy Is About to Change In the Web3, it’s common to hear phrases like “users own their data” or “decentralized by design”. But when you look closely, many applications still rely on centralized infrastructures to handle sensitive data — using services like AWS or Google Cloud for key management. This introduces a contradiction: decentralization on the surface, centralization underneath. But what if there was a way to manage secrets securely, without giving up decentralization?Introducing SEAL – Decentralized Secrets Management (DSM), now live on the Sui Testnet. SEAL aims to fix one of Web3’s biggest hypocrisies: shouting decentralization while secretly using AWS You maybe ask me: What is SEAL? SEAL is a protocol that lets you manage sensitive data securely and decentrally – built specifically for the Web3 world. Think of it as a privacy-first access control layer that plugs into your dApp. You can think of SEAL as a kind of programmable lock for your data. You don’t just lock and unlock things manually — you write policies directly into your smart contracts, using Move on Sui. Let’s say you’re building a dApp where: Only NFT holders can unlock a premium tutorial Or maybe a DAO has to vote before sensitive files are revealed Or you want metadata to be time-locked and only accessible after a specific date SEAL makes all of that possible. The access control lives onchain, fully automated, no need for an admin to manage it. Just logic, baked right into the blockchain. SEAL makes all of that possible. The access control lives onchain, fully automated, no need for an admin to manage it. Just logic, baked right into the blockchain. Another interesting piece is how SEAL handles encryption. It uses something called threshold encryption, which means: no single node can decrypt the data. It takes a group of servers to work together — kinda like multi-sig, but for unlocking secrets. This distributes trust and avoids the usual single-point-of-failure problem. And to keep things truly private, SEAL encrypts and decrypts everything on the client side. Your data is never visible to any backend. It stays in your hands — literally — on your device. and SEAL doesn’t care where you store your data. Whether it’s IPFS, Arweave, Walrus, or some other platform, SEAL doesn’t try to control that part. It just focuses on who’s allowed to see what, not where things are stored. So yeah, it’s not just a library or API — it’s an onchain-first, access-controlled, privacy-by-default layer for your dApp. SEAL fills a pretty critical gap. Let’s break that down a bit more. If you’re building a dApp that deals with any form of sensitive data — gated content, user documents, encrypted messages, even time-locked NFT metadata — you’ll run into the same problem: ➡️ How do you manage access securely, without relying on a centralized service? Without something like SEAL, most teams either: Use centralized tools like AWS KMS or Firebase, which clearly goes against decentralization Or try to patch together half-baked encryption logic themselves, which usually ends up brittle and hard to audit https://x.com/EmanAbio/status/1908240279720841425?ref_src=twsrc%5Etfw%7Ctwcamp%5Etweetembed%7Ctwterm%5E1908240279720841425%7Ctwgr%5E697f93dc65359d0c8c7d64ddede66c0c4adeadf1%7Ctwcon%5Es1_&ref_url=https%3A%2F%2Fwww.notion.so%2Fharryph%2FSEAL-Launches-on-Sui-Testnet-1cc4f8e09bb380969c0dcc627b96cc22 Neither of those scales well. Especially not when you’re trying to build trustless apps across multiple chains or communities. SEAL makes that entire process modular and programmable. You define your access rules in Move smart contracts, and SEAL handles the rest — key generation, decryption approvals, and access enforcement — all without anyone manually issuing keys or running backend checks. Even better, those rules are auditable and immutable — once they’re onchain, they follow the contract, not a human admin. So instead of asking “who should manage access to this data?” you just ask: “What logic should define access?” …and let the chain handle it. Clean and scalable. That’s what makes SEAL relevant for more than just “security tools” — it’s a base layer for any dApp that cares about privacy, compliance, or dynamic access logic. It’s a small shift — but it changes a lot about how we think of data in Web3. Instead of encrypting after deployment, or relying on external services, you start with privacy built-in — and access handled entirely by smart contract logic. And that’s exactly what Web3 needs right now. How Does SEAL Actually Work? We’ve covered what SEAL is and why Web3 needs it, let’s take a look at how it’s actually built under the hood. This part is where things get more technical — but in a good way. The architecture is elegant once you see how all the pieces fit together. At a high level, SEAL works by combining onchain access logic with offchain key management, using a technique called Identity-Based Encryption (IBE). This allows devs to encrypt data to an identity, and then rely on smart contracts to define who is allowed to decrypt it. Step 1: Access Rules in Smart Contracts (on Sui) Everything starts with the smart contract. When you’re using SEAL, you define a function called seal_approve in your Move contract — this is where you write your conditions for decryption. For example, here’s a simple time-lock rule written in Move: entry fun seal_approve(id: vector, c: &clock::Clock) { let mut prepared: BCS = bcs::new(id); let t = prepared.peel_u64(); let leftovers = prepared.into_remainder_bytes(); assert!((leftovers.length() == 0) && (c.timestamp_ms() >= t), ENoAccess); } Once deployed, this contract acts as the gatekeeper. Whenever someone wants to decrypt data, their request will get checked against this logic. If it passes, the key gets released. If not, they’re blocked. No one has to intervene. Step 2: Identity-Based Encryption (IBE) Here’s where the magic happens. Instead of encrypting data for a specific wallet address (like with PGP or RSA), SEAL uses identity strings — meaning you encrypt to something like: 0xwalletaddress dao_voted:proposal_xyz PkgId_2025_05_01 (a timestamp-based rule) or even game_user_nft_holder When the data is encrypted, it looks like this: Encrypt(mpk, identity, message) mpk = master public key (known to everyone) identity = the logic-defined recipient message = the actual data Later, if someone wants to decrypt, the key server checks if they match the policy (via the seal_approve call onchain). If it’s approved, it returns a derived private key for that identity. Derive(msk, identity) → sk Decrypt(sk, encrypted_data) The user can then decrypt the content locally. So encryption is done without needing to know who will decrypt ahead of time. You just define the conditions, and SEAL figures out the rest later. It’s dynamic. Step 3: The Key Server – Offchain, But Not Centralized You might wonder: who’s holding these master keys? This is where SEAL’s Key Server comes in. Think of it as a backend that: Holds the master secret key (msk) Watches onchain contracts (like your seal_approve logic) Only issues derived keys if the conditions are satisfied But — and this is key — SEAL doesn’t rely on just one key server. You can run it in threshold mode, where multiple independent servers need to agree before a decryption key is issued. For example: 3-of-5 key servers must approve the request. This avoids central points of failure and allows decentralization at the key management layer too. Even better, in the future SEAL will support MPC (multi-party computation) and enclave-based setups (like TEE) — so you can get even stronger guarantees without compromising usability. Step 4: Client-Side Decryption Once the key is returned to the user, the actual decryption happens on their device. This means: The server never sees your data The backend never stores decrypted content Only the user can access the final message It’s a solid privacy model. Even if someone compromises the storage layer (IPFS, Arweave, etc.), they still can’t read the data without passing the access logic. Here’s the quick mental model: This structure makes it easy to build dApps where access rules aren’t hardcoded — they’re dynamic, auditable, and fully integrated into your chain logic. The Team Behind SEAL SEAL is led by Samczsun, a well-known figure in the blockchain security community. Formerly a Research Partner at Paradigm, he has audited and saved multiple ecosystems from major exploits. Now, he’s focused full-time on building SEAL into a core piece of Web3’s privacy infrastructure. With his background and credibility, SEAL is not just another experimental tool — it’s a serious attempt at making decentralized data privacy both practical and scalable. As SEAL goes live on the Sui Testnet, it brings a new standard for how Web3 applications can manage secrets. By combining onchain access control, threshold encryption, and client-side privacy, SEAL offers a more trustworthy foundation for decentralized data handling. Whether you’re building dApps, DAOs, or decentralized games — SEAL provides a powerful toolkit to enforce access control and protect user data without compromising on decentralization. If Web3 is going to move forward, secure infrastructure like SEAL is not optional — it’s essential
- Sui
- Architecture
- SDKs and Developer Tools
8 AMM Bot in Sui Ecosystem
What are the key features and functionalities of AMM bots within the Sui ecosystem? How do they improve upon traditional trading mechanisms, and what advantages do they offer to users engaging with DeFi protocols on the Sui network? Do I need to build one or I can use Turbos Finance for example
- Sui
72Best AnswerIs the only way to publish Move packages through an EOA?
I assume there is no way on Sui chain as there is no module on chain which publishes packages.
- Sui
- SDKs and Developer Tools
- Move
63Best Answer
ArticleFoksa225ForPeera MetaJul 25, 2022How to create an account
To create an account on the Peeranha website you need to log in first. Peeranha supports four wallets you can log in with: Torus, MetaMask, WalletConnect, and Coinbase. Note: If you are new to Web3 we recommend you to use Torus. Log in with Torus Click Log in. Select the checkbox I agree to the Terms and Conditions and Privacy Policy. Choose Torus in the pop-up window. Select any of the suggested ways you want to sign in or enter your email address. You are now logged in and have an account. In your profile section, you can add more detailed information about yourself and track your progress and achievements. To edit your profile, click Profile and select Edit. Enter all the information that you want to be visible in your profile.
- tutorial
5- Expert Q&Aloth.broke110ForPolygonMar 31, 2025
Using heimdallcli in a dockerized local network setup?
I'm trying to use heimdallcli within my local dockerized network that I set up using matic-cli. My main goal is to send a proposal using this command: heimdallcli tx gov submit-proposal param-change {pathToProposalJSONFile} --validator-id {validatorID} --chain-id {chainID}. However, I'm encountering an error that states: 'Config File "heimdall-config" Not Found in "/var/lib/heimdall/config"'. The config directory doesn't seem to exist in the Docker environment, though I can see logs that suggest Heimdall is functioning. How can I resolve this and get the heimdallcli command working?
- Polygon PoS
54Best Answer 
ArticleFoksa225ForPeera MetaJul 08, 2022How to make a post
Making posts on Peeranha is easy. Follow the simple steps: Log in to your profile with any available wallets. Click the New post button. Select a community from the dropdown list where you want to make a post. Choose Post Type: Discussion, Expert, Tutorial. Note: Read carefully the requirements for each post type, to be sure that your post is published in the correct section. Enter your question in the Title field. To get a more detailed answer, give more details about what you would like to know in the Body field. In the Preview section, you may check how your post looks before publishing it. Select tags that suit your post most. Note: Tags help other users to find relevant information quickly. Click Post. Your post is published and soon you will get relevant answers from the other users.
- tutorial
5Move Programming Language - The Story Behind
In the ever-evolving landscape of blockchain technology, smart contract programming languages have become the backbone of decentralized applications (dApps). Among these, Move has emerged as a groundbreaking innovation, offering unique features that set it apart from traditional languages like Solidity or Vyper. Designed with security and scalability in mind, Move was created to address many of the vulnerabilities and inefficiencies inherent in earlier blockchain ecosystems. This article delves into the origins, features, and impact of the Move programming language, exploring its journey from inception to becoming one of the most promising tools for building robust decentralized systems. The Origins of Move: A Solution to Blockchain Challenges The Move programming language was first introduced by Meta (formerly Facebook) as part of its ambitious Diem project (initially called Libra). Diem aimed to create a global digital currency and financial infrastructure powered by blockchain technology. However, the team quickly realized that existing smart contract languages were insufficient for their vision. Traditional languages often lacked mechanisms to prevent common vulnerabilities such as reentrancy attacks, integer overflows, and unauthorized asset duplication. These issues had already caused significant damage in other ecosystems, most notably the infamous DAO hack on Ethereum. To overcome these challenges, Meta’s engineering team developed Move, a new language specifically designed for resource-oriented programming. Unlike conventional programming languages, Move treats digital assets as first-class resources , ensuring they cannot be duplicated, unintentionally deleted, or misused. This approach was inspired by linear logic, a mathematical framework that enforces strict ownership rules for resources. By embedding these principles into the core of the language, Move introduced a paradigm shift in how developers interact with digital assets on the blockchain. Although the Diem project was eventually shelved due to regulatory scrutiny, Move found new life in independent blockchain projects like Aptos and Sui. These platforms adopted Move as their primary smart contract language, recognizing its potential to revolutionize the way decentralized applications are built and secured. Key Features of Move: Why It Stands Out 1. Resource-Oriented Programming One of Move’s defining characteristics is its focus on resource-oriented programming . In Move, digital assets such as tokens, NFTs, or even custom objects are treated as resources that follow strict ownership rules. Once created, a resource cannot be copied or destroyed unless explicitly allowed by its module. This ensures that critical operations involving assets—such as transfers or state updates—are performed safely and securely. For example, consider a simple token transfer function written in Move: module examples::token { use sui::object::{Self, UID}; use sui::transfer; struct Token has key, store { id: UID, value: u64, } public fun mint(ctx: &mut TxContext, value: u64): Token { Token { id: object::new(ctx), value, } } public fun transfer_token(token: Token, recipient: address) { transfer::public_transfer(token, recipient); } } Here, the Token struct represents a resource that can only be transferred using the public_transfer function. Any attempt to duplicate or manipulate the token outside this function would result in a compilation error. This design eliminates entire classes of bugs and exploits commonly seen in other languages. 2. Modularity and Encapsulation Move promotes modular design , allowing developers to encapsulate functionality within self-contained modules. Each module defines its own types, functions, and access controls, ensuring clear separation between different components of a smart contract. For instance, a developer might create separate modules for token creation, trading pairs, and governance logic. This modularity enhances code readability, maintainability, and reusability. 3. Formal Verification Support Another standout feature of Move is its support for formal verification , a process used to mathematically prove the correctness of a program. Formal verification helps identify subtle bugs and edge cases that may not be caught through traditional testing methods. While not all Move-based projects require formal verification, the language’s structure makes it easier to apply this technique when needed. 4. Object-Centric Design (Sui-Specific Enhancements) On the Sui blockchain , Move has been further enhanced with an object-centric model . Every resource in Sui Move has a globally unique identifier (UID), enabling direct referencing and interaction with objects. This design simplifies complex workflows, such as managing NFTs or tracking user-specific data, while maintaining high performance and scalability. Real-World Applications of Move Since its adoption by Aptos and Sui, Move has been used to build a wide range of decentralized applications. Some notable examples include: 1. Decentralized Finance (DeFi) Protocols Move’s strong emphasis on security makes it ideal for DeFi applications, where billions of dollars worth of assets are at stake. Projects like Cetus —a decentralized exchange (DEX) built on Sui—leverage Move’s resource-oriented programming to implement advanced trading features while minimizing risks associated with asset manipulation. 2. Non-Fungible Tokens (NFTs) NFT marketplaces benefit greatly from Move’s ability to define and manage unique digital assets. Developers can create sophisticated NFT standards with granular control over ownership, royalties, and metadata. Additionally, Sui’s object-centric enhancements allow for seamless integration of dynamic NFTs, which can evolve based on predefined conditions. 3. Gaming and Metaverse Platforms Blockchain gaming requires efficient handling of in-game assets, player interactions, and real-time updates. Move’s modular architecture and low-latency execution make it well-suited for building immersive gaming experiences. Platforms like Blockus , a Web3 gaming ecosystem, utilize Move to power their decentralized games and economies. Comparing Move to Other Smart Contract Languages While Move shares some similarities with other smart contract languages, its unique features give it a competitive edge: Solidity : As Ethereum’s primary language, Solidity is widely adopted but suffers from legacy issues like vulnerability to reentrancy attacks. Move addresses these weaknesses through its resource-oriented model and stricter type safety. Rust (used in Solana) : Rust offers excellent performance and memory safety but lacks Move’s native support for resource management and formal verification. Additionally, Rust’s steep learning curve can deter newcomers compared to Move’s more intuitive syntax. Clarity (used in Stacks) : Clarity emphasizes transparency and predictability but operates within a limited scope tied to Bitcoin’s ecosystem. Move, on the other hand, supports broader use cases across multiple blockchains. The Future of Move: Adoption and Evolution As blockchain technology continues to mature, the demand for secure and scalable smart contract languages will only grow. Move is poised to play a pivotal role in shaping the next generation of decentralized applications, thanks to its innovative design and growing community support. Projects like Aptos and Sui are actively investing in developer education, tooling, and infrastructure to accelerate Move’s adoption. Initiatives such as the Move eLearning platform provide comprehensive tutorials and resources for aspiring developers, lowering the barrier to entry. Furthermore, collaborations with academic institutions and industry leaders are driving research into advanced topics like formal verification and cross-chain interoperability. Looking ahead, we can expect Move to expand beyond its current use cases, powering everything from enterprise-grade supply chain solutions to decentralized social networks. Its adaptability and robustness ensure that it remains relevant in an increasingly diverse and interconnected blockchain ecosystem.
- Move
5- Articleharry phan473ForSuiApr 24, 2025
Cross-Module Child Management with public_receive
This is the part 3 of "Parent-Child Objects in Sui Move" series. Sometimes your parent and child types are defined in different modules or even different packages. For example, you might have a generic Warehouse object that can store any kind of Parcel objects. The Warehouse module wants to pull out a Parcel child, but the Parcel type is defined elsewhere. In such cases, we use transfer::public_receive, which is the cross-module cousin of receive. receive vs public_receive As we saw, transfer::receive can only be called in the module that defines T (or a friend) because it doesn’t require T: store . The Move bytecode verifier actually ensures that in any call to receive, the type T is from the current module . This is a safety restriction for key-only objects. transfer::public_receive is a variant that requires T: key + store but allows receiving outside T’s module . In other words, if the object type has the store ability (meaning it’s allowed to exist in global storage freely), then any module (given a &mut UID of the parent) can receive it using public_receive . This is perfect for cases where the parent’s module is different from the child’s module. Why require store? Because store marks that the object can be safely persisted and passed around outside of its defining module. Key-only objects might have custom invariants that the original module wants to enforce on transfer/receive; by excluding those from public_receive, Sui forces developers to handle them in-module (as we’ll see with soul-bound objects). If an object has store, it’s more permissive, and Sui allows generic transfer/receive logic to manage it externally . Example: Separate Parent and Child Modules Let’s illustrate with a simple scenario: a Warehouse that stores Parcel objects. The Parcel type is defined in its own module, and the Warehouse in another. We’ll show how Warehouse can receive a Parcel child using public_receive. module demo::parcel { // Child module use sui::object::{Self, UID}; use sui::tx_context::{Self, TxContext}; /// A parcel object that can be stored in a Warehouse. /// It has both key and store, so it can be transferred across modules. struct Parcel has key, store { id: UID, contents: vector } public entry fun create_parcel(contents: vector, ctx: &mut TxContext): Parcel { Parcel { id: object::new(ctx), contents } } } module demo::warehouse { // Parent module use sui::transfer::{Self, Receiving, public_receive}; use demo::parcel::{Self, Parcel}; use sui::object::{UID}; use sui::tx_context::{Self, TxContext}; struct Warehouse has key { id: UID, location: address } public entry fun create_warehouse(location: address, ctx: &mut TxContext): Warehouse { Warehouse { id: object::new(ctx), location } } /// Receive a Parcel that was sent to this Warehouse. /// Returns the Parcel to the caller (transferred to caller's address). public entry fun withdraw_parcel( warehouse: &mut Warehouse, parcel_ticket: Receiving, ctx: &mut TxContext ): Parcel { // Using public_receive because Parcel is defined in another module and has store let parcel = public_receive(&mut warehouse.id, parcel_ticket) oai_citation_attribution:27‡docs.sui.io oai_citation_attribution:28‡github.com; // Transfer the parcel to the transaction sender (so the caller gets ownership) transfer::transfer(parcel, tx_context::sender(ctx)); // We return nothing because we've transferred the Parcel out to the caller. } } Let’s break down what’s happening in withdraw_parcel: We call public_receive(&mut warehouse.id, parcel_ticket). Because Parcel has the store ability, this call is allowed even though we’re not in the parcel module . Under the hood, this does the same check and extraction as receive, but it’s permitted cross-module since store indicates it’s safe to do so. https://github.com/MystenLabs/sui/blob/main/crates/sui-framework/packages/sui-framework/sources/transfer.move#:~:text=public%20fun%20public_receive,T%3E%29%3A%20T We then immediately transfer the received Parcel to the caller’s address (tx_context::sender(ctx)). This step ensures the parcel leaves the warehouse and goes to the user who initiated the withdrawal. We could also have just returned Parcel from the function, and Sui would treat it as an output to be owned by the caller’s address (since it’s an entry function output). Doing an explicit transfer is more verbose, but makes it clear what’s happening (and allows us to do any checks before releasing the object). Why include store in Parcel? If Parcel lacked the store ability (i.e. was only has key), the public_receive call in demo::warehouse would not compile – Sui enforces that T has store for public_receive . In that case, we’d be forced to retrieve the parcel using receive within the parcel module itself (or use some friend relationship), which complicates cross-module design. By adding store to Parcel, we effectively say “this object can be freely moved and received by external modules,” which is what we want for a generic container pattern. Function call pattern: To use these in a transaction, the flow would be: Deposit (transfer to object): Call transfer::public_transfer(parcel_obj, @warehouse_id) to send a Parcel into a Warehouse. This marks the parcel’s owner as the warehouse. (We use public_transfer here because it’s outside the Parcel module and Parcel has store . Inside the parcel’s module, a plain transfer would work too.) Withdraw (receive back): Later, call withdraw_parcel(warehouse_obj, Receiving(parcel_id, ...)). The Receiving can be obtained by the SDK by referencing the parcel’s ID and latest version. The function will call public_receive and then transfer the parcel to you. After the withdraw_parcel call, the parcel’s owner is back to an address (yours), so it’s a normal address-owned object again. The warehouse no longer owns it. Cross-module considerations: Notice that the Warehouse module needed to know about the Parcel type (we use demo::parcel::Parcel). This is because we explicitly type the Receiving as Receiving. If you wanted a truly generic container that could receive any type of object, you’d have to use generics or a different approach (possibly dynamic fields with type erasure). But for most use-cases, you’ll know what types of children you expect. Why public_receive instead of just calling receive? If we tried transfer::receive(&mut warehouse.id, parcel_ticket) in the warehouse module, the Move verifier would reject it because Parcel is not defined in demo::warehouse. Sui provides the public_receive as the blessed way to do this with an extra ability check (requiring store). Similarly, Sui has transfer vs public_transfer, freeze_object vs public_freeze_object, etc., following the same pattern: the public_ versions are for use outside the defining module and require store . Don’t forget the parent’s permission: Even with public_receive, you still need that &mut warehouse.id. We got it because withdraw_parcel is in Warehouse’s module and accepts &mut Warehouse. Thus, only someone who could call that (the warehouse’s owner) can withdraw the parcel. If the warehouse module didn’t provide such a function publicly, no one could externally call public_receive on its children either. So cross-module doesn’t bypass the parent’s control; it just allows the parent’s code to work with children of types it didn’t define. A note on store ability: Giving an object store makes it more flexible but slightly less restricted – any module with the parent reference can pull it out using public_receive. If you want to restrict how an object is retrieved (for example, enforce custom logic or prevent easy extraction), you might deliberately make it key-only. We’ll see an example of that with soul-bound objects. In those cases, you might implement a custom receive function instead of relying on public_receive. To sum up this part: public_receive is your friend for managing child objects defined in other modules, as long as those objects have the store ability. It allows you to build cross-module systems (like our Warehouse/Parcel) while still respecting ownership and access control. Just remember to include store on child types and use public_transfer when sending them to a parent from outside their module .
- Sui
- Architecture
5 - Article0xduckmove413ForSuiApr 25, 2025
Recap the video can supercharge your Sui Dev Journey
Let’s be real if you’ve ever built on Sui, you’ve probably hit some walls. From cryptic object IDs to juggling CLIs and spinning up localnets, it’s like prepping for a boss fight before you even write your first line of business logic. During a recent workshop as part of the Road to Overflow series, Moven from Dubhe Foundation broke down how Dubhe Engine works, what problems it solves, and how it’s more than just a tool — it’s a growing movement. Video link: https://www.youtube.com/watch?v=CHkOS-TYehM The Problem: Fragmented Tooling, Heavy Setup Moven kicked things off with some real talk about the current Sui dev landscape: Newcomers face a steep learning curve: setting up wallets, claiming test tokens, scaffolding packages, learning Move syntax, spinning up local testnets, configuring SDKs, and more. Even experienced developers find themselves wasting time on repetitive setup tasks rather than focusing on actual DApp logic. Codebases become monolithic fast — large, messy .move files with data structs, constructors, helpers, and entry functions all crammed together. In short: the ecosystem is growing fast, but the tools haven’t kept up until now. The Solution: Schema-Based Code Generation At the heart of Dubhe Engine is one key idea: schema-first development. With just one configuration file (d.config.ts), devs can define: Their onchain data structures Events Errors Custom types (even 2D vectors of self-defined structs!) From there, one command (pnpm dub schema:gen) auto-generates a fully structured Move package and frontend integration, complete with: Modularized file structure Onchain composability (via imports from Sui’s published packages) Localnet setup, build, deploy, and frontend support (Next.js ready) You write the logic. Dubhe handles the boilerplate. ⏱️ Real Impact: 80% Less Repetitive Code In internal experiments, Dubb-generated projects showed that only 20% of the code had to be written manually — the rest was scaffolding auto-generated via schemas. This means faster prototyping, fewer bugs, and more time to focus on what actually matters: your app’s core value. A Dev Ecosystem Engine Dubb isn’t stopping at scaffolding. Movin made it clear: this is infrastructure for a new developer economy. Here’s how the Dubb Engine community is evolving: Gas Subsidies:** For new builders experimenting with Dubb Task Bounties:** Like GitHub’s “good first issues,” but with rewards Governance Layer (D-OS):** Onchain voting for project prioritization Launchpad Support:** Helping mature projects secure funding DApp Staking:** Users can stake D-tokens to support their favorite DApps and vote on roadmap decisions This feedback loop fuels the whole Sui ecosystem: more devs → more apps → more users → more devs.
- Architecture
- SDKs and Developer Tools
5 How to access and manage nested structs and dynamic fields in Move?
How to access and manage nested structs and dynamic fields in Move?
- Sui
- Move
56Best Answer
- Q: How to Properly Use the Sui SDK for Frontend Integration?00
- Why can't I find the SUI wallet on devices or website?01
- How to integrate the Vue front-end framework into the sui ecosystem2
- Will Sui Become a Major Player in the Layer-1 Race?3
- Let's build the ultimate list of Sui dev extensions! Share your must-haves. 🔥00
- 2565
- 1780
- 517
- 473
- 413
- 402
- 397
- 369
- 360
- 328