🌱
Dev Compendium
  • Ethereum
    • Solidity
      • EVM
      • Architecture
      • Execution Context
      • Transactions
      • Gas
      • Calldata, Memory & Storage
      • Gas Optimisation
      • Function Declarations
      • receive() & fallback()
      • CALL vs. DELEGATE CALL
    • Yul
      • Introduction
      • Types
      • Basic Operations
      • Storage
      • Memory
        • Arrays
        • Structs
        • Tuples, revert, keccak256
        • Logs and Events
        • Gotchas
        • abi.encode
      • Calldata
        • External Calls
        • Dynamic Length Inputs
        • Transferring Value
        • Receiving Contract Calls
      • Contracts in Yul
      • Other Yul Functions
    • Foundry
    • Security
      • Common Vulnerabilities
      • Best Practices
      • Development Workflow
      • Contract Migration
    • Auditing Tools
      • Slither
      • Mythril
      • Fuzzing
    • Upgradable Contracts
      • Upgrade Patterns
      • ERC-1967 Implementation
      • Deployment
    • MEV
    • Tooling
      • Chainlink
      • IPFS
      • Radicle
    • Frontend
      • Contract Hooks
      • Wallet Connection
        • wagmi.sh
        • Rainbow Kit
      • thirdweb
    • Protocol Research
      • Uniswap v2
      • Uniswap v3
      • Curve
      • GMX
  • Starkware
    • Fundamentals
    • Account Abstraction
    • Universal Deployer
    • Cairo 1.0
    • starknet.js
    • Security Model
  • Zero Knowledge
    • Group Theory
    • ECDSA
  • Rust
    • Basic Operations
    • Set up
    • Primitives
    • Control Flow
    • Mutability & Shadowing
    • Adding Behavior
    • Lifetimes
    • Std Library
  • SUI
    • Architecture
    • Consensus Mechanism
    • Local Node Setup
    • Sui Client CLI
    • Move Contracts
      • Move
      • Move.toml
      • Move.lock
      • Accessing Time in Sui Move
      • Set up Development Framework
      • Debug & Publish
      • Package Upgrades
      • Sui Move Library
      • Difference from Core Move
    • Object Programming
      • Object Basics
      • Using Objects
      • Immutable Objects
      • Object Wrapping
      • Dynamic Fields
      • Collections
      • Unit Testing
      • Deployment with CLI
  • NEAR
    • Architecture
    • Contract Standards
      • Fungible Token (NEP-141)
      • Non-Fungible Token (NEP-171)
      • Storage Management (NEP-145)
      • Events (NEP-297)
      • Meta-Transactions
    • Rust Contracts
      • Development Workflow
      • Smart Contract Layout
      • Storage Management
      • Events & Meta-transactions
      • Method Types
      • Upgrading Contracts
      • Unit Testing
    • NEAR Libraries
    • Environment Variables
    • Serialisation
    • Security Concepts
    • Collections
    • JS SDK
Powered by GitBook
On this page
  • Object ownership
  • Transaction context
  1. SUI
  2. Move Contracts

Sui Move Library

PreviousPackage UpgradesNextDifference from Core Move

Last updated 2 years ago

Sui provides a list of Sui Move library functions that enables manipulation of objects in Sui. You can view source code for the implementation of the core Sui Move framework in the .

Object ownership

Objects in Sui can have different ownership types:

  • Exclusively owned by an address.

  • Exclusively owned by another object.

  • Immutable.

  • Shared.

Owned by an address

The module provides all the APIs needed to manipulate the ownership of objects.

The most common case is to transfer an object to an address. For example, when you create a new object is created, you typically transfer it to an address for ownership. In Sui Move, to transfer an object obj to an address recipient, you import the module then make the transfer:

use sui::transfer;

transfer::transfer(obj, recipient);

This call fully consumes the object, making it no longer accessible in the current transaction. After an address owns an object, for any future use (either read or write) of this object, the signer of the transaction must be the owner of the object.

Owned by another object

An object can be owned by another object when you add the former as a of the latter. While external tools can read the dynamic object field value at its original ID, from Move's perspective, you can only access it through the field on its owner using the dynamic_object_field APIs:

use sui::dynamic_object_field as ofield;

let a: &mut A = /* ... */;
let b: B = /* ... */;

// Adds `b` as a dynamic object field to `a` with "name" `0: u8`.
ofield::add<u8, B>(&mut a.id, 0, b);

// Get access to `b` at its new position
let b: &B = ofield::borrow<u8, B>(&a.id, 0);

If you pass the value of a dynamic object field as an input to an entry function in a transaction, that transaction fails. For instance, if you have a chain of ownership: address Addr1 owns object a, object a has a dynamic object field containing object b, and b has a dynamic object field containing object c, then in order to use object c in a Move call, Addr1 must sign the transaction and accept a as an input, and you must access b and c dynamically during transaction execution:

use sui::dynamic_object_field as ofield;

// Signer of ctx is Addr1
public entry fun entry_function(a: &A, ctx: &mut TxContext) {
  let b: &B = ofield::borrow<u8, B>(&a.id, 0);
  let c: &C = ofield::borrow<u8, C>(&b.id, 0);
}

Immutable

To make an object obj immutable, call freeze_object:

transfer::freeze_object(obj);

After this call, obj becomes immutable, meaning you can't mutate or delete it. This process is also irreversible: once an object is frozen, it stays frozen forever. Anyone can use an immutable object as a reference in their Move call.

Shared

To make an object obj shared, call share_object:

transfer::share_object(obj);

Transaction context

The TxContext module provides a few important APIs that operate based on the current transaction context.

To create a new ID for a new object:

// Assume `ctx` has type `&mut TxContext`.
let info = sui::object::new(ctx);

To obtain the current transaction sender's address:

sui::tx_context::sender(ctx)

After this call, obj stays mutable, but becomes shared by everyone so that anyone can send a transaction to mutate this object. However, you cannot transfer or embed a shared object in another object as a field. For more details, see the documentation.

Sui GitHub repo
Transfer
dynamic object field
shared objects