Stacks

db_stacks

Bronze layer

The Bronze layer contains all the raw data. This data has not been transformed.

Cycles

tbl_prod_br_cycles

The tbl_prod_br_cycles table provides a structured overview of cycles within the Stacks blockchain, starting from the genesis of Stacks 2.0. Each cycle represents a fixed number of blocks, facilitating the organization and analysis of blockchain data over time. This table is essential for understanding the temporal division of blockchain activity and aids in analyzing trends, rewards distributions, and other cycle-based metrics.

Column Description
cycle The sequential number of the cycle, starting from 0. Each cycle represents a group of 2100 blocks within the Stacks blockchain.
start_block The starting block number for the given cycle. This marks the first block in the cycle.
end_block The ending block number for the given cycle. This marks the last block in the cycle.
start_date The start date for the given cycle. This marks the start of the cycle.
end_date The ending date for the given cycle. This marks the end of the cycle.

Blocks

tbl_prod_br_blocks The table archives block data for the Stacks blockchain, detailing block identification, sequencing, and associated Bitcoin blockchain references due to Stacks’ unique proof-of-burn consensus mechanism. It records block numbers, hashes, transaction counts, and the execution costs related to transactions, offering essential insights for analysis of network activity and transactional efficiency on the Stacks blockchain.

col_name data_type comment
canonical boolean Canonical Blocks are the building blocks that contribute to the continuous, unbroken chain of blocks in the blockchain, each linking to its predecessor, forming the indelible ledger that blockchain is celebrated for. You expect this to be true.
number bigint stacks block number
hash string A unique identifier for each block, generated by applying a cryptographic hash function to the block’s data
index_block_hash string The hash of the index block.
parent_block_hash string The hash of the parent block.
timestamp bigint Timestamp of relevant block. If you use to_timestamp(timestamp) SQL code, you will get the actual date-time.
burn_block_hash string Corresponding Bitcoin block number’s hash. The block that is written in Bitcoin block’s hash.
burn_block_height bigint Corresponding Bitcoin block number. The block that is written in a Bitcoin block.
miner_txid string Corresponding transaction burned on Bitcoin block for the stacks block. Every stacks block is a transaction on Bitcoin. And this is that tx’s id. If you remove the 0x from the beginning, you will get the Bitcoin tx id.
transaction_count bigint Count of each transaction in the relevant block.
execution_cost_read_count bigint Captures the number of independent reads performed on the underlying data store.
execution_cost_read_length bigint The number of bytes read from the underlying data store.
execution_cost_runtime bigint Captures the number of cycles that a single processor would require to process the Clarity block. This is a unitless metric, meant to provide a basis for comparison between different Clarity code blocks.
execution_cost_write_count bigint Captures the number of independent writes performed on the underlying data store (see SIP-004).
execution_cost_write_length bigint The number of bytes written to the underlying data store.

Transactions

tbl_prod_br_transactions The table is a comprehensive record of transactions on the Stacks blockchain. It includes transaction identifiers, sender information, execution costs, and status details. This table links transactions to blocks, tracks microblock inclusion, and categorizes transaction types, such as token transfers and smart contract executions. It’s a key resource for analyzing transactional data within the Stacks ecosystem.

