Core Concepts

The Algorand Virtual Machine (AVM)

The AVM is the execution environment for smart contracts on Algorand. It's a stack-based virtual machine that runs TEAL (Transaction Execution Approval Language) bytecode.

Key characteristics:

• Deterministic - Same inputs always produce same outputs
• Stateful - Contracts can store persistent data on-chain
• Resource-limited - Execution has opcode budget limits
• Secure - Sandboxed execution environment

Smart Contracts

Algorand smart contracts (also called "applications" or "apps") are programs that run on the blockchain. Each contract consists of two programs:

• Approval Program - Contains the main contract logic. Executes when the contract is called.
• Clear State Program - Executes when a user opts out of the contract. Usually minimal logic.

State Storage

Smart contracts can store data in several locations:

Global State

Persistent storage that belongs to the contract itself. Accessible by anyone calling the contract.

1// Global state - stored in the contract
2count = GlobalState<uint64>({ initialValue: 0 })
3owner = GlobalState<Address>()

• Maximum 64 key-value pairs
• Keys up to 64 bytes, values up to 128 bytes
• Persists for the lifetime of the contract

Local State

Per-user storage. Each account that opts into the contract gets their own local state.

1// Local state - stored per user
2balance = LocalState<uint64>({ key: 'balance' })
3lastAction = LocalState<uint64>({ key: 'last' })

• Maximum 16 key-value pairs per user
• User must opt-in to use local state
• Cleared when user opts out

Box Storage

Flexible storage for larger data. Pay-per-use model based on size.

1// Box storage - flexible size
2userProfiles = BoxMap<Address, UserProfile>({ prefix: 'p' })
3config = Box<ConfigData>({ key: 'config' })

• Each box can be up to 32KB
• Minimum balance requirement based on size
• Great for variable-length data

Transactions

All interactions with smart contracts happen through transactions. Key transaction types:

• Application Call - Call a smart contract method
• Payment - Transfer ALGO between accounts
• Asset Transfer - Transfer ASAs (Algorand Standard Assets)
• Asset Config - Create or configure assets

Atomic Transactions

Algorand supports grouping up to 16 transactions atomically. Either all succeed or all fail.

1// Example: Swap requires atomic group
2// Transaction 1: User sends payment
3// Transaction 2: Contract sends asset
4// Both must succeed or both fail

ABI (Application Binary Interface)

The ABI defines how to interact with a smart contract. It specifies:

• Method names and signatures
• Parameter types and names
• Return types
• State schema (global/local storage)

When you build a contract, AVM Studio generates a {Contract}.arc56.json file containing the full ABI specification.

Opcode Budget

Every contract execution has a limited "opcode budget" - the maximum computational work allowed. Current limits:

• 700 opcodes base budget per transaction
• Pooled budget for grouped transactions (shared across the group)
• Inner transactions add 700 opcodes each to the pool

Inner Transactions

Smart contracts can create and submit transactions from within their execution. This enables:

• Sending payments from the contract
• Creating and transferring assets
• Calling other contracts

1// Send payment from contract
2sendPayment({
3  receiver: userAddress,
4  amount: 1_000_000  // 1 ALGO (in microALGOs)
5})

Minimum Balance Requirement

Accounts on Algorand must maintain a minimum balance to cover storage costs:

• 0.1 ALGO - Base account minimum
• 0.1 ALGO - Per ASA opted into
• 0.1 ALGO - Per app opted into
• Variable - Based on global/local state and box storage used

When deploying contracts, ensure the contract account is funded to cover its minimum balance.

Next Steps

Now that you understand the core concepts:

• Build your first contract - Apply these concepts
• Learn PuyaTS - Deep dive into the TypeScript syntax
• Ghost Testing - Test without deploying