To extract Move calls from CheckpointTransaction in Rust:

Access transaction.data – Contains the transaction details. Match on TransactionKind – Filter for ProgrammableTransaction. Iterate over commands – Look for MoveCall types. Example Code Snippet: if let TransactionKind::ProgrammableTransaction(pt) = &checkpoint_tx.transaction.data.kind { for cmd in &pt.commands { if let Command::MoveCall(move_call) = cmd { // Filter by package ID here println!("MoveCall: {:?}", move_call.package); } } } Key Steps:

Check move_call.package to match your target package ID. The MoveCall struct contains module, function, and args. (Ensure you’re using the correct SDK version—structs may vary slightly.)

To extract the Move calls from the CheckpointTransaction struct and filter transactions interacting with a specific package in Rust, you need to look at the transaction field and potentially other fields like effects or events.

Here's a step-by-step breakdown of how you can approach extracting the Move calls, assuming you are familiar with the sui-sender-indexer and how the data is structured in the CheckpointTransaction.

Key Structs

• CheckpointTransaction: Contains the transaction, effects, events, and input/output objects.
• Transaction: Represents the actual transaction.
• TransactionEffects: Contains information about the effects of the transaction.
• TransactionEvents: Holds the events emitted by the transaction.

You’ll likely be looking for Move call events that indicate which Move modules were interacted with. These events are stored in the events field of the CheckpointTransaction. The TransactionEvents would typically contain the Move events, and the transaction's effects might also have details about the package interacted with.

Steps to Extract the Move Calls

1. Access the events field: This field will contain the emitted events, including Move call events.
2. Look for Move Call Events: You need to filter events to find the ones related to Move calls, which might be represented as MoveEvent or similar, depending on the exact implementation in the indexer.
3. Filter by Package: If you're filtering based on a specific package, you would look for events that contain the package name or package address and filter them accordingly.

Example Code

Here's how you can approach it:

use sui_sender_indexer::{CheckpointTransaction, TransactionEffects, TransactionEvents};

fn extract_move_calls(transaction: &CheckpointTransaction, target_package: &str) {
    // Ensure the events field is Some, indicating events were emitted
    if let Some(events) = &transaction.events {
        // Iterate through each event
        for event in events.iter() {
            // Check if the event is a Move call event
            if let Some(move_event) = event.as_move_call() {
                // Extract the package address or name from the Move event
                let package = move_event.package_address();
                
                // Check if the package matches the target
                if package == target_package {
                    println!("Found Move call for package: {}", package);
                    // You can now process the Move call, e.g., print details, store it, etc.
                }
            }
        }
    } else {
        println!("No events found for this transaction.");
    }
}

Key Concepts to Focus On

1. TransactionEvents: These events should contain the Move call events. You'll need to iterate over these events and check if they are Move-related.

2. as_move_call(): This method (hypothetical, depending on your crate's implementation) would check if an event is a Move call. You will need to adapt this based on the actual API of the TransactionEvents struct.

3. Filtering by Package: Once you have identified the Move call event, check if its package matches the target_package. The package address might be stored directly in the event or in the call data.

Assumptions Based on the Struct

• Events: If Move calls are being logged as events in the events field, they will likely have some form of identifier for the package (e.g., package address).
• Transaction Effects: If Move calls modify objects or produce specific effects related to a package, the TransactionEffects might provide additional data (e.g., modified objects or logs related to the package).

Conclusion

This example assumes that Move call events are part of the emitted events in the CheckpointTransaction. If this isn't the case, you'll need to delve deeper into the Transaction struct or the TransactionEffects to find the interactions with the specific package.

You may need to adjust the event filtering based on the exact format of the Move events in your system. The method as_move_call() was used as an illustrative example and should be adapted to your actual crate's API for parsing Move call events.

To extract Move calls from a CheckpointTransaction in Rust, you need to parse the transaction.data field, which contains the transaction data including the ProgrammableTransaction with its list of Commands. The CheckpointTransaction struct you provided does not expose MoveCall directly, so you must:

1. Access transaction.data.transaction.kind to get the ProgrammableTransaction.
2. Iterate over its commands field and filter for Command::MoveCall.
3. Check if the called package matches your target package ID.

You’ll need to use the Sui SDK types (e.g., sui_types::transaction::ProgrammableTransaction) to decode the data. Example:

if let TransactionKind::ProgrammableTransaction(pt) = &transaction.data.kind {
    for cmd in &pt.commands {
        if let Command::MoveCall { package, .. } = cmd {
            if package == &target_package {
                // Found a MoveCall to your package
            }
        }
    }
}

Ensure you’re using the correct Sui types and version compatibility in your indexer.

To extract Move calls from CheckpointTransaction in Rust, you'll need to examine the transaction field which contains the original transaction data. For Move call interactions, focus on the Transaction::MoveCall variant within the transaction's command list. You can pattern match against the transaction type and then filter by package ID to identify specific interactions. The effects field may also contain relevant execution details about the Move calls. Remember to handle the Option wrapper properly when accessing nested transaction data.

To extract Move calls from CheckpointTransaction in Rust:

1. Access transaction.data – Contains the transaction details.
2. Match on TransactionKind – Filter for ProgrammableTransaction.
3. Iterate over commands – Look for MoveCall types.

Example Code Snippet:

if let TransactionKind::ProgrammableTransaction(pt) = &checkpoint_tx.transaction.data.kind {
    for cmd in &pt.commands {
        if let Command::MoveCall(move_call) = cmd {
            // Filter by package ID here
            println!("MoveCall: {:?}", move_call.package);
        }
    }
}

Key Steps:

• Check move_call.package to match your target package ID.
• The MoveCall struct contains module, function, and args.

(Ensure you’re using the correct SDK version—structs may vary slightly.)

You can extract Move calls from transactions in Rust using the Sui SDK by accessing the MoveCall events embedded within each CheckpointTransaction. The CheckpointTransaction struct itself doesn’t directly include Move call info, but you can derive it by deserializing the transaction inside it to inspect its commands.

Here's how you can do that:

First, use the Rust Sui SDK to fetch checkpoint data (e.g., via REST or gRPC), and then for each CheckpointTransaction:

let transaction = checkpoint_transaction.transaction;
if let sui_sdk_types::Transaction::ProgrammableTransaction(ptx) = transaction {
    for command in ptx.commands {
        if let sui_sdk_types::Command::MoveCall(move_call) = command {
            // You now have struct MoveCall with package, module, function, args
        }
    }
}

This lets you access the package ID and function name for each Move call in the programmable transaction. You can then filter transactions by the package you care about.

If the transaction is not a ProgrammableTransaction, it may be a system transaction (like Publish or Genesis) which uses a different format.

Additionally, if transactions emit events (inside checkpoint_transaction.events), you can parse those to confirm logic like function inputs or outcomes.

The Sui Rust SDK documentation and sui_sdk_types crate include full definitions for Transaction, ProgrammableTransaction, and Command::MoveCall—these are all you need to inspect the Move call structure without re-querying nodes. The types are described in the sui_sdk_types crate: ([docs.rs][1])