col_name data_type comment
hash string Unique identifier for the transaction
nonce bigint Random number used in mining process
fee_rate string Fee rate for the transaction
sender_address string Address of the sender
sponsored boolean Boolean indicating if the transaction is sponsored
post_condition_mode string Mode for post-conditions
post_conditions array Array of post-conditions
anchor_mode string Mode for anchoring
is_unanchored boolean Boolean indicating if the transaction is unanchored
parent_block_hash string Hash of the parent block
block_hash string Hash of the block containing the transaction
block_number bigint Block number containing the transaction
block_timestamp bigint Unix timestamp of the block containing the transaction
parent_burn_block_time bigint Timestamp of the parent burn block
canonical boolean Boolean indicating if the block is canonical
tx_index bigint Index of the transaction within the block
tx_status string Status of the transaction
tx_result struct Result of the transaction
microblock_hash string Hash of the microblock containing the transaction
microblock_sequence bigint Sequence number of the microblock containing the transaction
microblock_canonical boolean Boolean indicating if the microblock is canonical (Field marked as ‘null’ suggests missing information or not applicable.)
event_count bigint Count of events (Field marked as ‘null’ suggests missing information or not applicable.)
events array Array of events (Field marked as ‘null’ suggests missing information or not applicable.)
execution_cost_read_count bigint Number of independent reads performed on the underlying data store (Field marked as ‘null’ suggests missing information or not applicable.)
execution_cost_read_length bigint Number of bytes read from the underlying data store (Field marked as ‘null’ suggests missing information or not applicable.)
execution_cost_runtime bigint Number of cycles for processing (Field marked as ‘null’ suggests missing information or not applicable.)
execution_cost_write_count bigint Number of independent writes performed on the underlying data store (Field marked as ‘null’ suggests missing information or not applicable.)
execution_cost_write_length bigint Number of bytes written to the underlying data store (Field marked as ‘null’ suggests missing information or not applicable.)
tx_type string Type of the transaction (Field marked as ‘null’ suggests missing information or not applicable.)
token_transfer struct Details of token transfer if applicable (Field marked as ‘null’ suggests missing information or not applicable.)
coinbase_payload struct Data for coinbase transactions (Field marked as ‘null’ suggests missing information or not applicable.)
smart_contract struct Details of the smart contract if applicable (Field marked as ‘null’ suggests missing information or not applicable.)
contract_call struct Details of the contract call if applicable (Field marked as ‘null’ suggests missing information or not applicable.)
poison_microblock map<string,string> Information on poisoned microblock if applicable (Field marked as ‘null’ suggests missing information or not applicable.)

Contracts

tbl_prod_br_contracts The table records details of smart contracts on the Stacks blockchain. It tracks the transaction hash (tx_hash), whether the contract is the main (canonical) version, the contract’s address, and the associated block number. Contract-specific data like Clarity language version (clarity_version), source code, and ABI (Application Binary Interface) are also stored. Additionally, flags indicate if the contract pertains to a STX20 token (is_stx20) or a non-fungible token (is_nft), offering insights into the contract’s purpose and functionality. This table is vital for developers and analysts interested in smart contract deployment and usage patterns on Stacks.

col_name data_type comment
tx_hash string Transaction hash of the contract. Try searching it in explorer.hiro.so
canonical boolean Canonical Blocks are the building blocks that contribute to the continuous, unbroken chain of blocks in the blockchain, each linking to its predecessor, forming the indelible ledger that blockchain is celebrated for. You expect this to be true.
address string Address of the contract.
block_number bigint In which block this contract recorded in.
clarity_version bigint Clarity version of the contract.
source_code string The source code of the contract.
abi string The ABI (Application Binary Interface) of the contract.
is_stx20 boolean Indicates whether the contract is a Stacks 2.0 token (STX20).
is_nft boolean Indicates whether the contract is a non-fungible token (NFT).

Silver layer

The Silver Layer in the Stacks ecosystem serves as a crucial intermediary layer that enriches raw blockchain data with meaningful metadata, facilitating deeper insights and analysis. This layer particularly focuses on metadata about all tokens compliant with the SIP010 standard, STX20 tokens and individual decentralized application (dApp) activities through smart contract interactions. Below are the details of the views included in the Silver Layer for Stacks, highlighting the comprehensive metadata and activity records.

Proof of Transfer

Proof of Transfer, or PoX, is a novel consensus mechanism implemented by the Stacks blockchain, which is built on top of Bitcoin. The mechanism allows participants to lock up (or “stack”) their STX tokens temporarily to support the network’s security and consensus. In return, stackers receive rewards in Bitcoin. This process is governed by the smart contract SP000000000000000000002Q6VF78.pox-3. Please see our extensive deep dive article on how this data is generated here.

