- Total Prize Pool: $90,500
- High/Medium: $61,875 USDC
- Bot Race report awards: $5,625 USDC
- Analysis report awards: $3,750 USDC
- QA report awards: $1,875 USDC
- Gas report awards: $1,875 USDC
- Judge award: $9,000 USDC
- Lookout awards: $6,000 USDC
- Scout award: $500 USDC
- Join C4 Discord to register
- Submit findings using the C4 form
- Read our guidelines for more details
- Starts December 21, 2023 20:00 UTC
- Ends January 08, 2024 20:00 UTC
The 4naly3er report can be found here.
Automated findings output for the audit can be found here within 24 hours of audit opening.
Note for C4 wardens: Anything included in this Automated Findings / Publicly Known Issues section is considered a publicly known issue and is ineligible for awards.
The known issues (some of them intended by design) that are not in scope for this audit are outlined in the following:
- https://github.com/code-423n4/2023-12-autonolas/blob/main/governance/docs/Vulnerabilities_list_governance.pdf
- https://github.com/code-423n4/2023-12-autonolas/blob/main/registries/docs/Vulnerabilities_list_registries.pdf
- https://github.com/code-423n4/2023-12-autonolas/blob/main/tokenomics/docs/Vulnerabilities_list_tokenomics.pdf
- https://github.com/code-423n4/2023-12-autonolas/blob/main/lockbox-solana/docs/Vulnerabilities_list_tokenomics-solana.pdf
The current version of the lock_box.sol contact fails when doing a CPI call to the Orca Whirlpool program in the withdraw() function.
The issue is described here: CPI issue.
The withdraw() function testing is wrapped into a try-catch logic.
This audit is focused on parts of the Autonolas protocol. The protocol can be divided in three main parts: governance, registries, and tokenomics. Here is an overview of these parts.
The governance is designed to assume various control points to steer the Autonolas protocol. The veOLAS virtualized claim on OLAS Governance keys components are: a governance module, a Timelock, veOLAS. These components allow the community to propose, vote on, and implement changes. The governance token, veOLAS is the virtualized representation of OLAS locked and used a similar approach to veCRV, where votes are weighted depending on the time OLAS is locked other than the amount of locked OLAS. The maximum voting power for a fixed amount of locked OLAS can be achieved with the longest lock. In mathematical terms, voting power is calculated as amount * time_locked / MAXTIME. An overview of the governance process can be found here. While the OLAS token is a tradable utility token that will provide access to the core functionalities of the Autonolas project. The token follows the ERC20 standard and is deployed on the Ethereum mainnet. The token has an inflationary model to account for the economic primitives enabled by Autonolas tokenomics, e.g., bonding mechanism and OLAS top-up to boost developers' incentives (cf. Autonolas whitepaper). Exceptionally, some changes to the Autonolas Protocol can be executed by a community-owned multisig wallet (CM), bypassing the governance process. To align CM actions with the DAO’s intent and ensure their reversibility, a guard mechanism was introduced (see aip-3 for more details)
The core governance coordination mechanisms are anchored on a single chain. However, due to Autonolas’ multi-chain focus, Autonolas employs cross-chain governance to enable governance actions between Ethereum (L1) and L2 networks like Polygon and Gnosis Chain at present, and others in the future. For cross-chain governance, Autonolas sends messages from Ethereum-based governance contracts to the target chains, employing mechanisms like the FxPortal for Polygon and Arbitrary Message Bridge (AMB) for Gnosis Chain. Further details on Autonolas cross-chain bridging design can be found here. Whenever necessary, supplemented contracts are implemented for L1-L2 token transfers, such us the contracts enabling transfers of token deployed on Polygon to Ethereum and vice-versa based on a Polygon-native FxPortal. Motivations and design overview of token bridging between Polygon and Ethereum can be found here
Registries allow developer of code in form of agents, components, or services to register and manage their code on-chain. The code existing off-chain will be uniquely represented on-chain by means of NFTs. The registries part under audit is focussed on registrations and management of agents and components (off-chain) code uniquely represented on chain as NFTs. A summary of registries is provided here
The tokenomics aims to growth useful code and useful capital proportionally.
- Toward of growth useful code, it is incentivizes the (off-chain) creation and the (on-chain) registration of agents and components code making up useful services via the donations system. Specifically, the developers registering their code on-chain can accrue incentives proportional to their code contribution to registered service which received a donation (cf. the section How the staking model for agents and component code is incentivized).
- In order to grow useful capital, the protocol can grow its own liquidity by incentivizing liquidity providers to sell their own liquidity pairs (with one of the tokens in the pair being the protocol token, e.g. OLAS-ETH) to the protocol for OLAS at a discount (cf. the section How and when the bonding mechanism is incentivized).) Cf. the Autonolas tokenomics paper for more details.
For enabling bonding of pairs on different chains the following workflow is used:
- Move OLAS token from Ethereum to the target chain, using bridges with low trust requirements, good security, and minimal manual and team interaction to start the process.
- Create an LP-token on the target chain with the bridged OLAS token on the target chain and use popular decentralized exchanges with a Uni-v2-style AMM design.
- Transfer the LP-token back to Ethereum using the same bridge methods.
- Use the transferred LP-token for bonding in Autonolas' mechanism on Ethereum.
Whenever necessary additional contracts are deployed to enable bonding participation. This is the case for enabling bonding on Solana. Specifically, Orca AMM to create the LP-token can be used on Solana. Despite the possibility of creating full range deposit with Orca, LPs retain the ability to provide concentrated liquidity within a specific range, and as representations of their liquidity they receive non-fungible tokens. To ensure compatibility with the existing depository model a liquidity-lockbox contract is designed to encapsulate concentrated liquidity from Orca whirlpool contract and represent the liquidity with a full range with fungible tokens. More details and an overview of the design can be found here.
- Previous audits: :
The following folders containing audit-related materials associated with development progresses.
-
https://github.com/code-423n4/2023-12-autonolas/blob/main/governance/audits
-
https://github.com/code-423n4/2023-12-autonolas/blob/main/registries/audits
-
https://github.com/code-423n4/2023-12-autonolas/blob/main/tokenomics/audits
-
https://github.com/code-423n4/2023-12-autonolas/blob/main/lockbox-solana/audits
-
Documentation:
The following are relevant for governance related contracts:
- Summary of governance model
- Cross-chain governance design
- Bridging token created natively on Polygon to Ethereum and motivations
- GuardCM design and updates
The following are relevant for registries related contracts:
The following are relevant for tokenomics related contract:
-
Uniswap-v2 like pairs can be used for the depository contract, here an illustrative guide
-
Website: https://olas.network/
-
Twitter: @autonolas
-
Discord: https://discord.gg/Dh6UqUuV
| Contract | SLOC | Purpose | Libraries used |
|---|---|---|---|
| Governance contracts (11) | |||
| governance/contracts/GovernorOLAS.sol | 70 | This contract is the governance module contract | @openzeppelin/* |
| governance/contracts/Timelock.sol | 7 | This enforces a time delay on all the proposal executions. | @openzeppelin/* |
| governance/contracts/OLAS.sol | 82 | ERC20 token enabling the core functionalities of the protocol | solmate/* |
| governance/contracts/veOLAS.sol | 462 | veOLAS is a virtualized representation of the locked OLAS | @openzeppelin/* |
| governance/contracts/wveOLAS.sol | 140 | wveOLAS is a wrapper smart contract for view functions of veOLAS contract. This allows to fix non-intended view function behaviours in veOLAS | |
| governance/contracts/multisigs/GuardCM.sol | 321 | Smart contract for Gnosis Safe community multisig (CM) guard | @gnosis.pm/* |
| governance/contracts/bridges/FxGovernorTunnel.sol | 80 | Smart contract for the executing governance actions on Polygon dictated by cross-chain messages sends from Ethereum-based governance contracts | |
| governance/contracts/bridges/HomeMediator.sol | 82 | Smart contract for the executing governance actions on Gnosis chain dictated by cross-chain messages sends from Ethereum-based governance contracts | |
| governance/contracts/bridges/BridgedERC20.sol | 33 | ERC20 token representation representation of token from another chain. Token can be minted and burned by the bridge mediator contract. | solmate/* |
| governance/contracts/bridges/FxERC20ChildTunnel.sol | 52 | Smart contract for the L2 token management part | fx-portal/* |
| governance/contracts/bridges/FxERC20RootTunnel.sol | 49 | Smart contract for the L1 token management part | fx-portal/* |
| Governance interfaces (2) | |||
| governance/contracts/interfaces/IERC20.sol | 11 | ERC20 token interface | |
| governance/contracts/interfaces/IErrors.sol | 19 | Errors interface | |
| Registries contracts (8) | |||
| registries/contracts/GenericRegistry.sol | 75 | Smart contract for generic registry template | solmate/* |
| registries/contracts/UnitRegistry.sol | 151 | Smart contract for registering units (either agent or components) | |
| registries/contracts/ComponentRegistry.sol | 26 | Smart contract for registering components | |
| registries/contracts/AgentRegistry.sol | 41 | Smart contract for registering agents | |
| registries/contracts/GenericManager.sol | 33 | Smart contract for generic registry manager template | |
| registries/contracts/RegistriesManager.sol | 35 | Periphery smart contract for managing components and agents | |
| registries/contracts/multisigs/GnosisSafeMultisig.sol | 63 | Smart contract for Gnosis Safe multisig implementation of a generic multisig interface | @gnosis.pm/* |
| registries/contracts/multisigs/GnosisSafeSameAddressMultisig.sol) | 66 | Smart contract for Gnosis Safe verification of an already existent multisig address | @gnosis.pm/* |
| Registries interfaces (2) | |||
| registries/contracts/interfaces/IErrorsRegistries.sol) | 28 | Errors interface | |
| registries/contracts/interfaces/IRegistry.sol | 17 | Interface for the component / agent manipulation | |
| Tokenomics contracts (8) | |||
| tokenomics/contracts/Depository.sol | 254 | Smart contract handling the logic for creation and closure of bonding programs, and the deposits and redeems bonds | |
| tokenomics/contracts/Dispenser.sol | 65 | Smart contract for distributing code incentives | |
| tokenomics/contracts/DonatorBlacklist.sol | 42 | Smart contract for blacklisting donors | |
| tokenomics/contracts/GenericBondCalculator.sol | 44 | Smart contract for calculation of OLAS payouts for bond | [@prb-math/*]](https://github.com/PaulRBerg/prb-math) |
| tokenomics/contracts/Tokenomics.sol | 646 | Smart contract implementing the tokenomics model for code incentives and discount factor bonding mechanism regulations | |
| tokenomics/contracts/TokenomicsConstants.sol | 59 | Smart contract with tokenomics constants for annual inflation supplies | [@prb-math/*]](https://github.com/PaulRBerg/prb-math) |
| tokenomics/contracts/TokenomicsProxy.sol | 34 | Smart contract for tokenomics proxy. Proxy implementation is created based on the Universal Upgradeable Proxy Standard (UUPS) EIP-1822 | |
| tokenomics/contracts/Treasury.sol | 289 | Smart contract for managing Olas Treasury | |
| Tokenomics interfaces (10) | |||
| tokenomics/contracts/interfaces/IDonatorBlacklist.sol | 4 | DonatorBlacklist interface | |
| tokenomics/contracts/interfaces/IErrorsTokenomics.sol | 31 | Errors interface | |
| tokenomics/contracts/interfaces/IGenericBondCalculator.sol | 6 | Interface for generic bond calculator | |
| tokenomics/contracts/interfaces/IOLAS.sol | 5 | Interface for OLAS token | |
| tokenomics/contracts/interfaces/IServiceRegistry.sol | 12 | Interface for for the service registry calls | |
| tokenomics/contracts/interfaces/IToken.sol | 10 | Generic token interface for IERC20 and IERC721 tokens | |
| tokenomics/contracts/interfaces/ITokenomics.sol | 17 | Interface for tokenomics management | |
| tokenomics/contracts/interfaces/ITreasury.sol | 8 | Interface for treasury management | |
| tokenomics/contracts/interfaces/IUniswapV2Pair.sol | 7 | Uniswap v2 related interface | |
| tokenomics/contracts/interfaces/IVotingEscrow.sol | 4 | Interface for veOLAS (voting escrow) | |
| Lockbox Solana contracts (1) | |||
| lockbox-solana/solidity/liquidity_lockbox.sol | 260 | Smart contract for encapsulating concentrated liquidity from Orca whirlpool contract and represent the full range liquidity with fungible tokens | whirlpool |
| Lockbox Solana library (1) | |||
| lockbox-solana/solidity/library/spl_token.sol | 77 | This library provides a way for Solidity to interact with Solana's SPL-Token | SplToken |
-
@openzeppelin/contracts/utils/introspection/IERC165.sol
-
@openzeppelin/contracts/governance/Governor.sol
-
@openzeppelin/contracts/governance/extensions/GovernorSettings.sol
-
@openzeppelin/contracts/governance/compatibility/GovernorCompatibilityBravo.sol
-
@openzeppelin/contracts/governance/extensions/GovernorVotes.sol
-
@openzeppelin/contracts/governance/extensions/GovernorVotesQuorumFraction.sol
-
@openzeppelin/contracts/governance/extensions/GovernorTimelockControl.sol
-
@solmate/src/tokens/ERC20.sol
-
@solmate/src/tokens/ERC721.sol
-
@fx-portal/contracts/tunnel/FxBaseChildTunnel.sol
-
@fx-portal/contracts/tunnel/FxBaseRootTunnel.sol
-
@openzeppelin/contracts/governance/utils/IVotes.sol
-
@openzeppelin/contracts/token/ERC20/IERC20.sol
-
@prb/math/src/Common.sol
-
@prb/math/src/UD60x18.sol
-
@whirlpools
-
@solana
- If you have a public code repo, please share it here:
- https://github.com/valory-xyz/autonolas-governance/tree/pre-c4a
- https://github.com/valory-xyz/autonolas-registries/tree/pre-c4a
- https://github.com/valory-xyz/autonolas-tokenomics/tree/pre-c4a
- https://github.com/valory-xyz/autonolas-tokenomics-solana/tree/pre-c4a
- How many contracts are in scope?: 43
- Total SLoC for these contracts?: 3817
- How many external imports are there?: 17
- governance: @solmate/src/tokens/ERC20, OZ timelock controller, OZ IERC165, OZ governor, OZ governorSetting, OZ GovernorCompatibilityBravo, OZ GovernorVotes, OZ GovernorQuorumFraction, OZ IERC20, OZ IVotes, FxBaseChildTunnel.sol, FxBaseRootTunnel.sol, gnosis safe Enum.sol
- registries: @solmate/src/tokens/ERC721.so
- tokenomics: @prb/math/src/Common.sol, @prb/math/src/UD60x18.sol
- lockbox-solana: whirpool
- How many separate interfaces and struct definitions are there for the contracts within scope?:
- Separate interface: 14
- governance: 2
- tokenomics: 10
- registries: 2
- Struc definitions: 11
- governance: 3
- tokenomics: 6
- registries: 1
- lockbox-solana: 1
- Does most of your code generally use composition or inheritance?: Composition
- How many external calls?: 5 (Uniswap LP price, Balancer LP price, Safe enum, Safe creation, Orca whirlpool)
- What is the overall line coverage percentage provided by your tests?:
- governance: 98.72%
- tokenomics: 100%
- registries: 100%
- lockbox-solana: methods 100% covered (no way to measure as for the others)
- Is this an upgrade of an existing system?: No
- Check all that apply (e.g. timelock, NFT, AMM, ERC20, rollups, etc.):
- Timelock function
- NFT
- AMM
- Uses L2
- Multi-Chain
- Side-Chain
- ERC-20 Token
- Non ERC-20 Token
- Is there a need to understand a separate part of the codebase / get context in order to audit this part of the protocol?: No, but general context can help understanding the contract design choices, cf. [Autonolar Withepaper](https://www.autonolas.network/documents/whitepaper/Whitepaper%20v1.0.pdf)
- Please describe required context: N/A
- Does it use an oracle?: No
- Describe any novel or unique curve logic or mathematical models your code uses:
- Our governance token veOLAS adopts a similar approach to veCRV, where votes are weighted depending on the time OLAS is locked other than the amount of locked OLAS. The maximum voting power for a fixed amount of locked OLAS can be achieved with the longest lock. In mathematical terms, voting power is calculated as amount * time_locked / MAXTIME. An overview of the governance process can be found [here](https://github.com/code-423n4/2023-12-autonolas/blob/main/governance/docs/Governance_process.pdf )
- A brief overview of the tokenomics model can be found here https://github.com/code-423n4/2023-12-autonolas/blob/main/tokenomics/docs/Autonolas_tokenomics_audit.pdf. For more details, see the Tokenomics paper (cf. https://www.autonolas.network/documents/whitepaper/Autonolas_Tokenomics_Core_Technical_Document.pdf).
- A brief overview of the liquidity-loxcbox wrapper and the motivation for it can be found can be found here https://github.com/code-423n4/2023-12-autonolas/blob/main/lockbox-solana/docs/Bonding_mechanism_with_liquidity_on_Solana.pdf
- A brief overview of registries can be found here https://github.com/code-423n4/2023-12-autonolas/blob/main/registries/docs/AgentServicesFunctionality.pdf.
- Is this either a fork of or an alternate implementation of another project?: No
- Does it use a side-chain?: Yes
- Describe any specific areas you would like addressed: Funds at risk, OLAS token robustness, security of governance contracts, bridges security , CMguard contracts, correct behaviour, intended registries behaviour
The standard versions of Node.js along with Yarn are required (confirmed to work with Yarn 1.22.19 and npx/npm 10.2.0 and node v16.20.2).
cd into sub repo:
cd governance
Install the project:
yarn install
Compile the code:
npx hardhat compile
Run tests with gas report:
npx hardhat test
All the tests come with the gas
Audit findings are located here.
The list of known vulnerabilities can be found here.
cd into sub repo:
cd registries
Install the project:
yarn install
Compile the code:
npx hardhat compile
Run tests with gas report:
npx hardhat test
Note that due to some missing interaction with service registries (not part of the audit), test coverage can show lower percentage. To confirm the full coverage check https://github.com/valory-xyz/autonolas-registries/tree/pre-c4a
Audit findings are located here.
The list of known vulnerabilities can be found here.
cd into sub repo:
cd tokenomics
Install the project:
yarn install
Compile the code:
npm run compile
Run tests with Hardhat and gas report:
npx hardhat test
Audit findings are located here.
The list of known vulnerabilities can be found here.
cd into sub repo:
cd lockbox-solana
Install rust:
curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | sh
Install solana:
sh -c "$(curl -sSfL https://release.solana.com/v1.17.7/install)"
Install anchor:
cargo install --git https://github.com/coral-xyz/anchor avm --locked --force
avm install 0.29.0
avm use 0.29.0
Install the project:
yarn install
Build the code with:
anchor build
Run the validator in a separate window:
./validator.sh
Execute the testing script:
solana airdrop 10000 9fit3w7t6FHATDaZWotpWqN7NpqgL3Lm1hqUop4hAy8h --url localhost && anchor test --skip-local-validator --skip-build
Audit findings are located here.
The list of known vulnerabilities can be found here.
The current version of the code fails when doing a CPI call to the Orca Whirlpool program in the withdraw() function.
The issue is described here: CPI issue.
For the moment, the withdraw() function testing is wrapped into a try-catch logic.