最新的
随时了解最新帖子。
帖子
2649What are some use cases for Sui?
A:DeFi apps that need low fees and fast settlement NFTs that can evolve, combine, or hold other objects Games that require real-time, scalable interactions Social applications with dynamic digital assets
- Sui
- Move
00What are “owned” and “shared” objects in Sui?
A:Owned objects: Belong to a single user and can be transferred without global consensus. Shared objects: Can be used by multiple users or apps, but require consensus to update.
- Sui
- Move
00How fast is Sui?
A: Sui achieves sub-second transaction finality for simple transfers and can scale to handle very high throughput by parallelizing execution.
- Sui
- Move
00What are “owned” and “shared” objects in Sui?
A:Owned objects: Belong to a single user and can be transferred without global consensus. Shared objects: Can be used by multiple users or apps, but require consensus to update.
- Sui
- Move
00What language are Sui smart contracts written in?
A: Smart contracts on Sui are written in Move, a safe and resource-oriented programming language originally developed for the Diem project.
- Sui
- Move
00- 专家问答
为SuiSep 04, 2025How to implement governance mechanisms in Move?
: I’m trying to build a DAO on Sui. What are the recommended approaches for voting, proposal management, and ensuring fairness?
- Sui
- Architecture
- Transaction Processing
12 - 专家问答为SuiSep 04, 2025
Access control patterns in Move – what’s recommended
What’s the best way to enforce role-based permissions in Move? Should I store roles as capabilities, or use object ownership?
- Sui
- Architecture
- Security Protocols
02 
文章为SuiSep 04, 2025On-Chain Royalty Systems in Move: Design Patterns and Marketplace Compatibility
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.
- Sui
- Architecture
- SDKs and Developer Tools
1Leveraging Sui’s Object-Centric Model for Scalable dApp Development
How can I use Sui’s object-centric data model to improve scalability and parallel execution compared to traditional account-based models, and what design considerations should I keep in mind when building dApps that rely on owned vs. shared objects?
- Sui
- Architecture
13
- 4662
- 4340
- 4168
- 3036
- 2947
- 2773
- 2576
- 2565
- 2464
- 2458