POX3 Solo Stackers

tbl_prod_sl_pox3_stackers_solo Tracks various Proof of Transfer (PoX) and Stacking operations on the Stacks blockchain. It includes solo stacking transactions. The transactions are filtered to only include successful ones pertaining to the pox-3 smart contract and are related to solo stacking operations such as stack-stx, stack-extend, and stack-increase.

Field Name Description
hash The unique identifier of the transaction on the blockchain.
sender_address The Stacks wallet address of the sender initiating the transaction.
block_number The block number in which the transaction was included.
tx_date The timestamp of the block, converted to a human-readable date and time format.
btc_block_height The Bitcoin block height.
amount The amount of STX locked for stacking, normalized to STX units (converted from microSTX to STX with a decimal precision of 6), depending on the stacking operation.
btc_rewards_address_undecoded The Bitcoin address set to receive stacking rewards in it’s undecoded format
btc_rewards_address_version The Bitcoin address version. This is used to decode the Bitcoin address
btc_rewards_address_decoded The Bitcoin address set to receive stacking rewards, extracted and decoded from the function arguments.
function_name The name of the function called within the contract, indicating the type of stacking operation performed.
lock_period This represents the number of cycles the tokens are locked for stacking.
unlock_burn_height This represents the Bitcoin block number when the Stacked STX is unlocked
start_burn_height This is the Bitcoin block height at which the stacking period starts.
extend_cycle For stack-extend operations, this signifies the additional number of cycles for which an existing stack is extended.
start_cycle This signifies the start cycle the STX is locked in
end_cycle This signifies the end cycle the STX is locked in

POX3 Delegate Stackers

vw_prod_sl_pox3_stackers_delegates This dataset focuses on delegated stacking operations, capturing the delegation of STX tokens for stacking purposes. It tracks the delegation transactions, detailing the delegators, delegatees, and the amounts involved.

Field Name Description
hash The unique identifier of the transaction on the blockchain.
sender_address The Stacks wallet address of the sender initiating the transaction.
block_number The block number in which the transaction was included.
tx_date The timestamp of the block, converted to a human-readable date and time format.
function_name The name of the function called within the contract, indicating the type of stacking operation performed.
depending on the stacking operation.
btc_rewards_address_undecoded The Bitcoin address set to receive stacking rewards in it’s undecoded format
btc_rewards_address_version The Bitcoin address version. This is used to decode the Bitcoin address
btc_rewards_address_decoded The Bitcoin address set to receive stacking rewards, extracted and decoded from the function arguments.
start_burn_height This is the Bitcoin block height at which the stacking period starts.
unlock_burn_height This represents the Bitcoin block number when the Stacked STX is unlocked
lock_period This represents the number of cycles the tokens are locked for stacking.
amount The amount of STX locked for stacking, normalized to STX units (converted from microSTX to STX with a decimal precision of 6),
delegate_to The address to which the STX tokens are being delegated for stacking purposes.
start_cycle This signifies the start cycle the STX is locked in
unlock_cycle This signifies the end cycle the STX is locked in

POX3 Aggregate Stackers

vw_prod_sl_pox3_agg This dataset captures transactions pertaining to partial stacking commitments, allowing for an analysis of stacking operations that aggregate STX tokens from multiple sources. It provides insights into the delegation process, the amount of STX committed, and the intended reward cycles.

Field Name Description
hash The unique identifier of the transaction on the blockchain.
sender_address The Stacks wallet address of the sender initiating the transaction.
block_number The block number in which the transaction was included.
tx_date The timestamp of the block, converted to a human-readable date and time format.
function_name The name of the function called within the contract, indicating the type of stacking operation performed.
depending on the stacking operation.
btc_rewards_address_undecoded The Bitcoin address set to receive stacking rewards in it’s undecoded format
btc_rewards_address_version The Bitcoin address version. This is used to decode the Bitcoin address
btc_rewards_address_decoded The Bitcoin address set to receive stacking rewards, extracted and decoded from the function arguments.
amount The amount of STX locked for stacking, normalized to STX units (converted from microSTX to STX with a decimal precision of 6),
delegate_to The address to which the STX tokens are being delegated for stacking purposes.

