Post
Share your knowledge.
How do upgradable NFTs work in SUI
Means a person deploys a collection and Mints and transfers different NFTs to users. Now the person wants to upgrade the NFT for a game or character but how will he do it as NFTs are owned by the users and if they do not pass it as a Mutable reference then it cannot happen. So how does this work in SUI?
- Sui
Answers
3you will need a function in your smart contract that each holder will have to call to modify its nft/object. This guide should be helpful for you https://docs.shinami.com/docs/sui-high-level-gaming-guide
You store the modifiable parts of the NFT as dynamic fields under an NFT object. The main NFT object stays owned by the user, but you (the developer or game logic) are given capabilities or controlled access to mutate the upgradable parts (stats, skins, etc.).
module mygame::upgradable_nft {
use sui::object::{Self, UID};
use sui::tx_context::TxContext;
use sui::dynamic_field::{Self, DynamicField};
use sui::balance;
// --- The base NFT object ---
struct NFT has key {
id: UID,
name: String,
level: u64,
}
// --- Admin capability to control upgrades ---
struct UpgradeAuthority has key, store {
id: UID,
}
/// Create an upgrade authority
public fun init_authority(ctx: &mut TxContext): UpgradeAuthority {
UpgradeAuthority { id: object::new(ctx) }
}
/// Mint an NFT to the user
public fun mint_nft(
name: String,
recipient: address,
ctx: &mut TxContext
): NFT {
let nft = NFT {
id: object::new(ctx),
name,
level: 1,
};
transfer::transfer(nft, recipient)
}
/// Upgrade NFT by mutable reference (only if caller has authority)
public fun upgrade_nft(
authority: &UpgradeAuthority,
nft: &mut NFT
) {
nft.level = nft.level + 1;
}
}```
NFT is a standard object. When a user owns it, it can’t be mutated by someone else.
• UpgradeAuthority is a capability that the game dev or system contract owns.
• Users can opt in by giving mutable reference of their NFT (e.g., when playing a game level), and your contract will verify the authority before upgrading the NFT.
// Assume Alice owns an NFT and plays a game // She agrees to let the game system upgrade her NFT if she wins
entry fun user_plays_and_gets_upgrade( authority: &UpgradeAuthority, nft: &mut NFT, ctx: &mut TxContext ) { // Game logic... // If win: upgrade_nft(authority, nft); }
You can’t mutate objects you don’t have mutable access to.
• So either:
• The user calls the function and passes the NFT as &mut, OR
• You design the NFT with an internal “stat object” that is owned by the dev and pointed to by the main NFT (via object ID or dynamic field), allowing external upgrades.
In Sui, if you want to make NFTs upgradable after minting and transferring them to users, you need to plan for that flexibility right from the design stage. Since Sui enforces strict ownership and only the owner can mutate an object, you can’t directly upgrade a user's NFT unless they either send it back to you or interact with your smart contract and grant permission via a mutable reference. The most common and effective pattern is to separate the NFT's core identity from its upgradable data by using a two-part structure: the NFT object itself (which is transferred and owned) and a secondary object (like a metadata or stats object) that the NFT points to. This secondary object can be shared or controlled via capabilities so that game logic or your smart contract can update it without needing full ownership of the NFT. You can also implement access control using capabilities—if your contract issues a capability to users, they can authorize upgrades securely without giving up their NFT. In-game interactions like battles or level-ups would call smart contract functions that take both the NFT and its metadata, ensuring only approved upgrades happen. If users are expected to initiate upgrades, you can require them to call your function with the correct mutable reference. Without that, Sui’s model intentionally prevents forced changes, which is a security feature. So to enable upgradable NFTs in practice, you either structure them with external metadata that you control access to, or require users to opt into upgrades via transactions they sign.
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.
- 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