From Ethereum to Algorand
If you’re coming from Ethereum, this guide maps your existing knowledge to Algorand as quickly as possible. The goal is to draw correlations between terms and concepts and point out key paradigm differences.
Quick Mapping
Section titled “Quick Mapping”| Ethereum | Algorand | Key Difference |
|---|---|---|
| EOA (20 bytes Address) | Account (32 byte Address) | Same concept |
| Contract Account | Application + Application Account | Separate from accounts |
| Smart Contract | Application | Has its own account |
| ERC-20 / ERC-721 / ERC-1155 | ASA (Algorand Standard Asset) | Native, no contract required |
| Gas Fees | Flat Transaction Fee | Predictable and minimal |
| Proxy Pattern | Native Contract Upgradability | Built-in flexibility |
| Account Abstraction | Logic Sig / Rekeying | Protocol-level |
| Smart Contract Multisigs | Native Multisigs (SC optional) | Protocol-level |
How to Think in Algorand
Section titled “How to Think in Algorand”To understand Algorand, you need to think differently about some of the fundamental building blocks you’re already familiar with: Contracts, Accounts, Transactions, Tokens and Chain State.
On Ethereum, contracts are accounts. They hold assets and execute logic in the same place. On Algorand, those concerns are separated. An application defines logic, and an associated account holds assets.
Ethereum flows feel like a chain of calls. One contract calls another, which calls another. On Algorand, that pattern disappears. Transactions are composed together and executed atomically. You describe everything up front instead of relying on nested execution.
Tokens are also different. On Ethereum, tokens are contracts. On Algorand, they are part of the protocol. Sending a token feels the same as sending the native currency.
Finally, state access is explicit. You must declare what data you will touch before execution. This feels restrictive at first, but it leads to predictable performance. We’ll delve into each of these topics a bit more in this section.
Core Differences
Section titled “Core Differences”Accounts vs Applications
Section titled “Accounts vs Applications”On Ethereum, contracts are accounts. On Algorand, applications are separate from accounts but have an associated account that can hold assets.
Applications are identified by a simple integer ID. Their account address is derived from that ID. This account can hold Algo or any ASA, just like a user account.
Applications can also initiate transactions. These are called inner transactions and allow apps to send assets or interact with other apps. This is how applications perform actions like sending tokens or interacting with other applications. If you’re coming from Ethereum, inner transactions are the closest equivalent to a contract executing transfers during a function call.
Tokens (ERC vs ASA)
Section titled “Tokens (ERC vs ASA)”On Ethereum, tokens are defined by smart contracts, typically based on accepted standards. Each standard adds its own rules and interacting with tokens requires calling those contracts.
On Algorand, tokens are called Algorand Standard Assets (ASAs). You do not deploy a contract to create one because they are a part of the base protocol. Every ASA has the same security guarantees as the Algo token itself.
Transfers are as simple as submitting an asset transfer transaction to the network and referencing the desired ASA. The only extra step is opting in; an account’s owner must opt in before receiving an asset. This prevents spam and controls storage usage.
Another key difference is that ASAs are identified by an integer ID, not a contract address.
Costs: Fees vs Storage
Section titled “Costs: Fees vs Storage”Ethereum charges for computation. Every operation consumes gas, and costs can vary depending on network conditions.
Algorand separates costs into two concepts: transaction fees, which are flat and predictable, and storage, which has a variable cost based on the size of the data being stored.
The base transaction fee is small and predictable and is only paid when a transaction is successfully included in a block.
Storage is managed through the minimum balance requirement. As you store more data or opt into assets, your required balance increases.
This means you pay for how much state you use, not how complex your code is.
State & Execution Model
Section titled “State & Execution Model”There are three types of storage on Algorand:
- Global storage is shared across all users.
- Local storage is tied to individual accounts.
- Box storage allows for flexible key-value data storage.
The important part of these types is how they are accessed; you must declare which data your application will read or write before execution. Nodes can then prepare everything in advance.
This leads to consistent performance and also changes how you design contracts. You’ll need to think about access patterns up front rather than discover them at runtime.
Things That Feel Weird (At First)
Section titled “Things That Feel Weird (At First)”Some patterns you rely on in Ethereum do not exist here. Algorand intentionally makes different tradeoffs, and once you understand them, most of these differences start to feel like major simplifications.
No contract-to-contract call chains
Section titled “No contract-to-contract call chains”On Ethereum, contracts can call other contracts freely. This creates deep execution chains and complex control flow.
On Algorand, applications cannot call other applications in the same way. Instead, you compose multiple transactions together and execute them atomically as a group.
This shifts how you design systems. Instead of thinking in terms of nested calls, you think in terms of coordinated actions that are declared up front. It removes hidden execution paths and makes outcomes easier to reason about.
An added benefit to this is that if one of the grouped transactions were to fail, all other transactions in the group also fail, but no transaction fee is charged for any of the transactions within the group.
No implicit execution on token transfer
Section titled “No implicit execution on token transfer”On Ethereum, sending tokens to a contract can trigger logic automatically. This is the foundation of many patterns, but also a source of bugs and exploits.
On Algorand, transferring tokens does not trigger application logic. Nothing happens unless you explicitly call the application.
This makes behavior more predictable. If something executes, it is because you explicitly included an application call in the transaction group.
No nonces
Section titled “No nonces”Ethereum uses nonces to order transactions and prevent replay attacks.
Algorand does not use nonces. Instead, each transaction includes a validity window that defines when it can be accepted. If two identical transactions are submitted, only one can be confirmed.
If you need to send similar transactions multiple times, you must change some field, such as the note or the validity window.
This removes the need to track per-account counters and simplifies transaction construction.
For more granular replay protection, Algorand also supports leases, which prevent a transaction with the same lease value from being confirmed more than once within a given window.
Token opt-in is required
Section titled “Token opt-in is required”On Ethereum, any account can receive any token at any time.
On Algorand, an account must opt in before it can receive a specific asset. This is done by sending a zero-value transaction to itself.
At first, this feels like friction. In practice, it prevents spam and gives users control over what appears in their account. It also ties into storage costs, since each opt-in increases the account’s minimum balance requirement.
State access must be declared
Section titled “State access must be declared”On Ethereum, contracts can read from storage dynamically during execution.
On Algorand, you must declare which accounts, assets, and applications your transaction will access before execution begins.
This allows nodes to prepare all required data ahead of time. The result is faster and more predictable execution, but it requires you to think about data access patterns up front.
Things Algorand Does Better
Section titled “Things Algorand Does Better”Native Multisig
Section titled “Native Multisig”On Ethereum, multisigs are implemented with contracts. That adds complexity and coordination overhead.
On Algorand, multisigs are built into the protocol as a first-class feature and are simple to create and use.
With ARC-55, coordination can also happen on-chain. Transactions and signatures are stored in a shared contract. Signers no longer need to pass data around off-chain. Everyone works from the same source of truth.
Atomic Transfers
Section titled “Atomic Transfers”Algorand allows multiple transactions to be grouped together. The group will either succeed entirely or fail.
This replaces many patterns that would require complex contract logic on Ethereum. It is commonly used when interacting with applications. For example, sending a token and calling a contract can be done in one atomic group.
This is the foundation for how most multi-step interactions are built on Algorand.
Rekeying
Section titled “Rekeying”Rekeying allows an account to change its signing authority without changing its address.
This enables flexible security models. It can also simulate patterns similar to account abstraction, but without needing additional infrastructure.
Re-Entrancy Resistance
Section titled “Re-Entrancy Resistance”Algorand avoids many common re-entrancy issues by design.
Transfers do not trigger code execution. Applications cannot call themselves directly or indirectly. This removes entire classes of vulnerabilities that exist on Ethereum.
Common Patterns (Ethereum → Algorand)
Section titled “Common Patterns (Ethereum → Algorand)”Sending Tokens to a Contract
Section titled “Sending Tokens to a Contract”On Ethereum, sending tokens to a contract often involves approve → confirm → action → confirm flows and delegated transfers.
On Algorand, the process is explicit. You group a token transfer with an application call. Both transactions execute together or not at all.
Upgradeability
Section titled “Upgradeability”Ethereum relies heavily on proxy contracts because contracts are immutable.
Algorand allows applications to define their own update rules. You can make an application upgradable or permanently lock it. In most cases, you do not need proxy contracts at all.
Pull Over Push
Section titled “Pull Over Push”Transfers on Algorand can fail if the receiving account has not opted in or does not meet minimum balance requirements. When that happens, the entire transaction (or group) fails.
Instead of sending funds automatically, it is often better to record what a user can claim and let them claim it themselves.
This ensures the user is opted in, has sufficient balance, and is ready to receive the asset. It also prevents one unprepared account from causing a broader failure.
Factory Pattern
Section titled “Factory Pattern”Factories are possible but uncommon.
In most cases, a single application can handle many users. You only need factories when you want strict isolation between instances.
Tools & Services
Section titled “Tools & Services”| Category | Ethereum | Algorand |
|---|---|---|
| Block Explorer | Etherscan | List of block explorers |
| API / Node Access | Infura | nodely, BlockDaemon, GetBlock |
| Wallet | Metamask | Pera, Defly (WalletConnect) |
| Dev Framework | Hardhat, Truffle | AlgoKit |
| Local Network | Ganache | Sandbox |
Standards (ERC vs ARC)
Section titled “Standards (ERC vs ARC)”| Ethereum | Algorand |
|---|---|
| ERC-20 | ASA / ARC-20 |
| ERC-721 | ASA / ARC-3 / ARC-19 / ARC-89 |
| ERC-1155 | ASA variants |
ARC standards define conventions on top of native assets.
Summary
Section titled “Summary”This was just a high-level overview to give you a clearer mental model of Algorand by drawing correlations to Ethereum. We’ve covered how Algorand separates logic from accounts. Tokens are native. Transactions are composed instead of being chained. Fees are predictable, and storage is explicit.
When you’re ready to go deeper, carry on to the next sections.