sui.core Table: fact_changes Type: Base Table
Fact table capturing all object state transitions on the Sui blockchain, including creation,
mutation, deletion, wrapping, and unwrapping of objects. Each record documents the full lifecycle of
Sui objects (NFTs, coins, packages, etc.) as they are manipulated by transactions. Includes object
IDs, versions, types, and ownership changes, enabling forensic analysis, compliance reporting, and
application behavior tracing. Supports lineage analysis by linking object changes to specific
transactions, epochs, and owners. Critical for understanding Sui’s object-centric data model and for
tracking resource flows, upgrades, and state mutations across the network.
Data Coverage: This table contains data from January 2025 - Present (6.43B rows). It
relies on the balance changes object returned from the RPC response, which is why historical
backfill is not available.
Columns
| Column Name | Data Type | Description |
|---|---|---|
| CHECKPOINT_NUMBER | NUMBER | The sequential number of the checkpoint in which this record was finalized on the Sui blockchain. Checkpoints are consensus milestones that bundle and finalize multiple transactions, providing the primary unit of finality and recovery in Sui. Starts at 0 (genesis checkpoint) and increments by one for each new checkpoint. Used for time series analysis, transaction ordering, and measuring network throughput. Once a transaction is included in a checkpoint, it is permanently recorded and cannot be reverted. This dataset only includes checkpoints greater than or equal to 96605300. Example: 96605301. |
| BLOCK_TIMESTAMP | TIMESTAMP_NTZ | The network-agreed timestamp (in milliseconds since Unix epoch) when the checkpoint containing this record was finalized by Sui consensus. Represents the authoritative time of transaction finality, as determined by validator signatures. Used for temporal analytics, trend analysis, and aligning on-chain activity with real-world time. Example: ‘2024-06-01 12:34:56.789’. |
| TX_DIGEST | TEXT | A 32-byte cryptographic hash (Base58-encoded) uniquely identifying the transaction’s contents and structure. Serves as the primary key for transaction lookup, integrity verification, and cross-model joins. Enables cryptographic proof of transaction inclusion and supports lineage tracing across all Sui analytics. Example: ‘6Qk8…9Xz’. |
| TX_KIND | TEXT | The type of transaction executed. Values include ‘Programmable Transaction Block’ (PTB) for user-submitted transactions (up to 1,024 commands) and ‘System Transaction’ for validator/network operations. Determines execution path, available operations, and analytics grouping. Example: ‘ProgrammableTransactionBlock’. |
| TX_SENDER | TEXT | The 32-byte Sui address (hex with 0x prefix) that initiated and signed the transaction. Identifies the account responsible for the transaction and gas payment. Used for user activity tracking, wallet analytics, and authorization analysis. Example: ‘0xabc123…’. |
| MESSAGE_VERSION | TEXT | The version of the transaction data structure, supporting protocol evolution and backward compatibility. Currently uses ‘TransactionDataV1’. Ensures analytics remain robust across protocol upgrades. Example: ‘1’. |
| TX_SUCCEEDED | BOOLEAN | Boolean flag indicating transaction execution outcome. true = success, false = error. Used for outcome analysis, error monitoring, and success rate tracking. Example: true. |
| CHANGE_INDEX | NUMBER | Zero-based sequential index ordering object state changes within a transaction. Ensures atomicity and correct ordering for analytics and lineage tracing. Example: 2. |
| TYPE | TEXT | Type/category of object state modification or event. Enum: created, modified, deleted, wrapped, unwrapped (for changes); event type string (for events). Used for lifecycle analysis and state transition tracking. Example: ‘created’. |
| SENDER | TEXT | Sui address (32-byte hex) representing the transaction or event sender. Used for authorization, security analysis, and user activity tracking. Example: ‘0xabc123…’. |
| DIGEST | TEXT | 32-byte cryptographic hash (hex) of object contents, using SHA-256. Used for content verification, integrity checking, and unauthorized modification detection. Example: ‘a1b2c3…’. |
| OBJECT_ID | TEXT | Globally unique 32-byte identifier for Sui objects. Hex string, primary key for object tracking, provenance, and asset history. Example: ‘0x1234abcd…’. |
| OBJECT_TYPE | TEXT | Move type signature governing the object’s structure and behavior. Format: {package}::{module}::{struct}<type_parameters>. Enables type-based classification and filtering. Example: 0x2::coin::Coin<0x2::sui::SUI>. |
| VERSION | NUMBER | 8-byte unsigned integer incremented with every object modification. Tracks mutation frequency and supports version-based conflict resolution. Initial value: 1. Example: 5. |
| PREVIOUS_VERSION | NUMBER | Version number immediately preceding the current object version. Enables historical state reconstruction and audit trails. Value: current_version - 1 (0 for initial creation). Example: 4. |
| OBJECT_OWNER | TEXT | Indicates how the object is owned and accessed. Types: Address-owned, Shared (consensus), Immutable (public), Object-owned. Determines access patterns and transaction requirements. Example: ‘Shared’. |
| ADDRESS_OWNER | TEXT | The 32-byte Sui address (hex with 0x prefix) that owns this object when it has address-based ownership. Address-owned objects are controlled by a specific account and can only be accessed by their owner, providing exclusive control and enabling efficient parallel processing since they don’t require consensus. Used for wallet analytics, ownership tracking, and transaction authorization analysis. When null, the object has a different ownership type (shared, immutable, or object-owned). Example: ‘0xabc123…’. |
| SHARED_OWNER | VARIANT | Variant data structure indicating this object has shared ownership, meaning it’s accessible to everyone on the network and requires consensus validation for modifications. Shared objects enable coordination between multiple addresses but incur higher transaction costs due to consensus requirements. Used for marketplaces, escrows, AMMs, and other multi-user scenarios. Contains metadata about the shared object’s initial version and access permissions. When null, the object has address-based, immutable, or object-based ownership. Example: {"initial_shared_version": 123}. |
| PACKAGE_ID | TEXT | Unique identifier (object ID) of the Move package containing the event module. Used for package-level analytics, deployment tracking, and contract lineage. Example: ‘0x2’. |
| MODULES | TEXT | Comma-separated list of Move module names contained within the package. Modules define the package’s functionality and can be called by transactions to execute smart contract logic. Each module has a unique name within its package and contains functions, structs, and resources. Used for analyzing package composition, tracking module usage patterns, and understanding smart contract functionality. Example: ‘coin,transfer,governance’. |
| FACT_CHANGES_ID | TEXT | Surrogate key for the object changes fact table. Generated unique identifier by combining transaction digest and change index, ensuring each object state transition is uniquely tracked. Supports object lifecycle analysis, state tracking, and forensic investigations. In Sui, this is essential for tracing the full history of NFTs, coins, and other on-chain objects, supporting compliance, provenance, and application behavior analytics. |
| INSERTED_TIMESTAMP | TIMESTAMP_NTZ | Timestamp when the record was inserted into the analytics database. System-generated by the ETL pipeline, typically in TIMESTAMP_NTZ format. Used for data lineage, ETL monitoring, and freshness checks. In Sui analytics, this field is essential for tracking data ingestion latency, validating pipeline health, and supporting incremental model builds. Example: ‘2024-06-01 12:34:56.789’. |
| MODIFIED_TIMESTAMP | TIMESTAMP_NTZ | Timestamp when the record was last modified in the analytics database. System-generated for change tracking, data versioning, and consistency verification. In Sui, this supports incremental processing, late-arriving data correction, and auditability of analytics workflows. Used to monitor data staleness and trigger downstream updates. Example: ‘2024-06-01 12:34:56.789’. |