dApps

Our platform offers a specialized transformation of transaction data to cater to decentralized applications (dApps), particularly those in the DeFi sector. By processing raw transaction data, we extract and refine critical metrics such as trading volumes from decentralized exchanges (DEXs), collateral details from lending platforms, and token activities related to liquid staking.

This data transformation allows users to effortlessly access DeFi-specific insights, supporting informed decisions in trading, lending, and staking within the ecosystem. Our goal is to streamline complex datasets into actionable intelligence for dApp users and developers.

General

These foundational tables are pivotal in enriching our suite of dApp-specific tables with essential data. They act as core sources that inform and enhance the utility of subsequent datasets, providing a robust bedrock for a more insightful aggregation of dApp activities.

SIP10 Tokens

tbl_test_sl_sip10_tokens Please note This table is still in test as we are still adding support for Symbol, Name and Circulating supply.

This view provides metadata about all tokens that comply with the SIP010 Fungible Token standard. This includes critical information such as the token address and its decimal precision, which is essential for accurately representing token quantities and facilitating token-related operations.

Column Description
address address of the SIP010 token
decimals the amount of decimals of the token
symbol the symbol of the token
name the name of the token

BNS

vw_prod_sl_bns The view retrieves successful transactions related to BNS (Bitcoin Name Service) domain names, such as preorders, registrations, transfers, renewals, and other updates. It aims to offer insights into the usage and activities around the Stacks domain name services.

Field Name Description
hash The unique identifier of the transaction on the blockchain.
sender_address The Stacks wallet address of the sender initiating the transaction.
block_number The block number in which the transaction was included.
tx_date The timestamp of the block, converted to a human-readable date and time format.
function_name The specific function called within the bns contract, indicating the type of domain name operation.
amount Conditionally shows the asset amount for name-preorder and the renewal fee for name-renewal.
name For name-register, name-transfer, and name-renewal, this is the domain name involved.
new_owner For name-transfer operations, this indicates the new owner’s address of the domain name.

DEXs

We aggregate and refine swap volume data from leading decentralized exchanges, specifically ALEX and Bitflow. By streamlining the collection of trade data through direct blockchain interactions, the Silver Layer presents a unified and enriched view of the cryptocurrency market’s liquidity and trading activity. This integration allows users to access detailed records of swap events, providing insights into trading pair performances, volume fluctuations, and liquidity provisions. Our users leverage this high-fidelity data for in-depth market analysis, deriving strategic intelligence essential for traders and financial analysts who demand the most current and comprehensive market snapshots.

ALEX

ALEX is a DeFi platform built on Bitcoin through Stacks smart contracts. It aims to activate the latent capital in Bitcoin wallets by providing a suite of DeFi services. These include participating in IDO rounds of Stacks projects, AMM DEX, liquidity provision, $ALEX staking, and yield farming.

tbl_prod_sl_dapp_alex_swap

The tbl_prod_sl_dapp_alex_swap table provides a comprehensive look into the smart contract activity of the ALEX dApp, showcasing token swaps. It includes transaction timestamps, block numbers, contract identifiers, and detailed function arguments, facilitating an in-depth analysis of dApp interactions on the Stacks blockchain.

Field Type Description
block_timestamp datetime Timestamp when the block was mined
block_number integer The block number in the blockchain
hash string The hash of the transaction
fee_rate integer The fee rate for the transaction
sender_address string The address of the sender in the transaction
events array A list of events associated with the transaction
contract_id string The identifier of the contract
function_name string The name of the function called in the transaction
function_args array The arguments passed to the function
tokenA string The identifier for token A in the swap
tokenB string The identifier for token B in the swap
tokenAOut integer The amount of token A output from the swap
tokenBIn integer The amount of token B input into the swap
tokenA_symbol string The symbol of token A
tokenB_symbol string The symbol of token B
tokenA_decimals integer The number of decimals for token A
tokenB_decimals integer The number of decimals for token B

