You’ll find that Move’s resource model is both a safeguard and a constraint—it guarantees that assets like tokens, NFTs, or escrow objects can’t be copied or lost, which removes a whole category of bugs, but at the same time forces you to design workflows that are very explicit about ownership and movement. The elegance comes from leaning into patterns like wrapping resources in containers (e.g., Option<T> or custom structs) when you need to represent “maybe present, maybe not,” or using capability objects (small resources that grant permission to mutate or access a larger one) so you don’t need to pass heavy resources everywhere. For cases like resource-heavy protocols (e.g., AMMs), you can break down large shared resources into smaller sharded ones to avoid contention and keep your logic modular. Another trick is to use phantom types or zero-sized structs to encode constraints at the type level without actually holding a heavy resource. Here’s a simple illustration:

module my::vault {
    use sui::object;
    use sui::option::{Self, Option};

    struct Vault has key {
        id: UID,
        balance: u64,
    }

    // Wrapping in Option to allow "empty or filled"
    struct UserVault has key {
        id: UID,
        vault: Option<Vault>,
    }

    public fun deposit(uv: &mut UserVault, amount: u64) {
        let v = option::borrow_mut(&mut uv.vault);
        v.balance = v.balance + amount;
    }
}

You can use phantom types or zero-sized structs to encode constraints at the type level without actually holding a heavy resource.