Startseite

Klaus.move45

Sep 04, 2025

Artikel

Royalties remain one of the most debated aspects of NFT economics. On Sui, where NFTs are first-class objects, we have the chance to design royalty enforcement directly into Move smart contracts in a way that is both secure and marketplace-compatible. This article explores where royalty logic should live, the trade-offs between per-NFT and shared-manager designs, and patterns for multi-recipient splits and upgrades. Why Royalties Matter on Sui NFT royalties serve two goals: Artist/creator sustainability: enabling creators to earn on secondary sales. Protocol consistency: ensuring royalty enforcement works across marketplaces, not just at mint. Because Sui is object-centric, royalties can be attached either: Inside the NFT itself, making every token self-describing. In a shared royalty manager, centralizing enforcement and policy. Option A: Embedding Royalties Inside NFTs How it works Each NFT includes a Royalty field in its struct, storing recipient(s) and percentage. Marketplaces must read this field and enforce payout logic on transfers. Pros Self-contained: royalties travel with the NFT object. Immutable by default: if designed without upgrade hooks, prevents tampering. Creator-friendly: no external dependencies. Cons Duplication: every NFT stores its own royalty data. Harder upgrades: changing distribution requires burning/migrating NFTs. Fragmentation risk: inconsistent enforcement if marketplaces parse fields differently. Option B: Shared Royalty Manager How it works A shared RoyaltyManager object stores mappings of CollectionID -> RoyaltyPolicy. NFTs reference their collection’s policy via an ID. On resale, the marketplace queries the manager for splits. Pros Consistency: all NFTs in a collection follow the same policy. Upgradability: publishers can update policy (with capability controls). Efficiency: no duplication of royalty data inside every NFT. Cons Centralization risk: depends on the manager object being trusted and maintained. Complexity: marketplaces must implement standard calls to query the manager. Governance required: clear rules needed for who can update policies. Multi-Recipient Splits Whether royalties live in NFTs or a shared manager, creators often want splits (e.g., 70% artist, 20% developer, 10% DAO). Pattern: Store a vector representing recipient and basis points. At sale, iterate and distribute via transfer::public_transfer. For gas efficiency, cap the number of recipients or aggregate smaller ones off-chain. Upgradeability NFT-embedded royalties: upgrade requires new NFTs or wrapping. Shared manager: upgradeable via witness/capability pattern. Example: RoyaltyCap token grants update rights only to the collection creator. Marketplace Compatibility For royalties to work across Sui: Marketplaces must agree on a royalty standard (field schema or manager interface). Off-chain indexers (explorers, analytics) should surface royalty policies for transparency. Projects should publish open-source royalty modules so marketplaces can integrate directly. Recommendation For small, independent artists → embed royalties inside NFTs (simplicity, self-sovereignty). For large collections or evolving DAOs → use a shared RoyaltyManager (scalable, upgradable). In practice, the most future-proof design is hybrid: NFTs reference a RoyaltyManager but also embed a “minimum royalty” field. Marketplaces must honor at least the minimum, while the manager can coordinate upgrades or splits. Conclusion Royalty enforcement on Sui is not just a technical choice but also a governance and trust design. By leveraging Move’s object-centric model, developers can: Keep royalties immutable at the token level when trust minimization is critical. Use shared managers for collections that need flexibility and multi-party coordination. Ensure marketplace adoption by converging on standards for querying and enforcing royalties.

BigSneh1911

Sep 04, 2025

Artikel