Please note This table gets decimal places from tbl_prod_sl_sip10_tokens. and in the Gold layer will have volume statistics in STX and USD.

tbl_prod_sl_dapp_alex_prices

The tbl_prod_sl_dapp_alex_swap table provides an exchange rate for every pool on ALEX after every transaction.

Field Type Description
hash string Unique identifier of the transaction
sender_address string Address of the entity initiating the transaction
tx_date date Date of the transaction
tokenA string Identifier for the first token in the pair
tokenB string Identifier for the second token in the pair
tokenAPoolBalance integer Balance of tokenA in the liquidity pool
tokenBPoolBalance integer Balance of tokenB in the liquidity pool
exchangeRate decimal The exchange rate between tokenA and tokenB
contract_id string Identifier for the smart contract
function_name string Name of the function called in the transaction

Bitflow

vw_prod_sl_dapp_bitflow This dataset focuses on successful liquidity and swap event transactions. It covers add-liquidity, swap-x-for-y, swap-y-for-x, and withdraw-liquidity operations. Each record provides a transaction hash, the sender’s address, the block number, the date and time of the transaction (tx_date), an array of events (events), the function name indicating the operation (contract_call.function_name), and the function arguments (contract_call.function_args). The dataset also includes calculated fields for the amounts of token X and token Y involved in each transaction, with positive values typically representing token acquisitions and negative values indicating disbursements or deductions.

Field Name Description
hash The unique identifier of the transaction on the blockchain.
sender_address The Stacks wallet address of the sender initiating the transaction.
block_number The block number in which the transaction was included.
tx_date The timestamp of the block, formatted as a human-readable date and time.
events An array of events that were triggered by the transaction.
contract_call.function_name The name of the function called, indicating the type of operation (e.g., adding liquidity, swapping, etc.).
contract_call.function_args The arguments provided to the function call within the contract.
tokenY Represents the identifier or amount of token Y involved, extracted from the first function argument.
tokenX_amount (conditional) The calculated amount of token X involved in the operation, depending on the function name.
tokenY_amount (conditional) The calculated amount of token Y involved in the operation, depending on the function name.

Liquid Staking (Stacking) Tokens (LST)

Liquid staking tokens are innovative financial instruments in the DeFi ecosystem, allowing participants to stake cryptocurrencies and receive tokenized derivatives in return. These derivatives represent the staked assets, offering liquidity and enabling holders to engage in additional DeFi activities without unbonding their original stakes.

Key Features:

  • Liquidity: Users can access their staked value for use in other DeFi protocols.
  • Yield Optimization: Allows earning on staked assets while engaging in other yield-generating activities.
  • Flexibility and Security: Facilitates diverse investment strategies and mitigates certain risks associated with direct staking.

Use Cases:

  • Used in yield farming, as collateral for loans, and for trading to speculate or hedge positions.

Risks:

  • Involves smart contract risks, potential liquidity issues, and regulatory uncertainties.

Liquid staking tokens enhance capital efficiency in the blockchain realm, making staked assets work harder for the holder. They represent a key development towards making DeFi more accessible and versatile, though participants should be mindful of inherent risks.

StackingDAO stSTX

vw_dev_sl_dapp_stacking_dao This dataset includes successful transaction records for staking-related operations (deposit, withdraw, init-withdraw, add-rewards) on the Stacks blockchain. Each record in the dataset includes the transaction hash, sender address, block number, and a human-readable transaction date. It also details the events triggered, the specific function called within the staking contract, and the arguments provided to the function call. The dataset captures the amount involved in the transactions and, for certain operations, the NFT number and cycle number related to the transaction.

