You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Refresh Hubble data dictionary against crypto-stellar
Reconcile the Hubble data catalog with the live crypto-stellar BigQuery
datasets and the current stellar-dbt-public models. BigQuery is treated as
authoritative for which columns exist and their types; the dbt docs blocks
are authoritative for descriptions.
Add six tables that were missing from the catalog:
- gold/account-balances-daily-agg (crypto_stellar_dbt.account_balances__daily_agg)
- gold/soroban-core-metrics (crypto_stellar_dbt.soroban_core_metrics)
- silver/config-settings-snapshot (crypto_stellar_dbt.config_settings_snapshot)
- silver/reflector-prices-data-{cex,fex,sdex}-snapshot (snapshots.*)
token_transfers is deliberately excluded: the model lives in
stellar-dbt-public but only materializes to hubble-261722.sdf_marts when the
internal project runs it as a package, so it is not public data.
Notable corrections:
- tvl_agg documented accounts_tvl_usd / total_tvl_usd as USD-denominated. The
real columns are accounts_tvl / total_tvl in raw token amounts, and the
asset dimensions and liquidity_pools_tvl were missing entirely. The page had
no dbt docs link, which is why the drift went unnoticed.
- history-effects carried a duplicate 157-line column table outside the styled
div, a leftover from the catalog reorg (#1785). The two copies disagreed on
a column name.
- details.authorized_to_maintain_liabilites is spelled without the second "i"
in the warehouse; the docs used the correct English spelling, which would
break queries.
- config_settings had three stale pre-rename rows (min_temp_entry_ttl,
min_persistent_entry_ttl, max_entries_to_ttl) whose current names were
already documented. Adds 27 Protocol 23/26 columns.
- claimable_balances_current is disabled in stellar-dbt-public and has not
been written since 2026-07-16; the page now says so.
Copy file name to clipboardExpand all lines: docs/data/analytics/hubble/data-catalog/data-dictionary/bronze/claimable-balances.mdx
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -42,5 +42,6 @@ description: ""
42
42
| batch_run_date | The start date for the batch interval. When taken with the date in the batch_id, the date represents the interval of ledgers processed. The batch run date can be seen as a proxy of closed_at for a ledger. | datetime || Yes | The table is partitioned on batch_run_date. It is recommended to always include the batch_run_date in the filter if possible to help reduce query cost. |
43
43
| batch_insert_ts | The timestamp in UTC when a batch of records was inserted into the database. This field can help identify if a batch executed in real time or as part of a backfill | timestamp || Yes ||
44
44
| asset_id | Unique identifier for asset_code, asset_issuer | integer || No ||
45
+
| balance_id_strkey | The StrKey (`B...`) representation of the claimable balance id. | string || No | Introduced alongside [CAP-38](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0038.md) style StrKey encodings. Prefer this over the raw hex `balance_id` when joining to Horizon or RPC responses. |
| batch_insert_ts | The timestamp in UTC when a batch of records was inserted into the database. This field can help identify if a batch executed in real time or as part of a backfill | timestamp || Yes ||
74
71
| closed_at | Timestamp in UTC when this ledger closed and committed to the network. Ledgers are expected to close ~every 5 seconds | timestamp || Yes ||
75
72
| ledger_sequence | The sequence number of this ledger. It represents the order of the ledger within the Stellar blockchain. Each ledger has a unique sequence number that increments with every new ledger, ensuring that ledgers are processed in the correct order. | integer || Yes ||
73
+
| ledger_max_disk_read_entries | Maximum number of ledger entries a single ledger may read from disk. | integer || No | Protocol 23 (CAP-62/63) successor to `ledger_max_read_ledger_entries`, which now covers in-memory state only. |
74
+
| ledger_max_disk_read_bytes | Maximum number of bytes a single ledger may read from disk. | integer || No | Protocol 23 (CAP-62/63) successor to `ledger_max_read_bytes`. |
75
+
| tx_max_disk_read_entries | Maximum number of ledger entries a single transaction may read from disk. | integer || No | Protocol 23 (CAP-62/63) successor to `tx_max_read_ledger_entries`. |
76
+
| tx_max_disk_read_bytes | Maximum number of bytes a single transaction may read from disk. | integer || No | Protocol 23 (CAP-62/63) successor to `tx_max_read_bytes`. |
77
+
| fee_disk_read_ledger_entry | Fee in stroops charged per ledger entry read from disk. | integer || No | Protocol 23 (CAP-62/63) successor to `fee_read_ledger_entry`. |
78
+
| fee_disk_read_1kb | Fee in stroops charged per 1KB read from disk. | integer || No | Protocol 23 (CAP-62/63) successor to `fee_read_1kb`. |
79
+
| fee_write_1kb | Fee in stroops charged per 1KB written to the live Soroban state. | integer || No | Protocol 23 rename of the bucket-list write fee. |
80
+
| soroban_state_target_size_bytes | Target size in bytes of the live Soroban state, used as the inflection point for rent fee growth. | integer || No | Protocol 23 successor to `bucket_list_target_size_bytes`. |
81
+
| rent_fee_1kb_soroban_state_size_low | Rent fee in stroops per 1KB when the live Soroban state is below the target size. | integer || No | Protocol 23 successor to `write_fee_1kb_bucket_list_low`. |
82
+
| rent_fee_1kb_soroban_state_size_high | Rent fee in stroops per 1KB when the live Soroban state is above the target size. | integer || No | Protocol 23 successor to `write_fee_1kb_bucket_list_high`. |
83
+
| soroban_state_rent_fee_growth_factor | Multiplier applied to the rent fee once the live Soroban state exceeds the target size. | integer || No | Protocol 23 successor to `bucket_list_write_fee_growth_factor`. |
84
+
| live_soroban_state_size_window_sample_size | Number of samples retained in the sliding window used to average the live Soroban state size. | integer || No | Protocol 23 successor to `bucket_list_size_window_sample_size`. |
85
+
| live_soroban_state_size_window_sample_period | Number of ledgers between samples of the live Soroban state size. | integer || No ||
86
+
| live_soroban_state_size_window | The sliding window of sampled live Soroban state sizes used to compute rent fees. | array[integer]|| No | Protocol 23 successor to `bucket_list_size_window`. Repeated field. |
87
+
| ledger_max_dependent_tx_clusters | Maximum number of dependent transaction clusters per ledger. | integer || No | Protocol 23 parallel compute setting. |
88
+
| tx_max_footprint_entries | Maximum number of footprint entries per transaction. | integer || No | Protocol 23 ledger cost extension. |
89
+
| ledger_target_close_time_milliseconds | Target ledger close time in milliseconds. | integer || No | Protocol 23 SCP timing setting. |
90
+
| nomination_timeout_initial_milliseconds | Initial SCP nomination timeout in milliseconds. | integer || No | Protocol 23 SCP timing setting. |
91
+
| nomination_timeout_increment_milliseconds | SCP nomination timeout increment in milliseconds. | integer || No | Protocol 23 SCP timing setting. |
92
+
| ballot_timeout_initial_milliseconds | Initial SCP ballot timeout in milliseconds. | integer || No | Protocol 23 SCP timing setting. |
93
+
| ballot_timeout_increment_milliseconds | SCP ballot timeout increment in milliseconds. | integer || No | Protocol 23 SCP timing setting. |
94
+
| frozen_ledger_keys | Array of base64-encoded ledger keys frozen by validator governance. | array[string]|| No | Protocol 26 ([CAP-77](https://github.com/stellar/stellar-protocol/blob/master/core/cap-0077.md)). Repeated field. |
95
+
| frozen_ledger_keys_to_freeze | Array of base64-encoded ledger keys to freeze in this delta update. | array[string]|| No | Protocol 26 (CAP-77). Repeated field. |
96
+
| frozen_ledger_keys_to_unfreeze | Array of base64-encoded ledger keys to unfreeze in this delta update. | array[string]|| No | Protocol 26 (CAP-77). Repeated field. |
97
+
| freeze_bypass_txs | Array of hex-encoded transaction hashes that bypass frozen key restrictions. | array[string]|| No | Protocol 26 (CAP-77). Repeated field. |
98
+
| freeze_bypass_txs_to_add | Array of hex-encoded transaction hashes to add to the freeze bypass list. | array[string]|| No | Protocol 26 (CAP-77). Repeated field. |
99
+
| freeze_bypass_txs_to_remove | Array of hex-encoded transaction hashes to remove from the freeze bypass list. | array[string]|| No | Protocol 26 (CAP-77). Repeated field. |
Copy file name to clipboardExpand all lines: docs/data/analytics/hubble/data-catalog/data-dictionary/bronze/contract-code.mdx
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -40,5 +40,6 @@ description: ""
40
40
| n_imports | Number of imports in contract code | integer ||||
41
41
| n_exports | Number of exports in contract code | integer ||||
42
42
| n_data_segment_bytes | Number of data segment bytes in contract code | integer ||||
43
+
| ledger_key_hash_base_64 | The base64-encoded representation of the ledger key hash for this contract code entry. | string || No | Same value as `ledger_key_hash`, encoded in base64 instead of hex. |
Copy file name to clipboardExpand all lines: docs/data/analytics/hubble/data-catalog/data-dictionary/bronze/contract-data.mdx
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -41,5 +41,6 @@ description: ""
41
41
| val | The encoded value associated with the key in the contract data. The encoded val has two components (type and value) where type describes the data type and the value describes the encoded value of the data type for the contract data | json ||||
42
42
| val_decoded | The human-readable or decoded version of the value. This provides a clear and understandable representation of the value, making it easier to interpret and use in analysis | json ||||
43
43
| contract_data_xdr | The XDR (External Data Representation) encoding of the contract data. XDR is a standard format used to serialize and deserialize data, ensuring interoperability across different systems. This field contains the raw, serialized contract data in XDR format | string ||||
44
+
| ledger_key_hash_base_64 | The base64-encoded representation of the ledger key hash for this contract data entry. | string || No | Same value as `ledger_key_hash`, encoded in base64 instead of hex. |
Copy file name to clipboardExpand all lines: docs/data/analytics/hubble/data-catalog/data-dictionary/bronze/evicted-keys.mdx
+1Lines changed: 1 addition & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,5 +23,6 @@ description: ""
23
23
| is_evicted | If true, the ledger key hash has been evicted | boolean ||
24
24
| closed_at | The UNIX timestamp of the sequence number's age | timestamp || Yes ||
25
25
| ledger_sequence | The sequence number of this ledger. It represents the order of the ledger within the Stellar blockchain. Each ledger has a unique sequence number that increments with every new ledger, ensuring that ledgers are processed in the correct order. | integer || Yes ||
26
+
| is_evicted | Status flag indicating whether an entry is evicted or not. `false` signifies the key has been restored. | boolean || Yes ||
Copy file name to clipboardExpand all lines: docs/data/analytics/hubble/data-catalog/data-dictionary/bronze/history-assets.mdx
+2-1Lines changed: 2 additions & 1 deletion
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -19,13 +19,14 @@ description: ""
19
19
20
20
| Name | Description | Data Type | Domain Values | Required? | Notes |
21
21
| --- | --- | --- | --- | --- | --- |
22
-
| id | Unique identifier for the asset code, type and issuer combination. This is not a primary key on the table | float || Yes | Deprecated |
23
22
| asset_id | Unique identifier for asset_code, asset_issuer | integer || No ||
24
23
| asset_type | The identifier for type of asset code, can be a alphanumeric with 4 characters, 12 characters or the native asset to the network, XLM. | string | <ul><li>credit_alphanum4</li><li>credit_alphanum12</li><li>native</li></ul> | Yes | XLM is the native asset to the network. XLM has no asset code or issuer representation and will instead be displayed with an asset type of 'native' |
25
24
| asset_code | The 4 or 12 character code representation of the asset on the network | string || No | Asset codes have no guarantees of uniqueness. The combination of asset code, issuer and type represents a distinct asset |
26
25
| asset_issuer | The account address of the original asset issuer that created the asset | string || No ||
27
26
| batch_id | String representation of the run id for a given DAG in Airflow. Takes the form of `scheduled__<batch_end_date>-<dag_alias>`. Batch ids are unique to the batch and help with monitoring and rerun capabilities | string || Yes ||
28
27
| batch_run_date | The start date for the batch interval. When taken with the date in the batch_id, the date represents the interval of ledgers processed. The batch run date can be seen as a proxy of closed_at for a ledger. | datetime || Yes | The table is partitioned on batch_run_date. It is recommended to always include the batch_run_date in the filter if possible to help reduce query cost. |
29
28
| batch_insert_ts | The timestamp in UTC when a batch of records was inserted into the database. This field can help identify if a batch executed in real time or as part of a backfill | timestamp || Yes ||
29
+
| ledger_sequence | The sequence number of the ledger in which this asset was first seen. | integer || Yes ||
30
+
| closed_at | Timestamp in UTC when the ledger in which this asset was first seen closed and committed to the network. Ledgers are expected to close ~every 5 seconds. | timestamp || Yes ||
0 commit comments