Livepeer Onchain Treasury Upgrade - catellatech's results

Livepeer Onchain Treasury Upgrade Smart Contracts Analysis

Description overview of Livepeer Onchain Treasury Upgrade

The Livepeer Onchain Treasury Upgrade is a significant enhancement to the Livepeer protocol, which is a decentralized video infrastructure platform used in web3's social media and media applications. The primary objective of this upgrade is to create an onchain community treasury. This treasury is funded through a percentage of protocol rewards generated by the network.

To achieve this, OpenZeppelin governance tools are leveraged, and a custom voting power module is implemented to facilitate onchain voting. The upgrade process is detailed in various technical documents such as LIP-91, LIP-89, and LIP-92, which provide a comprehensive blueprint for the upgrade's implementation.

A critical aspect of this upgrade is ensuring that there are no significant changes to the behavior of the core protocol contract, known as the BondingManager, except for the specific modifications required to accommodate the community treasury. Attention is also paid to maintaining the security and integrity of the protocol to avoid introducing new vulnerabilities.

Additionally, it's worth noting that Livepeer employs a unique staking rewards calculation system, which is used not only for distributing rewards to participants but also for funding the community treasury.

1- System Overview

Scope

• BondingManager.sol: An existing contract that oversees the management of protocol bonds, often referred to as staking, as well as rewards. This upgrade introduces the capability to facilitate state checkpointing and the creation of treasury rewards. This contract holds paramount significance within the contest due to its pivotal role in the current protocol.

• BondingVotes.sol: This contract stores checkpoints of the BondingManager state to facilitate an IERC5805Upgradeable (IVotes) implementation for the OpenZeppelin Governor.

• EarningsPoolLIP36.sol: This library offers utility functions to calculate staking rewards utilizing the LIP-36 cumulative earnings algorithm.

• SortedArrays.sol: This library offers assistance for managing and searching within sorted arrays. It extends the functionality of Arrays.findUpperBound to include an equivalent findLowerBound for checkpoint retrieval.

• GovernorCountingOverridable.sol: Abstract contract that implements an OpenZeppelin Governor counting module, enabling delegators to override their delegates' (transcoders) votes on a proposal.

• Treasury.sol: This contract inherits from TimelockControllerUpgradeable to enable initialization. It is used by the governor to hold funds and execute proposals.

• LivepeerGovernor.sol: This contract serves as the practical Governor implementation, bringing together both the OZ built-in and custom modules and extensions into a tangible contract that can be instantiated and utilized. It primarily handles the framework necessary to assemble these components.

Privileged Roles

Some privileged roles exercise powers over the Controller contract:

• TicketBroker

    // Check if sender is TicketBroker
    modifier onlyTicketBroker() {
        _onlyTicketBroker();
        _;
    }

• RoundManager

    // Check if sender is RoundsManager
    modifier onlyRoundsManager() {
        _onlyRoundsManager();
        _;
    }

• Verifier

    // Check if sender is Verifier
    modifier onlyVerifier() {
        _onlyVerifier();
        _;
    }

We asked the sponsors about who will be responsible for these roles, and this was their response:

victorges — 09/2/2023 at 12:20
Hey warden!
The roles are managed by a special controller owner address which handles protocol governance. See the controller contact that holds all the contract (roles) addresses

dob | Livepeer — 09/2/2023 at 3:29
I have seen a few questions come through about the Verifier role, and whether it is trusted.

Only the registered "Verifier" in the Controller contract can call the slashTranscoder function. The registered verifier contract is 0x0000000000.... the null address. Hence it can't be invoked right now, as slashing is not active in the protocol.

Given the level of control that these roles possess within the system, users must place full trust in the fact that the entities overseeing these roles will always act correctly and in the best interest of the system and its users.

2- Codebase analysis through diagrams.

The main most important contracts of Livepeer Onchain Treasury Upgrade.

• In this audit, the protocol provided 5 contracts and 2 libraries. Here's a detailed diagrams of the essential components of each ones:

Contracts:

1. BondingManager:

We have created a diagram organized into sections to facilitate understanding for both developers and auditors of the main contract. This contract is responsible for managing three fundamental areas: Delegator and Transcoder Management, Asset and Stake Management, and Reward Management and State Update.

The contract plays a critical role in managing protocol bonds and rewards. A significant upgrade adds support for creating state checkpointing and generating rewards for the protocol's treasury. Additionally, the code includes sections related to the management of a decentralized video transcoding system, where delegates actively participate, and transcoders compete for rewards.

2. BondingVotes:

In this BondingVotes diagram, we provide a concise description of each function implemented by the contract. BondingVotes is responsible for the checkpointing logic for the state of the BondingManager and its primary purpose is to perform historical calculations related to participation in the Livepeer network.

3. GovernorCountingOverridable:

In this diagram, we review the functions performed in the contract and their respective purposes. The GovernorCountingOverridable contract serves as a foundation for implementing decentralized governance systems that allow delegates to override the votes of the transcoders they have delegated to. It also provides logic for vote counting and determining the success of proposals.

4. Treasury:

The Treasury contract is used to manage treasury funds and governance proposals in Livepeer, and its initialization function is responsible for configuring the time-lock controller for governance. The two main purposes of this contract are summarized in the provided diagram.

5. LivepeerGovernor:

In this diagram, we illustrate how the LivepeerGovernor contract acts as the treasury governor in Livepeer. It utilizes extensions and other contracts to implement governance logic and vote management.

Libraries

1. EarningsPoolLIP36:

This library provides functions to update and calculate cumulative fee and reward factors in an EarningsPool and to calculate the cumulative stake and fees of a delegator based on these factors. The diagram includes all the functions in the library.

2. SortedArrays:

