## Queries
- balance: Returns the balances for a given account, chain, and module combination.

This query calculates and returns the user's balance for each specified combination
of **account**, **chain ID**, and **module**. For example, it can return how much
balance the account `k:9492...5c17` holds on **chain 1** within the **coin** module.
- block: Retrieve detailed information about a specific block using its unique hash.

Every block in the Kadena blockchain is identified by a cryptographic hash — a unique fingerprint generated from its contents.
This query allows you to look up a block directly by that hash, returning all available details about it, such as its height, creation time, transactions, miner, and more.

This is especially useful when you already know the block’s hash (for example, from a transaction receipt or an event log) and want to quickly inspect or verify that block’s contents without scanning the entire chain.
- blocksFromDepth: Retrieves blocks based on their **depth** in the Kadena blockchain.

In Kadena, each new block extends the chain by one unit, and the term **depth** refers to how far a block is from the current chain tip (the most recent block).
- A block with a depth of `0` is the latest block (the chain head).
- A block with a depth of `1` is one block behind the tip, and so on.

Because new blocks can occasionally be reorganized near the tip, specifying a **minimumDepth** helps ensure that only blocks that are deep enough — and therefore finalized and stable — are returned.
For example, a `minimumDepth` of `20` means only blocks that are at least 20 blocks behind the current tip will be included in the results, reducing the chance of including blocks that might later be replaced due to a chain reorganization.

Use this query to fetch finalized blocks across one or more chains.
- blocksFromHeight: Retrieve blocks from one or more chains based on their block height range.

In Kadena, **height** represents a block’s sequential position within its chain, starting at 0 for the genesis block and increasing by 1 for each new block.
This query lets you fetch blocks by specifying a starting height (`startHeight`) and, optionally, an ending height (`endHeight`).
It is particularly useful when you want to retrieve a continuous range of blocks — for example, when backfilling data, syncing from a specific point in the chain, or analyzing block activity over a known range.

If `endHeight` is omitted, the query returns all blocks from the starting height up to the current chain tip.
- completedBlockHeights: Retrieve a list of **completed block heights** across one or more chains, starting from a given point.

In Kadena’s braided multi-chain architecture, a **block height** is considered *completed* only when **all chains** have successfully produced a block at that height.
Since each chain progresses independently, some chains may temporarily lag behind others. This query ensures that only *globally finalized* heights — where every specified chain has reached that block height — are returned.

This is particularly useful for building indexers, explorers, and analytics tools that require consistent cross-chain data.
You can specify how many completed heights to return with `heightCount`.
- events: Retrieve blockchain events with powerful filtering options.

In Kadena, events are emitted by smart contracts when specific actions occur (e.g., `coin.TRANSFER`).
You can filter by event name, module, chain, block, transaction, height range, or minimum depth,
and even by JSON parameters using Prisma-compatible JSON object property filters (stringified).
- fungibleAccount: Retrieve details of a specific fungible account (such as a KDA coin account) by its name and fungible type.

In Kadena, a fungible account represents a balance-holding entity for a given fungible token module (e.g., `coin`, which isthe native KDA token).
This query lets you look up that account’s information by providing its full `accountName` and the name of the fungible module.
It is commonly used to fetch the balance and metadata for a user or contract address.
- fungibleAccountsByPublicKey: Retrieve all fungible accounts associated with a given public key.

In Kadena, a single public key can control multiple accounts — for example, one on each chain, or accounts tied to
different contracts or modules. This query returns all `FungibleAccount` objects linked to the provided public key
for a specified fungible token (default: `coin`).

This is particularly useful when you want to discover all accounts controlled by a user key across the Kadena network,
including balances and activity for each.
- fungibleChainAccount: Retrieve details of a specific fungible account on a specific chain.

In Kadena’s multi-chain architecture, an account can exist on multiple chains simultaneously, each maintaining
its own balance and transaction history. This query lets you retrieve the state of a single `FungibleChainAccount`
by specifying the account name, the chain ID, and the fungible token module (default: `coin`).

It’s particularly useful when you need precise, chain-level information — such as a user’s balance or transfer
activity — without aggregating data across all chains.
- fungibleChainAccounts: Retrieve fungible account details across multiple chains.

