Algod Client

← Back to Examples Overview

Algorand node operations and queries using the AlgodClient.

Examples (19)

Example	Description
Node Health and Status	This example demonstrates how to check node health and status using the AlgodClient methods: health_check(), ready(), status(), and status_after_block(). Prerequisites:
Version and Genesis Information	This example demonstrates how to retrieve node version information and genesis configuration using the AlgodClient methods: versions() and genesis(). Prerequisites:
Ledger Supply Information	This example demonstrates how to retrieve ledger supply information using the AlgodClient method: supply(). Prerequisites:
Account Information	This example demonstrates how to retrieve comprehensive account information using the AlgodClient methods: account_information(), account_application_information(), and account_asset_information(). Prerequisites:
Transaction Parameters	This example demonstrates how to get suggested transaction parameters using suggested_params(). These parameters are essential for constructing valid transactions on the Algorand network. Prerequisites:
Send and Confirm Transaction	This example demonstrates how to send transactions and wait for confirmation using send_raw_transaction() and pending_transaction_information(). It shows the complete lifecycle of submitting a transaction to the Algorand network. Prerequisites:
Pending Transactions	This example demonstrates how to query pending transactions in the transaction pool using pending_transactions() and pending_transactions_by_address(). Pending transactions are those that have been submitted but not yet confirmed in a block. Prerequisites:
Block Data	This example demonstrates how to retrieve block information using the AlgodClient methods: block(), block_hash(), and block_tx_ids(). Prerequisites:
Asset Information	This example demonstrates how to retrieve asset information using the AlgodClient method: asset_by_id() Prerequisites:
Application Information	This example demonstrates how to retrieve application information using the AlgodClient method: application_by_id() Prerequisites:
Application Boxes	This example demonstrates how to query application boxes using the AlgodClient methods: application_boxes() and application_box_by_name() API Patterns: application_boxes(app_id) returns BoxesResponse with .boxes attribute (list of BoxDescriptor) application_box_by_name(app_id, box_name_bytes) returns Box with .name, .value, .round_ attributes BoxDescriptor.name is bytes (not base64) Box.name and Box.value are bytes (not base64) Box.round_ uses underscore to avoid Python reserved keyword Prerequisites:
TEAL Compile and Disassemble	This example demonstrates how to compile TEAL source code to bytecode and disassemble bytecode back to TEAL using the AlgodClient methods: teal_compile(source_bytes, sourcemap?) - Compile TEAL source to bytecode teal_disassemble(bytecode) - Disassemble bytecode back to TEAL Note: Python SDK takes bytes for teal_compile (use .encode()), while TypeScript takes string. CompileResponse uses attribute access with hash_ (underscore to avoid Python builtin). Prerequisites:
Transaction Simulation	This example demonstrates how to simulate transactions before submitting them to the Algorand network. Simulation allows you to: Preview transaction outcomes without committing to the blockchain Estimate transaction fees Detect potential errors before spending fees Debug smart contract execution Prerequisites:
Ledger State Deltas	This example demonstrates how to retrieve ledger state deltas using: ledger_state_delta(round) - Get state changes for a specific round ledger_state_delta_for_transaction_group(tx_id) - Get deltas for a specific transaction group transaction_group_ledger_state_deltas_for_round(round) - Get all transaction group deltas in a round State deltas show what changed in the ledger (accounts, balances, apps, assets) between rounds. Note: These endpoints may require node configuration to enable (EnableDeveloperAPI=true). Prerequisites:
Transaction Proof	This example demonstrates how to get transaction proofs using: transaction_proof(round, tx_id) - Get the Merkle proof for a transaction Transaction proofs are cryptographic proofs that a transaction is included in a specific block. They are used for light client verification, allowing clients to verify transaction inclusion without downloading the entire blockchain. The proof uses a Merkle tree structure where: Each transaction in a block is a leaf in the tree The root of the tree is committed in the block header The proof provides the sibling hashes needed to reconstruct the root Prerequisites:
Light Block Header Proof	This example demonstrates how to get light block header proofs using: light_block_header_proof(round) - Get the proof for a block header Light block header proofs are part of Algorand’s State Proof system, which allows light clients and other blockchains to verify Algorand’s blockchain state without needing to sync all blocks or trust intermediaries. Key concepts: State proofs are generated at regular intervals (every 256 rounds on MainNet) Light block header proofs verify that a block header is part of the state proof interval The proof uses a vector commitment tree (similar to Merkle tree) structure Only blocks within a state proof interval have available light block header proofs Prerequisites: Note: On LocalNet in dev mode, state proofs may not be generated, so this example demonstrates the API call and handles the expected errors gracefully.
State Proof	This example demonstrates how to get state proofs using: state_proof(round) - Get the state proof for a specific round State proofs are cryptographic proofs that attest to the state of the Algorand blockchain. They allow external systems (like bridges, light clients, and other blockchains) to verify Algorand’s blockchain state without trusting any intermediary. Key concepts: State proofs are generated at regular intervals (every 256 rounds on MainNet) Each state proof covers a range of block headers (the interval) State proofs are signed by a supermajority of online stake The proof uses post-quantum secure cryptographic techniques (Falcon signatures) Prerequisites: Note: On LocalNet in dev mode, state proofs are NOT generated because: 1. Dev mode doesn’t run real consensus 2. There are no real participation keys generating state proofs This example demonstrates the API call and handles the expected errors gracefully.
DevMode Timestamp Offset	This example demonstrates how to manage block timestamp offset in DevMode using: block_time_stamp_offset() - Get the current timestamp offset set_block_time_stamp_offset(offset) - Set a new timestamp offset In DevMode, you can control the timestamp of blocks by setting an offset. This is useful for testing time-dependent smart contracts without waiting for real time to pass. Key concepts: Timestamp offset is in seconds Setting offset to 0 resets to using the real clock New blocks will have timestamps = realTime + offset These endpoints only work on DevMode nodes (LocalNet in dev mode) Prerequisites: Note: These endpoints return HTTP 404 if not running on a DevMode node.
Sync Round Management	This example demonstrates how to manage the sync round using: sync_round() - Get the minimum sync round the ledger will cache set_sync_round(round) - Set the minimum sync round unset_sync_round() - Unset/reset the sync round What is the sync round? The sync round is a configuration that controls the minimum round the node will keep data for. When set, the node will: Only keep block data from this round onwards Allow old block data to be deleted/pruned Reduce storage requirements for archival data This is useful for: Nodes that only need recent data (not full archival history) Indexers that only need data from a specific point forward Applications that don’t need ancient historical data Key concepts: sync_round() returns GetSyncRoundResponse with round_ attribute set_sync_round(round) sets the minimum round to keep unset_sync_round() removes the sync round restriction Historical data below the sync round may be unavailable Prerequisites: Note: On some nodes, these endpoints may require admin privileges or return errors if the feature is not supported.

Quick Start

Run any example from the repository’s examples directory:

cd examples
uv run python algod_client/01_node_health_status.py