This library is useful for working with arrays of integers sorted in ascending order. In the diagram, we specify both the findLowerBound function, which is particularly useful for searching for a value in the array and finding the index of the last element that is less than or equal to the searched value, and the pushSorted function, which allows you to add values to the array while maintaining order and avoiding duplicates.

3- Livepeer Onchain Treasury Upgrade Architecture

This diagram illustrates the interaction among the key components of the Livepeer protocol. The LivepeerGovernor serves as the main governance system. The BondingManager is responsible for managing user participation, while BondingVotes is used to handle the voting logic. Lastly, the Treasury manages treasury funds and governance proposals related to the treasury. It also shows how a user engages with the system, all succinctly summarized in the diagram.

• Some potential areas of improvement or consideration could include:

  • User Experience: Enhancing the user experience for both transcoders and token holders can attract more participants. User-friendly interfaces, improved documentation, and educational resources can be beneficial.

  • Governance Flexibility: Evaluating the governance mechanisms to ensure they are adaptable and can accommodate changes as the ecosystem evolves.

  • Interoperability: Exploring interoperability with other blockchain networks or protocols can expand Livepeer's capabilities and reach.

  • Documentation and Education: Comprehensive documentation and educational materials can help users understand and navigate the Livepeer ecosystem more effectively.

4- Documents

• The documentation of the Livepeer Onchain Treasury Upgrade project is quite comprehensive and detailed, providing a solid overview of how Livepeer is structured and how its various aspects function. However, we have noticed that there is room for additional details, such as diagrams, to gain a deeper understanding of how different contracts interact and the functions they implement. With considerable enthusiasm, we have dedicated several days to creating diagrams for each of the contracts. We are confident that these diagrams will bring significant value to the protocol as they can be seamlessly integrated into the existing documentation, enriching it and providing a more comprehensive and detailed understanding for users, developers and auditors.

5- Systemic & Centralization Risks

Here's an analysis of potential systemic and centralization risks in the provided contracts:

Systemic Risks:

• Smart Contract Vulnerability Risk: Smart contracts can contain vulnerabilities that can be exploited by attackers. If a smart contract has critical security flaws, such as access errors or logic problems, this could lead to asset loss or system manipulation. We strongly recommend that, once the protocol is audited, necessary actions be taken to mitigate any issues identified by C4 Wardens.

• Third-Party Dependency Risk: Contracts rely on external data sources, such as @openzeppelin/contracts, and there is a risk that if any issues are found with these dependencies in your contracts, the Livepeer protocol could also be affected.

  • We observed that old versions of OpenZeppelin are used in the project, and these should be updated to the latest version:

    54: "@openzeppelin/contracts": "^4.9.2",
    55: "@openzeppelin/contracts-upgradeable": "^4.9.2",

  The latest version is 4.9.3 (as of July 28, 2023), while the project uses version 4.9.2.

• Update Risk: If the smart contract needs to be updated, there is a risk that updates may be implemented incorrectly or that new versions introduce vulnerabilities. Additionally, updates can lead to divisions within the user community.

  • The protocol uses a proxy, and according to the sponsor, the type of proxy is:

  victorges | livepeer — 09/2/2023 at 11:22
  it's a custom proxy implemented/documented here
  https://github.com/code-423n4/2023-08-livepeer/blob/a3d801fa4690119b6f96aeb5508e58d752bda5bc/contracts/ManagerProxy.sol#L19
  it's more similar to a "transparent proxy" pattern than UUPS, with the target contract address being managed by the controller as well

  If the logic controlling the proxy is not implemented correctly, there could be vulnerabilities that allow an attacker to modify the underlying contract or the proxy itself in an unintended way.

Centralization Risks:

• Participation Centralization: If a small group of transcoders or delegators controls a significant portion of assets or participation in the system, this could lead to significant centralization. This could undermine decentralization and system security.

• Decision-Making Centralization: If a small group of actors has disproportionate control over key decisions, such as system rule changes or reward allocation, this could lead to a centralized system where decisions are made for the benefit of a few rather than the entire community.

• Transcoder Node Centralization: If a small number of transcoders dominate the active set, this could lead to centralization in the provision of transcoding services, resulting in higher fees or the exclusion of smaller actors.

6- New insights and learning from this audit

Our latest insights from the Livepeer Onchain Treasury Upgrade protocol audit have been extensive. This audit has deepened our understanding of the Livepeer protocol upgrade, which introduces a community treasury funded by protocol rewards. The upgrade leverages OpenZeppelin governance primitives, underscoring the crucial role of auditing in upholding protocol integrity. It places particular emphasis on critical aspects like reward calculations and highlights security concerns, emphasizing the necessity of safeguarding against potential attacks to ensure ongoing system reliability. This audit has also showcased the protocol's adaptability, as it can seamlessly adjust its reward system and incorporate a community treasury.

Conclusion

Overall, the Livepeer Onchain Treasury Upgrade presents an interesting architecture aimed at establishing decentralized infrastructure for video streaming in web3 social and media applications. The development team has done a good job with the code. However, as is common in blockchain projects, Livepeer faces risks related to the security of its smart contracts and the centralization of key actors such as transcoders and delegators. Ultimately, the continued success of Livepeer will depend on its ability to address these challenges, especially after potential security issues are disclosed by C4 wardens. This will involve maintaining security and decentralization and remaining an attractive choice for web3 video streaming applications.

Time Spent ⏱

A total of 3 days were dedicated to completing this audit, distributed as follows:

1. 1st Day: Devoted to comprehending the protocol's functionalities and implementation.
2. 2nd Day: Initiated the analysis process, leveraging the documentation offered by the Livepeer Onchain Treasury Upgrade.
3. 3rd Day: Focused on conducting a thorough analysis, incorporating meticulously crafted diagrams derived from the contracts and information provided by the protocol.

Time spent:

15 hours