Sui Kiosk vs Aptos Token Objects for NFT Royalties: Which Approach Works Better?

14 October 2026

Sui Kiosk and Aptos Token Objects offer different mechanisms for enforcing NFT royalties, and the right choice depends on whether you need on-chain enforcement, flexibility for marketplace integration, or simpler implementation. Sui Kiosk provides a built-in royalty system with optional enforcement at the marketplace level, while Aptos Token Objects require developers to implement royalty logic manually using the token object's mutable properties. Neither approach guarantees royalties across all marketplaces by default.

How sui kiosk handles royalties

Sui Kiosk is a standard module in the Sui framework that manages the transfer and sale of digital assets. It includes a royalty mechanism built into the kiosk's transfer policies.

The Royalty Rule

When you create a kiosk for a collection, you can attach a royalty rule that specifies a percentage fee on secondary sales. This rule is enforced when a buyer purchases an item through the kiosk's purchase function. The fee is taken at the time of sale and sent to a designated beneficiary address.

Key characteristics:

• The royalty percentage is set at the collection level, not per individual token.
• The fee is calculated as a percentage of the sale price, which is determined by the seller.
• The beneficiary receives the fee immediately when the purchase completes.
• Marketplaces that integrate with Sui Kiosk can choose to respect or ignore the royalty rule. On-chain enforcement only works if the marketplace uses the kiosk's purchase flow.

Limitations

• A seller can bypass the kiosk entirely by transferring an NFT directly to a buyer outside the kiosk system. The royalty rule only applies to sales that go through the kiosk.
• The kiosk's royalty mechanism does not prevent off-platform sales or peer-to-peer transfers.
• If a marketplace does not use the kiosk's purchase function, royalties are not collected.

How aptos token objects handle royalties

Aptos Token Objects are a flexible standard that allows developers to define custom properties on each token. Royalties are not built into the standard. Instead, you must implement royalty logic using the token object's mutable fields and the Aptos framework's token module.

Implementing royalties with token objects

You can add a royalty percentage and beneficiary address as properties of the token object during minting. Then, when a transfer or sale occurs, your smart contract checks these properties and deducts the royalty fee.

Typical implementation steps:

1. Define a royalty field in the token object's struct, storing the percentage and beneficiary.
2. Create a transfer function that calculates the royalty amount, sends it to the beneficiary, and transfers the token.
3. Require all marketplaces to call your custom transfer function instead of using the default direct_transfer function.

Challenges

• There is no universal standard for royalty enforcement across Aptos marketplaces. Each marketplace must integrate with your custom transfer function.
• If a marketplace uses the default direct_transfer function, royalties are not collected.
• You must write and maintain the royalty logic yourself, including handling edge cases like partial payments or fee splitting.

Key Differences

Which one should you use?

Choose Sui Kiosk if:

• You are building on Sui and want a ready-made royalty system.
• You expect your collection to be traded on kiosk-compatible marketplaces.
• You are comfortable with the limitation that royalties only apply to kiosk sales.

Choose Aptos Token Objects if:

• You need fine-grained control over royalty logic, such as different rates for different token tiers.
• You are willing to write custom smart contract code and coordinate with marketplaces.
• You are building on Aptos and need to define your own transfer rules.

Practical considerations for both chains

Sui

• To enable royalties, you must deploy a kiosk and attach a royalty rule. The Sui documentation provides examples for setting up a kiosk and configuring transfer policies.
• Marketplaces like Sui Vision and others that use the kiosk standard will enforce royalties automatically. Check each marketplace's documentation for compatibility.

Aptos

• You can use the aptos_token module to create token objects with custom fields. The royalty field is not reserved, so you must define it yourself.
• To prevent bypassing, you can make your token non-transferable except through your custom function. This requires careful design and testing.
• Some Aptos marketplaces support custom transfer functions, but you must contact them individually to integrate.

Summary

Sui Kiosk offers a simpler, standardised approach to royalties with less custom code required, but it only works within the kiosk ecosystem. Aptos Token Objects give you full control at the cost of more development work and marketplace coordination. Neither system guarantees royalty enforcement across all trading scenarios. If on-chain royalty enforcement is critical, you may need to restrict transfers to only your approved functions, which limits interoperability. For most projects, the practical choice depends on which chain's ecosystem and marketplace support aligns better with your goals.

Back to sui & aptos