In Kadena’s multi-chain architecture, an account can exist on several chains simultaneously — each maintaining its own
balance, guard, and activity history. This query allows you to retrieve all `FungibleChainAccount` objects for a given
account name and fungible token (default: `coin`) across one or more specified chains in a single request.

It’s especially useful when you want a comprehensive view of how an account is distributed across multiple chains,
including balances and per-chain transaction or transfer histories.
- fungibleChainAccountsByPublicKey: Retrieve all fungible chain accounts associated with a given public key on a specific chain.

In Kadena, a single public key can control multiple accounts on the same chain — for example,
accounts created by different contracts or modules. This query returns all `FungibleChainAccount`
objects linked to the provided public key for a specified fungible token (default: `coin`) on the given chain.

It’s especially useful when you want to discover all accounts controlled by a user key on a particular chain,
including their balances, guards, and per-chain transaction history.
- gasLimitEstimate: Estimate the gas limit required to execute one or more transactions on the Kadena blockchain.

This query accepts one or more JSON-encoded transaction inputs and analyzes them to calculate
the expected gas usage. It automatically infers the transaction type based on the fields provided
and returns the estimated gas limit for each input.
If any transaction is invalid or cannot be parsed, the query will throw an error.

Supported input types and required fields:

- `full-transaction`: A fully signed transaction object.
  Required: `cmd`, `hash`, `sigs`

- `stringified-command`: A JSON-stringified command.
  Required: `cmd` (optional: `sigs`)

- `full-command`: A complete command object.
  Required: `payload`, `meta`, `signers`

- `partial-command`: A partially defined command.
  Required: `payload` and either `meta` or `signers`
  (optional: `chainId` if `signers` is provided without `meta`)

- `payload`: Only the payload of a command.
  Required: `payload`, `chainId`

- `code`: Pact execution code.
  Required: `code`, `chainId`

All input types optionally accept `networkId` to override the default network configured in the environment.

<pre style="font-size: 0.85em;"><code class="language-graphql">
query {
  gasLimitEstimate(
    input: [
      "{
        \"code\": \"(coin.details \\\"k:1234\\\")\",
        \"chainId\": \"3\"
      }"
    ]
  ) {
    amount
    inputType
  }
}
</code></pre>
- graphConfiguration: Retrieve general information about this GraphQL API endpoint.
It is commonly used to check how far back the indexer’s data goes and to verify the API version your application is interacting with.
- lastBlockHeight: Get the height of the block with the highest height.
- networkInfo: Retrieve comprehensive information about the Kadena network.

This query returns a `NetworkInfo` object containing key metrics and configuration details
about the current state of the network.

Developers typically use this query to monitor network health, verify node synchronization,
analyze performance metrics, or display high-level blockchain data in explorers and dashboards.
- node: Retrieve a single object in the graph by its globally unique identifier.

All major entities in this API implement the `Node` interface, which ensures that each one
has a unique `id` field. This query allows you to fetch any of those entities directly
using that global ID, regardless of its specific type (e.g., `Block`, `Transaction`, `FungibleAccount`).
- nodes: Retrieve multiple objects in the graph by their globally unique identifiers.

Like the `node` query, this query returns any entities that implement the `Node` interface,
but allows you to request several objects in a single call by passing a list of IDs.
It’s useful when resolving multiple references at once — for example, when reconstructing
relationships between entities or populating a list by ID.
- nonFungibleAccount: Retrieve details of a specific non-fungible account by its name.

A non-fungible account represents the ownership and activity of unique tokens (NFTs) on the Kadena blockchain.
Unlike fungible accounts that track divisible token balances, non-fungible accounts hold individual, distinct tokens
and their associated metadata.

This query lets you look up a specific account and retrieve information such as its NFT balances, per-chain details,
and historical transaction and transfer activity. It is commonly used in NFT explorers, wallets, or analytics tools
to inspect an account’s non-fungible holdings and interactions.
- nonFungibleChainAccount: Retrieve details of a specific non-fungible account on a specific chain.

This query returns a `NonFungibleChainAccount`, which represents an account’s NFT holdings and activity
**restricted to a single chain** within the Kadena network. Because Kadena operates as a multi-chain blockchain,
NFT balances, transactions, and transfers are tracked separately on each chain.

