Tapioca DAO Invitational audit details

• Total Prize Pool: $138,000 in USDC

  • HM awards: $119,450 in USDC
  • QA awards: $2,775 in USDC
  • Gas awards: $2,775 in USDC
  • Judge awards: $12,500 in USDC
  • Scout awards: $500 in USDC

• Join C4 Discord to register

• Submit findings using the C4 form

• Read our guidelines for more details

• Starts February 26, 2024 20:00 UTC

• Ends March 18, 2024 20:00 UTC

This is a Private audit

This audit repo and its Discord channel are accessible to certified wardens only. Participation in private audits is bound by:

1. Code4rena's Certified Contributor Terms and Conditions
2. C4's Certified Contributor Code of Professional Conduct

All discussions regarding private audits should be considered private and confidential, unless otherwise indicated.

Please review the following confidentiality requirements carefully, and if anything is unclear, ask questions in the private audit channel in the C4 Discord.

Automated Findings / Publicly Known Issues

The 4naly3er report for tap-token can be found here.

Prior audits can be viewed here, and the contents of these are also considered known issues and ineligible for awards. It is recommended that wardens read both Certora reports for helpful context.

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.

Overview

The Tapioca protocol is built with a lot of different smart contracts, scattered across 5 repositories.
It's an Omnichain protocol working the LayerZero messaging layer. At its core, Tapioca ERC20/ERC721 contracts uses the LayerZero contracts and infrastructure.

The other repos are here to support the ecosystem as well as to create a synergy between the tokenomics and the protocol features.

• TapiocaBar Core logic of the protocol. This is where USDO gets minted and lent.
• tapiocaz Contracts that contains a wrapper named TOFT, which is used to wrap gas tokens and transfer allow their usage through the LayerZero network.
• YieldBox A "BentoBox v2". Acts as a vault, that allow for yield strategies to be applied on the asset.
• yieldbox-strategies Yield strategies that will be used by a YieldBox asset.

Notes

• The docs provide a lot of information about the protocol and the user flow, given the size of the protocol, we encourage checking it at https://docs.tapioca.xyz/tapioca/.

Links

• Previous audits: https://docs.tapioca.xyz/tapioca/information/security-and-integrations#audits
• Documentation: https://docs.tapioca.xyz/tapioca
• Website: https://www.tapioca.xyz
• Twitter: https://twitter.com/tapioca_dao
• Discord: https://discord.com/invite/tapiocadao

Scope

See scope.txt

tap-token

tapioca-periph

Out of scope

Contract marked by // External, which all are node_modules/ external pacakages.

Additional Context

Our implementation of TapiocaDAO's tw, otherwise known as Time Weighted Average Magnitude Lock.
tw is a mechanism proposed as a solution for promoting sustainable economic growth for a decentralized finance ecosystem, while maintaining economic alignment among its participants.

tw addresses issues created by the prevailing practice of liquidity mining, which results in small groups of opportunistic capital providers motivated solely by profit capturing all benefits at the expense of all other actors.
tw was designed with game theory concepts to reach subgame perfect Nash equilibria, in contrast with liquidity mining where Nash equilibrium cannot be reached due to the presence of a dominant strategy

Read more about twAML at: https://www.tapioca.xyz/docs/twAML.pdf

Miscellaneous:

• An EIP2612 integration for an ERC721 was used.

• transferFrom should be assumed to always be used with the Pearlmit (Uniswap's permit2 alike) contract, instead of the actual token's transferFrom.

• LayerZero composed calls are supposed to be called on independent transactions given sequential indexes. However for security purposed, all composed calls will be executed in a single transaction.

• The blockchains that should be assumed for this contest are: Arbitrum, Ethereum, Optimism, Avalanche.

• In the event of a DoS, the duration would be 8 hours.

• Please list specific ERC20 that your protocol is anticipated to interact with. Could be "any" (literally anything, fee on transfer tokens, ERC777 tokens and so forth) or a list of tokens you envision using on launch.

• Please list specific ERC721 that your protocol is anticipated to interact with.

• Which blockchains will this code be deployed to, and are considered in scope for this audit?

• Please list all trusted roles (e.g. operators, slashers, pausers, etc.), the privileges they hold, and any conditions under which privilege escalation is expected/allowable

• In the event of a DOS, could you outline a minimum duration after which you would consider a finding to be valid? This question is asked in the context of most systems' capacity to handle DoS attacks gracefully for a certain period.

• Is any part of your implementation intended to conform to any EIP's? If yes, please list the contracts in this format:

  • Contract1: Should comply with ERC/EIPX
  • Contract2: Should comply with ERC/EIPY

Main invariants

twAML Invariants

• No lock can be created and unlocked in the same block
• No lock can be created and unlocked before its (original, uint256) duration has expired.
• Given a small amount of dust, I can never reach X multiple.
• I can never lock for longer than X (intended soft max cap enforced by math if not added via require).
• The sum of all balances at a given epoch, is the sum of all active locks.
• If I could have unlocked at epoch X, then the totalSum of Balances at epoch X reflects that.

Scoping Details

- If you have a public code repo, please share it here:  N/A
- How many contracts are in scope?: 42
- Total nSLoC for these contracts?:  4207
- How many external imports are there?: N/A 
- How many separate interfaces and struct definitions are there for the contracts within scope?:
- Does most of your code generally use composition or inheritance?: Inheritance.
- How many external calls?: 
- What is the overall line coverage percentage provided by your tests?: ~70%.
- Is this an upgrade of an existing system?: False.
- Check all that apply (e.g. timelock, NFT, AMM, ERC20, rollups, etc.): Timelock, NFT, ERC20.
- Is there a need to understand a separate part of the codebase / get context in order to audit this part of the protocol?: Yes
- Please describe required context: Some functions in `tapioca-periph/Magnetar` contract targets another repository, which is `tapioca-bar`.
- Does it use an oracle?: Yes. Oracles can be found in `tapioca-periph/oracle`.
- Describe any novel or unique curve logic or mathematical models your code uses: twAMl. Explained above.
- Is this either a fork of or an alternate implementation of another project?: False.
- Does it use a side-chain?: N/A
- Describe any specific areas you would like addressed: N/A

Tests

# cloning without recurse
git clone https://github.com/code-423n4/2024-02-tapioca.git

# Root of the repo
cd 2024-02-tapioca
git submodule update --init

# tapioca-periph
cd tapioca-periph
## Setup
yarn && git submodule update --init && forge install
## Tests
forge test

# tap-token
cd ../tap-token
## Setup
yarn && git submodule update --init && forge install && cp -r ../tapioca-periph/ gitmodule/tapioca-periph/
## Tests
forge test

Miscellaneous

Employees of Tapioca and employees' family members are ineligible to participate in this audit.