## Keyboard shortcuts

Press `←` or `→` to navigate between chapters

Press `S` or `/` to search in the book

Press `?` to show this help

Press `Esc` to hide this help

- Auto
- Light
- Dark

# Algorand Specifications

The new Ledger’s state that results from applying a valid block is the account state
that results from applying each transaction in that block, in sequence.

For a block to be valid, each transaction in its transaction sequence **MUST** be
valid at the block’s round rr and for the block’s genesis identifier GenesisIDBGenesisIDB.

For a transaction

Tx=(GenesisID,TxType,rfv,rlv,I,I′,I0,f,a,x,N,pk,sppk,nonpart,…)Tx=(GenesisID,TxType,rfv,rlv,I,I′,I0,f,a,x,N,pk,sppk,nonpart,…)

(where …… represents fields specific to [transaction types](https://specs.algorand.co/ledger/ledger-transactions#transaction-type)
besides `pay`and `keyreg`) to be valid at the intermediate state ρρ in
round rr for the genesis identifier GenesisIDBGenesisIDB, the following conditions
**MUST** all hold:

- It **MUST** represent a transition between two valid account states.

- Either GenesisID=GenesisIDBGenesisID=GenesisIDB or GenesisIDGenesisID is the empty string.

- TxTypeTxType is either `pay`, `keyreg`, `acfg`, `axfer`, `afrz`, `appl`, `stpf`,
or `hb`.

- There are no extra fields that do not correspond to TxTypeTxType.

- 0≤rlv−rfv≤TxTailmax0≤rlv−rfv≤TxTailmax.

- rfv≤r≤rlvrfv≤r≤rlv.

- \|N\|≤Tm,max\|N\|≤Tm,max.

- I≠IpoolI≠Ipool, I≠IfI≠If, and I≠0I≠0.

- Stake(r+1,I)≥f≥Tfee,minStake(r+1,I)≥f≥Tfee,min.

- The transaction is properly authorized as described in the [Authorization and\
Signatures](https://specs.algorand.co/ledger/ledger-txn-authorization) section.

- Hash(Tx)∉TxTailrHash(Tx)∉TxTailr.

- If x≠0x≠0, there exists no Tx′∈TxTailTx′∈TxTail with sender
I′I′, lease value x′x′, and last valid round r′lvrlv′
such that I′=II′=I, x′=xx′=x, and r′lv≥rrlv′≥r.

- If TxTypeTxType is `pay`,
  - I≠IkI≠Ik or both I′≠IpoolI′≠Ipool and
    I0≠0I0≠0.

- Stake(r+1,I)−f>aStake(r+1,I)−f>a if I′≠II′≠I and I′≠0I′≠0.

- If I0≠0I0≠0, then I0≠II0≠I.

- If I0≠0I0≠0, II cannot hold any assets.
- If TxTypeTxType is `keyreg`,
  - pρ,I≠2pρ,I≠2 (i.e., nonparticipatory accounts may not issue `keyreg`
    transactions)

- If nonpartnonpart is `True` then spk=0spk=0, pk=0pk=0 and
    sppk=0sppk=0

Given that a transaction is valid, it produces the following updated account state
for intermediate state ρ+1ρ+1:

- For II:
  - If I0≠0I0≠0 then
    aρ+1,I=a′ρ+1,I=a∗ρ+1,I=pρ+1,I=pkρ+1,I=0aρ+1,I=aρ+1,I′=aρ+1,I∗=pρ+1,I=pkρ+1,I=0;

- otherwise,
    - aρ+1,I=Stake(ρ+1,I)−a−faρ+1,I=Stake(ρ+1,I)−a−f if I′≠II′≠I
      and aρ+1,I=Stake(ρ+1,I)−faρ+1,I=Stake(ρ+1,I)−f otherwise.
    - a′ρ+1,I=Tr+1aρ+1,I′=Tr+1.
    - a∗ρ+1,I=a∗ρ,I+(Tr+1−a′ρ,I)⌊aρ,IA⌋aρ+1,I∗=aρ,I∗+(Tr+1−aρ,I′)⌊aρ,IA⌋.
    - If TxTypeTxType is `pay`, then pkρ+1,I=pkρ,Ipkρ+1,I=pkρ,I and pρ+1,I=pρ,Ipρ+1,I=pρ,I
    - Otherwise (i.e., if TxTypeTxType is `keyreg`),

- pkρ+1,I=pkpkρ+1,I=pk
      - pρ+1,I=0pρ+1,I=0 if pk=0pk=0 and nonpart=Falsenonpart=False
      - pρ+1,I=2pρ+1,I=2 if pk=0pk=0 and nonpart=Truenonpart=True
      - pρ+1,I=1pρ+1,I=1 if pk≠0pk≠0
      - If f>Bp,feef>Bp,fee, then Aeρ+1,I=TrueAeρ+1,I=True
- For I′I′ if I≠I′I≠I′ and either I′≠0I′≠0
or a≠0a≠0:
  - aρ+1,I′=Stake(ρ+1,I′)+aaρ+1,I′=Stake(ρ+1,I′)+a.

- a′ρ+1,I′=Tr+1aρ+1,I′′=Tr+1.

- a∗ρ+1,I′=a∗ρ,I′+(Tr+1−a′ρ,I′)⌊aρ,I′A⌋aρ+1,I′∗=aρ,I′∗+(Tr+1−aρ,I′′)⌊aρ,I′A⌋.
- For I0I0 if I0≠0I0≠0:
  - aρ+1,I0=Stake(ρ+1,I0)+Stake(ρ+1,I)−a−faρ+1,I0=Stake(ρ+1,I0)+Stake(ρ+1,I)−a−f.

- a′ρ+1,I0=Tr+1aρ+1,I0′=Tr+1.

- a∗ρ+1,I0=a∗ρ,I0+(Tr+1−a′ρ,I0)⌊aρ,I0A⌋aρ+1,I0∗=aρ,I0∗+(Tr+1−aρ,I0′)⌊aρ,I0A⌋.
- For all other I∗≠II∗≠I, the account state is identical to that in view ρρ.

For transaction types other than `pay` and `keyreg`, account state is updated based
on the reference logic described in the [Transaction section](https://specs.algorand.co/ledger/ledger-transactions).

Additionally, for all types of transactions, if the [rekey to](https://specs.algorand.co/ledger/ledger-transactions#rekey-to)
address of the transaction is nonzero and does not match the transaction sender address,
then the transaction sender account’s spending key is set to the rekey to address.
If the rekey to address of the transaction does match the transaction sender address,
then the transaction sender account’s spending key is set to zero.

> The rest of this section describes the legacy Distribution Rewards system. If
> the RrRr rewards rate parameter is 00, all computations keep values
> constant and no legacy reward distribution is carried out.

The final intermediate account ρkρk state changes the balance of the incentive
pool as follows:

aρk,Ipool=aρk−1,Ipool−Rr(Units(r))aρk,Ipool=aρk−1,Ipool−Rr(Units(r))

An account state in the intermediate state ρ+1ρ+1 and at round rr
is valid if all following conditions hold:

- For all addresses I∉{Ipool,If}I∉{Ipool,If}, either Stake(ρ+1,I)=0Stake(ρ+1,I)=0
or Stake(ρ+1,I)≥bmin×(1+NA)Stake(ρ+1,I)≥bmin×(1+NA), where NANA
is the number of assets held by that account.

- ∑IStake(ρ+1,I)=∑IStake(ρ,I)∑IStake(ρ+1,I)=∑IStake(ρ,I).