ALGORAND
ARCHITECTURE.
Understanding the two-tier node architecture, native asset standards, atomic transfers, and the state-proof mechanism that makes Algorand quantum-resistant.
How Algorand Thinks
Transaction-First Paradigm
In Algorand, transactions are first-class citizens. Smart contracts don't do things — they approve or reject transactions.
→ "Algorand smart contracts don't execute business logic. They validate transaction permissions."
Predictable Execution
No arbitrary loops. Bounded computation. You know exactly what a transaction costs before submitting.
Explicit Approval
Every asset, app interaction requires explicit opt-in. Users control what touches their accounts.
Self-Describing Messages
Transactions contain all info needed for validation. State is queried, not computed on-chain.
Protocol Stack
Algorand's architecture is built in layers, each providing specific functionality while maintaining the core principles of decentralization, security, and scalability.
The Blockchain Trilemma
Most blockchains sacrifice one of: Decentralization, Security, or Scalability. Algorand's architecture addresses all three through its unique consensus and protocol design.
Applications
Smart Contracts, DeFi, NFTs
Protocol
ASA, Atomic Transfers, State Proofs
Consensus
Pure Proof of Stake, VRF, BA*
Network
Relay Nodes, Participation Nodes
Two-Tier Node Architecture
Relay Nodes
High-performance nodes that facilitate communication between participation nodes. They don't participate in consensus but ensure network efficiency.
- Route blocks and votes
- Connect participation nodes
- No stake required
- Run by community/foundation
Participation Nodes
Nodes that actively participate in consensus by proposing and voting on blocks. Anyone can run one with minimal hardware.
- Propose blocks
- Vote in consensus
- Require participation keys
- Stake determines selection probability
{
"Version": 28,
"EndpointAddress": "127.0.0.1:8080",
"EnableDeveloperAPI": true,
"Archival": false,
"IsIndexerActive": false,
"NodeExporter": "prometheus"
}The Algorand Account Model
Algorand accounts are multi-purpose containers that can hold native currency, fungible/non-fungible assets, and application-specific state — all in a unified model.
Account Structure
Key Concepts
Minimum Balance Requirement
Every account must maintain 0.1 ALGO base + 0.1 ALGO per asset/app opt-in to prevent state bloat.
Opt-In Model
Users must explicitly opt-in to receive assets or interact with apps, preventing spam and ensuring consent.
Simpler than Ethereum
Unlike Ethereum's "everything is a contract" approach, Algorand accounts are native balance + state holders.
Standard Account
Basic account that holds ALGO and can opt-in to assets/apps
Transaction Types
Algorand supports six native transaction types, each optimized for specific operations. This native support eliminates the need for smart contracts for common operations.
Payment
Transfer ALGO between accounts
Asset Config
Create, modify, or destroy ASAs
Asset Transfer
Transfer ASAs between accounts
Asset Freeze
Freeze/unfreeze asset holdings
Application Call
Interact with smart contracts
Key Registration
Register participation keys for consensus
ASA Roles & Compliance
Algorand Standard Assets (ASAs) include built-in role-based controls that make them ideal for regulated environments, institutional finance, and enterprise use cases.
Manager
Modify asset parametersCan update asset configuration (except immutable fields). Can change other role addresses.
Reserve
Control supply distributionHolds un-minted supply. Used for token economics and supply management.
Freeze Manager
Freeze asset holdingsCan freeze/unfreeze asset holdings in any account. Used for compliance and emergency stops.
Clawback
Force transfer assetsCan revoke assets from any account. Required for regulatory compliance scenarios.
Why This Matters for Enterprise
ASAs are protocol-defined objects, not smart contracts. This gives uniform behavior, lower bug surface, and built-in compliance controls. It's why Algorand attracts enterprises, institutions, and regulated environments.
Atomic Transfers
Algorand supports native atomic transfers — groups of up to 16 transactions that either all succeed or all fail. No smart contract required.
Use Cases
- Trustless trading (Asset A for Asset B)
- Batch payments (payroll, dividends)
- Complex DeFi operations
- NFT sales with royalties
from algosdk import transaction
# Create transaction group
txn1 = transaction.PaymentTxn(
sender=alice,
receiver=bob,
amt=1000000, # 1 ALGO
sp=params
)
txn2 = transaction.AssetTransferTxn(
sender=bob,
receiver=alice,
amt=100,
index=asset_id,
sp=params
)
# Group transactions (atomic)
gid = transaction.calculate_group_id([txn1, txn2])
txn1.group = gid
txn2.group = gid
# Both must be signed & submitted together
# Either BOTH succeed or BOTH failState Proofs & Quantum Readiness
Post-Quantum Security
Algorand is proactive in safeguarding against quantum computing threats through State Proofs — post-quantum secure compact certificates using FALCON signatures.
State Proofs
Compact certificates attesting to state changes every 256 rounds
FALCON Signatures
Post-quantum secure digital signatures based on lattices
Future VRF Upgrade
Ability to swap VRF for post-quantum version when needed
Two Types of Smart Contracts
Algorand supports two distinct types of smart contracts, each with different capabilities and use cases. Session 3 will deep-dive into building stateful apps with PyTeal.
Stateless (LogicSig)
Contract AccountsPure validation logic. No storage. Signs transactions if conditions are met.
Stateful (Applications)
Smart ContractsCan store and modify on-chain state. Has global and local storage.
Architecture Summary
Transactions are first-class citizens, not computation
Two-tier node architecture for efficiency
Native ASA support with built-in compliance roles
Account model with opt-in for security
Atomic transfers for trustless multi-party operations
Quantum-resistant through State Proofs