Skip to main content
Schema: sui.core Table: fact_transaction_blocks Type: Base Table Fact table providing detailed metadata for every transaction block executed on the Sui blockchain. Includes transaction hash, sender, success status, gas usage, fee breakdowns, error codes, and dependency tracking. Serves as the primary source for transaction-level analytics, fee optimization, and network performance monitoring. Supports lineage tracing from transaction inputs to execution outcomes, including gas smashing, storage fee rebates, and error diagnostics. Critical for understanding Sui’s transaction model, user behavior, and application performance at scale.
Data Coverage: This table contains full historical coverage from April 2023 - Present (4.18B rows), covering all transaction blocks since the launch of Sui mainnet.

​
Columns

Column NameData TypeDescription
CHECKPOINT_NUMBERNUMBERThe 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_TIMESTAMPTIMESTAMP_NTZThe 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_DIGESTTEXTA 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_KINDTEXTThe 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_SENDERTEXTThe 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_VERSIONTEXTThe 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_FEEFLOATTotal gas fee paid for transaction execution, denominated in SUI tokens. Calculated as (computation_cost + storage_cost - storage_rebate) / 1e9. Used for economic modeling, fee optimization, and cost analysis. Example: 0.00123 (SUI).
TX_SUCCEEDEDBOOLEANBoolean flag indicating transaction execution outcome. true = success, false = error. Used for outcome analysis, error monitoring, and success rate tracking. Example: true.
TX_ERRORTEXTError message and code if the transaction failed. Human-readable string with error details for diagnostics, debugging, and error pattern analysis. Example: ‘MoveAbort: InsufficientBalance’.
TX_DEPENDENCIESVARIANTArray of transaction digests that this transaction depends on for object versions. Establishes transaction ordering and causality, supporting dependency analysis and complex flow tracing. Example: [‘6Qk8…9Xz’, ‘7Yl2…3Ab’].
GAS_USED_COMPUTATION_FEENUMBERTotal computation cost in MIST units (1 SUI = 1e9 MIST) for executing the transaction. Calculated as computation_units * gas_price. Used for analyzing transaction complexity and validator workload. Example: 1000000.
GAS_USED_NON_REFUNDABLE_STORAGE_FEENUMBERPortion of storage fees (in MIST) that cannot be reclaimed, ensuring storage fund sustainability. Calculated as storageunits * storageprice * 0.01. Used for economic modeling and storage fund analysis. Example: 10000.
GAS_USED_STORAGE_FEENUMBERTotal cost (in MIST) for storing data on-chain. Calculated as storage_units * storage_price. Users pay this upfront for perpetual storage. Used for storage analytics and cost modeling. Example: 500000.
GAS_USED_STORAGE_REBATENUMBERRefund amount (in MIST) when previously stored data is deleted. Calculated as original_storage_fee * 0.99. Incentivizes data cleanup and efficient storage usage. Example: 495000.
GAS_PRICENUMBERUser-submitted price per computation unit (in MIST). Structure: reference_gas_price + optional tip. Determines transaction priority and total cost. Used for fee market analysis and optimization. Example: 1000.
GAS_BUDGETNUMBERMaximum amount (in MIST) user is willing to pay for transaction execution. Protects users from excessive fees. Minimum: 2,000 MIST, Maximum: 50,000,000,000 MIST. Used for transaction planning and cost control. Example: 1000000.
GAS_OWNERTEXTSui address responsible for paying gas fees. Enables sponsored transactions (third-party gas payment). Used for payment model analytics and gasless UX studies. Example: ‘0xabc123…’.
FACT_TRANSACTION_BLOCKS_IDTEXTSurrogate key for the transaction blocks fact table. Generated unique identifier based on transaction digest, providing a one-to-one mapping to each transaction block. Enables efficient transaction-level analysis, performance monitoring, and lineage tracing from transaction inputs to execution outcomes. In Sui, this is critical for understanding transaction dependencies, gas usage, and execution results at scale.
INSERTED_TIMESTAMPTIMESTAMP_NTZTimestamp 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_TIMESTAMPTIMESTAMP_NTZTimestamp 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’.