Audit Comp | Folks: Liquid Staking

Proof of Concept (PoC) Requirements

A PoC, demonstrating the bug's impact, is required for this program and has to comply with the Immunefi PoC Guidelines and Rules.

Whitehat Educational Resources & Technical Info

What ERC20 / ERC721 / ERC777 / ERC1155 token standards are supported? Which are not?

Algorand has native support for tokens with ASAs (Algorand Standard Assets). The liquid staking token which is distributed is an Algorand ASA.

What emergency actions may you want to use as a reason to invalidate or downgrade an otherwise valid bug report?

We can update the deployed application in an emergency so some issues e.g. freezing of funds, may be mitigated from a permanent issue to a temporary issue. We also have the ability to pause immediate and/or delayed minting.

What monitoring systems may you want to use as a reason to invalidate or downgrade an otherwise valid bug report?

None

What addresses would you consider any bug report requiring their involvement to be out of scope, as long as they operate within the privileges attributed to them?

The four admins:

• The “admin” which is the super admin.
• The “register_admin” which can add proposers, set the proposer admin and register a proposer offline.
• The “xgov_admin” which can subscribe and unsubscribe proposers to xgov.
• The “proposer_admin” which can register a proposer online and offline.

What addresses would you consider any bug report requiring their involvement be out of scope, even if they exceed the privileges attributed to them?

None

Security Researcher Education

Project educational resources

• Design Overview for ALGO Staking Smart Contract https://docs.google.com/document/d/1w-0ZmpWGTGrFl46PNhjmguEKj3ChnnFnMM3X_is1R9M/edit?usp=sharing
• Smart Contract deployed on Testnet https://lora.algokit.io/testnet/application/730430673
• Algorand Consensus Incentivisation Whitepaper https://assets-global.website-files.com/62d96b0e9ea60fd1c96a1b50/65a7c0863805fd8b83cf34d5_upload_consensus-incentives.pdf
• The xGov Integration Requirements https://docs.google.com/document/d/1zB8-t0vHtkQVZeNgVlI5W8z38ugD8IhBK8uRrkoRAxM/edit?usp=sharing
• Docs for old version of ALGO Staking https://docs.folks.finance/functionalities/xalgo-liquid-staking

Is this an upgrade of an existing system? If so, which? And what are the main differences?

Yes it is an upgrade of the old version of ALGO Liquid Staking deployed at https://lora.algokit.io/mainnet/application/1134695678. The main differences are:

• Support for subscribing and unsubscribing from the xGov program.
• Support for 3rd party node runners where now each proposer has its own admin which can register it online and offline.
• The smart contract enforces the splitting of stake between the proposers.
• Removed “min_proposer_balance” checks.

Note that the existing state of the smart contract will persist after the update (global/local state and box storage).

Where do you suspect there may be bugs?

The calculations for “immediate_mint”, “delayed_mint”, “claim_delayed_mint” and “burn” cannot be manipulated. In addition, the smart contract should enforce an approximate equal stake split between the proposers.

You should also check privileged operations are safely guarded.

What external dependencies are there?

The main external dependency is the Algorand Consensus participation. Each proposers; participation keys will reside on its own Algorand Node and will receive ALGO rewards each time it proposes a block.

Another external dependency is the xGov program. The xGov power is given to block proposers and the smart contract allows delegating the control of the votes to an external address supplied by the “xgov_admin”.

Lastly some of the proposers’ Algorand Nodes may be run by trusted projects and/or key community members.

Are there any unusual points about your protocol that may confuse Security Researchers?

The smart contract is an update of an existing smart contract which is already deployed on mainnet. Therefore there is no application create call supported. In addition you should consider the existing state of the smart contract https://lora.algokit.io/mainnet/application/1134695678 (global/local state and box storage) as these will persist between updates. The accompanying Design Overview Document provides further details on this.

When an account is marked online/offline, the moment a key registration transaction is confirmed by the network it takes 320 rounds for the change to take effect. So, if a key registration is confirmed in round 5000, the account will stop participating at round 5320.

The same applies for changes in stake.