Use this query when you need precise, chain-level data about a particular account — for example, when building
an NFT explorer or wallet feature that shows a user’s holdings and interactions on a specific chain.
- pactQuery: Execute arbitrary Pact code via a local call without requiring gas estimation or signature verification.

The `pactQuery` query allows you to run read-only Pact code directly against the Kadena blockchain,
such as arithmetic expressions or contract read functions (e.g., `(coin.get-details "<account>")`).
It does **not** create a transaction or modify chain state — it simply executes the code locally and
returns the result.

This is ideal for use cases like:
- Retrieving token or account details without submitting a transaction.
- Running lightweight Pact expressions or view functions.
- Building dashboards or explorers that query contract state in real time.

Multiple queries can be sent in a single request by providing an array of `PactQuery` objects.
- transaction: Retrieve a specific transaction by its request key, with optional additional filters.

While a `requestKey` uniquely identifies a transaction at the Pact level, the same request key
can appear in **multiple blocks** due to chain reorganization or orphaned blocks. Because of this,
retrieving a transaction by `requestKey` alone may return more than one match over the chain’s history.

To disambiguate results, you can provide the `blockHash` parameter.
- A specific `requestKey` combined with a `blockHash` will always return **at most one transaction**, since that pair is unique.
- Among those combinations, **only one transaction will belong to a canonical block** (i.e., part of the main chain).
- All other matches (with the same `requestKey` but different `blockHash` values) represent transactions included in **orphaned blocks** — blocks that were mined but later discarded due to chain reorganization.

The `minimumDepth` parameter can also be used to limit results to transactions in blocks that are at least a certain depth from the chain tip, helping ensure finality.

This query is typically used when you need to verify the canonical inclusion of a transaction or inspect all occurrences of a given request key across the chain’s history.
- transactions: Retrieve a paginated list of transactions with flexible filtering options.

This query allows you to search and explore transactions on the Kadena blockchain based on
a wide range of parameters — including account involvement, block location, chain, request key,
height range, and coinbase status. It is commonly used by block explorers, wallets, and analytics tools
to inspect on-chain activity and trace transaction history.

You can combine multiple filters to refine results. For example:
- Filter by `accountName` to find transactions sent from or received by a specific account.
- Use `blockHash` to retrieve all transactions included in a particular block.
- Combine `chainId`, `minHeight`, and `maxHeight` to query transactions over a block range on a specific chain.
- Provide a `requestKey` to search for a particular transaction.
- Set `isCoinbase` to `true` to return only mining reward transactions.
- Use `minimumDepth` to ensure results include only transactions in finalized blocks.
- transactionsByPublicKey: Retrieve a paginated list of transactions associated with a specific public key.

This query returns all transactions that involve accounts controlled by the given `publicKey`.
Because a single public key can control multiple accounts — including accounts on different chains
or created by contracts — this query is a convenient way to fetch all related transactions
without needing to know each account name individually.

It is commonly used by wallets, explorers, and analytics tools to display a user’s complete
on-chain activity, track transactions linked to a particular key, or audit key usage across the network.
- transactionsByPactCode: Retrieve a paginated list of transactions that executed a specific Pact code.

This query allows you to search for transactions based on the exact Pact code they executed.
It’s particularly useful when you want to trace all interactions with a specific contract function,
audit how and when a certain piece of code was used on-chain, or analyze usage patterns of a given module.

Because the match is performed on the full Pact code string, results will only include transactions
where the executed code exactly matches the provided `pactCode`. This query is commonly used by block explorers,
indexers, and analytics tools to track contract usage and behavior over time.
- transfers: Retrieve a paginated list of token transfers with flexible filtering options.

This query returns on-chain transfer events — movements of tokens from one account to another —
and supports filtering by block, transaction, account, chain, token type, and more.
It is commonly used by explorers, wallets, and analytics tools to display account activity,
track token movements, and analyze on-chain transfers.

Transfers can represent either **fungible tokens** (like `coin` for KDA) or **non-fungible tokens (NFTs)**,
depending on the `isNFT` flag.

You can combine multiple filters to narrow down results. For example:
- Filter by `accountName` to retrieve all incoming and outgoing transfers for a specific account.
- Use `blockHash` to get all transfers included in a particular block.
- Combine `chainId` and `fungibleName` to target transfers of a specific token on a specific chain.
- Provide a `requestKey` to return transfers associated with a specific transaction.
- Set `isNFT: true` to return only NFT transfers.

