Post
Share your knowledge.
Soulbound ও Transferable Asset
Great article! I’d like to add a few practical points to reinforce the design and type safety around heterogeneous assets in Sui Move:
✅ Since dynamic_field::add<K, V>()
requires the store
ability, assets like soulbound tokens (which only have key
) can’t be stored directly. Instead, store only their ID
and listing metadata, which do have store
.
✅ Best approach: separate collections based on ability constraints:
VecMap<ID, ListingWithAsset>
→ forkey + store
assets (e.g., transferable NFTs)VecMap<ID, ListingMetadata>
→ forkey
-only assets (e.g., soulbound tokens)
✅ Add a runtime asset_type: String
tag to metadata. This enables you to identify and safely handle asset logic (e.g., transfers, display) even after type erasure.
✅ Phantom types are excellent for compile-time type tagging and preventing developer misuse (like accidental transfers of non-transferable tokens).
This modular structure is scalable, avoids Move ability violations, and allows for flexible marketplace design without sacrificing safety. Great work on explaining it so thoroughly!
- Sui
- NFT Ecosystem
Answers
1In that case, the SBT would depend on the owner of KioskOwnerCap, so it wouldn't really be soulbound.
Do you know the answer?
Please log in and share it.
Sui is a Layer 1 protocol blockchain designed as the first internet-scale programmable blockchain platform.

- ... SUIBigSneh+1396
- ... SUISuiLover+1333
- ... SUI0xduckmove+1207
- ... SUIThorfin+1202
- ... SUIOwen+970
- ... SUIharry phan+847
- ... SUItheking+742
- Why does BCS require exact field order for deserialization when Move structs have named fields?53
- Multiple Source Verification Errors" in Sui Move Module Publications - Automated Error Resolution43
- Sui Transaction Failing: Objects Reserved for Another Transaction25
- How do ability constraints interact with dynamic fields in heterogeneous collections?05