Post
Share your knowledge.
Implementing Ownership Privileges in SUI Move Smart Contracts
In EVM-based ERC20 tokens, we often use the transferOwnership
function to transfer ownership privileges. These privileges are important as they grant certain powers within the contract. I'm exploring how to achieve something similar in Sui Move smart contracts. From my understanding, due to the shared nature of Sui Move smart contracts, direct ownership is not possible. My current workaround involves creating an owner struct and transferring this object to the deployer. Users with this struct would then have specific privileges in the contract. However, I'm unsure if this approach is appropriate or if there's a better way to handle ownership in Sui Move smart contracts. Additionally, I'm facing an issue where the owner struct becomes immutable when created using the init
function, making it impossible to transfer. I'm looking for a solution to address this limitation as well. Any guidance on best practices for implementing ownership privileges in Sui Move smart contracts and a solution to the immutability problem with the owner struct would be highly appreciated.
- Move CLI
- Move
Answers
2Using an owner struct created in the init function to guard your contract functions is a common and valid pattern in Move development. It allows you to control access and permissions within your smart contract. Regarding the issue with transferring an immutable object, you are correct in your understanding. Immutable objects cannot be transferred because they are no longer owned by anyone. If your object is not frozen and you want to transfer it, ensure that your object has both key and store abilities. Objects with only key ability are soulbound tokens and can only be transferred using custom transfer logic.
Here are some helpful resources for further reading:
- SUI Move Intro Course - Capability Design Pattern
- SUI Examples - Capability Pattern
- SUI Framework Transfer Logic - Example Code
These links should provide you with more in-depth insights into capability-based access control and object transfers in SUI contracts.
In SUI contracts, the concept of ownership is handled differently compared to EVM-based ERC20 tokens. SUI contracts are designed around the concept of shared and owned objects docs.sui.io. [https://docs.sui.io/build/move]
To implement ownership privileges in SUI contracts, you can use the concept of owned objects. When an object is created, an address can be specified, and the object will be transferred to that address. This ensures that only the object owner can modify the object movebit.xyz. [https://www.movebit.xyz/blog/post/Sui-Objects-Security-Principles-and-Best-Practices.html]
Here's a basic example of how you might create an owned object in SUI:
public fun create_object(ctx: &mut TxContext) { let owner = ctx.sender(); let obj = Object::create(owner, /* other parameters */); } In this example, the create_object function creates an object that is owned by the sender of the transaction. The Object::create function takes the owner and other parameters as arguments.
As for the issue with the owner struct becoming immutable when created using the init function, you might need to rethink your approach. Instead of creating an owner struct, you could create an owned object as described above. This would allow you to transfer ownership of the object to different addresses.
However, please note that this is a very basic example and the actual implementation would depend on the specific requirements of your application. You should also consider the security implications of your ownership mechanism, as improper ownership handling can lead to vulnerabilities in your application.
Unfortunately, the search results do not provide any information about ownership in SUI contracts. Therefore, you may need to consult the SUI documentation or reach out to the SUI community for more information.
Do you know the answer?
Please log in and share it.
Move is an executable bytecode language used to implement custom transactions and smart contracts.

- ... SUIderiss+5
- ... SUIRamirez+5
- ... SUIElvin CLONE +5
- ... SUI
- ... SUI
- ... SUI
- ... SUIBritain+2