⚠️ **Important:** `fungibleName` **cannot** be used when `isNFT` is set to `true`. NFT transfers do not belong to a fungible token module, so this parameter must be omitted in that case.
- tokens: Retrieve a paginated list of all tokens deployed on the Kadena network, excluding the native `coin` token.

This query returns both fungible tokens and non-fungible token contracts (currently limited to `marmalade` and `marmalade-v2`),
providing basic metadata such as the token’s name, deployment chain, and contract address.

It is commonly used by explorers, indexers, and dApps to discover tokens deployed on-chain, list available assets,
or build token selection interfaces. The results are network-wide and not limited to a specific module or account.
- pools: Retrieve a paginated list of liquidity pools with sorting and optional protocol filtering.

This query returns AMM pools (currently sourced from a single protocol used by the Sushi team)
including reserves, TVL (USD), volume, fees, APR, and recent activity metrics.
Prices for TVL/volume/fees are computed using DIA data (https://api.diadata.org) refreshed
approximately every 5 minutes.

Use `orderBy` to sort by TVL, 24h/7d volume, 24h APR, or 24h transaction count (ASC/DESC),
and `protocolAddress` to limit results to a specific protocol/module name on Kadena.
Results support cursor-based pagination.
- pool: Retrieve a specific liquidity pool by its unique ID.

This query returns detailed information about a single AMM liquidity pool, including its reserves,
paired tokens, TVL, trading volume, APR, and recent performance metrics.
It’s commonly used by explorers, dashboards, and analytics tools to power individual pool detail views.

You can optionally provide a `timeFrame` to shape the data returned in metrics and charts, and a `type`
to filter transactions by category (e.g., swaps, adds, removes).

⚠️ **Note:** While `first`, `after`, `last`, and `before` arguments are accepted for API consistency,
they are **not used** by the internal resolvers of this query. Pagination of pool transactions is handled
by the parent pool resolver, not directly here.
- poolTransactions: Retrieve a paginated list of transactions for a specific liquidity pool.

This query returns all on-chain transactions related to a given AMM pool, such as swaps, liquidity additions,
and removals. It is most often used by explorers, analytics dashboards, and dApps to display pool activity,
analyze trading behavior, or calculate historical metrics.

You must provide the `pairId` (the unique pool identifier), and you can optionally filter by `type`
to restrict results to a specific category of transactions.
- liquidityPositions: Retrieve a paginated list of a user's liquidity positions across all supported pools.

This query returns all active liquidity positions associated with a given Kadena account (`walletAddress`),
including the amount of liquidity provided, its USD value, and the 24h APR for each position.
Each position also includes the underlying pool details for deeper insights.

It is commonly used by wallets, dashboards, and DeFi analytics tools to show a user's liquidity distribution,
portfolio value, and performance metrics across supported AMM protocols (currently limited to the Sushi-integrated DEX).
- dexMetrics: Retrieve key metrics for the decentralized exchange (DEX), including total value locked (TVL),
trading volume, and pool count, with optional historical data.

This query aggregates protocol-level statistics across all pools under a supported DEX
(currently limited to the Sushi-integrated deployment) and is commonly used by dashboards,
explorers, and analytics tools to visualize network-wide DeFi activity.

If `startDate` and `endDate` are not provided, the query defaults to a 30-day historical range.
Use `protocolAddress` to filter metrics for a specific DEX module on Kadena.

Returned data includes the current TVL, total pool count, total volume over the selected period,
and historical time series data for both TVL and volume.
- lastTokenPriceInKda: Retrieve the latest price of a specific token denominated in KDA.

This query returns the most recent known price of a given token relative to Kadena’s native token (`KDA`),
based on aggregated on-chain data and pricing information from supported sources.
- tokenPrice: Retrieve the latest price information for a specific token.

This query behaves like `tokenPrices` but returns the price data for a single token instead of a list.
It includes the token's price in both KDA and USD, the protocol where the price was sourced,
and the timestamp of the latest update.

Use this when you only need pricing information for a single token rather than fetching the full list.
- tokenPrices: Retrieve the latest price information for all tokens available in a specific protocol.

This query returns a list of `TokenPrice` objects, each containing the current price of a token
in both KDA and USD, along with metadata about the protocol and the timestamp of the most recent update.

It is commonly used by explorers, analytics dashboards, and DEX frontends to power price feeds,
portfolio valuations, and liquidity analytics.

You can optionally specify a `protocolAddress` to restrict the results to a particular DEX module.
If omitted, the default supported protocol (currently Sushi) is used.
## Subscriptions
- newBlocks: Subscribe to new blocks as they are produced on the Kadena network.

This subscription streams newly mined blocks in real time, allowing clients to react immediately
to chain updates without repeatedly polling the API. It is commonly used by explorers, indexers,
and event-driven applications that need to stay in sync with the latest state of the blockchain.

You can optionally filter the subscription by specific `chainIds` to receive blocks only from selected chains.
If omitted, blocks from all chains are included.
The `quantity` parameter controls how many of the most recent blocks are returned initially
when the subscription starts (default: 20).

After the initial batch, new blocks are pushed to the client as they are finalized.
- transaction: Subscribe to a transaction and receive an event when it is included in a block and indexed.

This subscription lets clients listen for a specific transaction by its `requestKey` and be notified
as soon as that transaction is mined, confirmed, and available in the indexer.
It is typically used by wallets, explorers, and dApps to update the transaction status in real time
without polling the API.

You can optionally specify a `chainId` to narrow the search to a single chain.
If omitted, the subscription will look for the transaction across all chains.

⚠️ **Note:** The event is emitted **only once** — when the transaction leaves the mempool and becomes part
of a block that has been indexed.
- transactions: Subscribe to transactions as they are confirmed on the Kadena network.

This subscription streams newly confirmed transactions in real time, allowing clients to react immediately
to network activity without polling. It is typically used by explorers, indexers, monitoring tools,
and analytics platforms to track transaction flow and update UIs as new data arrives.

By default, the subscription delivers transactions that have reached the minimum required confirmation depth,
ensuring they are finalized and indexed before being emitted.

The `quantity` parameter controls how many of the most recent transactions are included in the initial payload
when the subscription starts (default: 20). After the initial batch, new transactions are pushed to the client
as they are confirmed.
- events: Subscribe to on-chain events by their fully qualified name (e.g., `coin.TRANSFER`).

Streams matching events in real time once their containing blocks meet the required confirmation depth.
Useful for explorers, wallets, indexers, and analytics apps.

`parametersFilter` must be a stringified JSON using Prisma JSON property filter syntax.
Example:
  events(
    qualifiedEventName: "coin.TRANSFER",
    parametersFilter: "{\"array_starts_with\": \"k:abcdefg\"}"
  )

`quantity` controls the size of the initial payload (default: 20); new events are pushed thereafter.
- newBlocksFromDepth: Subscribe to new blocks starting from a specific minimum depth.

This subscription behaves like `newBlocks` but only emits blocks that have reached
a specified confirmation depth, ensuring they are finalized and stable before being delivered.
It is commonly used by indexers, explorers, and analytics tools that require deeper chain
finality guarantees rather than reacting to blocks as soon as they are mined.
## Directives
- complexity: Directive for specifying field complexity in the GraphQL schema.
The complexity is calculated as: value × (multiplier1_value × multiplier2_value × ...)
- include: Directs the executor to include this field or fragment only when the `if` argument is true.
- skip: Directs the executor to skip this field or fragment when the `if` argument is true.
- deprecated: Marks an element of a GraphQL schema as no longer supported.
- specifiedBy: Exposes a URL that specifies the behavior of this scalar.
- oneOf: Indicates exactly one field must be supplied and this field must not be `null`.
## Unions
- TransactionPayload: The payload of a transaction.
- TransactionInfo: The result of a transaction.
## Scalars
- BigInt: The `BigInt` scalar type represents non-fractional signed whole numeric values.
- DateTime: A date-time string at UTC, such as 2007-12-03T10:15:30Z, compliant with the `date-time` format outlined in section 5.6 of the RFC 3339 profile of the ISO 8601 standard for representation of dates and times using the Gregorian calendar.
- Decimal: Floats that will have a value of 0 or more.
- String: The `String` scalar type represents textual data, represented as UTF-8 character sequences. The String type is most often used by GraphQL to represent free-form human-readable text.
- Int: The `Int` scalar type represents non-fractional signed whole numeric values. Int can represent values between -(2^31) and 2^31 - 1.
- Boolean: The `Boolean` scalar type represents `true` or `false`.
- ID: The `ID` scalar type represents a unique identifier, often used to refetch an object or as key for a cache. The ID type appears in a JSON response as a String; however, it is not intended to be human-readable. When expected as an input type, any string (such as `"4"`) or integer (such as `4`) input value will be accepted as an ID.
- Float: The `Float` scalar type represents signed double-precision fractional values as specified by [IEEE 754](https://en.wikipedia.org/wiki/IEEE_floating_point).
## Interfaces
- Node: A globally identifiable object in the GraphQL schema.

All core entities in this API implement the `Node` interface, which guarantees that they have
a unique `id` field, enabling consistent caching, pagination, and reference resolution across the API.
- IGuard: A guard. This is a union of all the different types of guards that can be used in a pact.
## Enums
- TimeFrame: Time frame for chart data
- PoolOrderBy: Sort options for pools
- PoolTransactionType: Transaction type for pool events
- LiquidityPositionOrderBy: Sort options for liquidity positions
## Objects
- ChartDataPoint: A single time-series data point used in historical charts.

Each data point represents the value of a given metric (such as TVL or trading volume)
at a specific moment in time.
- PoolCharts: Chart data for a pool
- QueryTransactionsByPactCodeConnection: undefined
- QueryTransactionsByPactCodeConnectionEdge: undefined
- TransactionSummary: A lightweight summary of a transaction returned by the `transactionsByPactCode` query.

`TransactionSummary` provides essential metadata and execution details about transactions
that executed a specific Pact code, without the full payload of a `Transaction` object.
It is optimized for querying large sets of transactions efficiently when detailed fields
(like signatures, events, or full results) are not needed.

Each summary includes fundamental information such as the transaction’s request key, block height,
chain, gas usage, sender, and canonical status, as well as the original Pact code if available.
- QueryBalanceConnection: Connection type for balance query results.
- QueryBalanceConnectionEdge: undefined
- BalanceNode: A representation of a balance in the Kadena blockchain.
- FungibleAccount: Represents an account associated with a specific fungible token on the Kadena blockchain.

A `FungibleAccount` tracks the balance and activity of a single account (such as a user key account or contract)
for a given fungible token module (for example, `coin` for KDA).
Because Kadena is a multi-chain network, a fungible account may have balances distributed across multiple chains.
This type exposes both the aggregated balance and per-chain details, along with historical transactions and transfers.
- FungibleAccountTransactionsConnection: undefined
- FungibleAccountTransactionsConnectionEdge: undefined
- FungibleAccountTransfersConnection: undefined
- FungibleAccountTransfersConnectionEdge: undefined
- QueryCompletedBlockHeightsConnection: undefined
- QueryCompletedBlockHeightsConnectionEdge: undefined
- NonFungibleTokenBalance: Represents the balance of a specific non-fungible token (NFT) for a given account on a specific chain.

Each `NonFungibleTokenBalance` entry links an account, a unique token identifier, and its associated metadata.
Unlike fungible balances, which represent divisible amounts, non-fungible balances typically indicate
ownership of unique tokens — usually `0` (not owned) or `1` (owned) per token ID.

This type is useful for exploring which NFTs an account holds, retrieving metadata about those tokens,
and inspecting the chain and guard conditions associated with them.
- NonFungibleToken: The `NonFungibleToken` type provides key properties of a specific NFT, including its total supply,
decimal precision, and a reference URI containing extended metadata such as name, image, description,
or external resources. This type is typically returned as part of a `NonFungibleTokenBalance` object.
- QueryTransactionsByPublicKeyConnection: undefined
- QueryTransactionsByPublicKeyConnectionEdge: undefined
- QueryEventsConnection: undefined
- QueryEventsConnectionEdge: undefined
- QueryBlocksFromHeightConnection: undefined
- QueryBlocksFromHeightConnectionEdge: undefined
- QueryBlocksFromDepthConnection: undefined
- QueryBlocksFromDepthConnectionEdge: undefined
- QueryTransactionsConnection: undefined
- QueryTransactionsConnectionEdge: undefined
- QueryTransfersConnection: undefined
- QueryTransfersConnectionEdge: undefined
- Block: A **Block** is the fundamental unit of the Kadena blockchain.
Each block bundles a verified set of transactions and metadata that secure and extend the chain.
Blocks are linked together cryptographically — each one referencing its parent — forming the immutable and tamper-evident chain structure.
This type exposes all the core properties of a block, including consensus data (like difficulty, nonce, and proof of work), network metadata (like chain ID and epoch), and relations to transactions, events, and neighboring blocks.
- BlockNeighbor: The neighbor of a block.
- BlockEventsConnection: undefined
- BlockEventsConnectionEdge: undefined
- PageInfo: Pagination metadata returned alongside paginated query results.

`PageInfo` provides information about the current page of results and whether
there are more items available before or after the current set. It is used
in all connection-based queries to enable efficient cursor-based pagination.

You can use `startCursor` and `endCursor` as the `before` and `after` arguments
in subsequent queries to fetch previous or next pages of data.
- Event: Represents an event emitted during the execution of a smart contract function.

Events are structured outputs generated by Pact code when certain actions occur on-chain —
such as token transfers, mints, burns, or other contract-specific behaviors. They are commonly
used by explorers, indexers, wallets, and analytics tools to track contract activity, monitor
state changes, and trigger off-chain processes.

Each event is associated with a specific block, transaction, and request key, and includes
metadata like its qualified name (`moduleName.eventName`), parameters, and position within the transaction.
- FungibleChainAccount: Represents a fungible account **on a specific chain** in the Kadena blockchain.

While a `FungibleAccount` aggregates balances and activity across all chains, a `FungibleChainAccount`
focuses on a single chain. It exposes the account’s balance, security guard, and full transaction
and transfer history specific to that chain and fungible token (e.g., `coin` for KDA).

This type is useful when you need fine-grained, chain-level data — such as for explorers,
wallets, or analytics tools that track balances and movements per chain.
- FungibleChainAccountTransactionsConnection: undefined
- FungibleChainAccountTransactionsConnectionEdge: undefined
- BlockTransactionsConnection: undefined
- BlockTransactionsConnectionEdge: undefined
- Transaction: Represents a transaction executed on the Kadena blockchain.

A `Transaction` encapsulates the full structure and outcome of a blockchain transaction —
from the original signed command to the resulting execution details.
Each transaction is uniquely identified by its `hash` and includes the submitted command (`cmd`),
associated signatures (`sigs`), and the execution result (`result`).

This type is fundamental for querying and analyzing blockchain activity, tracking execution outcomes,
and verifying signed payloads.
- TransactionCommand: Represents the full command structure of a transaction on the Kadena blockchain.

A `TransactionCommand` defines all the inputs required to construct and execute
a Pact transaction, including metadata, payload, signers, and supporting information.
It reflects the exact structure submitted to the blockchain for validation and execution.
- TransactionMeta: Execution metadata that defines how a transaction is processed on the Kadena blockchain.

`TransactionMeta` contains contextual information that influences transaction execution,
such as which chain it runs on, how long it remains valid, its gas configuration, and
when it was created. This data is included in every `TransactionCommand` and is critical
for determining how the transaction is validated and scheduled by the network.
- TransactionSignature: List of capabilities associated with/installed by this signer.
- ContinuationPayload: The payload of an cont transaction.
- ExecutionPayload: The payload of an exec transaction.
- TransactionMempoolInfo: The mempool information.
- TransactionResult: The result of a transaction.
- TransactionResultEventsConnection: undefined
- TransactionResultEventsConnectionEdge: undefined
- TransactionResultTransfersConnection: undefined
- TransactionResultTransfersConnectionEdge: undefined
- Signer: A signer for a specific transaction.
- TransactionCapability: List of capabilities associated with/installed by this signer.
- FungibleChainAccountTransfersConnection: undefined
- FungibleChainAccountTransfersConnectionEdge: undefined
- Transfer: A transfer of funds from a fungible between two accounts.
- GraphConfiguration: General information about the GraphQL API.
- NetworkInfo: Detailed information about the current Kadena network and its state.

The `NetworkInfo` type provides an overview of the network’s operational and consensus metrics,
including circulation supply, hash rate, difficulty, transaction count, and chain topology details.
It’s commonly used by explorers, monitoring tools, and analytics dashboards to understand the
state, performance, and configuration of the Kadena blockchain network.
- CountersOfEachChain: undefined
- GenesisHeight: undefined
- PactQueryResponse: The result of executing a Pact query via a local call.

Each `PactQueryResponse` corresponds to one `PactQuery` input and contains
the execution result, status, and any error message returned by the Pact interpreter.
- GasLimitEstimation: Represents the gas estimation result for a single transaction input.
Includes the estimated gas amount and metadata about how the estimation was performed.
- NonFungibleAccount: Represents an account associated with non-fungible tokens (NFTs) on the Kadena blockchain.

A `NonFungibleAccount` tracks the ownership and activity of a specific account for non-fungible tokens.
Unlike fungible accounts, which hold divisible token balances, non-fungible accounts are associated
with unique tokens and their metadata. Because Kadena operates as a multi-chain network, a single
account may hold NFTs across multiple chains.

This type exposes account-level NFT balances, per-chain details, and historical transaction and transfer data.
- NonFungibleAccountTransactionsConnection: undefined
- NonFungibleAccountTransactionsConnectionEdge: undefined
- NonFungibleChainAccountTransactionsConnection: undefined
- NonFungibleAccountTransfersConnection: undefined
- NonFungibleAccountTransfersConnectionEdge: undefined
- NonFungibleChainAccountTransactionsConnectionEdge: undefined
- NonFungibleChainAccount: Represents a non-fungible (NFT) account **on a specific chain** in the Kadena network.

While `NonFungibleAccount` aggregates NFT holdings and activity across all chains for an account,
`NonFungibleChainAccount` focuses on a single chain. It exposes the account’s per-chain NFT balances
and its transaction/transfer history limited to that chain. This is useful for explorers, wallets,
and analytics tools that need precise, chain-level NFT data.
- NonFungibleChainAccountTransfersConnection: undefined
- NonFungibleChainAccountTransfersConnectionEdge: undefined
- KeysetGuard: A keyset guard.
- UserGuard: undefined
- RawGuard: DEPRECATED: a fallthrough IGuard type to cover non-KeysetGuard types.
- QueryTokensConnection: undefined
- QueryTokensEdge: undefined
- Token: undefined
- Pool: Represents an automated market maker (AMM) liquidity pool for a pair of tokens.

A `Pool` tracks on-chain reserves, liquidity (LP) supply, pricing-derived metrics (TVL, volume, fees),
and short-term performance indicators (24h / 7d deltas). Prices used to compute TVL/volume/fees
are sourced from DIA and refreshed periodically. Use this type to power pool lists, detail pages,
analytics dashboards, and historical charts.

Note: Numeric reserve and supply values are returned as strings to preserve precision.
- QueryPoolsConnection: undefined
- QueryPoolsConnectionEdge: undefined
- PoolTransaction: A swap transaction in a pool
- PoolTransactionsConnection: Connection type for pool transactions
- PoolTransactionEdge: Edge type for pool transactions
- LiquidityBalance: undefined
- LiquidityPosition: Represents a user's liquidity position within a specific AMM pool.

A `LiquidityPosition` tracks how much liquidity a given account has supplied to a pool,
along with its current USD value, 24-hour APR, and metadata about the associated pool.
It is typically used by wallets, dashboards, and DeFi analytics tools to display portfolio holdings,
yield performance, and pool-specific details for a user's positions.
- LiquidityPositionsConnection: undefined
- LiquidityPositionEdge: undefined
- DexMetrics: Aggregated performance metrics for a decentralized exchange (DEX).

`DexMetrics` provides a snapshot and historical overview of network-wide DeFi activity,
including total liquidity (TVL), trading volume, and the number of active pools.
It is designed for powering dashboards, analytics views, and protocol-level insights.

All USD-denominated values (TVL, volume) are calculated using price data from DIA,
and historical data is shaped by the time range specified in the query (defaults to 30 days if none is provided).
- TokenPrice: Represents the latest known price information for a specific token.

`TokenPrice` provides the current valuation of a token in both KDA (the Kadena native token)
and USD, along with metadata about the protocol where the token is traded and the timestamp
of the most recent price update.
## Inputs
- PactQuery: Represents a single Pact query to be executed on a specific chain.
- PactQueryData: undefined