Althea Liquid Infrastructure - PoeAudits's results

Althea Liquid-Infrastructure

Overview

The Althea Liquid Infrastructure project is an attempt to tokenize real-world revenue streams and distribute the rewards to users through an ERC-20 token. The project uses ERC-721 tokens to tokenize revenue streams such as Althea's pay-per-forward billing protocol, vending machines, renewable energy infrastructure, or electric car chargers. These ERC-721 tokens supply the LiquidInfrastructureERC20 contract with funds to distribute to token holders. Althea Liquid Infrastructure is to be deployed on Althea-L1, a Cosmos SDK chain with an EVM compatability layer. The purpose of these contracts are to facilitate the distribution of funds generated by independent, real-world revenue generating entities.

Contracts

LiquidInfrastructureNFT.sol

This contract is designed to mint a single NFT which represents a revenue source, and when managed by a LiquidInfrastructureERC20 allows the latter contract to aggregate the rewards from this contract. The LiquidInfrastructureNFT contract is designed to interact with several Cosmos modules on the Althea network for routing tokens and account recovery. It can be used without Cosomos functionality as a standalone entity controlled by a protocol manager. Functionality is limited to storing the token URI, setting some state variables associated with Cosmos modules, and withdrawing the contract's ERC-20 balance to the owner of the NFT or an arbitrary destination. The NFTs are designed to be transferred to the LiquidInfrastructureERC20 contract to be managed.

LiquidInfrastructureERC20.sol

This contract is designed to aggregate funds from numerous sources, represented by LiquidInfrastructureNFTs, and distribute the aggregated funds to token holders. The core of the contract is the distribution logic, which allows for managing allowed users, ERC-20 tokens, and LiquidInfrastructureNFTs. Unique features of this implementation include a lock on token transfers, minting, and burning during distributions. The distribution period is based on the block.number, which is generally ignored for the more consistent block.timestamp as block creation time can be variable. The protocol is designed to be used with some form of KYC to restrict who holds LiquidInfrastructureERC20 tokens. The system will use a set of trusted ERC-20 tokens as rewards for token holders.

System Design

The Problem Statement

When thinking about a system's design, it is helpful to first think about the problem it is trying to solve. Althea has a group of siloed systems that generate revenue, and they want to be able to distribute this revenue as rewards to participants in their decentralized network. From the whitepaper, "Althea's goal is for any person to be able to install a piece of equipment, participate in the decentralized ISP, and receive payment for the service." The smart contracts in this audit are Althea's attempt at creating a decentralized, inclusive distribution layer for their current and future services. These contracts are designed to gather the rewards generated by each service, aggregate, and distribute them proportionally to the intended recipients.

The Implementation

The contracts mostly solve the above problem by using a combination of ERC-721 and ERC-20 tokens to tokenize the revenue generating mechanisms and the reward vehicle. Unfortunately, the project does not leverage ERC-721 tokens properly, and the distribution mechanism is inherently flawed.

ERC-721

ERC-721 tokens are highly versatile and powerful tools in the blockchain ecosystem to define unique entities with common features, functions, and source. Originating from the same source is a crucial feature of ERC-721 tokens since this is used for interoperability and filtering. The LiquidInfrastructureNFT contract is designed to only ever mint a single ERC-721 token, which is used as an access control mechanism. Each Althea system designed to work using the LiquidInfrastructureERC20 distribution mechanism is supposed to have its own deployed LiquidInfrastructureNFT contract and sole NFT. This type of system does not benefit from ERC-721 tokens, and should just be a smart contract wallet. The existing functionality of the contract would be easier to implement as a smart contract wallet while reducing gas costs and complexity. Alternatively, the system could continue using ERC-721 tokens, where each token represents a revenue source and balances are kept for each token. This does change, and most likey increases, the risk profile of the contract and any bugs that occur. Instead of deploying a new contract for each revenue source, the contract would mint them a new NFT that tracks its own data and can be used similarly to the current design.

Distribution

Distributing tokens to users is a common problem for crypto protocols, and knowing what works and what does not takes trial and error. Due to the nature of blockchain math, which is unable to use decimals or fractions, using an ERC-20 token to calculate proportional ownership of a pool of funds is ill-advised. The issue stems from the ERC-20 tokens using the same order of magnitude as one another (generally), which defeats the purpose of using so many decimals in the first place. ERC-20 tokens typically have 18 decimals to account for rounding issues, effectively reducing differences in expected amounts after divisions to dust.

The implementation in LiquidInfrastructureERC20 faces a significant rounding issue on line: https://github.com/code-423n4/2024-02-althea-liquid-infrastructure/blob/main/liquid-infrastructure/contracts/LiquidInfrastructureERC20.sol#L275 When trying to calculate the rewards earned for each LiquidInfrastructureERC20 token, the result will be zero as long as the balance of ERC20 tokens is less than the total supply of LiquidInfrastructureERC20. This is assuming that the ERC-20 token also uses 18 decimal places, and it worsens significantly for tokens with fewer than 18 decimals.

The generally accepted solution to this problem is to instead use shares to track proportional ownership of a pool of tokens. This issue is significant enough to have a resolution in the form of ERC4626, token vaults. Openzeppelin's implementation of ERC4626 can be found here: https://github.com/OpenZeppelin/openzeppelin-contracts/blob/master/contracts/interfaces/IERC4626.sol

More information on ERC4626 can be found here: https://docs.openzeppelin.com/contracts/4.x/erc4626

Centralization

Althea Liquid-Infrastructure contains significant centralization risks, with considerable power given to the owners of the contracts, particularly LiquidInfrastructureERC20. Owners are able to grant and revoke the ability to receive LiquidInfrastructureERC20 tokens. Owners can alter what ERC-20 tokens are supported. Owners are able to burn tokens from holders (after fixing M-02 from bot-report.md). Owners also have unilateral control over managed NFTs.

Conclusion

In conclusion, the Althea Liquid Infrastructure project presents a novel approach to tokenizing real-world revenue streams and distributing rewards to users through ERC-20 tokens. However, upon close examination, several shortcomings and areas for improvement emerge. The utilization of ERC-721 tokens to represent revenue sources initially seems promising, but the implementation falls short of leveraging the full potential of these tokens. Additionally, the distribution mechanism suffers from inherent flaws, particularly in its handling of proportional ownership of funds using ERC-20 tokens.

Time spent:

8 hours