$$ \newcommand \Record {\mathrm{Record}} \newcommand \PartKey {\mathrm{PartKey}} \newcommand \Eligibility {\mathrm{A_e}} \newcommand \Stake {\mathrm{Stake}} \newcommand \Units {\mathrm{Units}} $$

$$ \newcommand \MBR {\mathrm{MBR}} \newcommand \MinBalance {b_{\min}} \newcommand \App {\mathrm{App}} \newcommand \AppFlatOptInMinBalance {\App_{\mathrm{optin},\MinBalance}} \newcommand \AppFlatParamsMinBalance {\App_{\mathrm{create},\MinBalance}} \newcommand \SchemaBytesMinBalance {\App_{\mathrm{b},\MinBalance}} \newcommand \SchemaMinBalancePerEntry {\App_{\mathrm{s},\MinBalance}} \newcommand \SchemaUintMinBalance {\App_{\mathrm{u},\MinBalance}} \newcommand \Box {\mathrm{Box}} \newcommand \BoxByteMinBalance {\Box_{\mathrm{byte},\MinBalance}} \newcommand \BoxFlatMinBalance {\Box_{\mathrm{flat},\MinBalance}} $$

Account State

The balances are a set of mappings from addresses, 256-bit integers, to balance records.

A balance record contains the following fields:

• The account raw balance in μALGO,
• The account status,
• The block incentive eligibility flag,
• The account last_proposed round,
• The account last_heartbeat round,
• The account rewards base and total awarded amount in μALGO,
• The account spending key,
• The account participation keys.

Note

In the rest of this section, all references to Reward calculation are with respect to the legacy distribution rewards system. They are kept here for completeness and for backward compatibility.

The account raw balance \( a_I \) is a 64-bit unsigned integer which determines how much μALGO the address has.

The account rewards base \( a^\prime_I \) and total-awarded amount \(a^\ast_I \) are 64-bit unsigned integers.

Combined with the account balance, the reward base and total awarded amount are used to distribute rewards to accounts lazily.

The account stake is a function which maps a given account and round to the account’s balance in that round and is defined as follows:

$$ \Stake(r, I) = a_I + (T_r - a^\ast_I) \left\lfloor \frac{a_I}{A} \right\rfloor $$

unless the account is non-participating (i.e. \( p_I = 2 \), defined below), in which case:

$$ \Stake(r, I) = a_I $$

\( \Units(r) \) is a function that computes the total number of whole earning units present in a system at round \( r \).

A user owns \( \left\lfloor \frac{a_I}{A} \right\rfloor \) whole earning units, so the total number of earning units in the system is:

$$ \Units(r) = \sum_I \left\lfloor \frac{a_I}{A} \right\rfloor $$

for the \( a_I \) corresponding to round \( r \).

In this sum, online and offline accounts are taken into consideration.

The account status \( p_I \) is an 8-bit unsigned integer which is either \( 0, 1, 2 \):

• A status of 0 corresponds to an offline account,
• A status of 1 corresponds to an online account,
• A status of 2 corresponds to a non-participating account.

Combined with the account stake, the account status determines how much voting stake an account has, which is a 64-bit unsigned integer defined as follows:

• The account balance, if the account is online.
• 0 otherwise.

The account’s spending key determines how transactions from this account must be authorized (e.g., what public key to verify transaction signatures against).

Transactions from this account must have this value (or, if this value zero, the account’s address) as their authorization address. This is described in the Authorization and Signatures section.

The account’s participation keys \( \PartKey \) are defined in Algorand’s specification of participation keys.

The account’s eligibility \( \Eligibility \) is a flag that determines whether the account has elected to receive payouts for proposing blocks (assuming it meets balance requirements at the time of block proposal).

An account’s participation keys and voting stake from a recent round is returned by the \( \Record \) procedure in the Byzantine Agreement Protocol.

There exist three special addresses:

• \( I_\mathrm{pool} \), the address of the incentive pool,

• \( I_f \), the address of the fee sink,

• \( I_\mathrm{sp} \), the address of the State Proof sender.

For the incentive pool and the fee sink, \( p_I = 2 \).

All three addresses are exempt from the minimum balance conditions of the account state validity conditions.

Minimum Balance Requirement

Every account has a minimum balance requirement (MBR), the amount of μALGO it must hold in order to occupy the space it uses in the Ledger. The MBR of an account \( I \) in the intermediate state \( \rho \), \( \MBR(\rho, I) \), is \( \MinBalance \) plus a contribution for each resource the account is responsible for:

$$ \begin{aligned} \MBR(\rho, I) = & \MinBalance \times (1 + N_A) \\ & + \AppFlatParamsMinBalance \times (N_C + N_P) \\ & + \AppFlatOptInMinBalance \times N_O \\ & + (\SchemaMinBalancePerEntry + \SchemaUintMinBalance) \times \mathrm{NumUint} \\ & + (\SchemaMinBalancePerEntry + \SchemaBytesMinBalance) \times \mathrm{NumByteSlice} \\ & + \BoxFlatMinBalance \times N_B + \BoxByteMinBalance \times S_B \end{aligned} $$

where, for the account \( I \) in the intermediate state \( \rho \):

• \( N_A \) is the number of assets it holds, whether created by it or opted in to,

• \( N_C \) is the number of applications it created and \( N_O \) is the number of applications it is opted in to,

• \( N_P \) is the total ExtraProgramPages of the applications whose sizes it sponsors — an application’s creator sponsors its size until another account sets it,

• \( \mathrm{NumUint} \) and \( \mathrm{NumByteSlice} \) are the summed state schema entry counts of the LocalStateSchema of each application it is opted in to and of the GlobalStateSchema of each application whose size it sponsors,

• \( N_B \) is the number of boxes held by the application whose account address is \( I \), and \( S_B \) is their total size in bytes, counting each box’s name and contents.

The sections describing those resources specify when each contribution is incurred and released. A contribution takes effect as soon as the state it accounts for is allocated, so an MBR increase is visible to a program that allocates state (through the AVM min_balance opcode) before that program completes.

The requirement itself is enforced after each transaction, for every account, as one of the account state validity conditions. No transaction type imposes an MBR check of its own.