Field Name Description
hash The unique identifier of the transaction on the blockchain.
sender_address The Stacks wallet address of the sender initiating the transaction.
block_number The block number in which the transaction was included.
tx_date The timestamp of the block, converted to a human-readable date and time format.
events An array of events triggered by the transaction.
contract_call.function_name The specific function called within the staking contract.
contract_call.function_args The arguments provided to the function call within the contract.
tx_result The result of the transaction execution, containing details about the success or failure of the operation.
tx_status The status of the transaction, indicating whether it was successful.
amount (conditional) The token amount involved in the deposit, init-withdraw, withdraw, or add-rewards operations, based on the function name.
nft_number (conditional) The NFT number associated with the init-withdraw and withdraw operations.
cycle (conditional) For add-rewards operations, this field indicates the cycle number for which rewards are being added.

Bridges

vw_dev_sl_bridge_abtc

This dataset captures successful transaction events for ABTC. The dataset includes transactions for transfer, mint-fixed, and burn-fixed operations. Each record details the transaction hash, sender address, block number, timestamp of the block, the events array, the name of the function called in the contract (function_name), and the arguments passed to the function (function_args). Additionally, it extracts the amount for transfer, burn-fixed, and mint-fixed functions, and the recipient for transfer function.

Field Name Description
hash The unique identifier of the transaction on the blockchain.
sender_address The Stacks wallet address of the sender initiating the transaction.
block_number The block number in which the transaction was included.
to_timestamp(block_timestamp) The timestamp of the block, converted to a human-readable date and time format.
events An array of events triggered by the transaction.
contract_call.function_name The specific function called within the contract, indicating the type of token operation performed.
contract_call.function_args The arguments provided to the function call within the contract.
amount (conditional) The token amount involved in the transfer, mint-fixed, or burn-fixed operations, extracted from the function arguments.
recipient (conditional) For transfer operations, the address of the recipient of the tokens, extracted from the function arguments.

MetaTokens

Metatokens, including standards like BRC20, STX20, and Ordinals, are protocols for representing a variety of digital assets on blockchain networks. These standards are pivotal for creating tokens that are fungible or non-fungible, depending on the use case, and ensure interoperability across different applications and services within the blockchain ecosystem.

These metatokens facilitate the digital representation of a wide array of assets—ranging from currencies, utility tokens, and governance tokens, to unique assets like collectibles or digital art. They define a common set of rules that the tokens must adhere to, which typically includes functions for transferring tokens, inquiring balances of addresses, and granting permission for one address to transfer tokens on behalf of another. This common framework allows for the consistent development of wallets, exchanges, decentralized applications, and even complex financial instruments, fostering an environment where digital assets can be easily created, managed, and exchanged.

vw_dev_sl_stx20

The vw_dev_sl_stx20 view captures transactions involving STX20 tokens, including minting, deploying, and transferring operations. It includes transaction identifiers, participant addresses, transaction dates, and operation types, among other details. This view is vital for tracking STX20 token movements and understanding their supply dynamics.

Column Description
hash Unique identifier for a transaction (varchar)
sender_address Address of the sender (varchar)
fee_rate Transaction fee rate (varchar)
recipient_address Address of the recipient (varchar)
stx_paid Amount of STX paid (varchar)
date Date of the transaction (date)
memo_text Text of the memo field (varchar)
STX_operation Type of operation (mint, deploy, or transfer) (enum)
stx20_ticker Ticker symbol for the token (varchar)
amount Amount of tokens (varchar)
total_supply Total supply of tokens (varchar)
limit_per_mint Limit per mint operation (varchar)

Gold Layer

This is the layer where the data is it’s most manageable. The data in this layer gives you answers to specific questions you have about Stacks.

Proof of Transfer

tbl_prod_gld_pox3_stackers_all

This table joins all Stacking STX transactions with all BTC reward transactions.

It unions the following data sources:

  • Stack STX via the Bitcoin chain
  • BTC rewards for Stacking STX
  • Stack STX via the Stacks chain
  • Delegate STX via the Stacks chain

Stack STX via the Bitcoin chain

It is possible to initiate stacking from the Bitcoin chain. We identify these transactions via the X2 magic code for Bitcoin transactions.

