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.

1. 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:

1. Inside the NFT itself, making every token self-describing.

2. In a shared royalty manager, centralizing enforcement and policy.

---

2. 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.

---

3. 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.

---

4. 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<(address, u64)> 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.

---

5. 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.

---

6. 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.

---

7. 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.

---

8. 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.