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 besides payand 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.

Additionally, for all types of transactions, if the 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).