BTC rewards for Stacking STX

To get the rewards we identify every transaction as it flows to the Stacking address. This follows the following path: Stacks Miner commits BTC in a transaction -> Track the Input of the Committed BTC -> Report on the output from the Input.

For example if a Stacks miner commits 3 values of 1,2 and 5 BTC in one Bitcoin transaction, we will report all three commits separately as rewards. This is to ensure that we have a full audit trail of the supply chain of the BTC from Miners to Stackers.

Stack STX via the Stacks chain

Due to the way the POX3 contract was designed, getting the cycles for the stack-extend and stack-increase involves a bit of complexity. Stack extend extends an existing stack-stx transaction, so we get the cycle from the stack-extend transactions by looking at the original stack-stx transaction and it’s lock cycle and then adding 1. For example if Stacker A stacked 120k STX for 5 cycles starting on cycle 60, then that will be reported as 120k STX cycle 60 and lock period of 5. But if that is then extended by 2 cycles, there will be another record returned with 120k STX for cycle 66 and a lock period of 2.

For stack-increase we use the block height of the transaction to determine the cycle the STX will be locked in.

Delegate STX via the Stacks chain

The delegate-stx and delegate-stack-stx functions in PoX3 both deal with the delegation of STX tokens for Stacking, but they serve different purposes and operate in distinct contexts.

delegate-stx The delegate-stx function is used to delegate the authority to lock STX for Stacking to another address (a delegate). When a user calls delegate-stx, they specify how much STX they want to delegate, the delegate’s address, an optional burn height at which the delegation expires, and an optional PoX address where the rewards should be sent. This function does not lock STX tokens itself but grants the specified delegate the permission to lock the user’s STX tokens on their behalf.

Key points about delegate-stx:

  • It sets up a delegation relationship allowing the delegate to later initiate Stacking on behalf of the delegator.
  • It can specify a PoX address for rewards and an expiration for the delegation. It is useful for users who wish to participate in Stacking indirectly through a service or pool.

delegate-stack-stx The delegate-stack-stx function is utilized by the delegate (an address given permission via delegate-stx) to actually lock the delegated STX tokens for Stacking. This function is called after delegate-stx and is the step where the STX tokens are actually committed to Stacking. When calling delegate-stack-stx, the delegate specifies the amount of STX to lock, the PoX address for rewards, the start burn height, and the lock period (number of reward cycles).

Key points about delegate-stack-stx:

  • It is used by a delegate to lock STX tokens for Stacking on behalf of a delegator.
  • It requires prior setup via delegate-stx.
  • It initiates the actual Stacking process using the delegated STX tokens.
  • In summary, delegate-stx is about setting up the delegation relationship and granting permission, while delegate-stack-stx is about the delegate taking action to lock the delegated STX for Stacking. The former is preparatory, and the latter is the execution step in the delegation process for participating in Stacking

Please note If you want a true figure for Stacking, you’ll need to exclude delegate-stx as they are committed but not finalized. We include them in this table here for completeness and an audit trail for users who are looking to debug their delegations.

tbl_prod_gld_pox3_stackers_solo_cycles

Each record in the table represents a unique stacking event by an individual stacker. The table records encompass a broad range of information, from basic transaction details to specific stacking parameters, such as the lock period and eligible cycles for rewards.

Field Name Description
hash Unique hash of the stacking transaction.
sender_address Cryptocurrency address of the stacker.
block_number Block number where the transaction was recorded.
tx_date Date and time when the transaction was processed.
btc_block_height Bitcoin block height at the time of the transaction.
amount Amount of cryptocurrency stacked.
btc_reward_address_decoded Decoded Bitcoin address for reward eligibility.
function_name Name of the smart contract function invoked.
lock_period Number of cycles the funds are locked for stacking.
start_burn_height Starting burn block height for stacking.
extend_cycle Indicator for extending the lock period.
start_cycle First eligible cycle for rewards.
end_cycle Last eligible cycle for rewards.