Applications

Algorand Smart Contracts, also known as Applications, are the logic component of our blockchain systems. A client can invoke these pieces of structured code to execute a specific method or logic inside the application.

Smart contracts live on the blockchain. Once they are deployed, the on-chain instance of the contract is referred to as an application and assigned an Application ID, which can be used by any client to lookup the application or to execute its methods.

Storage

Applications can store values on the Algorand blockchain using one of the following storage types:

• Global Storage
• Local Storage
• Boxes Storage

The Storage Overview section provides a detailed section on on-chain storage.

Data Storage - Overview Data storage primitives in the Algorand Virtual Machine (AVM)

Components

• Approval Program: Responsible for processing all application calls to the contract, except for the clear call, described in the next bullet. This program is responsible for implementing most of the logic of an application. Like Logic Signatures, this program will succeed only if one nonzero value is left on the stack upon program completion or the return opcode is called with a positive value on the top of the stack.
• Clear State Program: Handles accounts using the clear call to remove the smart contract from their balance record. This program will pass or fail the same way the ApprovalProgram does. However, whether the logic passes or fails, the contract will be removed from the account’s balance record.

In either program, if a global, box, or local state variable is modified and the program fails, the state changes will not be applied. Having two programs allows an account to clear the contract from its state, whether the logic passes or not. When the clear call is made to the contract, whether the logic passes or fails, the contract will be removed from the account’s balance record.

Interaction and Lifecycle

For interacting in a standard way with Applications, the Application Binary Interface (ABI) should be used. This specification defines the encoding/decoding of data types and is a standard for exposing and invoking methods in a smart contract.

For calling an Application, the clients must execute ApplicationCall transactions. Depending on the type, the application could show a different behavior and result:

• NoOp: Generic application call to execute the Approval Program
• OptIn: Accounts use this transaction to begin participating in a smart contract. Participation enables local storage usage.
• DeleteApplication: Transaction to delete the application.
• UpdateApplication: Transaction to update the logic of an application.
• CloseOut: Accounts use this transaction to close out their participation in the contract. This call can fail based on the programmed logic, preventing the account from removing the contract from its balance record.
• ClearState: Similar to CloseOut, the transaction will always clear a contract from the account’s balance record whether the program succeeds or fails.

The ClearStateProgram handles the ClearState transaction and the ApprovalProgram handles all other ApplicationCall transactions. These transaction types can be created with either goal or the SDKs. In the following sections, details on the individual capabilities of a smart contract will be explained.

Applications Lifecycle

Inner Transactions

Inner transactions are operations that an Application performs from within its execution context. When an application executes, it has its own associated account that can create and submit transactions, similar to how a regular account would.

Through inner transactions, Applications can:

• Send payments
• Hold assets
• Create assets
• Call other Applications
• Perform any other transaction allowed by regular accounts

Inner Transactions Learn more about how smart contracts can create and submit transactions from within their execution context