Using 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:

1. SUI Move Intro Course - Capability Design Pattern
2. SUI Examples - Capability Pattern
3. 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.