Decentralized Autonomous Organizations (DAOs) are a natural fit for Sui’s object-centric model. Unlike Ethereum-style smart contracts where governance often relies on storage mappings, Sui encourages structuring governance around Move objects. This leads to gas-efficient, modular, and secure designs. In this post, we’ll explore how to design a secure DAO on Sui, focusing on voting, role-based permissions, and proposal execution. Why Objects Instead of Mappings? On Ethereum, DAOs often store proposals, votes, and roles in mappings (e.g., mapping(uint => Proposal)). This works, but updating global storage can become costly and prone to contention. On Sui, each proposal and each role can be its own object: Proposals are owned or shared objects. Votes can be lightweight objects linked to proposals. Roles are represented as capabilities — tokens that grant permissions. This object-based model is inherently parallelizable and minimizes hotspots in shared state. Core DAO Components DAO Root Object Tracks governance parameters (quorum, proposal threshold, etc.). Shared object, but kept tiny to reduce conflicts. Proposal Objects Each proposal is a separate object created when a member submits one. Stores metadata (description, deadline, vote counts). Vote Objects Each vote is an owned object submitted by a member. Proposal object tallies results by consuming or referencing votes. Roles via Capabilities AdminCap: allows upgrading DAO parameters. MemberCap: allows creating proposals and voting. These capabilities are distributed at DAO creation and can later be delegated. Sample Code: Roles + Proposal Voting module dao::governance { use sui::object::{Self, UID}; use sui::tx_context::TxContext; use sui::transfer; use std::option; /// Root DAO object struct DAO has key { id: UID, quorum: u64, proposal_count: u64, } /// Capability for admin operations struct AdminCap has key, store { id: UID } /// Capability for members struct MemberCap has key, store { id: UID } /// Proposal object struct Proposal has key { id: UID, proposer: address, description: vector, yes_votes: u64, no_votes: u64, executed: bool, } /// Initialize DAO with one admin public entry fun init(ctx: &mut TxContext): (DAO, AdminCap) { let dao = DAO { id: object::new(ctx), quorum: 10, proposal_count: 0 }; let cap = AdminCap { id: object::new(ctx) }; (dao, cap) } /// Add a member capability (admin only) public entry fun add_member(dao: &mut DAO, _admin: &AdminCap, ctx: &mut TxContext): MemberCap { MemberCap { id: object::new(ctx) } } /// Create a proposal public entry fun propose( dao: &mut DAO, _member: &MemberCap, description: vector, ctx: &mut TxContext ): Proposal { dao.proposal_count = dao.proposal_count + 1; Proposal { id: object::new(ctx), proposer: tx_context::sender(ctx), description, yes_votes: 0, no_votes: 0, executed: false, } } /// Cast a vote public entry fun vote(p: &mut Proposal, support: bool) { if (support) { p.yes_votes = p.yes_votes + 1; } else { p.no_votes = p.no_votes + 1; } } /// Execute a proposal (if quorum met) public entry fun execute(dao: &DAO, p: &mut Proposal) { assert!(p.executed == false, 1); assert!(p.yes_votes >= dao.quorum, 2); p.executed = true; // DAO-specific logic (e.g., transfer funds, change params) goes here } } Security Considerations Resource Safety: Capabilities (AdminCap, MemberCap) enforce who can act — no need to track roles in global storage. Replay Protection: Ensure votes can’t be double-counted by consuming Vote objects. Gas Efficiency: Proposals and votes are independent objects, so transactions can run in parallel without clashing. Upgradability: DAO parameters (e.g., quorum) live in the root DAO object, adjustable only by AdminCap. Best Practices Keep the DAO root object small — don’t store vectors of all proposals or votes inside it. Use dynamic fields or references only when absolutely necessary. Push heavy analytics (e.g., full voting history) off-chain via events. Build for parallelism: independent proposals and votes should not block each other. Consider capability delegation if your DAO wants sub-committees or role hierarchies. Conclusion Sui’s object-based model enables DAOs that are more parallel, gas-efficient, and secure than traditional mapping-based governance. By structuring proposals, votes, and roles as objects, developers can create governance systems that scale gracefully while minimizing contention.

Neeola25

Aug 31, 2025

Artikel

Sui’s global design faces regulatory scrutiny, like KYC/AML gaps, hindering enterprise adoption in 2025. Step-by-step solution: Assess Regulations: Research jurisdiction-specific rules. Integrate Compliance Tools: Add zk-proofs for privacy. Audit for Standards: Certify with firms. Governance Alignment: Propose compliant features. Educate Stakeholders: Host webinars. Monitor Changes: Track legal updates.

dhaholar.35

Aug 29, 2025

Artikel

If you're trying to understand how validators work in the Sui blockchain, you’ll need to look at how they help maintain the network’s integrity and performance. Validators are responsible for processing transactions, reaching consensus, and securing the blockchain. In Sui, they play a unique role because of the network’s hybrid execution model. When transactions involve shared objects—like assets used by multiple users—validators use Byzantine Fault Tolerant (BFT) consensus to agree on the outcome. But when transactions involve only owned objects, they can be finalized instantly without full consensus. This setup allows you to enjoy both speed and security depending on the type of transaction. To become a validator, you need to run a node and stake SUI tokens. The more tokens you stake, the more weight your validator has in the consensus process. You also earn rewards based on your performance and reliability. If you’re building an app or running a service on Sui, understanding how validators work helps you design systems that interact efficiently with the network. One challenge you might face is deciding whether your app should use shared or owned objects. Shared objects require consensus and are slower to process, but they’re useful when multiple users need access to the same data—like in a multiplayer game or a decentralized exchange. Owned objects are faster and ideal for personal assets like wallets, profiles, or collectibles. By designing your app to minimize shared object usage, you can improve performance and reduce costs. Here’s a simple example of how you might define a shared counter object in Move: module example::SharedCounter { struct Counter has key { id: UID, value: u64, } public fun create(): Counter { Counter { id: UID::new(), value: 0 } } public fun increment(counter: &mut Counter) { counter.value = counter.value + 1; } public fun get_value(counter: &Counter): u64 { counter.value } } This counter can be shared across users, but every update will require consensus. If you redesign it to use owned counters, each user can manage their own without waiting for network agreement. Validators also help manage gas fees and transaction prioritization. When you submit a transaction, you include a gas payment, and validators choose which transactions to process based on these bids. This system keeps fees predictable and ensures that high-priority transactions are handled quickly.

dhaholar.35

Aug 29, 2025

Artikel

If you're trying to understand Sui’s object-centric data model, you’ll find that it’s one of the key innovations that sets this blockchain apart. Instead of using a traditional account-based system like Ethereum, Sui treats all assets and smart contract states as individual objects. Each object has a unique ID, an owner, and a type, and it can be updated, transferred, or interacted with independently. This design allows the network to process transactions in parallel, which means you can build apps that are faster and more scalable. When you create an object in Sui, it becomes a first-class citizen of the blockchain. You don’t just store values in an account—you define objects with specific behaviors and properties. For example, a token isn’t just a number in a wallet; it’s an object with metadata, ownership rules, and logic for how it can be transferred or modified. This gives you more control and flexibility when designing your application’s architecture. One of the biggest benefits of this model is that it allows for parallel execution. If two transactions interact with different objects, they can be processed at the same time without waiting for each other. This solves a major problem in traditional blockchains where every transaction has to be ordered and confirmed sequentially. With Sui, you can build systems that respond instantly and scale to millions of users without slowing down. To work with objects, you’ll use the Move programming language. Move is designed to handle resources safely, and Sui extends it with features like dynamic fields and object ownership. You can define custom object types, write methods to interact with them, and enforce rules about who can access or modify them. This makes it easier to build secure and modular smart contracts. Here’s a simple example of how you might define a user profile object in Move: module example::UserProfile { struct Profile has key { id: UID, name: vector, age: u8, owner: address, } public fun create(name: vector, age: u8, owner: address): Profile { Profile { id: UID::new(), name, age, owner, } } public fun update_age(profile: &mut Profile, new_age: u8) { profile.age = new_age; } public fun get_name(profile: &Profile): vector { profile.name } } This module lets you create a profile object, update its age, and retrieve its name. You can expand this to include more fields or behaviors depending on your app’s needs.

dhaholar.35

Aug 27, 2025

Artikel

If you're exploring how Sui compares to traditional blockchains, you’ll quickly notice that its design focuses on solving performance and scalability issues that older systems struggle with. Most blockchains, like Bitcoin and Ethereum, use an account-based model where transactions are processed one after another. This sequential processing creates bottlenecks, especially when many users interact with the network at the same time. Sui takes a different approach by using an object-based model, which allows it to process multiple transactions in parallel as long as they don’t touch the same object. This means you can build apps that respond faster and scale more easily. You also benefit from Sui’s unique consensus mechanism. Instead of applying consensus to every transaction, Sui only uses it when necessary—specifically for shared objects. For simple transfers or updates to owned objects, the network can finalize transactions instantly. This hybrid model gives you both speed and security, which is ideal if you're building real-time applications like games, marketplaces, or social platforms. Another key difference is how Sui handles smart contracts. While Ethereum uses Solidity, Sui relies on Move, a language designed for secure asset management. Move treats assets as resources that can’t be copied or lost, which helps prevent common bugs and exploits. You’ll find that Move’s strict rules make your code safer and easier to audit, especially when dealing with financial or ownership logic. Sui also improves the user experience by offering predictable gas fees. Instead of fluctuating wildly during high traffic, fees are managed through a market-based system where users bid for execution. This gives you more control over costs and helps your app stay affordable for users. If you're coming from another blockchain ecosystem, you’ll need to adjust to Sui’s object-centric mindset. Instead of thinking in terms of accounts and balances, you’ll work with objects that have unique IDs, owners, and states. This model is more flexible and lets you build complex systems with fine-grained control over behavior and access.

dhaholar.35

Aug 27, 2025

Artikel

If you're trying to understand what makes Sui different from other blockchains, you need to look at how it handles scalability and performance. Sui is built to process transactions in parallel, which means it doesn’t have to wait for one transaction to finish before starting another. This is possible because Sui uses an object-based model where each asset or data point is treated as a separate object with its own ownership and state. When two transactions don’t touch the same object, they can be executed at the same time without conflict. This design helps you avoid the bottlenecks that slow down traditional blockchains like Ethereum. You also benefit from Sui’s ability to scale horizontally. Instead of relying on a single chain to handle all activity, Sui spreads the load across multiple validators and uses a consensus mechanism only when necessary. For example, if you’re sending tokens between wallets and those tokens are not shared objects, the transaction can be finalized instantly without going through full consensus. This makes Sui ideal for applications that need fast response times, like games or social platforms. Another advantage you’ll notice is how Sui handles gas fees. Instead of fixed fees or unpredictable spikes, Sui uses a market-based system where users bid for execution. This keeps fees stable and gives you more control over transaction costs. If you’re building an app, this means your users won’t be surprised by sudden fee increases during peak times. When you start developing on Sui, you’ll interact with its object-centric model through the Move programming language. Move is designed to be safe and flexible, and Sui adds features like dynamic fields and object ownership to make it even more powerful. You’ll write modules that define how objects behave, and you’ll deploy them using the Sui CLI or SDK. This gives you full control over your app’s logic and data flow. Here’s a basic example of how you might define a simple token object in Move: module example::Token { struct Token has key { id: UID, value: u64, owner: address, } public fun mint(owner: address, value: u64): Token { Token { id: UID::new(), value, owner, } } public fun transfer(token: &mut Token, new_owner: address) { token.owner = new_owner; } public fun get_value(token: &Token): u64 { token.value } } This module lets you mint a token, transfer it to a new owner, and check its value. You can build on this to create more complex behaviors like staking, burning, or locking tokens.

dhaholar.35

Aug 27, 2025

Artikel

If you're new to Sui, you're stepping into a blockchain ecosystem designed for speed, scalability, and developer flexibility. Sui is a Layer 1 blockchain built by Mysten Labs that uses a unique object-based data model and the Move programming language to power decentralized applications. Unlike traditional blockchains that rely on account-based systems, Sui treats everything as an object, which allows it to process transactions in parallel and scale horizontally. To get started, you need to understand how Sui differs from other blockchains. Most chains like Ethereum process transactions sequentially, which can slow things down and increase fees. Sui avoids this by allowing independent transactions to be executed simultaneously. This is possible because each object in Sui has a unique ID and ownership, so the system can easily determine whether two transactions conflict or not. One of the first challenges you might face is understanding how assets are represented. In Sui, assets are objects with defined properties and behaviors. You don’t just send tokens—you interact with objects that can evolve, be transferred, or modified. This opens up new possibilities for building complex applications like games, marketplaces, and social platforms. Another hurdle is learning the Move language. Move was originally developed for Facebook’s Libra project and is designed to be safe and flexible. Sui extends Move with features like dynamic fields and object ownership, which makes it easier to build secure and modular smart contracts. If you’re coming from Solidity or Rust, you’ll need to adjust to Move’s strict type system and resource-oriented programming model. To start building, you’ll want to install the Sui CLI and connect to a testnet. The CLI lets you create wallets, send transactions, and deploy packages. You’ll also need the Sui SDK, which provides tools for integrating with the blockchain from your app. Once you’ve set up your environment, you can begin writing Move modules and testing them locally. Here’s a simple example of a Move module that defines a basic counter object: module example::Counter { struct Counter has key { value: u64, } public fun create(): Counter { Counter { value: 0 } } public fun increment(counter: &mut Counter) { counter.value = counter.value + 1; } public fun get_value(counter: &Counter): u64 { counter.value } } This module creates a counter object, lets you increment it, and retrieve its value. You can deploy this to Sui and interact with it using the CLI or SDK. As you build, you’ll run into questions about gas fees, validator roles, and transaction finality. Sui uses a unique consensus model that separates simple and complex transactions. Simple transactions that don’t involve shared objects can be finalized almost instantly, while complex ones go through a Byzantine Fault Tolerant (BFT) consensus process. This hybrid approach keeps the network fast and secure. To manage gas fees, Sui uses a market-based system where users bid for execution. This keeps fees predictable and fair, especially during high demand. Validators play a key role in maintaining the network, and you can stake SUI tokens to support them and earn rewards.

D’versacy 59

Aug 26, 2025

Artikel

Are you struggling to integrate wallet connections and design a seamless user experience for signing operations? 🤔 Do you want to learn how to create a user-friendly flow that minimizes errors and rejections? 📊 Look no further! In this article, we'll provide a step-by-step approach to integrate wallet adapters, design user flows, and handle errors gracefully. Choose Wallet Adapter Pattern 🔌 Use established wallet adapters or write a thin adapter layer that normalizes wallet APIs (connect, sign, send). Typical Front-end Flow 📈 Connect wallet and request account(s) 🔗 Show human-readable summary of the transaction (amounts, object moves) 📝 Request signature with signTransactionBlock 🔒 Submit and show pending state + final effects ⏱️ Error & Retry UX 🔄 Provide clear messages for gas/insufficient funds 💸 Offer “retry with increased gas” automatically or with user confirmation 🔁 Allow “simulate” transactions to show estimated costs before asking to sign 🔍 Security Considerations 🔒 Never send raw private keys to backend 🚫 Use signMessage for off-chain proof-of-ownership rather than sending txs unnecessarily 🔑 Best Practices 💡 By following these step-by-step guidelines, you'll be able to: Create a seamless user experience for wallet connections and signing operations Handle errors and rejections gracefully Ensure security and transparency in your application Happy building!