|
1 | 1 | --- |
2 | 2 | title: Claimable Balances |
3 | 3 | sidebar_position: 20 |
| 4 | +description: "" |
4 | 5 | --- |
5 | 6 |
|
6 | | -| Name | Description | Data Type | Domain Values | Primary Key? | Natural Key? | Partition or Cluster Field? | Required? | Notes | |
7 | | -| --- | --- | --- | --- | --- | --- | --- | --- | --- | |
8 | | -| balance_id | A unique identifier for this claimable balance. The Balance id is a compilation of \`Balance Type\` + \`SHA-256 hash history_operation_id\` | string | | | Yes | | Yes | The Balance Type is fixed at V0, \`00000000\`. If there is a protocol change that materially impacts the mechanics of claimable balances, the balance type would update to V1. | |
9 | | -| claimants | The list of entries which are eligible to claim the balance and preconditions that must be fulfilled to claim | array[record] | | | | | Yes | Multiple accounts can be specified in the claimants record, including the account of the balance creator. | |
10 | | -| claimants.destination | The account id who can claim the balance | string | | | | | Yes | | |
11 | | -| claimants.predicate | The condition which must be satisfied so the destination can claim the balance. The predicate can include logical rules using AND, OR and NOT logic. | array[record] | | | | | Yes | | |
12 | | -| claimants.predicate.unconditional | If true it means this clause of the condition is always satisfied | boolean | | | | | No | When the predicate is only unconditional = true, it means that the balance can be claimed under any conditions | |
13 | | -| claimants.predicate.abs_before | Deadline for when the balance must be claimed. If a balance is claimed before the date then the clause of the condition is satisfied. | string | | | | | No | | |
14 | | -| claimants.predicate.rel_before | A relative deadline for when the claimable balance can be claimed. The value represents the number of seconds since the close time of the ledger which created the claimable balance | integer | | | | | No | This condition is useful when creating a timebounds based on creation conditions. If the creator wanted a balance only claimable one week after creation, this condition would satisfy that rule. | |
15 | | -| claimants.predicate.abs_before_epoch | A UNIX epoch value in seconds representing the same deadline date as abs_before. | integer | | | | | No | | |
16 | | -| 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 | credit_alphanum4 credit_alphanum12 native | | | | Yes | | |
17 | | -| asset_code | The 4 or 12 character code representation of the asset on the network | string | | | | | No | | |
18 | | -| asset_issuer | The address of the account that created the asset | string | | | | | No | | |
19 | | -| asset_amount | The amount of the asset that can be claimed | float | | | | | Yes | | |
20 | | -| sponsor | The account address of the sponsor who is paying the reserves for this claimable balance | string | | | | | No | Sponsors of claimable balances are the creators of the balance. | |
21 | | -| flags | Denotes the enabling and disabling of certain balance issuer privileges | integer | 0 - None, Default 1 - Auth Clawback Enabled | | | | Yes | Flags are set by the claimable balance accounts for an asset. When user accounts claim a balance, the flags applied to the asset originate from this account | |
22 | | -| last_modified_ledger | The ledger sequence number when the ledger entry (this unique signer for the account) was modified. Deletions do not count as a modification and will report the prior modification sequence number | integer | | | Yes | cluster | Yes | | |
23 | | -| ledger_entry_change | Code that describes the ledger entry change type that was applied to the ledger entry. | integer | 0 - Ledger Entry Created 1 - Ledger Entry Updated 2 - Ledger Entry Deleted 3 - Ledger Entry State (value of the entry) | | Yes | | Yes | Valid entry change types are 0, and 2 for ledger entries of type \`claimable_balances\`. Once created, a balance cannot be updated. | |
24 | | -| deleted | Indicates whether the ledger entry (balance id) has been deleted or not. Once an entry is deleted, it cannot be recovered. | boolean | | | | | Yes | | |
25 | | -| 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 | | |
26 | | -| 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 | | | | MONTH partition | 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. | |
27 | | -| 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 | | |
28 | | -| asset_id | Unique identifier for asset_code, asset_issuer | integer | | | | cluster | No | | |
| 7 | +<div className="scoped-data-dictionary-table"> |
| 8 | + |
| 9 | +## Table Metadata |
| 10 | + |
| 11 | +| Property | Configuration | |
| 12 | +| --- | --- | |
| 13 | +| Natural Key(s) | balance_id, closed_at | |
| 14 | +| Partition Field(s) | batch_run_date (MONTH partition) | |
| 15 | +| Clustered Field(s) | asset_id, last_modified_ledger | |
| 16 | +| Documentation | [dbt docs](http://www.stellar-dbt-docs.com/#!/source/source.stellar_dbt_public.crypto_stellar.claimable_balances) | |
| 17 | + |
| 18 | +## Column Details |
| 19 | + |
| 20 | +| Name | Description | Data Type | Domain Values | Required? | Notes | |
| 21 | +| --- | --- | --- | --- | --- | --- | |
| 22 | +| balance_id | A unique identifier for this claimable balance. The Balance id is a compilation of `Balance Type` + `SHA-256 hash history_operation_id` | string | | Yes | The Balance Type is fixed at V0, `00000000`. If there is a protocol change that materially impacts the mechanics of claimable balances, the balance type would update to V1. | |
| 23 | +| claimants | The list of entries which are eligible to claim the balance and preconditions that must be fulfilled to claim | array[record] | | Yes | Multiple accounts can be specified in the claimants record, including the account of the balance creator. | |
| 24 | +| claimants.destination | The account id who can claim the balance | string | | Yes | | |
| 25 | +| claimants.predicate | The condition which must be satisfied so the destination can claim the balance. The predicate can include logical rules using AND, OR and NOT logic. | array[record] | | Yes | | |
| 26 | +| claimants.predicate.unconditional | If true it means this clause of the condition is always satisfied | boolean | | No | When the predicate is only unconditional = true, it means that the balance can be claimed under any conditions | |
| 27 | +| claimants.predicate.abs_before | Deadline for when the balance must be claimed. If a balance is claimed before the date then the clause of the condition is satisfied. | string | | No | | |
| 28 | +| claimants.predicate.rel_before | A relative deadline for when the claimable balance can be claimed. The value represents the number of seconds since the close time of the ledger which created the claimable balance | integer | | No | This condition is useful when creating a timebounds based on creation conditions. If the creator wanted a balance only claimable one week after creation, this condition would satisfy that rule. | |
| 29 | +| claimants.predicate.abs_before_epoch | A UNIX epoch value in seconds representing the same deadline date as abs_before. | integer | | No | | |
| 30 | +| asset_type | The identifier for type of asset code, can be an 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 | | |
| 31 | +| asset_code | The 4 or 12 character code representation of the asset on the network | string | | No | | |
| 32 | +| asset_issuer | The address of the account that created the asset | string | | No | | |
| 33 | +| asset_amount | The amount of the asset that can be claimed | float | | Yes | | |
| 34 | +| sponsor | The account address of the sponsor who is paying the reserves for this claimable balance | string | | No | Sponsors of claimable balances are the creators of the balance. | |
| 35 | +| flags | Denotes the enabling and disabling of certain balance issuer privileges | integer | <ul><li>0 - None, Default</li><li>1 - Auth Clawback Enabled</li></ul> | Yes | Flags are set by the claimable balance accounts for an asset. When user accounts claim a balance, the flags applied to the asset originate from this account | |
| 36 | +| last_modified_ledger | The ledger sequence number when the ledger entry (this unique signer for the account) was modified. Deletions do not count as a modification and will report the prior modification sequence number | integer | | Yes | | |
| 37 | +| ledger_entry_change | Code that describes the ledger entry change type that was applied to the ledger entry. | integer | <ul><li>0 - Ledger Entry Created</li><li>1 - Ledger Entry Updated</li><li>2 - Ledger Entry Deleted</li><li>3 - Ledger Entry State (value of the entry)</li></ul> | Yes | Valid entry change types are 0, and 2 for ledger entries of type `claimable_balances`. Once created, a balance cannot be updated. | |
| 38 | +| deleted | Indicates whether the ledger entry (balance id) has been deleted or not. Once an entry is deleted, it cannot be recovered. | boolean | | Yes | | |
| 39 | +| closed_at | Timestamp in UTC when this ledger closed and committed to the network. Ledgers are expected to close ~every 5 seconds | timestamp | | Yes | | |
| 40 | +| 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 | | |
| 41 | +| 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 | | |
| 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 | +| 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 | +| asset_id | Unique identifier for asset_code, asset_issuer | integer | | No | | |
| 45 | + |
| 46 | +</div> |
0 commit comments