[{"result":{"data":[{"id":"clw9e11e4001gdv0iigjylx5n","createdAt":"2024-05-16T15:10:39.434Z","description":"Beanstalk is a permissionless fiat stablecoin protocol built on Ethereum. Its primary objective is to incentivize independent market participants to regularly cross the price of 1 Bean over its dollar peg in a sustainable fashion.\n\nThis is the culmination of all your Beanstalk experience in one final boss code base!","content":"# Beanstalk: The Finale\n\n

\n $\"Beanstalk\"$ \n

\n\n# Contest Details\n\n### Prize Pool\n\n- Total Pool - $250,000\n- H/M - $220,000\n- Low - $10,000\n- Community Judging - $20,000\n- Starts: Monday, May 30, 2024\n- Ends: Monday, July 8, 2024\n\n### Stats\n\n- nSLOC: 12,285\n- Complexity Score: 7810\n\n## About\n\nBeanstalk is a permissionless fiat stablecoin protocol built on Ethereum. Its primary objective is to incentivize independent market participants to regularly cross the price of 1 Bean over its dollar peg in a sustainable fashion.\n\nBeanstalk does not have any collateral requirements. Beanstalk uses credit instead of collateral to create Bean price stability relative to its value peg of $1. The practicality of using DeFi is currently limited by the lack of decentralized low-volatility assets with competitive carrying costs. Borrowing rates on USD stablecoins have historically been higher than borrowing rates on USD, even when supply increases rapidly. Non-competitive carrying costs are due to collateral requirements.\n\nIn particular, this audit is centered around the changes included in the Beanstalk 3 upgrade, details for which can be found under the Scope section. While all Beanstalk contracts will be in scope for this audit, it is recommended that Hawks spend time focused on the new and unaudited changes in the Beanstalk 3 upgrade. It is estimated that about 30-40% of the code in this audit is new and unaudited.\n\nYou can read an overview of how Beanstalk works [here](https://docs.bean.money/almanac/introduction/how-beanstalk-works).\n\n- [Docs](https://docs.bean.money/)\n- [Whitepaper](https://bean.money/beanstalk.pdf)\n- [Website](https://bean.money/)\n- [Beanstalk Farms Twitter](https://twitter.com/BeanstalkFarms)\n- [Beanstalk Public GitHub Repo](https://github.com/BeanstalkFarms/Beanstalk)\n\n## Actors\n\n- Stalkholder / Silo Member\n - Anyone who Deposits assets on the Deposit Whitelist into the Silo, earning the illiquid Stalk token in doing so. Stalkholders participate in governance and earn Bean seigniorage.\n- `gm` caller\n - Anyone who calls the `gm` function to start the next Season.\n- Unripe holder\n - Anyone who holds Unripe Beans or Unripe LP. These assets were distributed to holders of BDV (Bean Denominated Value) at the time of the April 2022 governance exploit. Most Unripe holders have their Unripe assets Deposited in the Silo, and thus are also Stalkholders.\n- Fertilizer holder\n - Anyone who holds Fertilizer, the debt asset earned by participating in Beanstalk's recapitalization.\n- Pod holder\n - Anyone who holds Pods, the Beanstalk-native debt asset. Pods are minting when lending Beans to Beanstalk (Sowing Beans).\n\n## Scope\n\nThe following contracts are in scope.\n\nThe [Beanstalk 3 PR](https://github.com/BeanstalkFarms/Beanstalk/pull/909/files) on the public Beanstalk GitHub repo may be a useful reference for determining which code is new and unaudited.\n\n```js\nprotocol/\n└── contracts/\n ├── beanstalk/\n │ ├── Diamond.sol\n │ ├── Invariable.sol\n │ ├── ReentrancyGuard.sol\n │ ├── barn/\n │ │ ├── FertilizerFacet.sol\n │ │ └── UnripeFacet.sol\n │ ├── diamond/\n │ │ ├── DiamondCutFacet.sol\n │ │ ├── DiamondLoupeFacet.sol\n │ │ ├── OwnershipFacet.sol\n │ │ └── PauseFacet.sol\n │ ├── farm/\n │ │ ├── DepotFacet.sol\n │ │ ├── FarmFacet.sol\n │ │ ├── TokenFacet.sol\n │ │ ├── TokenSupportFacet.sol\n │ │ └── TractorFacet.sol\n │ ├── field/\n │ │ └── FieldFacet.sol\n │ ├── init/\n │ │ └── reseed/\n │ │ ├── L1/\n │ │ │ └── ReseedL2Migration.sol\n │ │ └── L2/\n │ │ ├── ReseedBarn.sol\n │ │ ├── ReseedBean.sol\n │ │ ├── ReseedField.sol\n │ │ ├── ReseedInternalBalances.sol\n │ │ ├── ReseedSilo.sol\n │ │ ├── ReseedSun.sol\n │ │ └── ReseedWhitelist.sol\n │ ├── market/\n │ │ └── MarketplaceFacet/\n │ │ ├── Listing.sol\n │ │ ├── MarketplaceFacet.sol\n │ │ ├── Order.sol\n │ │ └── PodTransfer.sol\n │ ├── metadata/\n │ │ ├── MetadataFacet.sol\n │ │ └── MetadataImage.sol\n │ ├── migration/\n │ │ ├── BeanL1RecieverFacet.sol\n │ │ ├── BeanL2MigrationFacet.sol\n │ │ ├── L1AppStorage.sol\n │ │ ├── L1Libraries/\n │ │ │ ├── LibBalance.sol\n │ │ │ ├── LibEth.sol\n │ │ │ ├── LibL1AppStorage.sol\n │ │ │ ├── LibTokenApprove.sol\n │ │ │ ├── LibTransfer.sol\n │ │ │ └── LibWeth.sol\n │ │ ├── L1ReentrancyGuard.sol\n │ │ └── L1TokenFacet.sol\n │ ├── silo/\n │ │ ├── ApprovalFacet.sol\n │ │ ├── BDVFacet.sol\n │ │ ├── ConvertFacet.sol\n │ │ ├── ConvertGettersFacet.sol\n │ │ ├── EnrootFacet.sol\n │ │ ├── L2ContractMigrationFacet.sol\n │ │ ├── PipelineConvertFacet.sol\n │ │ ├── SiloFacet/\n │ │ │ ├── SiloFacet.sol\n │ │ │ ├── SiloGettersFacet.sol\n │ │ │ └── TokenSilo.sol\n │ │ └── WhitelistFacet/\n │ │ ├── WhitelistFacet.sol\n │ │ └── WhitelistedTokens.sol\n │ ├── storage/\n │ │ ├── Account.sol\n │ │ ├── AppStorage.sol\n │ │ └── System.sol\n │ └── sun/\n │ ├── GaugePointFacet.sol\n │ ├── LiquidityWeightFacet.sol\n │ ├── OracleFacet.sol\n │ └── SeasonFacet/\n │ ├── Distribution.sol\n │ ├── Oracle.sol\n │ ├── SeasonFacet.sol\n │ ├── SeasonGettersFacet.sol\n │ ├── Sun.sol\n │ └── Weather.sol\n ├── ecosystem/\n │ ├── Drafter.sol\n │ ├── ShipmentPlanner.sol\n │ ├── junction/\n │ │ ├── Junction.sol\n │ │ ├── LogicJunction.sol\n │ │ └── MathJunction.sol\n │ ├── oracles/\n │ │ └── UsdOracle.sol\n │ ├── price/\n │ │ ├── BeanstalkPrice.sol\n │ │ ├── P.sol\n │ │ └── WellPrice.sol\n ├── libraries/\n │ ├── Convert/\n │ │ ├── LibChopConvert.sol\n │ │ ├── LibConvert.sol\n │ │ ├── LibConvertData.sol\n │ │ ├── LibLambdaConvert.sol\n │ │ ├── LibPipelineConvert.sol\n │ │ ├── LibUnripeConvert.sol\n │ │ └── LibWellConvert.sol\n │ ├── Decimal.sol\n │ ├── LibAppStorage.sol\n │ ├── LibBarnRaise.sol\n │ ├── LibBytes.sol\n │ ├── LibBytes64.sol\n │ ├── LibCases.sol\n │ ├── LibChop.sol\n │ ├── LibClipboard.sol\n │ ├── LibDiamond.sol\n │ ├── LibDibbler.sol\n │ ├── LibEvaluate.sol\n │ ├── LibFarm.sol\n │ ├── LibFertilizer.sol\n │ ├── LibFunction.sol\n │ ├── LibGauge.sol\n │ ├── LibIncentive.sol\n │ ├── LibLockedUnderlying.sol\n │ ├── LibMarket.sol\n │ ├── LibPRBMathRoundable.sol\n │ ├── LibReceiving.sol\n │ ├── LibRedundantMath128.sol\n │ ├── LibRedundantMath256.sol\n │ ├── LibRedundantMath32.sol\n │ ├── LibRedundantMathSigned128.sol\n │ ├── LibRedundantMathSigned256.sol\n │ ├── LibRedundantMathSigned96.sol\n │ ├── LibShipping.sol\n │ ├── LibTractor.sol\n │ ├── LibUnripe.sol\n │ ├── Minting/\n │ │ ├── LibMinting.sol\n │ │ └── LibWellMinting.sol\n │ ├── Oracle/\n │ │ ├── LibChainlinkOracle.sol\n │ │ ├── LibDeltaB.sol\n │ │ ├── LibEthUsdOracle.sol\n │ │ ├── LibOracleHelpers.sol\n │ │ ├── LibUniswapOracle.sol\n │ │ ├── LibUsdOracle.sol\n │ │ ├── LibWstethEthOracle.sol\n │ │ └── LibWstethUsdOracle.sol\n │ ├── Silo/\n │ │ ├── LibFlood.sol\n │ │ ├── LibGerminate.sol\n │ │ ├── LibSilo.sol\n │ │ ├── LibSiloPermit.sol\n │ │ ├── LibTokenSilo.sol\n │ │ ├── LibWhitelist.sol\n │ │ └── LibWhitelistedTokens.sol\n │ ├── Token/\n │ │ ├── LibApprove.sol\n │ │ ├── LibBalance.sol\n │ │ ├── LibEth.sol\n │ │ ├── LibTokenApprove.sol\n │ │ ├── LibTokenPermit.sol\n │ │ ├── LibTransfer.sol\n │ │ └── LibWeth.sol\n │ └── Well/\n │ ├── LibWell.sol\n │ └── LibWellBdv.sol\n └── tokens/\n ├── Bean.sol\n ├── ERC20/\n │ └── BeanstalkERC20.sol\n └── Fertilizer/\n ├── Fertilizer.sol\n ├── Fertilizer1155.sol\n └── Internalizer.sol\n```\n\n### Changes\n\nThe Beanstalk 3 upgrade includes implementations of:\n\n- [RFC: Generalized Convert](https://github.com/BeanstalkFarms/Beanstalk/issues/716);\n- [RFC: Generalized Flood](https://github.com/BeanstalkFarms/Beanstalk/issues/740);\n- [RFC: Tractor](https://github.com/BeanstalkFarms/Beanstalk/issues/734);\n- [RFC: Secure Beanstalk](https://github.com/BeanstalkFarms/Beanstalk/issues/729), which includes:\n - Upgrading the test suite to support Foundry;\n - Upgrading the Solidity version of Beanstalk from 0.7.6 to 0.8.20;\n - Migrating constants to state that are likely to be adjusted by the DAO in the future;\n- Whitelist v1.1 (discussed later);\n- Field V2 (discussed later); and\n- A series of contracts that can be used to migrate Beanstalk's state to an Ethereum L2.\n\n#### Whitelist v1.1\n\nWhitelisting a Well requires code changes to the Beanstalk contracts. While the changes can potentially be minimal, they ultimately increase the friction associated with whitelisting a Well. Ideally, the DAO can whitelist a Well with the `init` function of a diamond cut.\n\nThus, we propose to implement a generalized oracle, liquidity weight function and Gauge Point function.\n\n#### Field V2\n\nBeanstalk cannot easily add, modify or remove Yield Distributors, i.e., places where new Bean mints are allocated (currently the Silo, Field and Barn). It also cannot easily change the distribution of new Bean mints between various Yield Distributors.\n\nBeanstalk cannot support multiple Pod Lines, it cannot easily add, modify or remove Pod Lines and it cannot control the issuance of debt to particular Pod Lines.\n\nThus, we propose a generalized yield distribution system and Pod Line system. For reference, see [Temp-Check-4](https://snapshot.org/#/beanstalkfarms.eth/proposal/0xc716cb01aeecc01ea4127ace7219e7efe644e8173d228c6b6ff9331c4d373222).\n\n#### L2 Migration\n\nBeanstalk is a fairly gaseous protocol. While the costs of interacting with Beanstalk at the time of writing in May 2024 are reasonable, activity on Ethereum L1 is currently low. In the past when Gwei has reached mid to high double digit values, interacting with Beanstalk (such as Mowing, Planting, or Converting) have cost upwards of several hundred US dollars. This prices out smaller Farmers and reduces the efficacy of Beanstalk's peg maintenance mechanisms.\n\nThus, we propose a series of initialization scripts that migrate Beanstalk state to an L2 and a facet to allow smart contract addresses to choose an address on the L2 to claim their assets with. For reference, see [Temp-Check-5](https://snapshot.org/#/beanstalkfarms.eth/proposal/0x93dfc538a66c1c199f5c9f0fd9c0233ce3625c7ada9743bafc8b5fbc0fc38fc7).\n\n## Compatibilities\n\nBeanstalk implements the [ERC-2535 Diamond standard](https://docs.bean.money/developers/overview/eip-2535-diamond). It supports various whitelists for [Deposits](https://docs.bean.money/almanac/farm/silo#deposit-whitelist), [Minting](https://docs.bean.money/almanac/farm/sun#minting-whitelist), [Converts](https://docs.bean.money/almanac/peg-maintenance/convert#convert-whitelist), etc., particularly for LP tokens from [Basin](https://basin.exchange/).\n\nBlockchains:\n\n- Ethereum\n\nTokens:\n\n- ERC-20 (all are accepted in Farm balances, a whitelist is accepted on the Deposit Whitelist, etc.)\n- ERC-1155 (Fertilizer and Deposits are ERC-1155 tokens)\n\n## Setup\n\nInstall node version v16.20.0, using nvm or any node version package manager:\n\n```\nnvm install v16.20.0\n```\n\nClone the contest repo:\n```\ngit clone https://github.com/Cyfrin/2024-05-beanstalk-the-finale.git\ncd 2024-05-beanstalk-the-finale\n```\n\nInstall dependencies:\n\n```\ncd protocol\nyarn\n```\n\nAdd RPCs for mainnet testing. You can get a basic RPC from sites such as https://www.alchemy.com/:\n\n```bash\nexport FORKING_RPC={MAINNET_RPC}\n\nexport BASE_FORKING_RPC={BASE_RPC}\n```\n\nGenerate:\n\n```bash\nyarn generate\nyarn hardhat mockDiamondABI\n```\n\nTo run foundry tests:\n\n```bash\nfoundryup\nforge install foundry-rs/forge-std\nforge test\n```\n\nTo run hardhat tests:\n\n```bash\nyarn hardhat test\n```\n\n## Known Issues\n\nAll findings in the following resources are considered known issues:\n\n- All Beanstalk audit reports listed in this [repository](https://github.com/BeanstalkFarms/Beanstalk-Audits);\n- All bug reports from the Immunefi program listed [here](https://community.bean.money/bug-reports);\n- All reports and known issues in past Beanstalk Codehawks audits:\n - [Beanstalk Codehawks Part 1](https://www.codehawks.com/report/clsxlpte900074r5et7x6kh96);\n - [Beanstalk Codehawks Part 2](https://www.codehawks.com/report/clu7665bs0001fmt5yahc8tyh); and\n - [Beanstalk Codehawks Part 3](https://www.codehawks.com/contests/clvo5kwin00078k6jhhjobn22).\n- Additional Known Issues as detected by LightChaser available [here](https://github.com/Cyfrin/2024-05-beanstalk-the-finale/issues/1)\n","updatedAt":"2024-06-05T16:42:38.593Z","company":"Beanstalk","name":"Beanstalk: The Finale","logo":null,"logoImgPublicId":"company/m5oacju1uewfxdifcnfb","featuredImgPublicId":"featured/iqwldbeuykl2cbqcpjvc","forceFeatured":false,"reward":250000,"rewardHighMedium":220000,"rewardLow":10000,"rewardCommunityJudging":20000,"maxRewardedCommunityJudgingPosition":5,"xpBoost":0,"communityJudgingScoreToXpMultiplier":0,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2024-05-beanstalk-the-finale","telegram":"","discord":"","twitter":"BeanstalkFarms","github":"BeanstalkFarms","linkedIn":"","email":"","startDate":"2024-05-30T12:00:00.000Z","endDate":"2024-07-08T12:00:00.000Z","communityJudgingEnabled":true,"communityJudgingStartDate":"2024-07-08T13:00:00.000Z","communityJudgingEndDate":null,"userId":"clldzdkk60000mr082grbuj97","leadJudgeId":null,"firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"JUDGING","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":true,"cjEligibilityPreviousValidSubmission":true,"cjEligibilityPreviousMonetaryReward":true},{"id":"clwgjlhig0015rbi5sssuk0qe","createdAt":"2024-05-21T15:20:54.760Z","description":"TSender is a hyper gas efficient protocol for air dropping tokens to a large number of users. Inspired by the work of the Gaslite team. ","content":"# TSender\n\n

\n $\"gas-vs-1.png\"$ \n
\n\n# Contest Details\n\n### Prize Pool\n\n- Total Prize Pool: $15,000\n- H/M - $12,500\n- Low - $1,375\n- Community judging: $1,125\n\n- Starts: May 24, 2024 Noon UTC\n- Ends: May 31, 2024 Noon UTC\n\n### Stats\n\n- nSLOC: 256\n- Complexity Scope: 284\n\n## Percent Gas Efficiency Improvement vs Solidity\n\n

\n $\"gas-vs-1.png\"$ \n
\n\n- [TSender](#tsender)\n- [Contest Details](#contest-details)\n - [Prize Pool](#prize-pool)\n - [Stats](#stats)\n - [Percent Gas Efficiency Improvement vs Solidity](#percent-gas-efficiency-improvement-vs-solidity)\n- [About](#about)\n - [TSender Features](#tsender-features)\n - [GasliteDrop Comparison](#gaslitedrop-comparison)\n - [Gas Comparisons](#gas-comparisons)\n - [Efficiency Improvement vs Solidity](#efficiency-improvement-vs-solidity)\n - [Actual Gas Costs](#actual-gas-costs)\n- [Getting Started](#getting-started)\n - [Requirements](#requirements)\n - [foundry-zksync](#foundry-zksync)\n - [Installation](#installation)\n - [Quickstart / Usage](#quickstart--usage)\n - [Testing](#testing)\n - [Testing with zkSync](#testing-with-zksync)\n - [Why no stateful fuzz tests?](#why-no-stateful-fuzz-tests)\n - [Deployment](#deployment)\n- [Audit Data](#audit-data)\n - [Known issues](#known-issues)\n - [Expected Token Integrations](#expected-token-integrations)\n - [Scope](#scope)\n - [Chain compatibility](#chain-compatibility)\n - [Target deployment chains](#target-deployment-chains)\n - [Notes](#notes)\n- [Acknowledgements](#acknowledgements)\n\n# About\n\nHyper gas efficient smart contracts for air dropping tokens to a large number of users. Inspired by the work of the [Gaslite team](https://github.com/PopPunkLLC/GasliteDrop/tree/main). In the `src` folder, we have 4 main contracts:\n\n- `TSender.sol`: The Yul/Solidity implementation\n- `TSender.huff`: The Huff implementation\n- `TSender_NoCheck.huff`: The Huff implementation without the extra checks, making the output similar to `GasliteDrop`. Much more gas efficient, but without any safety rails.\n- `TSenderReference.sol`: The pure Solidity implementation\n\nEach contract has 1 or 2 functions:\n\n- `airdropERC20` (required): A function that takes in an array of recipients and an array of amounts, and sends the amounts to the recipients.\n- `areValidLists` (optional): A function that takes in an array of recipients and an array of amounts, and checks if the lists are valid.\n\n## TSender Features\n\n- Checks the `totalAmount` parameter matches the sum of the `amounts` array\n- Doesn't allow ETH to be sent with function calls\n- Makes sure the total lengths of the `amounts` array and `recipients` array are the same\n- Checks for zero address recipients\n\nAdditionally, we did not want to spend gas checking a few things, so we added a function called `areListsValid` that takes in a `address[] recipients` and `uint256[] amounts` to check for:\n\n- Duplicate addresses\n- Zero address sends\n- There is at least 1 recipient\n- All amounts are > 0\n- recipients.length == amounts.length\n\n## GasliteDrop Comparison\n\nThe work here was inspired by the [Gaslite team](https://github.com/PopPunkLLC/GasliteDrop/tree/main) with a few changes.\n\n1. The Yul & Huff have added safety checks (see [TSender Features](#tsender-features))\n2. The `TSender_NoCheck.huff` does not have the extra checks, but is just a gas optimized version of the original GasliteDrop contract.\n\n## Gas Comparisons\n\n> Note: Since our implementation adds more checks, the Huff code is slightly _less_ gas efficient when working with additional recipients than the original gaslite codebase, but it is a safer smart contract. However, we did include a Huff contract the did not include those checks to show the power of using Huff to reduce gas costs.\n\n### Efficiency Improvement vs Solidity\n\n| # of recipients | Yul | Gaslite | Huff | Huff (No Checks) |\n| --------------- | ----- | ------- | ----- | ---------------- |\n| 1 | 2.10% | 2.26% | 3.42% | 3.61% |\n| 10 | 3.23% | 3.38% | 3.51% | 3.65% |\n| 100 | 3.48% | 3.62% | 3.52% | 3.66% |\n| 1000 | 3.51% | 3.66% | 3.53% | 3.66% |\n\n### Actual Gas Costs\n\n| | Solidity | Yul | Gaslite | Huff | Huff, no check |\n| -------------------- | -------- | -------- | -------- | -------- | -------------- |\n| 1 Recipient Drop | 57377 | 56170 | 56080 | 55409 | 55300 |\n| 10 Recipient Drops | 295287 | 285737 | 285296 | 284931 | 284507 |\n| 100 Recipient Drops | 2674618 | 2581616 | 2577665 | 2580360 | 2576786 |\n| 1000 Recipient Drops | 26490540 | 25561280 | 25522229 | 25555524 | 25520450 |\n\n

\n $\"gas-vs-1000.png\"$ \n
\n\n# Getting Started\n\n## Requirements\n\n- [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)\n - You'll know you did it right if you can run `git --version` and you see a response like `git version x.x.x`\n- [foundry](https://getfoundry.sh/)\n - You'll know you did it right if you can run `forge --version` and you see a response like `forge 0.2.0 (816e00b 2023-03-16T00:05:26.396218Z)`\n- [huff](https://docs.huff.sh/get-started/installing/)\n - You'll know you did it right if you can run `huffc --version` and you see a response like `huffc 0.3.2`\n- [halmos](https://github.com/a16z/halmos)\n - You'll know you've done it right if you can run `halmos --version` and you see a response like `Halmos 0.1.12`\n\n### foundry-zksync\n\nWhen we work with zksync, we plan to use [foundry-zksync](https://github.com/matter-labs/foundry-zksync). You'll know you did it right if you can run `forge --version` and you see a response like `forge 0.0.2 (816e00b 2023-03-16T00:05:26.396218Z)`. At the moment, it doesn't play nicely with Huff, so when we go to build with zksync, we remove all the Huff related code.\n\n## Installation\n\n```bash\ngit clone https://github.com/cyfrin/2024-05-TSender\ncd 2024-05-TSender\nmake\n```\n\n## Quickstart / Usage\n\n### Testing\n\nTo test the codebase, you can run the following 2 commands:\n\n```bash\nmake test\nmake halmos\n```\n\n### Testing with zkSync\n\nTo test with zkSync, we must first remove our `Huff` tests. We will not be deploying the huff code to zkSync, and the codebases doesn't play nice with `foundry-zksync`.\n\nTo run zkSync tests:\n\n1. Comment out the following files\n 1. `TSenderHuffTest.t.sol`\n 2. `TSenderHuffNoCheckTest.t.sol`\n 3. `EquivalenceTest.sol`\n 4. `DeployHuff.s.sol`\n You'll need to leave this line uncommented in each file:\n\n```javascript\npragma solidity 0.8.24;\n```\n\n1. Run the tests:\n\n```bash\nmake zktest\n```\n\nor\n\n```\nforge test --zksync\n```\n\n_We have an issue in `foundry-zksync` to fix the issue with `avoid-contracts`. That would be the ideal solution in the future._\n\n#### Why no stateful fuzz tests?\n\nOur contract is expected to never have state. There are no `SSTORE` opcodes in the bytecode of this contract.\n\n### Deployment\n\nYou'll need to uncomment out the `DeployHuff.s.sol` codebase. It's commented out because zkSync has a hard time compiling it at the moment. This is ok because we do not intend to deploy huff to zksync.\n\n```\nmake deployYul\nmake deployHuff\n```\n\n# Audit Data\n\n## Known issues\n\n- Does not work with fee-on-transfer tokens\n- Does not check the return value of ERC20s, but it does check to see if the `transferFrom` or `transfer` call was successful. Meaning ERC20s that return `false` on a failed `transfer` or `transferFrom` but successfully execute, are not supported. If any of the expected token integrations are vulnerable to this pattern, flag it.\n- Upgradable/Deny List tokens can prevent this contract from working. We expect that, in the case that this contract or any recipient is on a deny list, the entire transaction will revert.\n\n## Expected Token Integrations\n\n- USDC\n- USDT\n- LINK\n- WETH\n\n## Scope\n\n```bash\n#-- interfaces\n| #-- ITSender.sol\n#-- protocol\n| #-- TSender.huff\n| #-- TSender.sol\n| #-- TSender_NoCheck.huff\n```\n\nIgnore:\n\n```bash\n#-- reference\n #-- TSenderReference.sol\n#-- script/\n```\n\nDeploy scripts are not in scope because we can easily redeploy if we have an issue.\n\n## Chain compatibility\n\nWe expect to be able to run our deploy scripts, and it will prevent us from deploying contracts to chains that are not supported. Right now, zkSync will work with the `yul` based `TSender.sol`, and all other chains listed in the `HelperConfig.sol` will work with the `TSender.huff` contract.\n\n### Target deployment chains\n\n- `TSender.sol`:\n - zkSync Era\n - Everything in the `TSender.huff` list\n- `TSender.huff`:\n - Ethereum\n - Arbitrum\n - Optimism\n - Base\n - Blast\n\n## Notes\n\n- There is an issue with how quickly the `foundry-zksync` compiler works, so we avoid compiling the `DeployHuff.s.sol` contract.\n- Compliation takes a _long_ time, so run tests accordingly. It may make sense to run tests with the standard foundry implementation before swapping to the `foundry-zksync` implementation.\n- Please take note of the target deployment chains during audit and check to see if our Huff or Solidity will work there.\n\n# Acknowledgements\n\n- [Gaslite](https://github.com/PopPunkLLC/GasliteDrop)\n- [PopPunkOnChain](https://twitter.com/PopPunkOnChain)\n- [Vectorized](https://github.com/Vectorized/)\n- [backseats_eth](https://twitter.com/backseats_eth)\n","updatedAt":"2024-06-06T17:40:45.471Z","company":"Cyfrin","name":"TSender","logo":null,"logoImgPublicId":"company/wb97ctb1ksvswgpnur5h","featuredImgPublicId":"featured/sdolg0f5iqohvnaobsdj","forceFeatured":false,"reward":15000,"rewardHighMedium":12500,"rewardLow":1375,"rewardCommunityJudging":1125,"maxRewardedCommunityJudgingPosition":5,"xpBoost":0,"communityJudgingScoreToXpMultiplier":0,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2024-05-TSender","telegram":"","discord":"https://discord.gg/cyfrin","twitter":"CodeHawks","github":"Cyfrin","linkedIn":"","email":"","startDate":"2024-05-24T12:00:00.000Z","endDate":"2024-05-31T12:00:00.000Z","communityJudgingEnabled":true,"communityJudgingStartDate":"2024-05-31T13:00:00.000Z","communityJudgingEndDate":"2024-06-03T13:00:00.000Z","userId":"clldzdkk60000mr082grbuj97","leadJudgeId":"clkgm90b9000gms085g528phk","firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":true,"cjEligibilityPreviousValidSubmission":true,"cjEligibilityPreviousMonetaryReward":true},{"id":"clvb9njmy00012dqjyaavpl44","createdAt":"2024-04-22T18:04:01.450Z","description":"Sablier is a permissionless token distribution protocol for ERC-20 assets. It can be used for vesting, payroll, airdrops, and more.\n\nThe sender of a payment stream first deposits a specific amount of ERC-20 tokens in a contract. Then, the contract progressively allocates the funds to the recipient, who can access them as they become available over time. The payment rate is influenced by various factors such as the start time, the end time, the total amount of tokens deposited and the type of stream.","content":"

\n $\"project-name\"$ \n

\n\n# Contest Details\n\n### Prize Pool\n\n- Total Pool - $53,440\n- H/M - $45,000\n- Low - $3,100\n- Community Judging Pool - $5,340\n\n- Starts: May 10, 2024 Noon UTC\n- Ends: May 31, 2024 Noon UTC\n\n### Stats\n\n- Total nSLOC: 2655\n- $/nSloc: $20\n\n## About\n\nSablier is a permissionless token distribution protocol for ERC-20 assets. It can be used for vesting, payroll, airdrops, and more.\n\nThe sender of a payment stream first deposits a specific amount of ERC-20 tokens in a contract. Then, the contract progressively allocates the funds to the stream recipient, also known as the Sablier NFT owner, who can access them as they become available over time. The payment rate is influenced by various factors such as the start time, the end time, the total amount of tokens deposited and the type of stream.\n\nThere are two repositories:\n\n### **v2-core**\n\nCore contracts facilitate the creation of three types of streams:\n\n1. **Lockup Linear**: This stream linearly unlocks assets over time.\n\n2. **Lockup Tranched**: Assets in this stream are unlocked in scheduled tranches such as monthly. This stream will be launching in v2.2.\n\n3. **Lockup Dynamic**: Our most versatile stream, allowing users to create various unlocking curves including exponential, unlock cliff, and timelock.\n\nFor additional details on how these streams work, please refer to our [documentation](https://docs.sablier.com/concepts/protocol/streaming). Note that the documentation is for v2.1, while the contracts in this contest apply to v2.2.\n\n### **v2-periphery**\n\nPeriphery contracts interact with core contracts and consist of two primary contracts:\n\n1. **Batch contract** enabled the creation of multiple streams within a single transaction.\n2. **Merkle Lockup contracts** support the distribution of vesting airdrops. A Merkle lockup contract is created using a factory contract and contains a Merkle tree root with details on airdrop recipients and amounts. Once deployed, recipients can claim their airdrops via the Merkle lockup contract. These are then distributed as Sablier streams, called as [Airstreams](https://docs.sablier.com/concepts/protocol/airstreams). Moreover, there is a grace period during which the airdrop creator can clawback unclaimed funds.\n\n### Useful links:\n\n[Previous audits](https://github.com/sablier-labs/audits)\n\n[Sablier's Website](https://sablier.com/)\n\n[Documentation](https://docs.sablier.com/)\n\n[GitHub](https://github.com/sablier-labs)\n\n[Warpcast](https://warpcast.com/sablier)\n\n[X](https://twitter.com/Sablier)\n\n## Actors\n\nThere are three roles assumed by actors in the Sablier protocol:\n\n### Recipient\n\nUsers who are the recipients of the streams. These users own the Sablier NFT which grants them the right to withdraw assets from the stream.\n\n### Sender\n\nUsers who create streams and are responsible for funding them. Senders are also authorized to cancel and renounce streams. These users can also trigger withdrawals on behalf of the recipients but only to the recipient's address.\n\n### Unknown caller\n\nThese are callers who are neither Sender nor Recipient but are allowed to trigger withdrawals on behalf of the recipients. This is because the withdraw function is publicly callable. Note that an unknown caller can withdraw assets only to the recipient's address.\n\n## Scope (contracts)\n\n### v2-core\n\n```tree\nsrc\n├── abstracts\n│ ├── Adminable.sol - A minimalist implementation to handle admin access\n│ ├── NoDelegateCall.sol - A minimalist implementation to prevent delegate calls\n│ └── SablierV2Lockup.sol - Handles common logic between all Sablier V2 Lockup contracts\n├── libraries\n│ ├── Errors.sol - Library containing all custom errors used in the Sablier protocol\n│ ├── Helpers.sol - Helpers to calculate and validate input data required to create streams\n│ ├── NFTSVG.sol - Library to generate NFT SVG\n│ └── SVGElements.sol - Library to generate specific components of NFT SVG\n├── types\n│ └── DataTypes.sol - Implementation for a set of custom data types used in V2 core\n├── SablierV2LockupDynamic.sol - Creates and manages Lockup streams with a dynamic distribution function\n├── SablierV2LockupLinear.sol - Creates and manages Lockup streams with a linear distribution function\n├── SablierV2LockupTranched.sol - Creates and manages Lockup streams with a tranched distribution function\n└── SablierV2NFTDescriptor.sol - Generates the URI describing the Sablier V2 stream NFTs\n```\n\n### v2-periphery\n\n```tree\nsrc\n├── abstracts\n│ └── SablierV2MerkleLockup.sol - Handles common logic between all Airstream campaigns\n├── libraries\n│ └── Errors.sol - Library containing all custom errors used in the Sablier protocol\n├── types\n│ └── DataTypes.sol - Implementation for a set of custom data types used in V2 periphery\n├── SablierV2BatchLockup.sol - Helpers to batch create Sablier V2 Lockup streams\n├── SablierV2MerkleLL.sol - Allows users to claim Airdrops using Merkle proofs. These airdrops are powered by Lockup Linear streams\n├── SablierV2MerkleLT.sol - Allows users to claim Airdrops using Merkle proofs. These airdrops are powered by Lockup Tranched streams\n└── SablierV2MerkleLockupFactory.sol - Factory for deploying Airdrop campaigns using CREATE\n```\n\n## Compatibilities\n\nSablier protocol is compatible with the following:\n\n1. Any network which is EVM compatible\n2. Any ERC20 token\n\nIts not compatible with:\n\n1. Any network which is not EVM compatible\n2. Any token standard other than ERC20\n3. Rebased ERC20 tokens can be used but yield will be lost\n4. Ether (ETH)\n\n## Setup\n\nClone the contest repository:\n\n```bash\ngit clone https://github.com/Cyfrin/2024-05-Sablier.git\ncd 2024-05-Sablier\ncode .\n```\n\nThen either go to `v2-core` or `v2-periphery`.\n\n```bash\n$ cd v2-core\n```\n\nOnce you are inside the project directory, run the following commands to install Node.js dependencies and build the contracts:\n\n```bash\n$ bun install --frozen-lockfile\n$ bun run build\n```\n\nTo see a list of available scripts:\n\n```bash\n$ bun run\n```\n\nTo run tests:\n\n```bash\n$ bun run test --no-match-test testFork\n```\n\nTo run fork tests against the Ethereum mainnet, follow the below instructions:\n\n1. copy the `.env.example` file to create a `.env` file\n2. Set `RPC_URL_MAINNET` to the URL of your mainnet RPC endpoint.\n\nThen use the below command to run fork tests:\n\n```bash\n$ bun run test --match-test testFork\n```\n\n## Assumptions\n\nThe protocol makes the following assumptions:\n\n1. The total supply of any ERC-20 token remains below `type(uint128).max`.\n\n2. The `transfer` and `transferFrom` methods of any ERC-20 token strictly reduce the sender's balance by the transfer amount and increase the recipient's balance by the same amount. In other words, tokens that charge fees on transfers are not supported.\n\n3. An address's ERC-20 balance can only change as a result of a `transfer` call by the sender or a `transferFrom` call by an approved address. This excludes rebase tokens and interest-bearing tokens.\n\n4. The token contract does not allow callbacks (e.g. ERC-777 is not supported).\n\n### v2-core\n\n1. The immutable variables `MAX_SEGMENT_COUNT` and `MAX_TRANCHE_COUNT` have values that cannot lead to an overflow of the block gas limit.\n\n### v2-periphery\n\n1. `MerkleLockup` uses a Merkle tree to distribute airstream funds. The leaves of the Merkle tree are not checked to be valid at the contract level. This Merkle tree is generated by the Sablier interface which we expect users to trust. If a user submits Merkle Root directly with an IPFS hash (which we also allow through the UI), our backend performs a validation check to ensure that the Merkle tree is correctly generated.\n\n2. For `MerkleLockup,`, a **grace period** is defined as the initial period during which `clawback` can be used. It ends 7 days after the first airstream claim has been made. Thus, airstream creators are assumed to be trusted during the grace period.\n\n3. In the case of `MerkleLockup`, if an Airstream campaign is created by a team, all members in that team are assumed to have trust among them i.e. they would not rug each other.\n\n4. In `SablierV2MerkleLT`, the unlock percentages and durations for tranches are uniform across all airdrop claimers.\n\n## Known Issues\n\n### v2-core\n\n1. In `SablierV2Lockup`, when `onLockupStreamCanceled()`, `onLockupStreamWithdrawn()` and `onLockupStreamRenounced()` hooks are called, there could be gas bomb attacks because we do not limit the gas transferred to the external contract. This is intended to support complex transactions implemented in those hooks.\n\n### v2-periphery\n\n1. In `SablierV2MerkleLockupFactory`, users can submit root hashes with duplicate indexes or create Merkle trees with incorrect depths, potentially leading to unclaimable assets or unexpected behavior. These issues are exacerbated by the fact that the Merkle tree's validity is not checked at the contract level. As per assumption (7), it is expected that the Merkle tree will be correctly generated. In case of a malicious Merkle tree, `clawback` can be called to withdraw funds from the deployed `MerkleLockup` contracts until the grace period ends.\n\n2. In `SablierV2MerkleLockupFactory`, malicious `lockupLinear` and `lockupTranched` contract addresses can be passed during `createMerkleLL()` and `createMerkleLT()` functions respectively.\n\n3. In `SablierV2MerkleLockupFactory`, `aggregateAmount` and `recipientCount` values are exclusively emitted in the `CreateMerkleLT` and `CreateMerkleLL` events. These values are not validated within the create functions as they are not utilized elsewhere in the contract. However, it's important to note that this impacts integrators who listen to these events and rely on these values. We advise caution, as they may be inaccurate.\n\n4. If the `admin` of the deployed `SablierV2MerkleLT` and `SablierV2MerkleLL` contracts is modified, the `onLockupStreamWithdrawn()` hook callback, if it is implemented, will continue to be made to the original `admin` for the airstreams that were already claimed at the time of the change.\n\n**[Additional known issues as detected by LightChaser](https://github.com/Cyfrin/2024-05-Sablier/issues/1)**\n","updatedAt":"2024-06-14T18:08:42.902Z","company":"Sablier","name":"Sablier","logo":null,"logoImgPublicId":"company/tiyiiu6e4hib55p0tm3m","featuredImgPublicId":"featured/a50pzzxwqcy0mdnqfvhz","forceFeatured":false,"reward":53440,"rewardHighMedium":45000,"rewardLow":3100,"rewardCommunityJudging":5340,"maxRewardedCommunityJudgingPosition":5,"xpBoost":0,"communityJudgingScoreToXpMultiplier":0,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2024-05-Sablier","telegram":"","discord":"https://discord.gg/cyfrin","twitter":"Sablier","github":"sablier-labs","linkedIn":"","email":"","startDate":"2024-05-10T12:00:00.000Z","endDate":"2024-05-31T12:00:00.000Z","communityJudgingEnabled":true,"communityJudgingStartDate":"2024-05-31T13:00:00.000Z","communityJudgingEndDate":"2024-06-05T13:00:00.000Z","userId":"clldzdkk60000mr082grbuj97","leadJudgeId":"clkgm90b9000gms085g528phk","firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":true,"cjEligibilityPreviousValidSubmission":true,"cjEligibilityPreviousMonetaryReward":true},{"id":"clvo5kwin00078k6jhhjobn22","createdAt":"2024-05-01T18:30:59.999Z","description":"Beanstalk is a permissionless fiat stablecoin protocol built on Ethereum. Its primary objective is to incentivize independent market participants to regularly cross the price of 1 Bean over its dollar peg in a sustainable fashion.","content":"# Beanstalk Part 3 Codehawks\n\n

\n $\"Beanstalk\"$ \n

\n\n# Contest Details\n\n### Prize Pool\n\n- Total Pool - $21,000\n- H/M - $17,900\n- Low - 1,000\n- Community Judging - $2,100\n- Starts: Monday, May 6, 2024 Noon UTC\n- Ends: Monday, May 20, 2024 Noon UTC\n\n### Stats\n\n- nSLOC: 1,104\n- Complexity Score: 818\n- $/nSLOC: $19.02\n- $/Complexity: $25.67\n\n## About\n\nBeanstalk is a permissionless fiat stablecoin protocol built on Ethereum. Its primary objective is to incentivize independent market participants to regularly cross the price of 1 Bean over its dollar peg in a sustainable fashion.\n\nBeanstalk does not have any collateral requirements. Beanstalk uses credit instead of collateral to create Bean price stability relative to its value peg of $1. The practicality of using DeFi is currently limited by the lack of decentralized low-volatility assets with competitive carrying costs. Borrowing rates on USD stablecoins have historically been higher than borrowing rates on USD, even when supply increases rapidly. Non-competitive carrying costs are due to collateral requirements.\n\nIn particular, this audit is centered around the changes included in the Misc. Improvements BIP described in the PR comment [here](https://github.com/BeanstalkFarms/Beanstalk/pull/802). The diff from this PR may be helpful to review in order to understand exactly which code in this audit is new and unaudited.\n\nYou can read an overview of how Beanstalk works [here](https://docs.bean.money/almanac/introduction/how-beanstalk-works).\n\n- [Docs](https://docs.bean.money/)\n- [Whitepaper](https://bean.money/beanstalk.pdf)\n- [Website](https://bean.money/)\n- [Beanstalk Farms Twitter](https://twitter.com/BeanstalkFarms)\n- [Beanstalk Public GitHub Repo](https://github.com/BeanstalkFarms/Beanstalk)\n\n## Actors\n\n- Stalkholder / Silo Member\n - Anyone who Deposits assets on the Deposit Whitelist into the Silo, earning the illiquid Stalk token in doing so. Stalkholders participate in governance and earn Bean seigniorage.\n- `gm` caller\n - Anyone who calls the `gm` function to start the next Season.\n- Unripe holder\n - Anyone who holds Unripe Beans or Unripe LP. These assets were distributed to holders of BDV (Bean Denominated Value) at the time of the April 2022 governance exploit. Most Unripe holders have their Unripe assets Deposited in the Silo, and thus are also Stalkholders.\n- Fertilizer holder\n - Anyone who holds Fertilizer, the debt asset earned by participating in Beanstalk's recapitalization.\n- Pod holder\n - Anyone who holds Pods, the Beanstalk-native debt asset. Pods are minting when lending Beans to Beanstalk (Sowing Beans).\n\n## Scope\n\nThe following contracts are in scope.\n\n```js\nprotocol/\n└── contracts/\n ├── beanstalk/\n │ ├── barn/\n │ │ └── UnripeFacet.sol\n │ ├── silo/\n │ │ └── ConvertFacet.sol\n │ └── sun/\n │ └── SeasonFacet/\n │ └── Sun.sol\n └── libraries/\n ├── Convert/\n │ ├── LibChopConvert.sol\n │ ├── LibConvert.sol\n │ ├── LibConvertData.sol\n │ └── LibLambdaConvert.sol\n ├── LibChop.sol\n ├── LibFertilizer.sol\n ├── LibStrings.sol\n ├── LibUnripe.sol\n └── Minting/\n └── LibWellMinting.sol\n```\n\n## Compatibilities\n\nBeanstalk implements the [ERC-2535 Diamond standard](https://docs.bean.money/developers/overview/eip-2535-diamond). It supports various whitelists for [Deposits](https://docs.bean.money/almanac/farm/silo#deposit-whitelist), [Minting](https://docs.bean.money/almanac/farm/sun#minting-whitelist), [Converts](https://docs.bean.money/almanac/peg-maintenance/convert#convert-whitelist), etc., particularly for LP tokens from [Basin](https://basin.exchange/).\n\nBlockchains:\n\n- Ethereum\n\nTokens:\n\n- ERC-20 (all are accepted in Farm balances, a whitelist is accepted on the Deposit Whitelist, etc.)\n- ERC-1155 (Fertilizer and Deposits are ERC-1155 tokens)\n\n## Setup\n\nClone repo:\n\n```bash\ngit clone https://github.com/Cyfrin/2024-05-Beanstalk-3\n```\n\nInstall dependencies:\n\n```bash\ncd 2024-05-Beanstalk-3/protocol\nyarn\n```\n\nAdd RPC:\n\n```bash\nexport FORKING_RPC=https://eth-mainnet.g.alchemy.com/v2/{RPC_KEY}\n```\n\ngenerate:\n\n```bash\nyarn generate\n```\n\nTest:\n\n```bash\nyarn test\n```\n\n## Known Issues\n\nAll findings in the following resources are considered known issues:\n\n- All Beanstalk audit reports listed in this [repository](https://github.com/BeanstalkFarms/Beanstalk-Audits);\n- All bug reports from the Immunefi program listed [here](https://community.bean.money/bug-reports);\n- All reports and known issues in past Beanstalk Codehawks audits:\n - [Beanstalk Codehawks Part 1](https://www.codehawks.com/report/clsxlpte900074r5et7x6kh96); and\n - [Beanstalk Codehawks Part 2](https://www.codehawks.com/contests/clu7665bs0001fmt5yahc8tyh).\n- Additional Known issues as identified by LightChaser's Static Analysis found [here](https://github.com/Cyfrin/2024-05-Beanstalk-3/issues/1).\n","updatedAt":"2024-05-30T10:48:15.824Z","company":"Beanstalk","name":"Beanstalk Part 3","logo":null,"logoImgPublicId":"company/km9b9u4fxgjhmg9e2fhb","featuredImgPublicId":"featured/mq8nv88qkkijg4dwmp21","forceFeatured":false,"reward":21000,"rewardHighMedium":17900,"rewardLow":1000,"rewardCommunityJudging":2100,"maxRewardedCommunityJudgingPosition":5,"xpBoost":0,"communityJudgingScoreToXpMultiplier":0,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2024-05-Beanstalk-Part-3","telegram":"","discord":"https://discord.gg/cyfrin","twitter":"BeanstalkFarms","github":"BeanstalkFarms","linkedIn":"","email":"","startDate":"2024-05-06T12:00:00.000Z","endDate":"2024-05-20T12:00:00.000Z","communityJudgingEnabled":true,"communityJudgingStartDate":"2024-05-20T13:00:00.000Z","communityJudgingEndDate":"2024-05-23T13:00:00.000Z","userId":"clldzdkk60000mr082grbuj97","leadJudgeId":"clr7msrkm0049q8odnpeafgru","firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":true,"cjEligibilityPreviousValidSubmission":true,"cjEligibilityPreviousMonetaryReward":true},{"id":"clv1eptuo0003bcnzce1ap7om","createdAt":"2024-04-15T20:28:04.318Z","description":"Basin is a composable EVM-native decentralized exchange protocol that allows for the composition of arbitrary exchange functions, network-native oracles and exchange implementations into a single liquidity pool known as a Well.","content":" $\"Basin$ \n\n# Beanstalk: Dive into Basin\n\n## Contest Details\n\n### Prize Pool\n\n- Total Pool - 12,000\n- H/M - $10,000\n- Low - $1,000\n- Community Judging - $1,000\n- Starts: Monday, April 22, 2024\n- Ends: Monday, April 29, 2024\n\n### Stats\n\n- nSLOC: 479\n- Complexity Score: 945\n- $/nSLOC: $25.05\n\n## About\n\nBasin is a composable EVM-native decentralized exchange protocol that allows for the composition of arbitrary exchange functions, network-native oracles and exchange implementations into a single liquidity pool known as a Well. In practice, Basin lowers the friction for market makers to deploy liquidity with custom orders and allows their liquidity to be used by other network-native protocols without additional trust assumptions.\n\nA Well is a constant function AMM that allows the provisioning of liquidity into a single pooled on-chain liquidity position. Each Well is defined by its Tokens, Well Function, and Pump:\n\n- The Tokens define the set of ERC-20 tokens that can be exchanged in the Well.\n- The Well Function defines an invariant relationship between the Well's reserves and the supply of LP tokens.\n - Pumps are on-chain oracles that are updated upon each interaction with the Well.\n\nMulti Flow Pump is an inter-block MEV manipulation resistant network-native Pump implementation for arbitrary current data in an EVM for both instantaneous and time-weighted average values.\n\n**In particular, this audit is focused on changes to the ConstantProduct2 Well Function, the Multi Flow Pump (now v1.1.0) and library changes associated with each.** You can read the full RFC of and diff for Multi Flow v1.1.0 [here](https://github.com/BeanstalkFarms/Basin/pull/127). Notably, the Well Implementation in `src/Well.sol` and the Well factory contract in `src/Aquifer.sol` is not in-scope of this audit.\n\nMore documentation on Basin and Multi Flow here:\n\n- [Docs](https://docs.basin.exchange/)\n- [Basin Whitepaper](https://basin.exchange/basin.pdf)\n- [Multi Flow Whitepaper](https://basin.exchange/multi-flow-pump.pdf)\n- [Basin GitHub README](https://github.com/BeanstalkFarms/Basin)\n\n## Actors\n\nThe only \"actors\" in the context of Basin are traders (takers) and liquidity providers (makers), as with any decentralized exchange. In a sense, external protocols that consume data stored in Pumps (like Multi Flow) could be considered another actor.\n\n## Scope\n\nThe following contracts are in scope of this audit:\n\n```js\nsrc/\n└── contracts/\n ├── functions/\n │ ├── ConstantProduct2.sol\n │ └── ProportionalLPToken2.sol\n ├── libraries/\n │ ├── LibLastReserveBytes.sol\n │ └── LibMath.sol\n └── pumps/\n └── MultiFlowPump.sol\n```\n\n## Compatibilities\n\nBlockchains:\n\n- Ethereum\n\nTokens:\n\n- ERC-20 (Any ERC-20 tokens can be traded in Wells)\n\n## Setup\n\n```bash\ngit clone https://github.com/Cyfrin/2024-04-Beanstalk-DIB\ncd 2024-04-Beanstalk-DIB\ncode .\n```\n\nThis repository uses Foundry as a smart contract development toolchain.\n\nSee the [Foundry Docs](https://book.getfoundry.sh/) for more info on installation and usage.\n\n```\nfoundryup\nforge install\nforge build\n```\n\n### Tests\n\nPrior to running tests, you should set up your environment. At present this repository contains fork tests against ETH mainnet; your environment will need an `MAINNET_RPC_URL` key to run these tests. This is used in `IntegrationTestGasComparisons.sol`.\n\nAdditionally, the `--ffi` cheatcode is used to verify certain actions. Due to the arbitrary code execution nature of `--ffi`, it is advised to review the executed code prior to running.\n\nTo setup the python environment:\n\n```\npython3.10 -m venv env\nsource env/bin/activate\npython3.10 -m pip install -r requirements.txt\n```\n\nThe tests using -ffi are:\n\n- `testFuzz_powu()`\n- `testSim_capReserve_decrease()`\n- `testSim_capReserve_increase()`\n\nIf errors occur during python execution, follow the steps described here: https://stackoverflow.com/a/75399269.\n\nThe code being executed is:\n\n- `test/pumps/simulate.py`\n- `test/differential/powu.py`\n\nThe main command to run the tests is:\n\n`forge test --ffi`\n\n_If the ffi tests are failing, you may need to add an `output` folder in the `test` directory._\n\nTo omit invariant tests:\n\n`forge test --ffi --no-match-test invariant`\n\nTo run slither:\n\n- `python3 -m pip install slither-analyzer`\n- `slither .`\n\n## Known Issues\n\nAll findings in the following audit reports:\n\n- 06/16/23: [Basin Halborn Report](https://arweave.net/1IKi4iqRvu3qu_GdcLY4f3u9PgvOMvuRltU7AIXAEyA) @ [e5441fc](https://github.com/BeanstalkFarms/Basin/tree/e5441fc78f0fd4b77a898812d0fd22cb43a0af55)\n- 06/16/23: [Basin Cyfrin Report](https://arweave.net/usT3ClfjHwpX32OXnh5De1aH79csX1PMoXJCghXBaps) @ [e5441fc](https://github.com/BeanstalkFarms/Basin/tree/e5441fc78f0fd4b77a898812d0fd22cb43a0af55)\n- 10/05/23: [Basin Code4rena Report](https://code4rena.com/reports/2023-07-basin) @ [7e51c02](https://github.com/code-423n4/2023-07-basin/tree/7e51c025d32aff3f2456842c83cda66cda274d11)\n- All bug reports from the Immunefi program listed [here](https://community.bean.money/bug-reports).\n\nPlease find additional Known Issues as Identified by LightChaser [here](https://github.com/Cyfrin/2024-04-Beanstalk-DIB/issues/2).\n","updatedAt":"2024-05-13T18:19:14.232Z","company":"Beanstalk","name":"Beanstalk: Dive Into Basin","logo":null,"logoImgPublicId":"company/dkpeqjkgetkxsga9v5q6","featuredImgPublicId":"featured/fchujcoxck2crj1rf9iz","forceFeatured":false,"reward":12000,"rewardHighMedium":10000,"rewardLow":1000,"rewardCommunityJudging":1000,"maxRewardedCommunityJudgingPosition":5,"xpBoost":0,"communityJudgingScoreToXpMultiplier":0,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2024-04-Beanstalk-DIB","telegram":"","discord":"https://discord.gg/cyfrin","twitter":"CodeHawks","github":"BeanstalkFarms","linkedIn":"","email":"","startDate":"2024-04-22T12:00:00.000Z","endDate":"2024-04-29T12:00:00.000Z","communityJudgingEnabled":true,"communityJudgingStartDate":"2024-04-29T13:00:00.000Z","communityJudgingEndDate":"2024-05-02T13:00:00.000Z","userId":"clldzdkk60000mr082grbuj97","leadJudgeId":"clr7msrkm0049q8odnpeafgru","firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":true,"cjEligibilityPreviousValidSubmission":true,"cjEligibilityPreviousMonetaryReward":true},{"id":"clu7665bs0001fmt5yahc8tyh","createdAt":"2024-03-25T16:35:43.864Z","description":"Beanstalk is a permissionless fiat stablecoin protocol built on Ethereum. Its primary objective is to incentivize independent market participants to regularly cross the price of 1 Bean over its dollar peg in a sustainable fashion.\n\nThis audit is centered around the BIP (Beanstalk Improvement Proposal) that whitelists the BEAN:wstETH Well in the Silo and migrates liquidity underlying Unripe assets from BEAN:ETH to BEAN:wstETH.","content":"# Beanstalk Codehawks Part 2\n\n

\n\n# Contest Details\n\n### Prize Pool\n\n- Total Pool - 35,000\n- H/M - 30,000\n- Low - 1,500\n- Community Judging - 3,500\n- Starts: Monday, April 01, 2024 Noon UTC\n- Ends: Monday, April 15, 2024 Noon UTC\n\n### Stats\n\n- nSLOC: 1,991\n- Complexity Score: 1203\n\n## About\n\nBeanstalk is a permissionless fiat stablecoin protocol built on Ethereum. Its primary objective is to incentivize independent market participants to regularly cross the price of 1 Bean over its dollar peg in a sustainable fashion.\n\nBeanstalk does not have any collateral requirements. Beanstalk uses credit instead of collateral to create Bean price stability relative to its value peg of $1. The practicality of using DeFi is currently limited by the lack of decentralized low-volatility assets with competitive carrying costs. Borrowing rates on USD stablecoins have historically been higher than borrowing rates on USD, even when supply increases rapidly. Non-competitive carrying costs are due to collateral requirements.\n\nIn particular, this audit is centered around the BIP (Beanstalk Improvement Proposal) that whitelists the BEAN:wstETH Well in the Silo and migrates liquidity underlying Unripe assets from BEAN:ETH to BEAN:wstETH. You can read more details in the RFC for the update [here](https://github.com/BeanstalkFarms/Beanstalk/issues/731).\n\nYou can read an overview of how Beanstalk works [here](https://docs.bean.money/almanac/introduction/how-beanstalk-works).\n\n* [Docs](https://docs.bean.money/)\n* [Whitepaper](https://bean.money/beanstalk.pdf)\n* [Website](https://bean.money/)\n* [Beanstalk Farms Twitter](https://twitter.com/BeanstalkFarms)\n* [Beanstalk Public GitHub Repo](https://github.com/BeanstalkFarms/Beanstalk)\n\n## Actors\n\n* Stalkholder / Silo Member\n * Anyone who Deposits assets on the Deposit Whitelist into the Silo, earning the illiquid Stalk token in doing so. Stalkholders participate in governance and earn Bean seigniorage.\n* `gm` caller\n * Anyone who calls the `gm` function to start the next Season.\n* Unripe holder\n * Anyone who holds Unripe Beans or Unripe LP. These assets were distributed to holders of BDV (Bean Denominated Value) at the time of the April 2022 governance exploit. Most Unripe holders have their Unripe assets Deposited in the Silo, and thus are also Stalkholders.\n* Fertilizer holder\n * Anyone who holds Fertilizer, the debt asset earned by participating in Beanstalk's recapitalization.\n* Pod holder\n * Anyone who holds Pods, the Beanstalk-native debt asset. Pods are minting when lending Beans to Beanstalk (Sowing Beans). Not particularly relevant for the scope of this audit.\n\n## Scope\n\nGenerally, the audit covers the Silo, the Sun and many of their associated libraries. A couple contracts from the Barn (related to Unripe assets) are also in scope. \n\nSpecifically, only the following contracts are in scope.\n\n```js\nprotocol/\n└── contracts/\n ├── beanstalk/\n │ ├── AppStorage.sol\n │ ├── barn/\n ├── FertilizerFacet.sol\n │ │ └── UnripeFacet.sol\n │ ├── init/\n │ │ └── InitMigrateUnripeBeanEthToBeanSteth.sol\n │ ├── silo/\n │ │ ├── BDVFacet.sol\n │ │ └── SiloFacet/\n │ │ └── Silo.sol\n │ └── sun/ \n │ ├── GaugePointFacet.sol\n │ ├── LiquidityWeightFacet.sol\n │ └── SeasonFacet/\n │ └── Oracle.sol\n └── libraries/\n ├── Convert/ \n │ ├── LibConvert.sol\n │ └── LibUnripeConvert.sol \n ├── LibBarnRaise.sol\n ├── LibEvaluate.sol\n ├── LibFertilizer.sol\n ├── Minting/ \n │ └── LibWellMinting.sol\n ├── Oracle/ \n │ ├── LibChainlinkOracle.sol\n │ ├── LibEthUsdOracle.sol\n │ ├── LibOracleHelpers.sol\n │ ├── LibUniswapOracle.sol\n │ ├── LibUsdOracle.sol\n │ ├── LibWstethEthOracle.sol\n │ └── LibWstethUsdOracle.sol\n ├── Silo/\n │ └── LibWhitelist.sol\n └── Well/\n ├── LibWell.sol\n └── LibWellBdv.sol\n```\n\n## Compatibilities\n\nBeanstalk implements the [ERC-2535 Diamond standard](https://docs.bean.money/developers/overview/eip-2535-diamond). It supports various whitelists for [Deposits](https://docs.bean.money/almanac/farm/silo#deposit-whitelist), [Minting](https://docs.bean.money/almanac/farm/sun#minting-whitelist), [Converts](https://docs.bean.money/almanac/peg-maintenance/convert#convert-whitelist), etc., particularly for LP tokens from [Basin](https://basin.exchange/).\n\nBlockchains:\n* Ethereum\n\nTokens:\n* ERC-20 (all are accepted in Farm balances, a whitelist is accepted on the Deposit Whitelist, etc.)\n* ERC-1155 (Fertilizer and Deposits are ERC-1155 tokens)\n\n## Setup\n\nClone repo: \n\n```bash\ngit clone https://github.com/Cyfrin/2024-04-beanstalk-2\n```\nInstall dependencies: \n```bash\ncd Beanstalk/protocol\nyarn\n```\nAdd RPC:\n```bash\nexport FORKING_RPC=https://eth-mainnet.g.alchemy.com/v2/{RPC_KEY}\n```\n\ngenerate: \n```bash\nyarn generate\n```\nTest: \n```bash\nyarn test\n```\n\n## Known Issues\n\n* The `enrootDeposits` functions do not properly emit ERC-1155 events.\n * `enrootDeposits` updates a user's Unripe Deposits' BDV and issues the corresponding Stalk to the user. The single `enrootDeposit` function correctly emits the ERC-1155 events, but the multiple variant incorrectly emits a `transferSingle` event to the 0 address for each Deposit. Given the Beanstalk subgraph does not use these events, and cannot be used to harm the protocol, the fix will be implmented in a separate upgrade to Beanstalk.\n\n* All findings in the following audit reports\n * [Cyfrin's initial audit report of v0 of the Gauge System](https://arweave.net/tfK_IQlxz1lABDEq4aefN9gPQaynKZKYFvFyU8seYA8) (the version of the Gauge System in this Codehawks audit is substantially different, hence the need for another audit);\n * [Cyfrin's initial Beanstalk report](https://arweave.net/JQodlB-9fil-OWfWOwYy6Q8eqWITJXtyaN5z_Anq1S0);\n * All Beanstalk audit reports listed in this [repository](https://github.com/BeanstalkFarms/Beanstalk-Audits);\n * **TBD: Beanstalk Codehawks Part 1**; and\n * All bug reports from the Immunefi program listed [here](https://community.bean.money/bug-reports).\n**Additional Known Issues:**\n\n- LightChaser - [Bot Issues](https://github.com/Cyfrin/2024-04-beanstalk-2/issues/1)\n- Valid Issues as Determined by Part 1:\n- Beanstalk Part 1 - [Part 1 Audit Preliminary Report](https://www.codehawks.com/report/clsxlpte900074r5et7x6kh96)\n","updatedAt":"2024-05-04T17:53:25.186Z","company":"Beanstalk","name":"Beanstalk Part 2","logo":null,"logoImgPublicId":"company/vwkqymxqrtutq4rdvf7w","featuredImgPublicId":"featured/v4xlsnns3byousguxgz0","forceFeatured":false,"reward":35000,"rewardHighMedium":30000,"rewardLow":1500,"rewardCommunityJudging":3500,"maxRewardedCommunityJudgingPosition":5,"xpBoost":0,"communityJudgingScoreToXpMultiplier":0,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2024-04-beanstalk-2","telegram":"","discord":"https://discord.gg/cyfrin","twitter":"BeanstalkFarms","github":"BeanstalkFarms","linkedIn":"","email":"","startDate":"2024-04-01T12:00:00.000Z","endDate":"2024-04-15T12:00:00.000Z","communityJudgingEnabled":true,"communityJudgingStartDate":"2024-04-15T12:00:00.000Z","communityJudgingEndDate":"2024-04-22T12:00:00.000Z","userId":"clldzdkk60000mr082grbuj97","leadJudgeId":"clr7msrkm0049q8odnpeafgru","firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":true,"cjEligibilityPreviousValidSubmission":true,"cjEligibilityPreviousMonetaryReward":true},{"id":"clsxlpte900074r5et7x6kh96","createdAt":"2024-02-22T19:13:31.663Z","description":"Beanstalk is a permissionless fiat stablecoin protocol built on Ethereum. Its primary objective is to incentivize independent market participants to regularly cross the price of 1 Bean over its dollar peg in a sustainable fashion.","content":"# Beanstalk Codehawks\n

\n $\"Beanstalk\"$ \n

\n\n# Contest Details\n\n### Prize Pool\n\n- Total Pool - $100,000\n- H/M - $95,000\n- Low - $5,000\n- Starts: Monday, February 26, 2024\n- Ends: Monday, March 25, 2024\n\n### Stats\n\n- nSLOC: 5776\n- Complexity Score: 3356\n- $/nSLOC: $15.58\n- $/Complexity: $26.82\n\n## About\n\nBeanstalk is a permissionless fiat stablecoin protocol built on Ethereum. Its primary objective is to incentivize independent market participants to regularly cross the price of 1 Bean over its dollar peg in a sustainable fashion.\n\nBeanstalk does not have any collateral requirements. Beanstalk uses credit instead of collateral to create Bean price stability relative to its value peg of $1. The practicality of using DeFi is currently limited by the lack of decentralized low-volatility assets with competitive carrying costs. Borrowing rates on USD stablecoins have historically been higher than borrowing rates on USD, even when supply increases rapidly. Non-competitive carrying costs are due to collateral requirements.\n\nIn particular, the [Sun](https://docs.bean.money/almanac/farm/sun) and [Silo](https://docs.bean.money/almanac/farm/silo) components of Beanstalk are in scope of this audit. The code in the repository includes the Seed Gauge System upgrade, which upgrades the Silo to autonomously adjust the Grown Stalk issued to holders of various whitelisted tokens. An overview of the Gauge System can be read [here](https://github.com/BeanstalkFarms/Beanstalk/issues/726).\n\nYou can read an overview of how Beanstalk works [here](https://docs.bean.money/almanac/introduction/how-beanstalk-works).\n\n* [Docs](https://docs.bean.money/)\n* [Whitepaper](https://bean.money/beanstalk.pdf)\n* [Website](https://bean.money/)\n* [Beanstalk Farms Twitter](https://twitter.com/BeanstalkFarms)\n* [Beanstalk Public GitHub Repo](https://github.com/BeanstalkFarms/Beanstalk)\n\n## Actors\n\n* Stalkholder / Silo Member\n * Anyone who Deposits assets on the Deposit Whitelist into the Silo, earning the illiquid Stalk token in doing so. Stalkholders participate in governance and earn Bean seigniorage.\n* `gm` caller\n * Anyone who calls the `gm` function to start the next Season.\n* Unripe holder\n * Anyone who holds Unripe Beans or Unripe LP. These assets were distributed to holders of BDV (Bean Denominated Value) at the time of the April 2022 governance exploit. Most Unripe holders have their Unripe assets Deposited in the Silo, and thus are also Stalkholders. Somewhat relevant to this audit.\n* Fertilizer holder\n * Anyone who holds Fertilizer, the debt asset earned by participating in Beanstalk's recapitalization. Not particularly relevant for the scope of this audit.\n* Pod holder\n * Anyone who holds Pods, the Beanstalk-native debt asset. Pods are minting when lending Beans to Beanstalk (Sowing Beans). Not particularly relevant for the scope of this audit.\n\n## Scope\n\nGenerally, the audit covers the Silo, the Sun and many of their associated libraries. A couple contracts from the Barn (related to Unripe assets) are also in scope. \n\nSpecifically, only the following contracts are in scope.\n\n```js\nprotocol/\n└── contracts/\n ├── beanstalk/\n │ ├── AppStorage.sol\n │ ├── barn/\n │ │ └── UnripeFacet.sol\n │ ├── init/\n │ │ ├── InitBipSeedGauge.sol\n │ │ └── InitWhitelistStatuses.sol\n │ ├── silo/\n │ │ ├── BDVFacet.sol\n │ │ ├── ConvertFacet.sol\n │ │ ├── EnrootFacet.sol\n │ │ ├── MigrationFacet.sol\n │ │ ├── SiloFacet/\n │ │ │ ├── Silo.sol\n │ │ │ ├── SiloFacet.sol\n │ │ │ ├── SiloGettersFacet.sol\n │ │ │ └── TokenSilo.sol\n │ │ └── WhitelistFacet/\n │ │ ├── WhitelistedFacet.sol\n │ │ └── WhitelistedTokens.sol\n │ └── sun/ \n │ ├── GaugePointFacet.sol\n │ ├── LiquidityWeightFacet.sol\n │ └── SeasonFacet/\n │ ├── Oracle.sol\n │ ├── SeasonFacet.sol\n │ ├── SeasonGettersFacet.sol\n │ ├── Sun.sol\n │ └── Weather.sol\n ├── libraries/\n │ ├── Convert/ \n │ │ ├── LibChopConvert.sol\n │ │ ├── LibConvert.sol\n │ │ ├── LibConvertData.sol\n │ │ ├── LibLambdaConvert.sol\n │ │ ├── LibUnripeConvert.sol \n │ │ └── LibWellConvert.sol \n │ ├── LibCases.sol\n │ ├── LibChop.sol\n │ ├── LibEvaluate.sol\n │ ├── LibFertilizer.sol\n │ ├── LibGauge.sol \n │ ├── LibIncentive.sol \n │ ├── LibLockedUnderlying.sol\n │ ├── LibUnripe.sol\n │ ├── Minting/ \n │ │ └── LibWellMinting.sol\n │ ├── Oracle/ \n │ │ ├── LibChainlinkOracle.sol\n │ │ ├── LibEthUsdOracle.sol\n │ │ └── LibUsdOracle.sol\n │ ├── Silo/\n │ │ ├── LibGerminate.sol\n │ │ ├── LibLegacyTokenSilo.sol\n │ │ ├── LibSilo.sol\n │ │ ├── LibTokenSilo.sol\n │ │ ├── LibUnripeSilo.sol\n │ │ ├── LibWhitelist.sol\n │ │ └── LibWhitelistedTokens.sol\n │ └── Well/\n │ └── LibWell.sol\n └── pipeline/\n └── junctions/\n └── UnwrapAndSendETH.sol\n \n```\n\n## Compatibilities\n\nBeanstalk implements the [ERC-2535 Diamond standard](https://docs.bean.money/developers/overview/eip-2535-diamond). It supports various whitelists for [Deposits](https://docs.bean.money/almanac/farm/silo#deposit-whitelist), [Minting](https://docs.bean.money/almanac/farm/sun#minting-whitelist), [Converts](https://docs.bean.money/almanac/peg-maintenance/convert#convert-whitelist), etc., particularly for LP tokens from [Basin](https://basin.exchange/).\n\nBlockchains:\n* Ethereum\n\nTokens:\n* ERC-20 (all are accepted in Farm balances, a whitelist is accepted on the Deposit Whitelist, etc.)\n* ERC-1155 (Fertilizer and Deposits are ERC-1155 tokens)\n\n## Setup\n\nClone repo: \n\n```bash\ngit clone https://github.com/Cyfrin/2024-02-Beanstalk-1\n```\nInstall dependencies: \n```bash\ncd Beanstalk/protocol\nyarn\n```\nAdd RPC:\n```bash\nexport FORKING_RPC=https://eth-mainnet.g.alchemy.com/v2/{RPC_KEY}\n```\n\nBuild: \n```bash\nnpx hardhat compile\n```\nTest: \n```bash\nnpx hardhat test\n```\n\n## Known Issues\n\n* The `enrootDeposits` functions do not properly emit ERC-1155 events.\n * `enrootDeposits` updates a user's Unripe Deposits' BDV and issues the corresponding Stalk to the user. The single `enrootDeposit` function correctly emits the ERC-1155 events, but the multiple variant incorrectly emits a `transferSingle` event to the 0 address for each Deposit. Given the Beanstalk subgraph does not use these events, and cannot be used to harm the protocol, the fix will be implmented in a separate upgrade to Beanstalk.\n\n* The `SeasonFacet` contract is known to be too large to deploy on mainnet (due to `LibGerminate`). This will be fixed before the Seed Gauge System is deployed\n\n* All findings in the following audit reports\n * [Cyfrin's initial audit report of v0 of the Gauge System](https://arweave.net/tfK_IQlxz1lABDEq4aefN9gPQaynKZKYFvFyU8seYA8) (the version of the Gauge System in this Codehawks audit is substantially different, hence the need for another audit);\n * [Cyfrin's initial Beanstalk report](https://arweave.net/JQodlB-9fil-OWfWOwYy6Q8eqWITJXtyaN5z_Anq1S0);\n * All Beanstalk audit reports listed in this [repository](https://github.com/BeanstalkFarms/Beanstalk-Audits); and\n * All bug reports from the Immunefi program listed [here](https://community.bean.money/bug-reports).\n\n**Additional Known Issues as outlined here: [Additional Known Issues](https://github.com/Cyfrin/2024-02-Beanstalk-1/issues/1)**\n","updatedAt":"2024-04-06T19:22:40.720Z","company":"Beanstalk","name":"Beanstalk Part 1","logo":null,"logoImgPublicId":"company/ycg7ldplxqc2yj7vvqlr","featuredImgPublicId":"featured/olgwyfjxkjom0kvccjht","forceFeatured":false,"reward":100000,"rewardHighMedium":95000,"rewardLow":5000,"rewardCommunityJudging":0,"maxRewardedCommunityJudgingPosition":5,"xpBoost":0,"communityJudgingScoreToXpMultiplier":0,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2024-02-Beanstalk-1","telegram":"","discord":"https://discord.gg/cyfrin","twitter":"BeanstalkFarms","github":"BeanstalkFarms","linkedIn":"","email":"","startDate":"2024-02-26T12:00:00.000Z","endDate":"2024-03-25T12:00:00.000Z","communityJudgingEnabled":false,"communityJudgingStartDate":"2024-03-25T12:00:00.000Z","communityJudgingEndDate":"2024-04-01T12:00:00.000Z","userId":"clldzdkk60000mr082grbuj97","leadJudgeId":"clr7msrkm0049q8odnpeafgru","firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":true,"cjEligibilityPreviousValidSubmission":false,"cjEligibilityPreviousMonetaryReward":true},{"id":"clt7ewpli0001w7f6ol2yojki","createdAt":"2024-02-29T16:00:37.782Z","description":"Moonwell is an open and decentralized lending and borrowing protocol built on Base, Moonbeam, and Moonriver. The app's intuitive design ensures a streamlined user experience, enabling everyone to do more with their digital assets. Moonwell is a fork of Compound, and naming has been modified from cTokens to mTokens, which are interest bearing tokens that represent the underlying asset.","content":"# Moonwell Contest\n\n

\n $\"Moonwell\"$ \n

\n\n# Contest Details\n\n### Prize Pool\n\n- Total Pool - $15,000\n- H/M - $14,000\n- Low - $1,000\n- Community Judging Pool - $1,500\n\n- Starts: Monday, March 04, 2024 Noon UTC\n- Ends: Monday, March 11, 2024 Noon UTC\n\n### Stats\n\n- nSLOC: 394\n- Complexity Score: 260\n- $/nSLOC: $38.07\n- $/Complexity: $57.69\n\n# Moonwell Protocol\n\n## Contest Details\n\nThis contest will be focused on two main changes to the Moonwell protocol on Moonbeam. The first change is to upgrade the mTokens to a new implementation, and the second change is to liquidate bad debt from the protocol. Two separate contracts will be used to upgrade existing contracts, and a governance proposal will be used to liquidate bad debt should the DAO choose to ratify these changes.\n\n## About the Project\n\nMoonwell is an open and decentralized lending and borrowing protocol built on Base, Moonbeam, and Moonriver. The app's intuitive design ensures a streamlined user experience, enabling everyone to do more with their digital assets.\nMoonwell is a fork of Compound, and naming has been modified from `cTokens` to `mTokens`, which are interest bearing tokens that represent the underlying asset.\n\n[Documentation](https://docs.moonwell.fi/moonwell/discover/about-moonwell)\n\n[Website](https://moonwell.fi/)\n\n[Twitter](https://twitter.com/MoonwellDeFi)\n\n[GitHub](https://github.com/moonwell-fi/)\n\n## Compatibilities\n\nCompatibilities:\nBlockchains: - Ethereum/Any EVM - Moonbeam\nTokens: - ERC20 standard implementations (including Moonbeam pre-compile) - Non standard ERC20 implmentations such as fee-on-transfer or no boolean returned on `transfer` or `transferFrom` not supported.\n\n## Actors\n\nThere are two main actors in the Moonwell protocol:\n\n- privileged actors: this is the timelock and the guardian, which are able to execute certain functions on the protocol\n- users: these are the people who interact with the protocol, by either supplying or borrowing assets from the protocol\n\n## Scope\n\nThe scope of this audit is to verify that the changes to the Moonwell protocol mTokens are implemented according to specifications and that no security vulnerabilities are introduced in the process.\n\n- The audit will include the following contracts:\n - `MIP-M17`\n - `MErc20DelegateFixer`\n - `MErc20DelegateMadFixer`\n\n## Setup\n\n```\ngit clone https://github.com/Cyfrin/2024-03-Moonwell.git\ncd 2024-03-Moonwell\n```\n\nTo run the integration tests, run the following command:\n\n```\nforge test --match-contract MIPM17IntegrationTest --fork-url moonbeam\n```\n\nTo run the Certora Prover and see the result of formal verification, run the following commands:\n\n```\ncertoraRun certora/confs/SharePrice.conf\n```\n\n```\ncertoraRun certora/confs/MErc20DelegateFixer.conf\n```\n\n## Governance Proposal\n\nThis proposal will remove all Nomad collateral from `.mad` mTokens, sending the underlying to the community multisig, and zero all borrows from users with bad debt.\n\nIn order to allow mToken collateral sweeping and bad debt write offs, the mTokens will have their implementations upgraded.\n\nThis will stop further issues and to allow the exchange rates of the assets to stay the same post proposal. Interest Rate Models may need to be changed in order to stop rate spikes due to changes in supply and borrow amounts.\n\nSee [this](https://forum.moonwell.fi/t/request-for-proposal-rfp-redemption-and-reallocation-of-nomad-collateral-and-protocol-reserves-for-frax-market-enhancement/746/3) forum post for additional information.\n\n## Delegate Bad Debt Fixer\n\nThis proposal changes the logic contract that is used by both the mFRAX and mxcDOT to a new `MErc20DelegateFixer` contract. This contract will allow the bad debt to be repaid with reserves or user supplied cash, and will allow the bad debt to be written off so no further interest accrues because of this bad debt.\n\n## Delegate Nomad Fixer\n\nThis proposal also upgrades the logic contract for the .mad mTokens to a new `MErc20DelegateMadFixer` contract. This contract will allow the Nomad collateral to be swept to the community multisig. After the collateral is swept, the share price will change, however this is not of concern as the collateral is being removed from the system, and the .mad mTokens will no longer allow users the ability to redeem the mTokens for their underlying.\n\n## Storage Offset Verification\n\nThis proposal changes the logic contract that is used by the `MErc20Delegator` with two new `MErc20Delegate` contracts. To verify the storage slot offsets between the new and the old contracts remain unchanged, the following commands can be run:\n\n```\nslither src/OriginalMToken.sol --print variable-order\n```\n\nThen running slither on the new contracts and comparing the output to ensure no storage slots from 0 to 19 have been changed.\n\n```\nslither src/MErc20DelegateFixer.sol --print variable-order\n```\n\ndiffing the output, we can see that the 20th slot has been added in the DelegateFixer.\n\n```\n< MErc20Delegate:\n---\n> MErc20DelegateFixer:\n63a58\n> | MErc20DelegateFixer.badDebt | uint256 | 20 | 0 |\n64a60,74\n>\n\n```\n\nThe only other difference is the name change of the contract.\n\nTo view the diff of the storage slots of the .mad MToken fixer contract, run the following command:\n\n```\nslither src/MErc20DelegateMadFixer.sol --print variable-order\n```\n\n```\n1c1,9\n< ComptrollerErrorReporter:\n---\n> INFO:Printers:\n> ComptrollerInterface:\n> +--------------------------------+--------+------+--------+\n> | Name | Type | Slot | Offset |\n> +--------------------------------+--------+------+--------+\n> | ComptrollerInterface.gasAmount | uint16 | 0 | 0 |\n> +--------------------------------+--------+------+--------+\n>\n> EIP20Interface:\n13c21\n< EIP20Interface:\n---\n> ComptrollerErrorReporter:\n19,25d26\n< ComptrollerInterface:\n< +--------------------------------+--------+------+--------+\n< | Name | Type | Slot | Offset |\n< +--------------------------------+--------+------+--------+\n< | ComptrollerInterface.gasAmount | uint16 | 0 | 0 |\n< +--------------------------------+--------+------+--------+\n<\n32,39c33\n< MDelegatorInterface:\n< +-----------------------------------+---------+------+--------+\n< | Name | Type | Slot | Offset |\n< +-----------------------------------+---------+------+--------+\n< | MDelegationStorage.implementation | address | 0 | 0 |\n< +-----------------------------------+---------+------+--------+\n<\n< MErc20Delegate:\n---\n> MErc20DelegateMadFixer:\n64a59,67\n>\n> MDelegatorInterface:\n> +-----------------------------------+---------+------+--------+\n> | Name | Type | Slot | Offset |\n> +-----------------------------------+---------+------+--------+\n> | MDelegationStorage.implementation | address | 0 | 0 |\n> +-----------------------------------+---------+------+--------+\n>\n>\n```\n\nThe only difference between the contracts are the contract names. The storage offsets remain unchanged. `MDelegatorInterface` and `ComptrollerInterface` can be safely ignored as they are not inherited and thus do not affect storage slots.\n\n## Contract Diffing\n\nTo verify the source code changes between the new and old contracts, the diff can be viewed for the [`MErc20DelegateFixer`](https://www.diffchecker.com/kVNFeip6/) and [`MErc20DelegateMadFixer`](https://www.diffchecker.com/rgqeBxSw/).\n\n## Integration Testing\n\nIn order to integration test the new contracts, run the following command:\n\n```\nforge test --match-contract MIPM17IntegrationTest --fork-url https://rpc.api.moonbeam.network -vvv\n```\n\n## Invariants\n\nThe following invariants must hold true immediately after the contracts are upgraded:\n\n- no state variables are changed\n- storage offsets are not changed\n- only one new variable has been added\n- exchange rate cannot change from calling functions `repayBadDebtWithCash`, `repayBadDebtWithReserves`, or `fixUser`.\n- If bad debt is repaid with reserves, the reserves must be decreased by the same amount as the bad debt.\n- if cash is used to repay bad debt, the underlying must be increased by the amount the bad debt decreased.\n\nThe following invariants must remain true after the governance proposal is executed:\n\n- total borrows equals the sum of borrow balance for all users borrowing\n- total supply equals the sum of supply balance for all users supplying\n- exchange rate is the same as before the proposal for non .mad MTokens, mFRAX and mxcDOT\n\n## Formal Verification\n\nThe new functions `repayBadDebtWithCash`, `repayBadDebtWithReserves`, and `fixUser` have been verified using formal verification.\nThe latest run can be found [here](https://prover.certora.com/output/651303/d5f6f29618d84b1c90fb1b11c90f2578/?anonymousKey=68171dea5299ad449392910f5c4eac61b69eda9b);\n\nThe prover can be run with the following commands:\n\n```\ncertoraRun certora/confs/SharePrice.conf\n```\n\n```\ncertoraRun certora/confs/MErc20DelegateFixer.conf\n```\n\n## Deployment\n\nRun the following commands to deploy the new contracts:\n\n```\nforge script script/GovernorBravo.s.sol:GovernorBravoScript -vvvv --rpc-url moonbeam --broadcast --verify --etherscan-api-key {key}\n```\n\nTo dry run the deployment and verify the calldata, run the following command:\n\n```\nforge script script/GovernorBravo.s.sol:GovernorBravoScript -vvvv --rpc-url moonbeam\n```\n\n**Note**, your calldata may differ as the contract addresses are not known in advance, however the number of actions should stay the same, and the user liquidation calldata should be unchanged.\n\n### Proposal Actions and Calldata\n\nRunning the script should output the following calldata and proposal actions:\n\n

Proposal Description:

\n\n

\n\n# MIP-M17: Redemption and Reallocation of Nomad Collateral and Protocol Reserves for FRAX Market Enhancement (Proposal 2)\n\n## Overview\n\nThis proposal will remove all collateral mTokens from users with bad debt from all markets, sending them to the community multisig. In order to allow mToken collateral sweeping and bad debt write offs, the mTokens will have their implementations upgraded. This will stop further issues and allow the exchange rates of the assets to stay the same post-proposal.\n\nFollowing the passing of the signaling snapshot [poll](https://snapshot.org/#/moonwell-governance.eth/proposal/0xe30b2ec324ad04397eb864dd464d3f57f44c63ccf684c9a126f9dd34908fd5c7), this governance proposal is being created to execute the second step in restoring liquidity to the markets.\n\nPlease see the forum post [here](https://forum.moonwell.fi/t/request-for-proposal-rfp-redemption-and-reallocation-of-nomad-collateral-and-protocol-reserves-for-frax-market-enhancement/746/3) for further details on this governance proposal.\n\n\n\n------------------ Proposal Actions ------------------\n  1). Upgrade MErc20Delegate for mFRAX to MErc20DelegateFixer\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x555bcc4000000000000000000000000034a1d3fff3958843c43ad80f30b94c510645c316000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000000\n\n\n  2). Upgrade MErc20Delegate for mxcDOT to MErc20DelegateFixer\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x555bcc4000000000000000000000000034a1d3fff3958843c43ad80f30b94c510645c316000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000000\n\n\n  3). Liquidate bad mFRAX debt for user: 0xe0b2026e3db1606ef0beb764ccdf7b3cee30db4a\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000e0b2026e3db1606ef0beb764ccdf7b3cee30db4a\n\n\n  4). Liquidate bad mFRAX debt for user: 0xccb8e090fe070945cc0131a075b6e1ea8f208812\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000ccb8e090fe070945cc0131a075b6e1ea8f208812\n\n\n  5). Liquidate bad mFRAX debt for user: 0x7ecf0bf3d94dce4838d57b63dc96d6ddc2cc63e7\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000007ecf0bf3d94dce4838d57b63dc96d6ddc2cc63e7\n\n\n  6). Liquidate bad mFRAX debt for user: 0x6a67a0e5265730952ed7dd648aed357c7444999e\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000006a67a0e5265730952ed7dd648aed357c7444999e\n\n\n  7). Liquidate bad mFRAX debt for user: 0xaaddc55883b7df9944d54c20f2822f476673cbc0\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000aaddc55883b7df9944d54c20f2822f476673cbc0\n\n\n  8). Liquidate bad mFRAX debt for user: 0x7c976f00e84db0b44f945fc6d7fad34b43150a1a\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000007c976f00e84db0b44f945fc6d7fad34b43150a1a\n\n\n  9). Liquidate bad mFRAX debt for user: 0x4f5ef03e870332a1b42453bbf57b8a041e89efe8\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000004f5ef03e870332a1b42453bbf57b8a041e89efe8\n\n\n  10). Liquidate bad mFRAX debt for user: 0xa89da48796bb808cb9af3637ff7ab436f968c7d5\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000a89da48796bb808cb9af3637ff7ab436f968c7d5\n\n\n  11). Liquidate bad mFRAX debt for user: 0x54dc6782d6fc5fc05f8486d365186ff25cc44ba7\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f700000000000000000000000054dc6782d6fc5fc05f8486d365186ff25cc44ba7\n\n\n  12). Liquidate bad mFRAX debt for user: 0x395ef2d7a5d499b62ac479064b7eaa51ae823a22\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000395ef2d7a5d499b62ac479064b7eaa51ae823a22\n\n\n  13). Liquidate bad mFRAX debt for user: 0xf4f1f5dd2801f94b732d240a46103089905ccd4e\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000f4f1f5dd2801f94b732d240a46103089905ccd4e\n\n\n  14). Liquidate bad mFRAX debt for user: 0x9f6dc2cf76fd22a0e5f11e0edde73502364ffbb8\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000009f6dc2cf76fd22a0e5f11e0edde73502364ffbb8\n\n\n  15). Liquidate bad mFRAX debt for user: 0x57e421c8a16bf0a609ef87e296cb931113a5e3ed\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f700000000000000000000000057e421c8a16bf0a609ef87e296cb931113a5e3ed\n\n\n  16). Liquidate bad mFRAX debt for user: 0x60298d41cef0759f1127fc5e48ba3b663a9e0889\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f700000000000000000000000060298d41cef0759f1127fc5e48ba3b663a9e0889\n\n\n  17). Liquidate bad mFRAX debt for user: 0xa3db05c72c79d52d2d37170a342a2c21c5e5d7c0\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000a3db05c72c79d52d2d37170a342a2c21c5e5d7c0\n\n\n  18). Liquidate bad mFRAX debt for user: 0xd4d70647651e84536eb218d5889ab764115c4d82\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000d4d70647651e84536eb218d5889ab764115c4d82\n\n\n  19). Liquidate bad mFRAX debt for user: 0xdd15c08320f01f1b6348b35eebe29fdb5ca0cda6\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000dd15c08320f01f1b6348b35eebe29fdb5ca0cda6\n\n\n  20). Liquidate bad mFRAX debt for user: 0xcbc21fbf92519f6d90c05a6fda1a7cb72fa6e02b\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000cbc21fbf92519f6d90c05a6fda1a7cb72fa6e02b\n\n\n  21). Liquidate bad mFRAX debt for user: 0x6722ae8c7a49553f1a80153517d1cfeca7eca5f7\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000006722ae8c7a49553f1a80153517d1cfeca7eca5f7\n\n\n  22). Liquidate bad mFRAX debt for user: 0x99b84a77f64e5acc269073cf082951c3ce57fe64\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f700000000000000000000000099b84a77f64e5acc269073cf082951c3ce57fe64\n\n\n  23). Liquidate bad mFRAX debt for user: 0xf98a854bc00eaa854894d79e11315a2114c58120\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000f98a854bc00eaa854894d79e11315a2114c58120\n\n\n  24). Liquidate bad mFRAX debt for user: 0x175a795ef04bc146fd6d6f852e5adec8b356e310\n  target: 0x1C55649f73CDA2f72CEf3DD6C5CA3d49EFcF484C\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000175a795ef04bc146fd6d6f852e5adec8b356e310\n\n\n  25). Liquidate bad mxcDOT debt for user 0xdd15c08320f01f1b6348b35eebe29fdb5ca0cda6\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000dd15c08320f01f1b6348b35eebe29fdb5ca0cda6\n\n\n  26). Liquidate bad mxcDOT debt for user 0x51d7193812b5b70e5e30df5c18ac2062c5f51c5e\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f700000000000000000000000051d7193812b5b70e5e30df5c18ac2062c5f51c5e\n\n\n  27). Liquidate bad mxcDOT debt for user 0xc265ba4d9ed33620978b03235fc9f5aa026da275\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000c265ba4d9ed33620978b03235fc9f5aa026da275\n\n\n  28). Liquidate bad mxcDOT debt for user 0x9f6dc2cf76fd22a0e5f11e0edde73502364ffbb8\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000009f6dc2cf76fd22a0e5f11e0edde73502364ffbb8\n\n\n  29). Liquidate bad mxcDOT debt for user 0x3a531c90e52a02817c0d31794d0ac4ea35a66602\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000003a531c90e52a02817c0d31794d0ac4ea35a66602\n\n\n  30). Liquidate bad mxcDOT debt for user 0x1fb540757cfd698b4a8f81e510ed09aa67a4f970\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000001fb540757cfd698b4a8f81e510ed09aa67a4f970\n\n\n  31). Liquidate bad mxcDOT debt for user 0x396a6d7a33655c45044143cb8a812227bf279578\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000396a6d7a33655c45044143cb8a812227bf279578\n\n\n  32). Liquidate bad mxcDOT debt for user 0x1f93dc0e5f249c8961027d447c973b9ce7ab7366\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000001f93dc0e5f249c8961027d447c973b9ce7ab7366\n\n\n  33). Liquidate bad mxcDOT debt for user 0xaaddc55883b7df9944d54c20f2822f476673cbc0\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000aaddc55883b7df9944d54c20f2822f476673cbc0\n\n\n  34). Liquidate bad mxcDOT debt for user 0xd2dff7007586be8f2e6cb84de65190b81adf6a9b\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000d2dff7007586be8f2e6cb84de65190b81adf6a9b\n\n\n  35). Liquidate bad mxcDOT debt for user 0x4f5ef03e870332a1b42453bbf57b8a041e89efe8\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000004f5ef03e870332a1b42453bbf57b8a041e89efe8\n\n\n  36). Liquidate bad mxcDOT debt for user 0xd4d70647651e84536eb218d5889ab764115c4d82\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000d4d70647651e84536eb218d5889ab764115c4d82\n\n\n  37). Liquidate bad mxcDOT debt for user 0x985c3e74201d8c4907e7d8db06bb1f83639bef0c\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000985c3e74201d8c4907e7d8db06bb1f83639bef0c\n\n\n  38). Liquidate bad mxcDOT debt for user 0x8dfd78676fa1929d1c7b64fbd3133e3b4ec305b3\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000008dfd78676fa1929d1c7b64fbd3133e3b4ec305b3\n\n\n  39). Liquidate bad mxcDOT debt for user 0xdc7428eeff0cdac1a45f310debb9af91708f47c9\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000dc7428eeff0cdac1a45f310debb9af91708f47c9\n\n\n  40). Liquidate bad mxcDOT debt for user 0x08c3e7b6e273d4434fa466ff23dba7c602a961a7\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f700000000000000000000000008c3e7b6e273d4434fa466ff23dba7c602a961a7\n\n\n  41). Liquidate bad mxcDOT debt for user 0xf9923ae543f039c71cd1bbc95ee3db6f36afcce6\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000f9923ae543f039c71cd1bbc95ee3db6f36afcce6\n\n\n  42). Liquidate bad mxcDOT debt for user 0x3769859a5efa6133cd74c5eb5080f46beffb6cef\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000003769859a5efa6133cd74c5eb5080f46beffb6cef\n\n\n  43). Liquidate bad mxcDOT debt for user 0xb3e6420941acc44c2996666b4b5c998c1545fc19\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000b3e6420941acc44c2996666b4b5c998c1545fc19\n\n\n  44). Liquidate bad mxcDOT debt for user 0x54dc6782d6fc5fc05f8486d365186ff25cc44ba7\n  target: 0xD22Da948c0aB3A27f5570b604f3ADef5F68211C3\npayload\n  0x28d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f700000000000000000000000054dc6782d6fc5fc05f8486d365186ff25cc44ba7\n\n\n  45). Upgrade MErc20Delegate for mUSDC.mad to MErc20DelegateMadFixer\n  target: 0x02e9081DfadD37A852F9a73C4d7d69e615E61334\npayload\n  0x555bcc40000000000000000000000000a8452ec99ce0c64f20701db7dd3abdb607c00496000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000000\n\n\n  46). Sweep all mUSDC.mad\n  target: 0x02e9081DfadD37A852F9a73C4d7d69e615E61334\npayload\n  0xc18cfe86000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7\n\n\n  47). Upgrade MErc20Delegate for mETH.mad to MErc20DelegateMadFixer\n  target: 0xc3090f41Eb54A7f18587FD6651d4D3ab477b07a4\npayload\n  0x555bcc40000000000000000000000000a8452ec99ce0c64f20701db7dd3abdb607c00496000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000000\n\n\n  48). Sweep all mETH.mad\n  target: 0xc3090f41Eb54A7f18587FD6651d4D3ab477b07a4\npayload\n  0xc18cfe86000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7\n\n\n  49). Upgrade MErc20Delegate for mwBTC.mad to MErc20DelegateMadFixer\n  target: 0x24A9d8f1f350d59cB0368D3d52A77dB29c833D1D\npayload\n  0x555bcc40000000000000000000000000a8452ec99ce0c64f20701db7dd3abdb607c00496000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000000\n\n\n  50). Sweep all mwBTC.mad\n  target: 0x24A9d8f1f350d59cB0368D3d52A77dB29c833D1D\npayload\n  0xc18cfe86000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7\n\n\n  Calldata for proposal:\n  0xda95691a00000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000007000000000000000000000000000000000000000000000000000000000000000d600000000000000000000000000000000000000000000000000000000000001a000000000000000000000000000000000000000000000000000000000000003a4000000000000000000000000000000000000000000000000000000000000000320000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c30000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c0000000000000000000000001c55649f73cda2f72cef3dd6c5ca3d49efcf484c000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c3000000000000000000000000d22da948c0ab3a27f5570b604f3adef5f68211c300000000000000000000000002e9081dfadd37a852f9a73c4d7d69e615e6133400000000000000000000000002e9081dfadd37a852f9a73c4d7d69e615e61334000000000000000000000000c3090f41eb54a7f18587fd6651d4d3ab477b07a4000000000000000000000000c3090f41eb54a7f18587fd6651d4d3ab477b07a400000000000000000000000024a9d8f1f350d59cb0368d3d52a77db29c833d1d00000000000000000000000024a9d8f1f350d59cb0368d3d52a77db29c833d1d000000000000000000000000000000000000000000000000000000000000003200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000003200000000000000000000000000000000000000000000000000000000000006400000000000000000000000000000000000000000000000000000000000000660000000000000000000000000000000000000000000000000000000000000068000000000000000000000000000000000000000000000000000000000000006a000000000000000000000000000000000000000000000000000000000000006c000000000000000000000000000000000000000000000000000000000000006e00000000000000000000000000000000000000000000000000000000000000700000000000000000000000000000000000000000000000000000000000000072000000000000000000000000000000000000000000000000000000000000007400000000000000000000000000000000000000000000000000000000000000760000000000000000000000000000000000000000000000000000000000000078000000000000000000000000000000000000000000000000000000000000007a000000000000000000000000000000000000000000000000000000000000007c000000000000000000000000000000000000000000000000000000000000007e00000000000000000000000000000000000000000000000000000000000000800000000000000000000000000000000000000000000000000000000000000082000000000000000000000000000000000000000000000000000000000000008400000000000000000000000000000000000000000000000000000000000000860000000000000000000000000000000000000000000000000000000000000088000000000000000000000000000000000000000000000000000000000000008a000000000000000000000000000000000000000000000000000000000000008c000000000000000000000000000000000000000000000000000000000000008e00000000000000000000000000000000000000000000000000000000000000900000000000000000000000000000000000000000000000000000000000000092000000000000000000000000000000000000000000000000000000000000009400000000000000000000000000000000000000000000000000000000000000960000000000000000000000000000000000000000000000000000000000000098000000000000000000000000000000000000000000000000000000000000009a000000000000000000000000000000000000000000000000000000000000009c000000000000000000000000000000000000000000000000000000000000009e00000000000000000000000000000000000000000000000000000000000000a000000000000000000000000000000000000000000000000000000000000000a200000000000000000000000000000000000000000000000000000000000000a400000000000000000000000000000000000000000000000000000000000000a600000000000000000000000000000000000000000000000000000000000000a800000000000000000000000000000000000000000000000000000000000000aa00000000000000000000000000000000000000000000000000000000000000ac00000000000000000000000000000000000000000000000000000000000000ae00000000000000000000000000000000000000000000000000000000000000b000000000000000000000000000000000000000000000000000000000000000b200000000000000000000000000000000000000000000000000000000000000b400000000000000000000000000000000000000000000000000000000000000b600000000000000000000000000000000000000000000000000000000000000b800000000000000000000000000000000000000000000000000000000000000ba00000000000000000000000000000000000000000000000000000000000000bc00000000000000000000000000000000000000000000000000000000000000be00000000000000000000000000000000000000000000000000000000000000c000000000000000000000000000000000000000000000000000000000000000c200000000000000000000000000000000000000000000000000000000000000c400000000000000000000000000000000000000000000000000000000000000c600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000320000000000000000000000000000000000000000000000000000000000000640000000000000000000000000000000000000000000000000000000000000070000000000000000000000000000000000000000000000000000000000000007c0000000000000000000000000000000000000000000000000000000000000084000000000000000000000000000000000000000000000000000000000000008c0000000000000000000000000000000000000000000000000000000000000094000000000000000000000000000000000000000000000000000000000000009c00000000000000000000000000000000000000000000000000000000000000a400000000000000000000000000000000000000000000000000000000000000ac00000000000000000000000000000000000000000000000000000000000000b400000000000000000000000000000000000000000000000000000000000000bc00000000000000000000000000000000000000000000000000000000000000c400000000000000000000000000000000000000000000000000000000000000cc00000000000000000000000000000000000000000000000000000000000000d400000000000000000000000000000000000000000000000000000000000000dc00000000000000000000000000000000000000000000000000000000000000e400000000000000000000000000000000000000000000000000000000000000ec00000000000000000000000000000000000000000000000000000000000000f400000000000000000000000000000000000000000000000000000000000000fc0000000000000000000000000000000000000000000000000000000000000104000000000000000000000000000000000000000000000000000000000000010c0000000000000000000000000000000000000000000000000000000000000114000000000000000000000000000000000000000000000000000000000000011c0000000000000000000000000000000000000000000000000000000000000124000000000000000000000000000000000000000000000000000000000000012c0000000000000000000000000000000000000000000000000000000000000134000000000000000000000000000000000000000000000000000000000000013c0000000000000000000000000000000000000000000000000000000000000144000000000000000000000000000000000000000000000000000000000000014c0000000000000000000000000000000000000000000000000000000000000154000000000000000000000000000000000000000000000000000000000000015c0000000000000000000000000000000000000000000000000000000000000164000000000000000000000000000000000000000000000000000000000000016c0000000000000000000000000000000000000000000000000000000000000174000000000000000000000000000000000000000000000000000000000000017c0000000000000000000000000000000000000000000000000000000000000184000000000000000000000000000000000000000000000000000000000000018c0000000000000000000000000000000000000000000000000000000000000194000000000000000000000000000000000000000000000000000000000000019c00000000000000000000000000000000000000000000000000000000000001a400000000000000000000000000000000000000000000000000000000000001ac00000000000000000000000000000000000000000000000000000000000001b400000000000000000000000000000000000000000000000000000000000001bc00000000000000000000000000000000000000000000000000000000000001c400000000000000000000000000000000000000000000000000000000000001cc00000000000000000000000000000000000000000000000000000000000001d800000000000000000000000000000000000000000000000000000000000001de00000000000000000000000000000000000000000000000000000000000001ea00000000000000000000000000000000000000000000000000000000000001f000000000000000000000000000000000000000000000000000000000000001fc00000000000000000000000000000000000000000000000000000000000000084555bcc4000000000000000000000000034a1d3fff3958843c43ad80f30b94c510645c316000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000084555bcc4000000000000000000000000034a1d3fff3958843c43ad80f30b94c510645c31600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000060000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000e0b2026e3db1606ef0beb764ccdf7b3cee30db4a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000ccb8e090fe070945cc0131a075b6e1ea8f20881200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000007ecf0bf3d94dce4838d57b63dc96d6ddc2cc63e700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000006a67a0e5265730952ed7dd648aed357c7444999e00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000aaddc55883b7df9944d54c20f2822f476673cbc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000007c976f00e84db0b44f945fc6d7fad34b43150a1a00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000004f5ef03e870332a1b42453bbf57b8a041e89efe800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000a89da48796bb808cb9af3637ff7ab436f968c7d500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f700000000000000000000000054dc6782d6fc5fc05f8486d365186ff25cc44ba700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000395ef2d7a5d499b62ac479064b7eaa51ae823a2200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000f4f1f5dd2801f94b732d240a46103089905ccd4e00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000009f6dc2cf76fd22a0e5f11e0edde73502364ffbb800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f700000000000000000000000057e421c8a16bf0a609ef87e296cb931113a5e3ed00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f700000000000000000000000060298d41cef0759f1127fc5e48ba3b663a9e088900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000a3db05c72c79d52d2d37170a342a2c21c5e5d7c000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000d4d70647651e84536eb218d5889ab764115c4d8200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000dd15c08320f01f1b6348b35eebe29fdb5ca0cda600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000cbc21fbf92519f6d90c05a6fda1a7cb72fa6e02b00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000006722ae8c7a49553f1a80153517d1cfeca7eca5f700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f700000000000000000000000099b84a77f64e5acc269073cf082951c3ce57fe6400000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000f98a854bc00eaa854894d79e11315a2114c5812000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000175a795ef04bc146fd6d6f852e5adec8b356e31000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000dd15c08320f01f1b6348b35eebe29fdb5ca0cda600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f700000000000000000000000051d7193812b5b70e5e30df5c18ac2062c5f51c5e00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000c265ba4d9ed33620978b03235fc9f5aa026da27500000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000009f6dc2cf76fd22a0e5f11e0edde73502364ffbb800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000003a531c90e52a02817c0d31794d0ac4ea35a6660200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000001fb540757cfd698b4a8f81e510ed09aa67a4f97000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000396a6d7a33655c45044143cb8a812227bf27957800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000001f93dc0e5f249c8961027d447c973b9ce7ab736600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000aaddc55883b7df9944d54c20f2822f476673cbc000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000d2dff7007586be8f2e6cb84de65190b81adf6a9b00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000004f5ef03e870332a1b42453bbf57b8a041e89efe800000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000d4d70647651e84536eb218d5889ab764115c4d8200000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000985c3e74201d8c4907e7d8db06bb1f83639bef0c00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000008dfd78676fa1929d1c7b64fbd3133e3b4ec305b300000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000dc7428eeff0cdac1a45f310debb9af91708f47c900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f700000000000000000000000008c3e7b6e273d4434fa466ff23dba7c602a961a700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000f9923ae543f039c71cd1bbc95ee3db6f36afcce600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f70000000000000000000000003769859a5efa6133cd74c5eb5080f46beffb6cef00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000b3e6420941acc44c2996666b4b5c998c1545fc1900000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000004428d8cd8c000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f700000000000000000000000054dc6782d6fc5fc05f8486d365186ff25cc44ba7000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000084555bcc40000000000000000000000000a8452ec99ce0c64f20701db7dd3abdb607c00496000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000024c18cfe86000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000084555bcc40000000000000000000000000a8452ec99ce0c64f20701db7dd3abdb607c00496000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000024c18cfe86000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f7000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000084555bcc40000000000000000000000000a8452ec99ce0c64f20701db7dd3abdb607c00496000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000600000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000024c18cfe86000000000000000000000000949d6a0e3b1064d498d529a388b953b344cd13f700000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040323204d49502d4d31373a20526564656d7074696f6e20616e64205265616c6c6f636174696f6e206f66204e6f6d616420436f6c6c61746572616c20616e642050726f746f636f6c20526573657276657320666f722046524158204d61726b657420456e68616e63656d656e74202850726f706f73616c2032290a0a2323204f766572766965770a0a546869732070726f706f73616c2077696c6c2072656d6f766520616c6c20636f6c6c61746572616c206d546f6b656e732066726f6d20757365727320776974682062616420646562742066726f6d20616c6c206d61726b6574732c2073656e64696e67207468656d20746f2074686520636f6d6d756e697479206d756c74697369672e20496e206f7264657220746f20616c6c6f77206d546f6b656e20636f6c6c61746572616c207377656570696e6720616e64206261642064656274207772697465206f6666732c20746865206d546f6b656e732077696c6c206861766520746865697220696d706c656d656e746174696f6e732075706772616465642e20546869732077696c6c2073746f7020667572746865722069737375657320616e6420616c6c6f77207468652065786368616e6765207261746573206f66207468652061737365747320746f2073746179207468652073616d6520706f73742d70726f706f73616c2e0a0a466f6c6c6f77696e67207468652070617373696e67206f6620746865207369676e616c696e6720736e617073686f74205b706f6c6c5d2868747470733a2f2f736e617073686f742e6f72672f232f6d6f6f6e77656c6c2d676f7665726e616e63652e6574682f70726f706f73616c2f307865333062326563333234616430343339376562383634646434363464336635376634346336336363663638346339613132366639646433343930386664356337292c207468697320676f7665726e616e63652070726f706f73616c206973206265696e67206372656174656420746f206578656375746520746865207365636f6e64207374657020696e20726573746f72696e67206c697175696469747920746f20746865206d61726b6574732e0a0a506c65617365207365652074686520666f72756d20706f7374205b686572655d2868747470733a2f2f666f72756d2e6d6f6f6e77656c6c2e66692f742f726571756573742d666f722d70726f706f73616c2d7266702d726564656d7074696f6e2d616e642d7265616c6c6f636174696f6e2d6f662d6e6f6d61642d636f6c6c61746572616c2d616e642d70726f746f636f6c2d72657365727665732d666f722d667261782d6d61726b65742d656e68616e63656d656e742f3734362f332920666f7220667572746865722064657461696c73206f6e207468697320676f7665726e616e63652070726f706f73616c2e0a0000000000000000000000000000000000000000000000000000000000\n  Propose Gas Metering: 6380808\n  schedule batch calldata with  50 actions\n  proposalId: 74\n  Execution Gas Metering: 1511076\n\n

\n\n## Mocks\n\nThe following mocks have been used to test this upgraded system `Mock USDT`, `Mock USDC`, `Mock xcDOT`. These contracts needed to be mocked as they use a precompile on Moonbeam, which reverts when used in a foundry fork. The mocks stand in place of the precompile and allow the tests to run by etching the bytecode onto the precompile address.\n\n## Return Values\n\nxcDOT returns true on transfer and transferFrom. This has been confirmed by the Moonbeam team. FRAX also returns true after a successful transferFrom.\n\n## Files in Scope\n\n| Contract | SLOC | Purpose | Libraries used | Comments |\n| -------------------------- | ---- | ------------------------------ | -------------- | ------------------------------------------------------ |\n| MErc20DelegateFixer.sol | 63 | Bad Debt Fixer Logic | SafeMath |\n| MErc20DelegateMadFixer.sol | 9 | Nomad Collateral Sweeper Logic | n/a |\n| mip-m17.sol | 198 | MIP-M17 Governance Proposal | n/a | Validate function out of scope, deployment is in scope |\n\nThe only issues that are in scope are the ones that could reasonably arise as a result of the upgrade. Any issues that were present in the previous implementation are out of scope.\n\n## Out of Scope Findings\n\nThe `validate` function in the MIP-M17 proposal is out of scope for this audit. This function is not used in the contracts that are being upgraded.\n\nNon standard ERC20 token `transferFrom` does not return a boolean value and will cause Delegate Fixer to fail. This is out of scope as all mTokens that use Delegate Fixer underlying values return true on `transferFrom`.\n\nShare price of .mad mTokens will fall drastically after the proposal is executed. This is expected behavior and out of scope.\n\n.mad ERC20 tokens return a boolean value on transfer. This is out of scope.\n\nFee on transfer tokens not supported with the current implementation of either fixer contract. This is out of scope.\n\nAddresses passed to `fixUser` are not checked to be valid as these values are found in JSON files and will not be address 0. Address 0 checks are out of scope.\n\nAddresses in the contract are assumed to be non-zero. This is out of scope as Addresses.sol would throw an error if an address retrieved was 0.\n\nKnown Compound V2 issues are out of scope. This audit is only concerned with new issues that may arise from the upgrade that were not already present. Any issues in [this](https://code4rena.com/audits/2023-07-moonwell) report are out of scope, and any findings from previous compound audits or Moonwell are out of scope.\n\nThe only items in scope are new issues that may arise from the upgrade. Any issues that were present in the previous implementation are out of scope.\n\nGovernance could liquidate users that are healthy. This is out of scope as it is expected behavior and governance is assumed to be trusted and non-malicious.\n\nSpeculating about future changes that could happen after this upgrade are out of scope unless the changes are directly related to the upgrade.\n\n**Additional Known Issues as outlined [here](https://github.com/Cyfrin/2024-03-Moonwell/issues/1)**\n\n## Definition Changes\n\nCash in the Compound whitepaper is defined as the underlying asset balance of the mToken. This definition has been changed to underlying asset balance of the mToken plus the bad debt amount. This change was necessary to allow the share price to remain unchanged when bad debt is created by fixing users. This has flow on effects for the frontend as the getCash function will return higher than the underlying balance of the mToken.\n\n### Exchange Rate\n\nThe current exchange rate forumula is:\n\n```\nexchangeRate = (cash + total borrows - reserves) / totalSupply\n```\n\nSee [this](https://betterprogramming.pub/compound-v2-in-depth-6227c0528b5) article for an explanation of the exchange rate.\n\nThe new exchange rate formula post upgrade for mFRAX and mxcDOT is:\n\n```\nexchangeRate = (bad debt + cash + total borrows - reserves) / totalSupply\n```\n\nThis new formula accounts for the bad debt. The exchange rate will not change when bad debt is realized, or repaid with reserves or cash.\n","updatedAt":"2024-04-02T14:27:39.806Z","company":"Moonwell","name":"Moonwell","logo":null,"logoImgPublicId":"company/n0p9zsbc1kpuwhmbergr","featuredImgPublicId":"featured/drnzkodvu3dibuz1kolk","forceFeatured":false,"reward":15000,"rewardHighMedium":14000,"rewardLow":1000,"rewardCommunityJudging":1500,"maxRewardedCommunityJudgingPosition":5,"xpBoost":0,"communityJudgingScoreToXpMultiplier":0,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2024-03-Moonwell","telegram":"","discord":"https://discord.gg/cyfrin","twitter":"","github":"moonwell-fi","linkedIn":"","email":"","startDate":"2024-03-04T12:00:00.000Z","endDate":"2024-03-11T12:00:00.000Z","communityJudgingEnabled":true,"communityJudgingStartDate":"2024-03-11T12:00:00.000Z","communityJudgingEndDate":"2024-03-18T12:00:00.000Z","userId":"clldzdkk60000mr082grbuj97","leadJudgeId":"clk3twjk3003imj08kmy05ubk","firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":true,"cjEligibilityPreviousValidSubmission":true,"cjEligibilityPreviousMonetaryReward":true},{"id":"clrzgrole0007xtsq0gfdw8if","createdAt":"2024-01-29T21:50:50.690Z","description":"Morpheus AI is a Smart Agent concept of connecting LLMs and AI Agents to wallets, Dapps, & smart contracts promises to open the world of Web3 to everyone. Chatting in normal language with your Smart Agent and having it understand the question or task, is similar to how Google's search engine opened the early internet up to the general public.","content":"# MorpheusAI\n\n

\n $\"Morpheus\"$ \n

\n\n\n\n## Contest Details\n\n- Total Prize Pool: $22,500\n - HM Awards: 20,000\n - Low Awards: 2,500\n- Starts: January 30, 2024 1200 UTC\n- Ends: February 03, 2024 1200 UTC\n\n## Stats\n- nSLOC: 1054\n- Dollars per nSLOC: $21.35\n\n## About the Project\n\n* *MOR* - The Morpheus Network Token.\n* *LinearDistributionIntervalDecrease* - A library for calculating linear distribution intervals with a plenty of options.\n* *Distribution* - The contract that distributes the MOR tokens to the stakers and the team members.\n* *L1Sender* - A contract that allows to communicate between L1 and L2. It is used to send a minting request to the L2 using the Layer Zero. It is also used to transfer deposited tokens from the L1 to the L2.\n* *L2MessageReceiver* - A contract that receives messages from the L1Sender contract.\n* *L2TokenReceiver* - A contract that receives tokens from the L1Sender contract. It is used to Uniswap market making.\n\nMorpheus AI is a Smart Agent concept of connecting LLMs and AI Agents to wallets, Dapps, & smart contracts promises to open the world of Web3 to everyone. Chatting in normal language with your Smart Agent and having it understand the question or task, is similar to how Google's search engine opened the early internet up to the general public.\n\nThe project is launching using the Techno Capital Machine (TCM) model inspired by https://twitter.com/BasedBeffJezos and outlined here - https://github.com/MorpheusAIs/Morpheus/blob/1b8abd0694940acc10a0b70611148d6e893ba017/!KEYDOCS%20README%20FIRST!/4.TechnoCapitalMachineTCM.md#L4\n\nThe contract audit will cover the initial phases of the TCM development.\n\nUsers direct yield toward the open source project of their choice by depositing assets such as stETH into a Smart Contract.\n50% of the daily yield purchases tokens in the open source project, which are contributed to an AMM trading pair as Protocol Owned Liquidity.\n50% of the daily yield remains as stETH and is added to an AMM as the other half of the trading pair as Protocol Owned Liquidity.\nThe open source project emits its native token to the contributor of the yield on a daily basis.\n\nLater development of the project will ensure holders of the native tokens have access to the open source project’s utility.\n\n\n- [Documentation](https://github.com/MorpheusAIs/Morpheus/)\n- [Website](https://mor.org)\n- [Twitter](https://twitter.com/MorpheusAIs)\n- [GitHub](https://github.com/MorpheusAIs/Morpheus/)\n\n## Actors\n\nCapital Provider \n\n- Deposit stETH into the contract. \n- Claim MOR Tokens\n- Withdraw stETH from the contract\n\nCode Provider \n- imported into the smart contract \n\n\n## Scope (contracts)\n\nAll items within the below directory **mocks can be considered in-scope**\nhttps://github.com/Cyfrin/2024-01-Morpheus\n\n```\n├── contracts\n│ ├── Distribution.sol\n│ ├── L1Sender.sol\n│ ├── L2MessageReceiver.sol\n│ ├── L2TokenReceiver.sol\n│ ├── MOR.sol\n│ ├── interfaces\n│ │ ├── IDistribution.sol\n│ │ ├── IL1Sender.sol\n│ │ ├── IL2MessageReceiver.sol\n│ │ ├── IL2TokenReceiver.sol\n│ │ ├── IMOR.sol\n│ │ ├── tokens\n│ │ │ ├── IStETH.sol\n│ │ │ └── IWStETH.sol\n│ │ └── uniswap-v3\n│ │ └── INonfungiblePositionManager.sol\n│ ├── libs\n│ │ └── LinearDistributionIntervalDecrease.sol\n│ └── mock\n│ ├── DistributionV2.sol\n│ ├── GatewayRouterMock.sol\n│ ├── L1SenderV2.sol\n│ ├── L2MessageReceiverV2.sol\n│ ├── L2TokenReceiverV2.sol\n│ ├── NonfungiblePositionManagerMock.sol\n│ ├── SwapRouterMock.sol\n│ └── tokens\n│ ├── StETHMock.sol\n│ └── WStETHMock.sol\n```\n\n## Compatibilities\n\n\nThe contract is EVM compatible, works with Arbitrum and integrates to Uniswap AMM.\n\nCompatibiilities:\n- Blockchains:\n - Ethereum/Arbitrum\n- Tokens: \n - stETH\n - MOR\n\n\n\n## Setup\n\n```\ngit clone https://github.com/Cyfrin/2024-01-Morpheus.git\ncd 2024-01-Morpheus\n```\n\n### Install Dependencies\n\nTo install the dependencies, run the following command:\n\n```bash\nnpm install\n```\n\n### Compilation\n\nTo compile the contracts, use the next script:\n\n```bash\nnpm run compile\n```\n\n### Test\n\nTo run the tests, execute the following command:\n\n```bash\nnpm run test\n```\n\nTo run the tests for forked mainnet, run:\n\n```bash\nnpm run test-fork\n```\n\n> You need to set the `INFURA_KEY` environment variable to run the tests for forked mainnet.\n\nOr to see the coverage, run:\n\n```bash\nnpm run coverage\n```\n\n> You need to set the `INFURA_KEY` environment variable to run the coverage.\n\n### Deployment\n\nBefore deploying, you need to create an `.env` file following the example of `.env.example`.\n\nNext, you need to fill out config file `deploy/data/config.json` (yoy may choose another file name, based on the network). The example of the config file is already provided. Make sure to fill out all the fields, specifically the `payoutStart` field.\n\nNext, call script located in `deploy/deploy-all.sh` with the following arguments:\n\n```bash\n./deploy/deploy-all.sh \n```\n\nWhere the first argument is the L1 network name and the second argument is the L2 network name.\n\n(network is the name of the network, which should be in `hardhat.config.js`)\n\n### Local Deployment\n\nTo deploy the contracts locally, run the following commands (in the different terminals):\n\n```bash\nnpm run private-network\n./deploy/deploy-all.sh localhost localhost\n```\n\n> The local deployment is may fail due to the lack of third-party contracts. To fix this, you may run test deployment on the forked mainnet.\n\n### Bindings\n\nThe command to generate the bindings is as follows:\n\n```bash\nnpm run generate-types\n```\n\n> See the full list of available commands in the `package.json` file.\n\n## Known Issues:\n\n- Users interacting with the MorpheusAI Smart Contracts must be aware of the privileged roles in the protocol and which actions these privileged roles can perform. Distribution.sol is the contract that will hold the user's staked funds i.e. a token such as stETH. Currently, there are mechanisms, controlled only by the owner of the contract, that can cause indefinite custody of the user's deposited tokens. In other words, users would never be able to withdraw their staked funds again. The owner role must be fully trusted.\n\n- The alias of L1Sender.sol on Arbitrum will hold the ETH received as a gas refund from bridging tokens\nContext: L1Sender.sol, L2TokenReceiver.sol\n\nCommunity Approach - Deploy a contract that can rescue the ETH on the L2 alias address of L1Sender. Or oth- erwise, accept that any excess ETH sent is lost and protect L1Sender.sendDepositToken() with a check that _msgSender() == distribution.\n\n- Negative rebasing of stETH deposits in Distribution.sol can cause bank run and loss to new depositors. \n\nThe Distribution._withdraw() function pays out deposits on a first-come-first-serve basis. This means if there occurs a slashing of staked ETH in Lido (negative rebasing), the stETH balance in Distribution is insufficient to serve all users.\nThe Distribution contract accounts for this scenario by limiting the amount that can be withdrawn to the contract's balance:\nThis may cause a \"bank-run\" where users want to withdraw their stETH as long as there is any left.\nOnce this \"bank-run\" is over, there may be a pool deposits balance greater zero and a stETH balance equal to zero. When new depositors come in, they could lose their funds to existing depositors that withdraw.\nRecommendation: According to Lido docs, rebases have never been negative thus far.\nTracking stETH deposits directly seems to be a deliberate decision by the Morpheus team. As such the issue is\nsimply a reminder for users interacting with the Morpheus smart contracts and the finding can be acknowledged.\n\n- Adjusted for a small lag in the system. \n\n- UUPSUpgradeable contracts will implement a constructor with a call to Initializ- able.disableInitializers\nContext: Distribution.sol, L1Sender.sol, L2TokenReceiver, L2MessageReceiver.sol\n\nMinimum - 1/3 yield - How far you take it out. \n\n- LIDO Staking potential attack vector - There is a mismatch between re-base rewards issued from LIDO to the MOR Project and MOR rewards issued to stakers that withdraw stETH immediately prior to the rebase time each day. The 7 day lockup restricts the maximum variance to 12.5% \"boost\"\n\nAdditional Known Issues as detected by static Analysis: https://github.com/Cyfrin/2024-01-Morpheus/issues/1\n\n\n\n","updatedAt":"2024-02-09T13:30:22.411Z","company":"MorpheusAI","name":"MorpheusAI","logo":null,"logoImgPublicId":"company/lqgum0l8pxf8butrd13n","featuredImgPublicId":"featured/qsrw8yy9afrssewrosfy","forceFeatured":false,"reward":22500,"rewardHighMedium":20000,"rewardLow":2500,"rewardCommunityJudging":0,"maxRewardedCommunityJudgingPosition":5,"xpBoost":0,"communityJudgingScoreToXpMultiplier":null,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2024-01-Morpheus","telegram":"","discord":"https://discord.gg/Dc26EFb6JK","twitter":"MorpheusAIs","github":"MorpheusAIs","linkedIn":"","email":"","startDate":"2024-01-30T12:00:00.000Z","endDate":"2024-02-03T12:00:00.000Z","communityJudgingEnabled":false,"communityJudgingStartDate":null,"communityJudgingEndDate":null,"userId":"clldzdkk60000mr082grbuj97","leadJudgeId":"clkgm90b9000gms085g528phk","firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":false,"cjEligibilityPreviousValidSubmission":false,"cjEligibilityPreviousMonetaryReward":false},{"id":"clqf7mgla0001yeyfah59c674","createdAt":"2023-12-21T12:59:44.636Z","description":"A first-of-its-kind liquid delegated staking platform delivering DeFi composability for Chainlink Staking. Built by premier Chainlink ecosystem developer LinkPool, powered by Chainlink node operators, and governed by the stake.link DAO, stake.link's extensible architecture is purpose-built to support Chainlink Staking and to extend participation in the Chainlink Network.","content":"# stake.link\n\n
\n

\n $\"stake.link\"$ \n

\n
\n\n\n## Contest Details\n\n- Total Prize Pool: \n - HM Awards: 25,000\n - Low Awards: 2,500\n- Starts - Friday December 22, 2023 Noon UTC\n- Ends - Friday January 12, 2024 Noon UTC\n\n## Stats\n- nSLOC: 1414\n- Complexity Score: 1278\n- Dollars per Complexity: $21.52\n- Dollars per nSLOC: $19.45\n\n## About the Project\n\nstake.link is a first-of-its-kind liquid delegated staking platform delivering DeFi composability for Chainlink Staking. Built by premier Chainlink ecosystem developer LinkPool, powered by Chainlink node operators, and governed by the stake.link DAO, stake.link's extensible architecture is purpose-built to support Chainlink Staking and to extend participation in the Chainlink Network.\n\n\n- [Documentation](https://docs.stake.link) (out of scope/not relevant for this audit, provided for context)\n- [Website](https://stake.link)\n- [Twitter](https://www.twitter.com/stakedotlink)\n- [GitHub](https://github.com/stakedotlink)\n- [Governance Forum](https://talk.stake.link)\n\n## Protocol Overview\n\nThe stake.link protocol is a liquid staking protocol that was designed primarily for LINK staking although it can easily be extended to support other assets. The scope of this audit is confined to staking of the protocol token (SDL), rewards distribution to SDL stakers, and the implementation of this functionality across multiple chains using CCIP.\n\nThe protocol is designed to support one primary chain and multiple secondary chains. The contracts on the primary chain store global state for the protocol that accounts for all secondary chains while contracts on secondary chains store only localized state for that chain. \n\nContracts will be deployed as follows:\n\n#### Primary chain (Ethereum):\n- SDLPoolPrimary.sol\n- SDLPoolCCIPControllerPrimary.sol\n- RESDLTokenBridge.sol\n- WrappedTokenBridge.sol\n- RewardsInitiator.sol\n\n#### Secondary chains (Arbitrum, Optimism):\n- SDLPoolSecondary.sol\n- SDLPoolCCIPControllerSecondary.sol\n- RESDLTokenBridge.sol\n\n### SDLPoolPrimary\n\nThe primary SDL pool enables users to stake SDL and receive an reSDL NFT representing their stake position. A user may choose to lock their SDL for a period of time giving a \"boost\" to their stake position proportional the length of of time they lock for. Each reSDL NFT has an \"effective balance\" which represents the base amount of SDL a user staked plus any applicable boost. This effective balance is used to determine the amount of benefit a user receives in various aspects of the protocol such as the amount of rewards received.\n\nRewards come from the liquid staking part of the protocol (out of scope) but most importantly they are periodically distributed to SDL stakers pro rata to the effective reSDL balance of each staker.\n\nIf a user has staked but not locked their SDL, they may withdraw it at any time. If they have locked their SDL, they must wait a minimum of half their total lock period at which point they may initiate a withdrawal which will set their boost to 0 and start the countdown for the second half of their total lock period. Once the second half of their total lock period has elapsed, they may withdraw their SDL. If a user chooses not to initiate a withdrawal, they will continue to receive their full boosted effective balance indefinitely until they initiate a withdrawal.\n\n### SDLPoolSecondary\n\nThe secondary SDL pool functions in the same way as the primary SDL pool with one main difference. When a user performs any action that will alter their effective reSDL balance such as staking, locking, withdrawaing, or initiating a withdrawal, the action will be queued instead of taking effect immediately. Periodically a CCIP update will be received from the primary SDL pool, after which, a user may execute their queued actions. This queue is necessary to keep accounting consistent between the primary SDL pool and secondary SDL pool.\n\n### LinearBoostController\nThe linear boost controller handles the calculations to determine how much boost is received for a locking duration.\n\n### SDLPoolCCIPController (primary/secondary)\n\nThe primary SDL pool CCIP controller handles all interactions with CCIP for the primary SDL pool. Specifically, it sends rewards to secondary chains, sends and receives updates to/from secondary chains, and sends and receives reSDL NFTs to/from secondary chains. The secondary SDL pool CCIP controller performs these same functions but instead of sending rewards, it receives rewards.\n\nThe distribtion of rewards on the primary chain will be periodically triggered by a Keeper through the Rewards Initiator at which point rewards will be distributed to stakers in the primary SDL pool and any applicable rewards will be sent over CCIP to all secondary chains. \n\nWhen a secondary chain receives the rewards, they will be distributed to stakers in the secondary SDL pool. If there are any actions queued at the time of distribution, a Keeper will trigger an update that sends a CCIP message to the primary chain with a payload that includes the new total effective reSDL balance in the secondary SDL pool accounting for all queued actions and the number of new reSDL NFTs that are queued to be minted if any.\n\nOnce the primary SDL pool receives the message, it will update the necessary accounting with the new total effective balance and it will increment the global reSDL token index by the number of new NFTs to be minted. It will then send a CCIP message back to the secondary chain with a payload that includes the starting token index that the new NFTs should be minted with. Once the secondary SDL pool receives this message, users are free to execute their queued actions.\n\n### RESDLTokenBridge\n\nThe reSDL token bridge handles the transfer of reSDL NFTs between the primary and secondary chains. While this is the contract that users interact with, the SDL pool CCIP controllers are the contracts that actually send/receive the CCIP messages.\n\n### WrappedTokenBridge\n\nThe wrapped token bridge handles the transfer of liquid staking tokens (stLINK) between the primary and secondary chains. Specifically it allows a user to wrap stLINK into wstLINK and send it to a secondary chain in a single tx which is necessary because stLINK only exists as wstLINK on secondary chains due to its rebasing nature. Similarly, it also allows a user to transfer wstLINK from a secondary chain to the primary chain and receive stLINK on the primary chain in a single tx.\n\n### RewardsInitiator\nThe rewards initiator is responsible for initiating reward updates/distribution and is called periodically by a Keeper. A second Keeper will also track the deposit change in the staking pool through the rewards initator and trigger a reward update if the deposit change is negative, however, that is outside the scope of this audit.\n\n\n\n## Actors\n\n\n| Role | Description |\n| ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |\n| Staker | Stakers deposit SDL into the SDL Pool in order to receive a percentage of protocol rewards. |\n| Owner | The owner has authorization to modify protocol parameters and perform upgrades for contracts that are upgradeable. The owner for all ownable contracts is a 5/7 multisig. |\n| Keeper | Keepers are Chainlink Automation bots that perform specific tasks either on a time-based schedule or when certain contract state conditions are met. They perform tasks for the protocol such as distributing rewards and initiating cross-chain updates. |\n\n\n## Scope (contracts)\n\n\n```js\ncontracts/\n└── core/\n ├── ccip/\n │ ├── base/\n │ │ └── SDLPoolCCIPController.sol\n │ ├── RESDLTokenBridge.sol\n │ ├── SDLPoolCCIPControllerPrimary.sol\n │ ├── SDLPoolCCIPControllerSecondary.sol\n │ └── WrappedTokenBridge.sol\n └── sdlPool/\n ├── base/\n │ └── SDLPool.sol\n ├── LinearBoostController.sol\n ├── SDLPoolPrimary.sol\n └── SDLPoolSecondary.sol\n └── RewardsInitiator.sol\n```\n\n## Compatibilities\n\nBlockchains:\n- Ethereum\n- Arbitrum\n- Optimism\n\nTokens:\n- ETH\n- LINK `ERC677`\n- stLINK `ERC677`\n- wstLINK `ERC677`\n- SDL `ERC677`\n- reSDL `ERC721`\n\n\n## Setup\n\nInstall dependencies:\n```bash\nyarn\n```\n\nCompile contracts:\n```bash\nyarn compile\n```\n\nRun tests:\n```bash\nyarn test\n```\n\n## Known Issues\n\n- Potential loss of rewards on secondary chain\n - If a staker's reSDL is in flight between chains at the time rewards are distributed, they won't receive their share of rewards\n - In the worst case, the last staker in a secondary SDL pool could transfer their reSDL back to the main chain while rewards are in flight causing the secondary SDL pool to revert once rewards arrive. An attacker could then stake into the pool and claim all rewards\n\n- CCIP dependency\n - The protocol is dependent on Chainlink's CCIP and will cease to function if there is an issue sending and receiving messages between chains\n - CCIP txs may fail if `extraArgs` or `maxLINKFee` are incorrectly set\n\n- Keeper dependency\n - The protocol is dependent on Chainlink automation and assumes it will continue to function at all times although keeper functions can be called manually if necessary\n\n- Owner control and contract upgradeability risks\n - The owner has control over certain parameters and can upgrade certain contracts which can cause issues if set or performed incorrectly\n\n- Any additional issues detected by Aderyn outlined [here](https://github.com/Cyfrin/2023-12-stake-link/issues/1).\n","updatedAt":"2024-02-07T13:02:27.024Z","company":"stake.link","name":"stake.link","logo":null,"logoImgPublicId":"company/ump7ojuyvodvbrmjoghb","featuredImgPublicId":"featured/q4epn0mlfhbwqlhw7i7i","forceFeatured":false,"reward":27500,"rewardHighMedium":25000,"rewardLow":2500,"rewardCommunityJudging":0,"maxRewardedCommunityJudgingPosition":5,"xpBoost":0,"communityJudgingScoreToXpMultiplier":null,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2023-12-stake-link","telegram":"","discord":"","twitter":"stakedotlink","github":"stakedotlink","linkedIn":"","email":"","startDate":"2023-12-22T12:00:00.000Z","endDate":"2024-01-12T12:00:00.000Z","communityJudgingEnabled":false,"communityJudgingStartDate":null,"communityJudgingEndDate":null,"userId":"clldzdkk60000mr082grbuj97","leadJudgeId":"clra1r21c0006w6ilcrtk9vt3","firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":false,"cjEligibilityPreviousValidSubmission":false,"cjEligibilityPreviousMonetaryReward":false},{"id":"clql6lvyu0001mnje1xpqcuvl","createdAt":"2023-12-25T17:17:55.347Z","description":"Secure your crypto assets, such as ETH, WBTC, ARB, LINK, & PAXG tokenized gold, in smart contracts that you control and no one else, then effortlessly borrow stablecoins with 0% interest loans and no time limit to pay back.","content":"# The Standard\n\n
\n

\n $\"Ditto\"$ \n

\n
\n\n## Contest Details\n\n- Total Prize Pool:\n - HM Awards: $17,500\n - Low Awards: $2,500\n- Starts - December 27, 2023 Noon UTC\n- Ends - January 10, 2024 Noon UTC\n\n## Stats\n\n- nSLOC: 609\n- Complexity Score: 698\n- Dollars per Complexity: $28.65\n- Dollars per nSLOC: $32.84\n\n## About the Project\n\nSecure your crypto assets, such as ETH, WBTC, ARB, LINK, & PAXG tokenized gold, in smart contracts that you control and no one else, then effortlessly borrow stablecoins with 0% interest loans and no time limit to pay back.\n\n- [Website](https://www.thestandard.io/)\n- [Twitter](https://www.thestandard.io/)\n- [GitHub](https://github.com/the-standard)\n\n## Actors\n\n- **Borrowers**: users creating Smart Vaults, depositing their collateral, borrowing EUROs stablecoins against it\n\n- **Smart Vault Manager**: contract managing vault deployments, controls admin data which dictates behaviour of Smart Vaults e.g. fee rates, collateral rates, dependency addresses, managed by The Standard\n\n- **Stakers**: users adding TST and/or EUROs to the Liquidation Pool, in order to gain rewards from borrowing fees and vault liquidations\n\n- **Liquidation Pool Manager**: contract managing liquidations and distribution of borrowing fees in the pool\n\n## Scope (contracts)\n\nAll contracts at commit `7c9f84772eacb588c00a2add9f46aa93211a7132`\n\n- [SmartVaultV3]\n- [SmartVaultManagerV5]\n- [LiquidationPool]\n- [LiquidationPoolManager]\n\n## Compatibilities\n\nThe live version of these contracts (deployed to Arbitrum One) have some key external dependencies:\n\n- [WBTC](https://arbiscan.io/token/0x2f2a2543b76a4166549f7aab2e75bef0aefc5b0f)\n- [ARB](https://arbiscan.io/address/0x912ce59144191c1204e64559fe8253a0e49e6548)\n- [LINK](https://arbiscan.io/token/0xf97f4df75117a78c1a5a0dbb814af92458539fb4)\n- [PAXG](https://arbiscan.io/token/0xfeb4dfc8c4cf7ed305bb08065d08ec6ee6728429)\n- [Chainlink ETH / USD feed](https://arbiscan.io/address/0x639fe6ab55c921f74e7fac1ee960c0b6293ba612)\n- [Chainlink WBTC / USD feed](https://arbiscan.io/address/0xd0c7101eacbb49f3decccc166d238410d6d46d57)\n- [Chainlink ARB / USD feed](https://arbiscan.io/address/0xb2a824043730fe05f3da2efafa1cbbe83fa548d6)\n- [Chainlink LINK / USD feed](https://arbiscan.io/address/0x86e53cf1b870786351da77a57575e79cb55812cb)\n- [Chainlink PAXG / USD feed](https://arbiscan.io/address/0x2ba975d4d7922cd264267af16f3bd177f206fe3c)\n- [Chainlink EUR / USD feed](https://arbiscan.io/address/0xa14d53bc1f1c0f31b4aa3bd109344e5009051a84)\n- [Uniswap V3 Swap Router](https://arbiscan.io/address/0xE592427A0AEce92De3Edee1F18E0157C05861564)\n- [The Standard EURO](https://arbiscan.io/token/0x643b34980e635719c15a2d4ce69571a258f940e9)\n- [The Standard Token](https://arbiscan.io/token/0xf5a27e55c748bcddbfea5477cb9ae924f0f7fd2e)\n\nAs well as administrative dependencies managed by us:\n\n- A [Token Manager](https://arbiscan.io/address/0x33c5A816382760b6E5fb50d8854a61b3383a32a0), storing data about which tokens are accepted Smart Vault Collateral\n- A [Deployer](https://arbiscan.io/address/0x53509eF0e49c8a386b81093711aF1eF29357cc25), facilitating user creations of Smart Vaults\n- An [Index](https://arbiscan.io/address/0x56c7506410e5e242261c5E0db6941956c686E5A1), storing vault owners' token IDs and vault addresses\n- A [Price Calculator](https://arbiscan.io/address/0x6ff84e5bf2cff6cf1f23071a6f4e2e169d535e97), using Chainlink data feeds to calculate price conversions for vaults\n- An [NFT Metadata Generator](https://arbiscan.io/address/0x3C70276Ee29FD659a9D06983522b731784012c54), producing token URI metadata based on current vault state\n\nFor this test environment, collateral tokens have been replaced by a test ERC20 token. EUROs and TST have been replaced with mock versions. Chainlink feeds have been replaced by static price feeds. Uniswap swaps have been stubbed by a contract stub.\n\nThe administrative dependencies are managed by The Standard and are therefore not within the scope of this audit. They are replicated in the test environment.\n\n```\nCompatibilities:\n Blockchains:\n - Any EVM chains with live Chainlink data feeds and live Uniswap pools\n Tokens:\n - ETH\n```\n\n## Setup\n\nThis project uses Hardhat.\n\nTo install the dependencies:\n\n```\nnpm install\n```\n\nTo run the test suite:\n\n```\nnpx hardhat test\n```\n\nTo start the default test environment, you can start a local Hardhat node:\n\n```\nnpx hardhat node\n```\n\nAnd use the deploy script to build the environment on the running node:\n\n```\nnpx hardhat run --network localhost scripts/deploy.js\n```\n\nYou should see an output similar to:\n\n```\nSmartVaultManager: 0x...\nLiquidationPoolManager: 0x...\nLiquidationPool: 0x...\nUser 0x... has balance 9999.923234... ETH\nUser 0x... minted with 1000 test TST\nUser 0x... minted with 1000 test EUROs\nUser 0x... minted with 1000 test USDs\n```\n\nUse these addresses to interact with your locally deployed contracts.\n\n## Known Issues\n\n**SmartVaultManagerV5**\n\n- This is version 5 of an OpenZeppelin upgradeable contract. That is why there is no constructor setting the initial state variables\n- `_safeMint` is a reentrancy risk, however this is mitigated by the fact that the contract will try to mint the same token ID again, and reverting\n- Dependencies on our administrative SmartVaultIndex, SmartVaultDeployer, NFTMetadataGenerator contracts\n- `vaults` function array length is unchecked going into for loop. An abuse of NFT minting by a user could prevent them from being able to use this `vaults` function\n- `mint` function is dependent on our SmartVaultDeployer and SmartVaultIndex contracts, however we have the administrative control over setting these addresses\n- Very important access control roles are granted to the Smart Vaults (`MINTER_ROLE`, `BURNER_ROLE`), giving these contracts strong permissions over the supply of EUROs, however this is a necessary key feature in our project, as users must be able to borrow through their vaults. As such the SmartVaultManager must also have a admin role in EUROs access control\n- If a Smart Vault's `undercollateralised` function reverts, it cannot be liquidated\n- No zero address check for administrative functions `setWethAddress`, `setSwapRouter2`, `setNFTMetadataGenerator`, `setSmartVaultDeployer`, `setProtocolAddress`, `setLiquidatorAddress`. However we have benefited from this. This can allow the blocking of certain Smart Vault features. e.g. we were previously able to block a vulnerability in the Smart Vault feature by setting the Swap Router to a zero address\n\n**SmartVaultV3**\n\n- Dependencies on our administrative contracts SmartVaultManager and PriceCalculator, but these addresses are set by our contracts on deployment. This is also the case with the EUROs contract. These addresses could be set to anything on deployment, but this Smart Vault contract only provides value to a user if it has EUROs minting and burning permissions, which are only granted when deployed via SmartVaultManager's `mint`\n- Length of accepted tokens array throughout contract is unchecked, but this Token Manager contract is managed by us and there is unlikely to be more than 5-10 tokens in this array\n- Throughout contract, dependent on an accurate prices being produced by PriceCalculator `tokenToEurAvg`, `tokenToEur`, `eurToToken` functions, but this contract is managed by us, and uses Chainlink data feeds for reliable price data\n- `maxMintable` function will revert if SmartVaultManager `collateralRate` is 0, but this value is controlled by us and should never be\n- `getAssetBalance` function will revert if the token provided has an incorrect combination of symbol bytes array and token address, however this data is managed by our TokenManager contract\n- Contract requires the `protocol` address to be a payable address. This address will be set to the LiquidationPoolManager, which has a `receive` function\n- Also requires `protocol` to be able to access the ERC20s sent. LiquidationPoolManager uses the same TokenManager list to handle assets.\n- `liquidateERC20` is dependent on the token addresses provided by our TokenManager being correct\n- `mint` function requires SmartVaultManager's `HUNDRED_PC` to not be 0, but the value is a constant\n- `swap` is dependent on Uniswap V3 Swap Router. The address must be correct for this swap to be safely completed. This swap router address is controlled by our administrative SmartVaultManager contract\n- `minimumAmountOut` can be set to 0 if there is no value required to keep collateral above required level. The user is likely to lose some value in the swap, especially when Uniswap fees are factored in, but this is at the user's discretion\n- `setOwner` can change control of the vault, but this can only be completed by the SmartVaultManager contract, and is only called when completing an NFT transfer\n\n**LiquidationPoolManager**\n\n- Length of accepted tokens array is unchecked, but this TokenManager contract is managed by us and there is unlikely to be more than 5-10 tokens in this array\n- `protocol` address must be payable, and able to handle ERC20s transferred. This address will be set to our Protocol's treasury wallet.\n\n**LiquidationPool**\n\n- No length check for number of stake `holders`. This could cause a problem throughout contract if there are a high number of stakers\n- TokenManager `getAcceptedTokens` array length unchecked, but uses an administrative contract which is managed by us. Unlikely to be more than 5-10 items\n- `position` function depends on `getTstTotal` not being 0. However, if current position has TST, then `TSTtotal` will never be 0\n- `distributeFees` function requires an approval of EUROs beforehand, but LiquidationPoolManager approves the amount before calling the function\n- `distributeAssets` function requires `stakeTotal` to be greater than 0, but this will always be the case if any `_positionStake > 0`\n- Function is also dependent on Chainlink EUR / USD providing a price greater than 0\n- Also dependent on accurate {Token} / USD prices being accurate, and greater than 0\n- Dependent on `collateralRate` being greater than 0. This value is managed in our administrative SmartVaultManager contract, and the project is dependent on that value being correct\n- `LiquidationPool` requires EUROs `BURNER_ROLE` permission, but this is an important function of the Liquidation Pool\n\n**Additional Issues**\n- Issues caught by Aderyn [here](https://github.com/Cyfrin/2023-12-the-standard/issues/1)\n","updatedAt":"2024-02-26T18:42:08.087Z","company":"The Standard","name":"The Standard","logo":null,"logoImgPublicId":"company/pof1bznxgva82rxr8g8u","featuredImgPublicId":"featured/yorpgbgh7vmwsx18ywy7","forceFeatured":false,"reward":20000,"rewardHighMedium":17500,"rewardLow":2500,"rewardCommunityJudging":0,"maxRewardedCommunityJudgingPosition":5,"xpBoost":0,"communityJudgingScoreToXpMultiplier":0,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2023-12-the-standard","telegram":"","discord":"","twitter":"thestandard_io","github":"the-standard","linkedIn":"","email":"","startDate":"2023-12-27T12:00:00.000Z","endDate":"2024-01-10T12:00:00.000Z","communityJudgingEnabled":false,"communityJudgingStartDate":null,"communityJudgingEndDate":null,"userId":"clldzdkk60000mr082grbuj97","leadJudgeId":"clqx1mw2t000cp0c6v34ywh6q","firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":false,"cjEligibilityPreviousValidSubmission":false,"cjEligibilityPreviousMonetaryReward":false},{"id":"clo38mm260001la08daw5cbuf","createdAt":"2023-10-23T18:35:12.555Z","description":"Steadefi is the next-gen DeFi protocol designed to provide the highest and most sustainable real yields to our investors without the stress of constant position management or the prolonged downturns of the crypto markets.","content":"# Steadefi Codehawks Audit\n\n

\n $\"Steadefi\"$ \n

\n\n\n## Contest Details\n- Total Prize Pool: $35,000\n - High/Medium Awards: $33,000\n - Low: $2,000\n- Start: 26th October 2023 12:00pm UTC\n- End: 6th November 2023 12:00pm UTC\n\n\n## Stats\n- nSLOC: 2,289\n- Complexity Score: 1,634\n- Dollars per nSLOC: ~$15\n- Dollars per Complexity: ~$21\n\n## About\nSteadefi provides vaults with automated risk management for earning leveraged yields effectively and passively in bull, crab and bear markets. With lending and leveraged delta long and neutral stategies, Steadefi's vaults cater to different risk/reward strategies to the best yield-generating DeFi protocols.\n\nAs of October 2023, Steadefi is looking to launch vaults that earn yield from GMX v2 on Arbitrum and Avalanche network.\n\n\n## Official Links\n- [Protocol Documentation](https://docs.steadefi.com)\n- [Website](https://www.steadefi.com)\n- [Front-End Interface](https://www.steadefi.com/vaults)\n- [Blog](https://blog.steadefi.com)\n- [Twitter](https://twitter.com/steadefi)\n- [Discord](https://discord.gg/steadefi)\n\n\n## Protocol Overview\nThere are 2 types of vaults: **Lending Vaults** and **Strategy Vaults**.\n\nA typical set up for 3x Leverage, Delta Long and Delta Neutral strategies to the ETH-USDC GM LP pool on GMXv2, with isolated ETH and USDC lending vaults are as follows:\n\n![Protocol Overview](https://res.cloudinary.com/droqoz7lg/image/upload/v1698422767/protocol-overview_k3yank.png)\n\n> Note that Delta Long strategies borrow only USDC for more leverage, while Delta Neutral strategies borrow both USDC for leverage **as well as** borrow ETH in order to delta hedge the ETH exposure of the liquidity provided to the ETH-USDC GM LP pool (borrowing = hedging).\n\n### Further Technical Documentation\n🚨 **For more details, please check out the [Technical Documentation](https://github.com/Cyfrin/2023-10-SteadeFi/blob/main/docs/technical-documentation.md) directory in this repository.**\n\n### Recorded Video for Codehawks\n[Recorded Explainer Video](https://www.loom.com/share/88ce04a31a4343439cdc9501a6a9448a)\n\n## Actors\n| Role | Responsibilities |\n| ------ | --------------- |\n| Lender | Lenders deposit assets to Lending Vaults (1 asset per Lending Vault) to earn safer, more stable borrow interest on their assets. |\n| Depositor | Depositors deposit assets to Strategy Vaults (Strategy Vaults could accept different assets) to earn earn higher yields than if they were to supply their assets to the yield-earning protocol directly. Depending on the strategy however, they take on different types of risk which would affect their final profit and losses. |\n| Keeper | Keepers are automated \"bots\" that run 24/7, frequently scheduled and/or event-triggered code scripts to perform various protocol maintainence tasks. These tasks include updating of borrow interest rates for Lending Vaults, rebalancing Strategy Vaults whose health are out of its' strategy parameter limits, compounding earned yield for Strategy Vaults, reverting certain issues for strategy vaults when they occur and triggering Emergency Pauses for lending and strategy vaults in the event of any possible issues. |\n| Owner | Owner are administrators that have rights to configure and update various sensitive vault configurations and parameters. Owners of deployed smart-contracts (vaults, oracles, etc.) should be Timelocks of which are managed by Multi-Sigs that require at least a 2 out of 3 signing approval for any transactions to happen with a 24 hours delay. Note that on contract deployment, the immediate Owner is the hot wallet deployer account. After deploying and initial configuration of the contract, the ownership should be immediately transferred from the hot wallet deployer to a Timelock managed by a Multi-Sig. |\n\n\n\n## Scope\n### Contracts in scope:\n```js\ncontracts\n├── interfaces\n ├── oracles\n ├── IChainlinkOracle.sol\n ├── IGMXOracle.sol\n ├── strategy\n ├── gmx\n ├── IGMXVault.sol\n ├── IGMXVaultEvent.sol\n├── oracles\n ├── ChainlinkARBOracle.sol\n ├── GMXOracle.sol\n├── strategy\n ├── gmx\n ├── GMXCallback.sol\n ├── GMXChecks.sol\n ├── GMXCompound.sol\n ├── GMXDeposit.sol\n ├── GMXEmergency.sol\n ├── GMXManager.sol\n ├── GMXProcessDeposit.sol\n ├── GMXProcessWithdraw.sol\n ├── GMXReader.sol\n ├── GMXRebalance.sol\n ├── GMXTrove.sol\n ├── GMXTypes.sol\n ├── GMXVault.sol\n ├── GMXWithdraw.sol\n ├── GMXWorker.sol\n└── utils\n ├── Errors.sol\n```\n\n### Contracts out of scope:\n```js\ncontracts\n├── interfaces\n ├── lending\n ├── protocols\n ├── swap\n ├── tokens\n├── lending\n├── oracles\n ├── ChainlinkOracle.sol\n├── mocks\n├── swaps\n\n```\n\n## Compatibilities\nBlockchains:\n - Arbitrum\n - Avalanche\n\nTokens on Arbitrum:\n - ETH\n - WETH: `0x82aF49447D8a07e3bd95BD0d56f35241523fBab1`\n - WBTC: `0x2f2a2543B76A4166549F7aaB2e75Bef0aefC5B0f`\n - ARB: `0x912CE59144191C1204E64559FE8253a0e49E6548`\n - LINK: `0xf97f4df75117a78c1a5a0dbb814af92458539fb4`\n - SOL: `0x2bCc6D6CdBbDC0a4071e48bb3B969b06B3330c07`\n - UNI: `0xfa7f8980b0f1e64a2062791cc3b0871572f1f7f0`\n - USDC: `0xaf88d065e77c8cC2239327C5EDb3A432268e5831`\n - ETH-USDC GM: `0x70d95587d40a2caf56bd97485ab3eec10bee6336`\n - WBTC-USDC GM: `0x47c031236e19d024b42f8AE6780E44A573170703`\n - ARB-USDC GM: `0xC25cEf6061Cf5dE5eb761b50E4743c1F5D7E5407`\n - LINK-USDC GM: `0x7f1fa204bb700853D36994DA19F830b6Ad18455C`\n - SOL-USDC GM: `0x09400D9DB990D5ed3f35D7be61DfAEB900Af03C9`\n - UNI-USDC GM: `0xc7Abb2C5f3BF3CEB389dF0Eecd6120D451170B50`\n\nTokens on Avalanche:\n - AVAX\n - WAVAX: `0xB31f66AA3C1e785363F0875A1B74E27b85FD66c7`\n - BTC.b: `0x152b9d0FdC40C096757F570A51E494bd4b943E50`\n - WETH.e: `0x49D5c2BdFfac6CE2BFdB6640F4F80f226bc10bAB`\n - SOL: `0xFE6B19286885a4F7F55AdAD09C3Cd1f906D2478F`\n - USDC: `0xb97ef9ef8734c71904d8002f8b6bc66dd9c48a6e`\n - AVAX-USDC GM: `0x913C1F46b48b3eD35E7dc3Cf754d4ae8499F31CF`\n - BTC.b-USDC GM: `0xFb02132333A79C8B5Bd0b64E3AbccA5f7fAf2937`\n - WETH.e-USDC GM: `0xB7e69749E3d2EDd90ea59A4932EFEa2D41E245d7`\n - SOL-USDC GM: `0xd2eFd1eA687CD78c41ac262B3Bc9B53889ff1F70`\n\n## Setup\nInstall all project dependencies with yarn\n```bash\n$ yarn\n```\n\nCompile all contracts\n```bash\n$ yarn compile\n```\n\nNote: You may need to add Foundry to this Hardhat project if you do not have foundry installed: See instructions hereL: [https://hardhat.org/hardhat-runner/docs/advanced/hardhat-and-foundry](https://hardhat.org/hardhat-runner/docs/advanced/hardhat-and-foundry)\n\n### Deployment\nDeploy scripts are all in the `/scripts` directory. Short-cut helper bash functions are in `package.json`.\n\nNote that deployment for different chains or strategies may have different contracts to deploy.\n\nThe steps below are for deploying strategy vaults for ETH-USDC on GMX, using Uniswap for asset swaps.\n\n**After deploying a contract successful, the address of the contract should be updated in `constants.ts` file accordingly so future deploy scripts can utilise the correct deployed contracts.**\n\n**0) Add deployer wallet private key to `.env`**\n\nAdd deployer private key to `.env`\n```javascript\nPRIVATE_KEY_DEPLOYER=\n```\n\n**1) Deploy Chainlink Oracle**\n```bash\n$ npx hardhat run --network arbitrumOne scripts/arb/oracles/deploy-oracle-chainlink-arb.ts\n```\nNote that the price feeds for ETH and USDC should be updated to this oracle.\n\nThis oracle is re-usable for future Arbitrum protocol oracles and strategy vaults.\n\n**2) Deploy GMX Oracle**\n```bash\n$ npx hardhat run --network arbitrumOne scripts/arb/oracles/deploy-oracle-gmx.ts\n```\nThis oracle is re-usable for future GMX strategy vaults.\n\n**3) Deploy a Swap**\n```bash\n$ npx hardhat run --network arbitrumOne scripts/arb/swap/deploy-swap-uniswap.ts\n```\nNote that the fee tiers for ETH and USDC swap pool should be updated in this swap.\n\nThis swap is re-usable for future Arbitrum strategy vaults.\n\n**4) Deploy Lending Vaults**\n```bash\n# Deploy a native ETH Lending Vault\n$ npx hardhat run --network arbitrumOne scripts/arb/lending/deploy-lending-vault-native.ts\n\n# Deploy a USDC Lending Vault\n$ npx hardhat run --network arbitrumOne scripts/arb/lending/deploy-lending-vault-stable.ts\n```\n\nThese lending vaults will be re-usable for future ETH-USDC GMX strategy vaults.\n\n**5) Deploy Strategy Vaults**\n```bash\n# Deploy re-usable strategy vault external library contracts\n$ npx hardhat run --network arbitrumOne scripts/arb/strategy/gmx/deploy-strategy-gmx-libraries.ts\n\n# Deploy a Leveraged Long strategy vault\n$ npx hardhat run --network arbitrumOne scripts/arb/strategy/gmx/deploy-strategy-gmx-long-eth.ts\n\n# Deploy a Leveraged Neutral strategy vault\n$ npx hardhat run --network arbitrumOne scripts/arb/strategy/gmx/deploy-strategy-gmx-neutral-eth.ts\n```\n\nThe library contracts deployed will also be re-usable for other GMX strategy vaults.\n\n**5) Post-Deployment Setup (optional for audit)**\n- Configure Keepers (Relayers, Sentinels, Autotasks)\n- Configure back-end data collection and database\n- Configure front-end interface\n\n\n### Testing\n\nTests coverage\n```bash\n$ forge coverage\n```\n\nRun all tests\n```bash\n$ forge test\n```\n\nRun a particular test suite\n```bash\n$ forge test --match-contract GMXDepositTest\n```\n\nRun a particular test with calltrace\n```bash\n$ forge test --match-test test_createDeposit -vvvv\n```\n\n## Additional Context\n- **Chainlink price feed dependency**\n - The protocol is dependent on Chainlink price feeds operating accurately and correctly. In situations where it does not, the oracle contracts would already revert, therefore preventing further actions with the vaults.\n - It should be assumed that for all accepted tokens in this protocol, there is a price feed for it (the \"GM\" LP tokens' price comes from GMX itself which uses Chainlink as well)\n- **Keeper dependency**\n - The strategy vaults are dependent on keepers running to compound and rebalance the vaults periodically. It should be assumed that the keepers will always be able to run 24/7 to trigger the right functions. However, if there can be issues arising due to such functions, please report them as findings.\n- **GMXTrove only applies if reward tokens are the same as vault's tokenA/tokenB and are airdropped to vault**\n- **It is expected that Neutral strategy vaults will have a leverage factor of 3x and above**\n - A leverage of less than 3x (e.g. 2x) for Neutral strategies may not work to correctly to borrow enough long token to hedge while still adhering to the correct leverage factor.\n - The issue will arise in `GMXManager.calcBorrow()` and `GMXReader.additionalCapacity()` where the computation of shortToken (tokenB) to borrow may underflow.\n - However, Long strategies are OK to have 2x as they simply borrow short token to leverage up.\n - As it does not make sense to deploy a Neutral strategy vault with less than 3x leverage as the strategy will fail, we did not add checks to this in the constructor function.\n- **Rounding errors**:\n - Conversion between scaled and normalized balances inherently incurs some rounding error; we consider rounding errors limited to \"dust\" (miniscule amounts left unaccounted for) out of scope unless they lead to additional unexpected behavior (e.g. if a rounding error can prevent withdrawal batches from being closed).\n- **Accounting terms**:\n - Assets = Equity + Debt\n - Equity = what depositors put into vault\n - Debt = loans from Lending vaults\n - Delta = Refers to the position exposure of this vault's strategy to the underlying volatile asset. Delta can be a negative value.\n\n## Known Issues\n\n- **Vault inflation attack**\n - Just like other smart contract vaults (like ERC-4626 standard), the vaults are also susceptible to a Inflation/Donation Attack that can be carried out by the first depositor to the vault. We will mitigated this by being the first to deposit a small amount to any new vaults and sending the vault share tokens to the vault contract itself, so it will not be accessible to anyone.\n- **GMX Callback failures**\n - The strategy vaults are dependent on GMX's callback to work. GMX's callbacks are only triggered when GMX's keepers successful execute the deposit/withdraw liquidity orders that our vaults submit to it. If GMX's keepers do not work for whatever reason, there is nothing we can do except to cancel the order request. Note that if the attempt to trigger the callback to the vaults by GMX went through BUT it failed, then this should be a finding, as it could be due to faulty code logic on our vaults or too much gas being used in the callback function (there is a 2 million gas limit for callback functions).\n- **No zero address on constructor and functions**\n - We have removed zero address checks on constructor and functions unless they are critical to the core/logic of the vault. This is to reduce gas fees incurred for every trigger of the function, as the function may revert naturally when a zero address is passed in. For e.g., no zero address check needed for getting token price/value from oracles.\n- **Post successful compound() may result in vault's health being out of balance**\n - It is OK for deposit/withdrawals when vault status is out of range, as any deposits will bring vault closer to target leverage and delta, and withdrawals will still obtain their assets accurately and accordingly. If this is found to NOT be the case, then please report this as a finding.\n- **There needs to be enough lending capacity for a successful rebalance**\n - There can be a situation where there is not enough lending capacity to rebalance the vault correctly (e.g. not enough lending capacity to borrow, so the vault's debt ratio is under the lower debt ratio parameters). The strategy vault can only wait until there is enough lending capacity in order to execute a successul rebalance.\n- **Swap deadline is consciously set as block.timestamp for certain functions**\n - In: `GMXDeposit.processDepositFailureLiquidityWithdrawal() and `GMXProcessWithdraw.processWithdraw()`\n - Reminder: A swap deadline timestamp is passed to protect against miners delaying swap transactions until a more favourable time for them to process it.\n - However for the above 2 functions that implements a swap, we decided to allow the deadline to be set as the current block timestamp for these function as they are triggered as a follow up function (by a callback/keeper) and not directly by a user/keeper. If this follow on functions revert due to the swap transaction being processed after a set fixed deadline timestamp, this will cause the vault to be in a \"stuck\" state. To resolve this, this function will have to be called again with an updated deadline until it succeeds/a miner processes the transaction.\n- **PUSH0 opcode with Solidity version 0.8.21 unsupported on L2 networks**\n - Known issue and does not cause any issues during compile or runtime during testing\n\n## Attack ideas (Where to look for bugs)\n- **General**\n - Lenders from lending vaults should be protected from any bad debt or loss of funds as a result of vault's actions. Any flow that results in lending vaults not getting paid back would be critical.\n - Due to design of GMX v2 where adding/removing liquidity involves two transactions, it could lead to internal accounting issues if the various scenarios (success/cancelled/failure) are not handled properly\n - All scenarios should be handled to ensure vault eventually returns to an Open status. Consider how a scenario might lead to a stuck vault (other statuses).\n- **Emergency actions**\n - After emergency actions (pause, close) all loans should be repaid, users' funds secured, and all vault activity should be paused except for emergency withdrawals. Consider ways in which this state might be violated.\n\n- **Main invariants**\n - Assuming a 3X leveraged vault, leverage should never deviate too far from 3. Otherwise, it would imply excessive over or under-borrowing from lending vaults which could result in bad debt\n - After every action (deposit/withdraw/rebalance/compound), the vault should be cleared of any token balances. Violation of this could allow a subsequent depositor to benefit from it.\n\n## Additional Known Issues (4nalyzer)\nAdditional known issues can be found [here](https://github.com/Cyfrin/2023-10-SteadeFi/issues/1)\n","updatedAt":"2023-11-24T18:09:03.544Z","company":"Steadefi","name":"Steadefi","logo":null,"logoImgPublicId":"company/lfvhwkbbr7dtl3o8cu4p","featuredImgPublicId":"featured/hkt5fpi5zf8airkki4tm","forceFeatured":false,"reward":35000,"rewardHighMedium":33000,"rewardLow":2000,"rewardCommunityJudging":0,"maxRewardedCommunityJudgingPosition":5,"xpBoost":0,"communityJudgingScoreToXpMultiplier":null,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2023-10-SteadeFi","telegram":"","discord":"","twitter":"steadefi","github":"steadefi","linkedIn":"","email":"","startDate":"2023-10-26T12:00:00.000Z","endDate":"2023-11-06T12:00:00.000Z","communityJudgingEnabled":false,"communityJudgingStartDate":null,"communityJudgingEndDate":null,"userId":"clldzdkk60000mr082grbuj97","leadJudgeId":"clp7n0q8y0000gdxb9hizn3n6","firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":false,"cjEligibilityPreviousValidSubmission":false,"cjEligibilityPreviousMonetaryReward":false},{"id":"cll5rujmw0001js08menkj7hc","createdAt":"2023-08-10T23:09:40.712Z","description":"Vyper is a Pythonic programming language designed specifically for the Ethereum Virtual Machine. Prioritizing security, compiler simplicity, and auditability, Vyper intentionally omits several features from Python to reduce vulnerabilities and potential EVM exploits. Vyper enables developers to deploy smart contracts on the Ethereum platform while ensuring that the contracts are more transparent and easier to audit than those written in other languages.","content":"# Vyper 0.3.10rc3 Compiler - Competition Details\n\n $\"\"$ \n\n# Contest Details\n- Total Prize Pool: $150,000(+) USDC\n - HM: 95%\n - L: 5%\n- Starts: September 14, 2023 \n- Ends: November 4th, 2023\n- nSLOC: ~14,644\n\nThe donation address for prizes is:\n- `eth:0x18996AdDe10E9AC12e47e5D6a0F486793fad2c15` (vyper-contest.eth)\n- Any EVM Chain: `0xf71d2231bc1309db6419F82afD8157ea858ADd8C`\n\n# Vyper Compiler Walkthrough\n\n- [READ HERE](https://hackmd.io/@pcaversaccio/how-vyper-compiles-into-bytecode)\n\n# About the Contest\n\n## In Scope:\n- Everything in ./vyper (~15,000 nSLOC)\n- Vyper Commit Hash:\n - `3b310d5` \n - Aka the [0.3.10rc3](https://github.com/vyperlang/vyper/releases/tag/v0.3.10rc3)\n - _All the code for this commit is also located in this repo_\n\n\n## Out of scope:\n- Anything outside `./vyper` folder\n- Any issue in the repo labeled \"bug\" is a known bug, and any issue merged or closed from past versions of vyper is a known bug, and does not qualify. \n- EVM version related bugs. For example, the following finding would not qualify: \n```\nVyper 0.3.9 defaults to shanghai which adds the PUSH0 opcode and which is not yet supported on many chains like Optimism. This can lead to dangerous creation and runtime failures.\n```\n\n## Known Issues\n\nYou can see the list of [known issues here.](https://github.com/Cyfrin/2023-09-vyper-compiler/issues/1)\n\n## Judging\n\nDue to the sensitivity of the contest, judging for this contest will be private, and conducted by the Cyfrin team, VSA (Vyper Security Alliance), and the contest will likely involve additional external participants. \n\n## Scoring:\nFor this contest, we are looking exclusively for Highs & Mediums. There will be no Informational / QA prize pool. \n- H/M - 95%\n- L - 5%\n \nYou can check the total prize pool here: [0x18996AdDe10E9AC12e47e5D6a0F486793fad2c15](https://etherscan.io/address/0x18996AdDe10E9AC12e47e5D6a0F486793fad2c15)\n\n## Severity Rating\n\nWe will use the matrix in the CodeHawks documentation to decide severity, but here are some examples.\n\n## Severity Rating Examples \n\n### High \n- High Impact: Reentrancy locks are in the wrong storage slot\n- High Likelihood: Always \n\n### Medium\n- High Impact: Compiler puts reentrancy lock at the wrong spot \n- Low Likelihood: Only when the contract address starts with 0x0000, your codebase is exactly 4,567 lines long, and has a very specific function name. \n\n### Low\n- Low Impact: An extra `INVALID` Opcode is added at the end of metadata\n- Low Likelihood: If the first text in the codebase is \"snek snek snek snek is king\" \n\n## Invited Hawk\n\nThis is our first contest that will include a paid \"Invited Hawk\". We are excited to welcome [obront.eth](https://twitter.com/zachobront) to this contest! He will be paid an additional flat fee from outside the prize pool. \n\n## Additional context:\n- The codegen and optimizer sections are critical because it creates/modifies the output EVM code, so if you're looking for Highs, that's likely where you'll find them.\n- Access control - handing the user unintended powers - is a focus of potential attack\n- It's likely that if the compiler produces EVM opcodes/bytecode that is not correct, it could be considered a H/M even if it's not apparent. So please submit your lows. \n\nWe will be working closely with the Vyper Security Alliance on submissions. \n\n# Sponsors \n\n\n
\n\n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n \n

Lido	Yearn	Curve
\n \n $\"\"$ \n \n	\n \n $\"\"$ \n \n	\n \n $\"\"$ \n \n
Cyfrin	UnoRe
\n \n $\"\"$ \n \n	\n \n $\"\"$ \n \n

\n
\n\n--------------------------------------------------------\n\n**Vyper compiler security audit competition starts 14th September with $150k worth of bounties.** [See the competition on CodeHawks](https://www.codehawks.com/contests/cll5rujmw0001js08menkj7hc) and find [more details in this blog post](https://mirror.xyz/0xBA41A04A14aeaEec79e2D694B21ba5Ab610982f1/WTZ3l3MLhTz9P4avq6JqipN5d4HJNiUY-d8zT0pfmXg).\n\n $\"\"$ \n\n[![Build Status](https://github.com/vyperlang/vyper/workflows/Test/badge.svg)](https://github.com/vyperlang/vyper/actions/workflows/test.yml)\n[![Documentation Status](https://readthedocs.org/projects/vyper/badge/?version=latest)](http://vyper.readthedocs.io/en/latest/?badge=latest \"ReadTheDocs\")\n[![Discord](https://img.shields.io/discord/969926564286459934.svg?label=%23vyper)](https://discord.gg/6tw7PTM7C2)\n\n[![PyPI](https://badge.fury.io/py/vyper.svg)](https://pypi.org/project/vyper \"PyPI\")\n[![Docker](https://img.shields.io/docker/cloud/build/vyperlang/vyper)](https://hub.docker.com/r/vyperlang/vyper \"DockerHub\")\n\n[![Coverage Status](https://codecov.io/gh/vyperlang/vyper/branch/master/graph/badge.svg)](https://codecov.io/gh/vyperlang/vyper \"Codecov\")\n[![Language grade: Python](https://github.com/vyperlang/vyper/workflows/CodeQL/badge.svg)](https://github.com/vyperlang/vyper/actions/workflows/codeql.yml)\n\n# Getting Started\nSee [Installing Vyper](http://vyper.readthedocs.io/en/latest/installing-vyper.html) to install vyper.\nSee [Tools and Resources](https://github.com/vyperlang/vyper/wiki/Vyper-tools-and-resources) for an additional list of framework and tools with vyper support.\nSee [Documentation](http://vyper.readthedocs.io/en/latest/index.html) for the documentation and overall design goals of the Vyper language.\n\nSee [Learn.Vyperlang.org](https://learn.vyperlang.org/) for **learning Vyper by building a Pokémon game**.\nSee [try.vyperlang.org](https://try.vyperlang.org/) to use Vyper in a hosted jupyter environment!\n\n**Note: Vyper is beta software, use with care**\n\n# Installation\nSee the [Vyper documentation](https://vyper.readthedocs.io/en/latest/installing-vyper.html)\nfor build instructions.\n\n# Compiling a contract\nTo compile a contract, use:\n```bash\nvyper your_file_name.vy\n```\n***generate bytecode***\n\n vyper -f bytecode file-name.vy > file-name.bin\n\n***generate abi***\n\n vyper -f abi file-name.vy > file-name.abi\n\nThere is also an [online compiler](https://vyper.online/) available you can use to experiment with\nthe language and compile to ``bytecode`` and/or ``IR``.\n\n**Note: While the vyper version of the online compiler is updated on a regular basis it might\nbe a bit behind the latest version found in the master branch of this repository.**\n\n## Testing (using pytest)\n\n(Complete [installation steps](https://vyper.readthedocs.io/en/latest/installing-vyper.html) first.)\n\n```bash\nmake dev-init\npython setup.py test\n```\n\n# Contributing\n* See Issues tab, and feel free to submit your own issues\n* Add PRs if you discover a solution to an existing issue\n* For further discussions and questions, post in [Discussions](https://github.com/vyperlang/vyper/discussions) or talk to us on [Discord](https://discord.gg/6tw7PTM7C2)\n* For more information, see [Contributing](http://vyper.readthedocs.io/en/latest/contributing.html)\n","updatedAt":"2024-02-19T20:15:50.142Z","company":"Vyper","name":"Vyper - Compiler","logo":null,"logoImgPublicId":"company/ssfxbedrpfm80dyfwhiy","featuredImgPublicId":"featured/rauc5ndfubywjsfsanit","forceFeatured":false,"reward":160000,"rewardHighMedium":150000,"rewardLow":10000,"rewardCommunityJudging":0,"maxRewardedCommunityJudgingPosition":5,"xpBoost":0,"communityJudgingScoreToXpMultiplier":0,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2023-09-vyper-compiler","telegram":"","discord":"https://discord.gg/QvUA338Jbu","twitter":"vyperlang","github":"vyperlang","linkedIn":"","email":"","startDate":"2023-09-14T04:00:00.000Z","endDate":"2023-11-04T04:00:00.000Z","communityJudgingEnabled":false,"communityJudgingStartDate":null,"communityJudgingEndDate":null,"userId":"clldzdkk60000mr082grbuj97","leadJudgeId":"closq2s9v0003l3083kct7o67","firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":true,"privateSubmissionsPublicAfterFinalisationToggle":true,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":false,"cjEligibilityPreviousValidSubmission":false,"cjEligibilityPreviousMonetaryReward":false},{"id":"clm871gl00001mp081mzjdlwc","createdAt":"2023-09-06T20:30:12.196Z","description":"The system mints pegged assets (stablecoins) using an orderbook, using over-collateralized staked ETH. ","content":"# Ditto \n\n \n\n\n## Contest Details \n\n- Total Prize Pool: $55,000\n - HM Awards: $50,000\n - Low Awards: $5,000\n - No GAS, Informational, or QAs\n- Starts September 8, 2023\n- Ends Oct 8th, 2023\n\n## Stats\n- nSLOC: ~3365\n- Complexity Score: ~1682\n- Dollars per Complexity: ~$33\n- Dollars per nSLOC: ~$16\n\n# About the Project\n\n- [Docs](https://dittoeth.com/)\n- [Twitter](https://twitter.com/dittoproj)\n\n# OrderBook\n\n## Scope (contracts)\n\nLet's prioritize the core parts: orderbook functions (making orders: `createX`), yield (`updateYield`, `distributeYield`), shortRecord functions (`increaseCollateral`)\n\n- [ ] libraries/AppStorage.sol\n- [ ] libraries/DataTypes.sol (struct packing for storage types)\n- [ ] facets/AskOrdersFacet.sol\n- [ ] facets/BidOrdersFacet.sol (particularly the `bidMatchAlgo`. bids are different because they match against both types of sell: ask/short)\n- [ ] facets/ShortOrdersFacet.sol\n- [ ] facets/OrdersFacet.sol\n- [ ] libraries/LibOrders.sol\n- [ ] facets/YieldFacet.sol\n- [ ] libraries/LibBridge.sol\n- [ ] facets/ShortRecordFacet.sol\n- [ ] libraries/LibShortRecord.sol\n- [ ] facets/MarginCallPrimaryFacet.sol\n- [ ] facets/MarginCallSecondaryFacet.sol\n- [ ] facets/ExitShortFacet.sol\n- [ ] facets/ERC721Facet.sol (only care about `transferFrom`, `mintNFT` since the rest is standard OZ)\n- [ ] libraries/LibAsset.sol\n- [ ] libraries/LibVault.sol\n- [ ] libraries/LibOracle.sol\n- [ ] facets/VaultFacet.sol\n- [ ] facets/BridgeRouterFacet.sol\n- [ ] bridges/BridgeReth.sol (links to rETH)\n- [ ] bridges/BridgeSteth.sol (links to stETH)\n- [ ] facets/OwnerFacet.sol (dao only)\n- [ ] tokens/Asset.sol (ERC20)\n- [ ] tokens/Ditto.sol (ERC20)\n- [ ] facets/MarketShutdownFacet.sol\n\n## Out of Scope\n\n> don't care about these or any view functions, can skip these.\n\n- Diamond.sol\n- libraries/LibDiamond.sol\n- libraries/PRBMathHelper.sol\n- libraries/UniswapOracleLibrary.sol\n- libraries/UniswapTickMath.sol (copied bc of sol 0.8 + contract size too big)\n- libraries/console.sol\n- libraries/Constants.sol\n- libraries/Errors.sol\n- libraries/Events.sol\n- interfaces/*.sol\n- mocks/*.sol\n- governance/*.sol\n- facets/TWAPFacet.sol\n- facets/TestFacet.sol\n- facets/ViewFacet.sol\n- facets/DiamondCutFacet.sol\n- facets/DiamondLoupeFacet.sol\n\n# Known Issues\n\n- Oracle is very dependent on Chainlink: similar to Liquity. stale/invalid prices fallback to uniswap TWAP. 2 hours staleness means it can be somewhat out of date\n- Oracle: non ETH/USD oracle assets currently have no Uniswap TWAP fallback, it reverts.\n- Need boostrap phase: when there are few shorts/TAPP is low, easy to fall into black swan scenario\n- Bootstrap for ditto rewards: first claimer gets 100% of ditto reward\n- Events: still adding core events, mostly admin events for now.\n- Not done with governance setup\n- Not finished with mainnet deployment setup\n\n## Known Considerations from previous stablecoin Codehawk report\n[https://www.codehawks.com/report/cljx3b9390009liqwuedkn0m0]\n\n- H-01: Collateral tokens < 18 decimals: Project assumes collateral tokens are 18 decimals because they will all specifically be ETH LSTs like rETH. stETH and rETH are both 18. diamondCut upgrade can be used otherwise. (see old reports)\n- H-02: Liquidation reverts: Liquidation shouldn't revert the due to lack of collateral or the extra liquidation fee/bonus because the TAPP can be used. Primary liquidation can revert if there are no orders, secondary liquidation doesn't have an associated fee\n- H-03: Liquidation of small shorts: Protocol attempts to cover liquidating small positions in a few ways: there is a minimum short amount upon creation, gas fee is paid by shorter not liquidator. Shorts with too small fee to get liquidated are also too small to effect the market with bad debt. If needed, the shutdownMarket can be called when market CR is < minimumCR to freeze that market and allow people to redeemErc. Worst case, TAPP/DAO can also secondary liquidate small positions\n- M-01: protocol is only planned to be on L1\n- M-02 stale price: stale period is intentionally set at 2 hours for Ethereum/mainnet for base oracle (ETH/USD), which fallsback to TWAP. For multi-asset oracle, considering adding a mapping to track different stale heartbeats (Gold is 24 hours)\n- M-03 revert if outside of min/max answer: Shouldn't happen for a feed like ETH/USD, but will add checks for minAnswer and maxAnswer according to chainlink docs\n- M-04 decimals: protocol assumes same decimals, not calling decimals() to save a SLOAD of gas. Can use diamond upgrade if needed for multi-asset if necessary.\n- M-05 burnFrom: protocol doesn't inherit OZ ERC20Burnable, just calls _burn directly with owner modifier.\n- M-06 duplicate inputs: protocol uses arrays for inputs for orderhints which isn't an issue, batches for secondary margin call (checks for deleted shorts), and combineShorts ids which checks deleted shorts\n- M-07 oracle fallback: protocol uses Uniswap TWAP\n- M-08 fee-on-transfer: protocol's bridges for reth/steth account checks for fees on deposit of eth into steth or reth by checking balanceOf. It doesn't do it for depositing the token itself, protocol assumes steth/reth won't add a fee on transfer.\n- M-09 liquidate revert: protocol can use TAPP\n- M-10 upgradable collateral: diamond upgradable, bridges are whitelisted already, will think about detecting upgrades\n- M-11 liquidate front run: No particular protections against frontrunning an order/liquidation, and oracle manipulation (unlikely for ETH/USD pair for both chainlink/uniswap)\n- M-12 dos liquidation: secondary liquidation doesn't need to be precise, can't be blocked\n\n\n# OrderBook\n\n## Competition Setup\n\nAdd a mainnet rpc url so you can run fork tests. \n\n```\nbun install\nbun run interfaces\nforge build\necho 'ANVIL_9_PRIVATE_KEY=0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6' > .env && echo 'MAINNET_RPC_URL=XXXXX' >> .env\nforge test\n```\n\n## Setup\n\n```sh\n# Install Bun to run TS/JS\ncurl -fsSL https://bun.sh/install | bash\n# if already installed\nbun upgrade\n# download files from package.json into node_modules\nbun install\n# Install foundry for solidity\ncurl -L https://foundry.paradigm.xyz | bash\nfoundryup\n# init/update submodules for forge-std\ngit submodule update --init --recursive\n# setup .env file\necho 'ANVIL_9_PRIVATE_KEY=0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6' > .env && echo 'MAINNET_RPC_URL=XXXXX' >> .env\n# disable next telemetry\nnpx next telemetry disable\n```\n\n```sh\n# If needed, use volta to get node/npm, uses field in package.json\ncurl https://get.volta.sh | bash\nvolta install node\n```\n\n## Develop\n\n> `bun run` to check commands\n> there's a `pre-push` git hook (bypass with `--no-verify`)\n> If you want to reset everything not tracked in git: `git clean -xfd`\n\n- To run local node: `bun run anvil`, then deploy with `bun run deploy-local`\n- To run UI: `bun run dev` (`http://localhost:3000`)\n- Check `scripts` in `package.json`\n - `bun run build` to compile contracts\n - `bun run interfaces` to re-compile solidity interfaces\n - `bun run test`, `bun run test-gas` (`forge test`)\n - `-- --vv` for verbosity\n - `-- --watch` to watch files\n - `-- -m testX` to match tests\n - `bun run coverage` (first `brew install lcov`)\n\n> https://book.getfoundry.sh/forge/writing-tests.html#writing-tests\n> For info on `v`, https://book.getfoundry.sh/forge/tests.html?highlight=vvvv#logs-and-traces\n\n## Get Started\n\n````sh\nbun run build\nbun run test\nbun run test-gas\nbun run coverage\n\n## Aliases\n\n```sh\nalias i='bun run interfaces-force'\nalias t=\"forge test \"\nalias tm=\"forge test --match-test \"\nalias ts=\"forge test --match-test statefulFuzz\"\nalias g=\"bun run test-gas\"\nalias gm=\"FOUNDRY_PROFILE=gas forge build && FOUNDRY_PROFILE=testgas forge test --match-test \"\nalias w='forge test -vv --watch '\n\nt -m testA\ngm testA\nw -m testA\n```\n````\n","updatedAt":"2023-11-06T11:01:10.537Z","company":"Ditto","name":"DittoETH","logo":null,"logoImgPublicId":"company/ltz8kv2hxjeiphxrxwhi","featuredImgPublicId":"featured/ozatkb8bsv6zk3unsgoz","forceFeatured":false,"reward":55000,"rewardHighMedium":50000,"rewardLow":5000,"rewardCommunityJudging":0,"maxRewardedCommunityJudgingPosition":5,"xpBoost":0,"communityJudgingScoreToXpMultiplier":null,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2023-09-ditto","telegram":"","discord":"https://discord.gg/cyfrin","twitter":"dittoproj","github":"dittoeth","linkedIn":"","email":"","startDate":"2023-09-08T00:00:00.000Z","endDate":"2023-10-08T23:59:00.000Z","communityJudgingEnabled":false,"communityJudgingStartDate":null,"communityJudgingEndDate":null,"userId":"clldzdkk60000mr082grbuj97","leadJudgeId":"clk3twjk3003imj08kmy05ubk","firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":false,"cjEligibilityPreviousValidSubmission":false,"cjEligibilityPreviousMonetaryReward":false},{"id":"cllcnja1h0001lc08z7w0orxx","createdAt":"2023-08-15T18:43:19.829Z","description":"The SPARKN protocol is a Web3 project that aims to build a marketplace for anyone who wants to solve their problems or anyone who wants to help solve problems.\nAs a first step, we have created the protocol. The details of how to use the protocol is up to the users. This team is a graduate of the Foundry Full Course on YouTube with $15,000 up for grabs! ","content":"# Contest Details\n\n
\n

\n $\"Sparkn\"$ \n

\n
\n\n# Contest Details\n\n## Contest Details \n\n- Total Prize Pool: $15,000\n - HM Awards: $14,000\n - Low Awards: $1,000\n - No GAS, Informational, or QAs\n- Starts August 21, 2023\n- Ends August 28th, 2023\n\n## Stats\n- nSLOC: ~194\n- Complexity Score: ~213\n- Dollars per Complexity: ~$70\n\n# About the Project\n\n- [Landing Page](https://sparkn.io/)\n- [CodeFox Twitter](https://twitter.com/CodeFoxInc)\n- [Sparkn Twitter](https://twitter.com/sparkn_io)\n\n# Sparkn\n\n## Incentive\n\nNowadays information is spread around the world in an incredible speed. However, in some isolated areas the information gaps are too substantial to overcome the challenges. One of the biggest challenges we noticed so far is: neither there are talented people nor incentives to create great ideas in some of these areas.\n\nWe found that there are many problems can be solved by the community in a more innovative and open way if things are done openly and smartly with adequate incentives.\n\nSince its inception, Web3, or we can all it \"blockchain industry\", has been thriving, thanks in part to its inherent incentive structure. We believe that the underlying philosophy and values of Web3 can be applied more widely to address various problems.\n\nOur belief is that the more problems we can solve using this technology, the more value we can generate. This, in turn, will allow more people to reap the benefits of Web3 and blockchain. Ultimately, this could lead to the widespread adoption of Web3, allowing it to become a mainstream technology\n\nBecause of this, we have created **SPARKN**.\n\n# What is SPARKN\n\nSPARKN protocol is a Web3 project that aspires to create a marketplace for anyone looking to find solutions to their problems or eager to assist others in solving theirs.\n\nAs an initial step, we've developed the protocol without any limitations. The manner in which the protocol is used is entirely at the discretion of the users, allowing them to adapt it to their unique needs and preferences.\n\n## Scope\n\n- src/\n - ProxyFactory.sol\n - Distributor.sol\n - Proxy.sol\n\n## Out of Scope\n\nAny file except for the files in the above Scope.\n\n## Contracts\n\nThe contracts in this repository are used as escrows for SPARKN users' assets on-chain.\nOur goal is to make sure assets on SPARKN are safe and transparent, no matter who is using it.\n\nThese contracts are responsible for the escrowing of users' funds and distributing them to the winners of the contests. We tried to keep things simple and safe.\n\nAll the contracts are sitting in the `src/` folder. These are the core contracts of the protocol.\n\nThe contracts are supposed to be deployed to any EVM-compatible chains.\n\n# Roles\n\nThere are mainly 3 roles in the protocol. Another role is the owner.\n\n- Organizer: The person who creates the contest and he is responsible for distributing the prizes to the winners. We also sometimes call this role \"innovator\".\n- Sponsor: the person who is willing to fund the contest. Sponsor can be anyone include the organizer.\n- Supporter: the person who is willing to help solve the problem. Winners are selected from the supporters.\n- Owner: The administrator of the protocol.\n\nThe graph below shows the structure of the contracts and their relationships in the protocol.\n\n![contracts structure](https://res.cloudinary.com/droqoz7lg/image/upload/v1692174387/contractsStructure_atnqmw.png)\n\n### More Context\n\n- The contracts is created with the philosophy of \"supporter first\".\n\nIf a contest is created and funded, there is no way to refund. All the funds belong to the persons who wants to help solve the problem, we call them \"supporters\". And there is a certain assets-locking period of time in which no one except the organizer can call and distribute the funds to the winners.\n\n- SPARKN protocol consists of both web2 and Web3, and the system can be upgraded in the future. Because the structure of the contracts are simple and straightforward, and at the same time, all contests have their own life cycle, it is easy to upgrade the system in the future. Once a contest's life cycle ends, we can decide to introduce new contests with any necessary upgrades from that point on.\n\n#### `ProxyFactory.sol`\n\nThis is the main entry point of the protocol.\n\nIt has several functions.\n\n- The owner can use it to set new contests.\n- The organizer can use it to deploy proxy and distribute prizes to winners.\n- The organizer can use meta transaction to send signature to someone else to deploy proxy and distribute prizes to winners.\n- The owner can deploy proxy and distribute prizes to winners if organizer did not call the function in time.\n- The owner can distribute the tokens stuck in the proxy after the proxy's expiration.\n- Anyone can call `getProxyAddress()` to get the address of the proxy even before its deployment.\n- It contains a whitelist.\n\nThis contract inherits the `Ownable` contract from OpenZeppelin for access control. And it inherits the `EIP712` contract from OpenZeppelin for meta transaction. `_hashTypedDataV4` is used for function `deployProxyAndDistributeBySignature()`.\n\n#### `Distributor.sol`\n\nThis is a contract used as the logic contract of the proxy. It will not be used as a single contract, but it will be called through proxy as delegate calls.\n\nIts functions are as follows:\n\n- Only the proxy factory can call the `distribute` function to distribute prizes to winners.\n- During the distribution of prizes, a certain portion of the token in the proxy contract will be sent to the stadium address as fee.\n- During the calls, it will check the whitelist in the factory contract.\n\n#### `Proxy.sol`\n\nThis is a proxy contract. It will be deployed by the factory contract. This contract is paired with every single contest in the protocol.\n\n- It is designed with minimal logic in it.\n- All the calls to proxy contract will be delegated to the implementation(distributor) contract.\n\n## Tests\n\nTests are in the `test/` folder. More explanations about test cases can be found in the test folder's [`README.md`](https://github.com/codefox-inc/sparkn-contracts/tree/main/test) file.\n\n## Known Issues\n\nThese are known issues or designed by purpose.\n\n- There is a way to rescue the token stuck in the proxy contract after the deployment and distribution of prizes only when the token is whitelisted. If the token is not whitelisted, and then if someone sent the token by mistake, the token will be stuck there forever.\n- Proxy contracts are designed to be deployed and distribute the prizes to winners simultaneously. Before the deployment, sponsors are supposed to send the whitelisted ERC20 token to the anticipated/calculated proxy contract address. The proxy address can be calculated by the function `getProxyAddress()`.\n- Proxy contracts are supposed to be disposed after the contest is over. If there is a need to upgrade the protocol, we will just create a new implementation contract and deploy proxies with the new implementation contract. And so is the factory contract.\n- Owner is in charge of some of the key functions of the protocol. Owner's centralization risk is not an issue to be considered this time.\n- We may build a reputation system in the futue to handle the issue of the system being maliciously used, e.g., sybil attack.\n\nSee [here for more known issues](https://github.com/Cyfrin/2023-08-sparkn/issues/1) generated by the 4nalyz3r tool.\n\n## Notes\n\n- We have designed the protocol by using a lot of immutable variables. So it is supposed that there is no state variable collision in the system. If you find any issue, please report.\n- The reason we chosse to use the proxy and implementation pattern is because this can reduce a lot of gas with only deploying the proxy contract with minimal size for each contest.\n- Unfortunately, the current condition of Web3's scalibility is not able to support total on-chain application. That is why we created a more versatile version of it using a hybrid solution of web2 and Web3. We will try to make it more and more decentralized after we onborad more users and the condition of Web3 improves.\n\n## Sequence Diagram of the Protocol\n\nThis sequence diagram shows how the protocol works considering the process of the contest with the roles in the protocol.\n\n```mermaid\nsequenceDiagram\n actor 1 as Owner\n actor S as Sponsor\n actor O as Organizer\n participant PF as ProxyFactory\n participant P as Proxy\n participant D as Distributior\n actor W as Winners\n actor RT as rescue requestor\n Note over 1,W: Contest Preparation Phase\n activate PF\n activate D\n 1->>PF: setContest()\n PF-->>S: getProxyAddress()\n S->>P: send erc20 token\n PF-->>O: getProxyAddress()\n O->>P: send erc20 token\n Note over PF,D: Wait for contest to reach close time\n Note over 1,W: Distribution Phase\n rect rgba(0, 255, 0, 0.1)\n alt Pattern 1: Distribute by organizer\n Note over O: When organizer is active to end the contest\n O->>PF: deployProxyAndDistribute()\n else Pattern 2: Distribute by signature\n Note over O: When organizer is active and wants to use meta tx\n O ->> 1: send signature\n 1->>PF: deployProxyAndDistributeBySignature()\n note over PF: signature validation is OK\n else Pattern 3: Distribute by owner\n Note over 1,W: Contest Expiration Phase\n Note over O: When organizer is not active\n Note over PF, D: And if contest is expired\n 1->>PF: deployProxyAndDistributeByOwner()\n end\n end\n PF->>P: deploy proxy and calls distribute()\n activate P\n P->>D: delegatecall distribute()\n P-xW: distribute erc20 token as prizes\n P-->>PF: Proxy address\n PF-->>O: Proxy address\n deactivate P\n rect rgba(0, 0, 255, 0.1)\n opt\n activate P\n Note over 1,W: Contest Expiration Phase\n Note over P: Proxy is deployed and token is distributed\n Note over P: If whitelisted tokens are sent by mistake\n 1->>PF: distributeByOwner()\n PF->>P: deploy proxy and calls distribute\n P->>D: delegatecall distribute()\n P-xRT: rescue erc20 token, send to rescue requestor\n end\n end\n deactivate PF\n deactivate P\n deactivate D\n Note over 1,W: Contest ends here\n\n```\n\n# How to Start\n\n1. Install dependencies\n\n```bash\nforge install\n```\n\n2. Run tests\n\n```bash\nforge test\n```\n\nrun a single test\n\n```bash\nforge test --mt \n```\n\nrun fuzz test\n\n```bash\nforge test --match-contract FuzzTestProxyFactory\n```\n\nsee test coverage\n\n```bash\nforge coverage\n```\n\n3. Deploy contracts\n\n```bash\nforge deploy --network \n```\n\nor deploy to local network\n\n```bash\nmake deploy\n```\n\n4. Other things to do\n\nFormat the codes\n\n```bash\nmake format\n```\n\n# Reference\n\n- [Foundry Book](https://book.getfoundry.sh/)\n- [OpenZeppelin](https://docs.openzeppelin.com/contracts/4.x/)\n","updatedAt":"2023-09-15T09:33:22.483Z","company":"CodeFox Inc.","name":"Sparkn ","logo":null,"logoImgPublicId":"company/mdsu3k5i2qjdx1sk1pav","featuredImgPublicId":"featured/buqtuxcbzzblt7hsinmi","forceFeatured":false,"reward":15000,"rewardHighMedium":14000,"rewardLow":1000,"rewardCommunityJudging":0,"maxRewardedCommunityJudgingPosition":5,"xpBoost":null,"communityJudgingScoreToXpMultiplier":null,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2023-08-sparkn","telegram":"","discord":"https://discord.gg/dAHusppNrp","twitter":"sparkn_io","github":"codefox-inc","linkedIn":"","email":"","startDate":"2023-08-21T04:00:00.000Z","endDate":"2023-08-29T04:00:00.000Z","communityJudgingEnabled":false,"communityJudgingStartDate":null,"communityJudgingEndDate":null,"userId":"cljx5xan10002kx0877m20mbo","leadJudgeId":null,"firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":false,"cjEligibilityPreviousValidSubmission":false,"cjEligibilityPreviousMonetaryReward":false},{"id":"clkbo1fa20009jr08nyyf9wbx","createdAt":"2023-07-20T21:29:57.911Z","description":"Oracle free peer to peer perpetual lending\n\nBefore diving into the codebase and this implementation of the Blend lending protocol, it is recommended that you read the original paper by Paradigm and Blur: \n\nhttps://www.paradigm.xyz/2023/05/blend#continuous-loans","content":"# CodeHawks Beedle Contest - Competition Details\n\n- Total Prize Pool: $20,000\n - HM Awards: $18,000\n - LQAG: $2,000\n- Starts: July 24th, 2023\n- Ends August 7th, 2023\n- nSLOC: ~706\n- Complexity: ~381\n- Judging Ends August 14th, 2023\n\n# In Scope\n\nAll contracts in `src` are in scope. \n\n```\nsrc/\n├── Beedle.sol\n├── Fees.sol\n├── Lender.sol\n├── Staking.sol\n├── interfaces\n│ ├── IERC20.sol\n│ └── ISwapRouter.sol\n└── utils\n ├── Errors.sol\n ├── Ownable.sol\n └── Structs.sol\n```\n\n# About Beedle\n- [Twitter](https://twitter.com/beedlefi)\n\n# Beedle\nOracle free peer to peer perpetual lending\n\nBefore diving into the codebase and this implementation of the Blend lending protocol, it is recommended that you read the [original paper by Paradigm and Blur](https://www.paradigm.xyz/2023/05/blend#continuous-loans)\n\n# build\n`forge init`\n\n`forge install OpenZeppelin/openzeppelin-contracts`\n\n`forge install vectorized/solady`\n\n`forge build`\n\n# test\n`forge test`\n\n# deploy\nfirst copy the `.example.env` file and create your own `.env` file\n\n`forge script script/LenderScript.s.sol:LenderScript --rpc-url $GOERLI_RPC_URL --broadcast --verify -vvvv`\n\n# Contract Overview\n\n## `Lender.sol`\n\nLender is the main singleton contract for Beedle. It handles all borrowing, repayment, and refinancing.\n\n### `Lending`\n\nIn order to be a lender you must create a lending pool. Lending pools are based on token pairs and any lender can have one pool per lending pair. When creating a pool, lenders choose several key inputs\n\n`loanToken` - the token they are lending out\n`collateralToken` - the token they are taking in as collateral\n`minLoanSize` - the minimum loan size they are willing to take (this is to prevent griefing a lender with dust loans)\n`poolBalance` - the amount of `loanToken` they want to deposit into the pool\n`maxLoanRatio` - the highest LTV they are willing to take on the loan (this is multiplied by 10^18)\n`auctionLength` - the length of liquidation auctions for their loans\n`interestRate` - the interest rate they charge for their loans\n\nAfter creating a pool, lenders can update these values at any time. \n\n### `Borrowing`\n\nOnce lending pools are created by lenders, anyone can borrow from a pool. When borrowing you will choose your `loanRatio` (aka LTV) and the amount you want to borrow. Most other loan parameters are set by the pool creator and not the borrower. After borrowing from a pool there are several things that can happen which we will break down next. \n\n1. `Repaying`\nRepayment is the most simple of all outcomes. When a user repays their loan, they send back the principal and any interest accrued. The repayment goes back to the lenders pool and the user gets their collateral back. \n2. `Refinancing`\nRefinancing can only be called by the borrower. In a refinance, the borrower is able to move their loan to a new pool under new lending conditions. The contract does not force the borrower to fully repay their debt when moving potisitions. When refinancing, you must maintain the same loan and collateral tokens, but otherwise, all other parameters are able to be changed. \n3. `Giving A Loan`\nWhen a lender no longer desires to be lending anymore they have two options. They can either send the loan into a liquidation auction (which we will get into next) or they can give the loan to another lender. Lenders can give away their loan at any point so long as, the pool they are giving it to offers same or better lending terms. \n4. `Auctioning A Loan`\nWhen a lender no longer wants to be in a loan, but there is no lending pool available to give the loan to, lenders are able to put the loan up for auction. This is a Dutch Auction where the variable changing over time is the interest rate and it is increasing linearly. Anyone is able to match an active pool with a live auction when the parameters of that pool match that of the auction or are more favorable to the borrower. This is called buying the loan. If the auction finishes without anyone buying the loan, the loan is liquidated. Then the lender is able to withdraw the borrowers collateral and the loan is closed. \n\n## `Staking.sol`\n\nThis is a contract based on the code of `yveCRV` originally created by Andre Cronje. It tracks user balances over time and updates their share of a distribution on deposits and withdraws. \n","updatedAt":"2023-09-06T10:08:15.927Z","company":"BeedleFi","name":"Beedle - Oracle free perpetual lending","logo":null,"logoImgPublicId":"company/is0wiwcjnvzbnesiipsi","featuredImgPublicId":"featured/gdtgv1zrmbbhffjrxkgw","forceFeatured":false,"reward":20000,"rewardHighMedium":18000,"rewardLow":2000,"rewardCommunityJudging":0,"maxRewardedCommunityJudgingPosition":5,"xpBoost":null,"communityJudgingScoreToXpMultiplier":null,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2023-07-beedle","telegram":"","discord":"https://discord.gg/YSwAvcxVsv","twitter":"beedlefi","github":"0xTingle","linkedIn":"","email":"","startDate":"2023-07-24T04:00:00.000Z","endDate":"2023-08-07T04:00:00.000Z","communityJudgingEnabled":false,"communityJudgingStartDate":null,"communityJudgingEndDate":null,"userId":"cljx5xan10002kx0877m20mbo","leadJudgeId":null,"firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":2,"lowXpRate":10,"mediumXpRate":30,"highXpRate":90,"cjEligibilityContestParticipation":false,"cjEligibilityPreviousValidSubmission":false,"cjEligibilityPreviousMonetaryReward":false},{"id":"cljx3b9390009liqwuedkn0m0","createdAt":"2023-07-10T16:40:58.030Z","description":"This project is meant to be a stablecoin where users can deposit WETH and WBTC in exchange for a token that will be pegged to the USD. The system is meant to be such that someone could fork this codebase, swap out WETH & WBTC for any basket of assets they like, and the code would work the same.","content":"# Foundry DeFi Stablecoin CodeHawks Audit Contest\n\n
\n

\n\n $\"Code$ \n\n

\n
\n\n## Contest Details \n\n- Total Prize Pool: $15,000\n - HM Awards: $14,000\n - LQAG Awards: $1,000\n- Starts July 24, 2023\n- Ends August 5th, 2023\n- nSLOC: 236\n- Complexity: 177\n\n## Submissions \n\n- Submit to [CodeHawks](https://www.codehawks.com/contests/cljx3b9390009liqwuedkn0m0)\n\n## In Scope\n\nAll contracts in `src` are in scope.\n\n*Note on `script` folder*:\nThe contracts in `script` are the scripts you can assume are going to be used to deploy and interact with the contracts. If they have an issue that will affect the overall security of the system, they are in scope. However, if they have a security issue that only affects the script and not the overall deployment of the stablecoin protocol, it is out of scope.\n\n## Scope\n```bash\n./src/\n├── DSCEngine.sol\n├── DecentralizedStableCoin.sol\n└── libraries\n └── OracleLib.sol\n```\n\nEverything else is considered out of scope.\n\n# Known Issues\n\nThe following issues can be ignored. \n\n- A known gas issue, is that we use storage variables instead of immutables for storing the addresses of the collateral. You can ignore this. \n\n- If the protocol ever becomes insolvent, there is _almost_ no way to recover. This is a known issue. \n\n# Differential Tests\n\nYou can find a nearly idential edition of this code in [Vyper here](https://github.com/Cyfrin/brownie-stablecoin-v23). For gas golfers, doing differential tests on these two contracts might be a great starting point. \n\n# About\n\nThis is Lesson 12 of the[Ultimate Foundry 27-hour Solidity Course](https://www.youtube.com/watch?v=umepbfKp5rI). \n\nThis project is meant to be a stablecoin where users can deposit WETH and WBTC in exchange for a token that will be pegged to the USD. The system is meant to be such that someone could fork this codebase, swap out WETH & WBTC for any basket of assets they like, and the code would work the same.\n\n\n- [Foundry DeFi Stablecoin CodeHawks Audit Contest](#foundry-defi-stablecoin-codehawks-audit-contest)\n - [Contest Details](#contest-details)\n - [Submissions](#submissions)\n - [In Scope](#in-scope)\n - [Scope](#scope)\n- [Known Issues](#known-issues)\n- [Differential Tests](#differential-tests)\n- [About](#about)\n- [Getting Started](#getting-started)\n - [Requirements](#requirements)\n - [Quickstart](#quickstart)\n - [Optional Gitpod](#optional-gitpod)\n- [Usage](#usage)\n - [Start a local node](#start-a-local-node)\n - [Deploy](#deploy)\n - [Deploy - Other Network](#deploy---other-network)\n - [Testing](#testing)\n - [Test Coverage](#test-coverage)\n- [Deployment to a testnet or mainnet](#deployment-to-a-testnet-or-mainnet)\n - [Scripts](#scripts)\n - [Estimate gas](#estimate-gas)\n- [Formatting](#formatting)\n\n# Getting Started\n\n## Requirements\n\n- [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)\n - You'll know you did it right if you can run `git --version` and you see a response like `git version x.x.x`\n- [foundry](https://getfoundry.sh/)\n - You'll know you did it right if you can run `forge --version` and you see a response like `forge 0.2.0 (816e00b 2023-03-16T00:05:26.396218Z)`\n\n## Quickstart\n\n```\ngit clone https://github.com/Cyfrin/foundry-defi-stablecoin-codehawks\ncd foundry-defi-stablecoin-codehawks\nforge build\n```\n\n### Optional Gitpod\n\nIf you can't or don't want to run and install locally, you can work with this repo in Gitpod. If you do this, you can skip the `clone this repo` part.\n\n[![Open in Gitpod](https://gitpod.io/button/open-in-gitpod.svg)](https://gitpod.io/#github.com/PatrickAlphaC/foundry-smart-contract-lottery-f23)\n\n# Usage\n\n## Start a local node\n\n```\nmake anvil\n```\n\n## Deploy\n\nThis will default to your local node. You need to have it running in another terminal in order for it to deploy.\n\n```\nmake deploy\n```\n\n## Deploy - Other Network\n\n[See below](#deployment-to-a-testnet-or-mainnet)\n\n## Testing\n\nWe talk about 4 test tiers in the video. \n\n1. Unit\n2. Integration\n3. Forked\n4. Staging\n\nIn this repo we cover #1 and Fuzzing. \n\n```\nforge test\n```\n\n### Test Coverage\n\n```\nforge coverage\n```\n\nand for coverage based testing: \n\n```\nforge coverage --report debug\n```\n\n\n# Deployment to a testnet or mainnet\n\n1. Setup environment variables\n\nYou'll want to set your `SEPOLIA_RPC_URL` and `PRIVATE_KEY` as environment variables. You can add them to a `.env` file, similar to what you see in `.env.example`.\n\n- `PRIVATE_KEY`: The private key of your account (like from [metamask](https://metamask.io/)). **NOTE:** FOR DEVELOPMENT, PLEASE USE A KEY THAT DOESN'T HAVE ANY REAL FUNDS ASSOCIATED WITH IT.\n - You can [learn how to export it here](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key).\n- `SEPOLIA_RPC_URL`: This is url of the goerli testnet node you're working with. You can get setup with one for free from [Alchemy](https://alchemy.com/?a=673c802981)\n\nOptionally, add your `ETHERSCAN_API_KEY` if you want to verify your contract on [Etherscan](https://etherscan.io/).\n\n1. Get testnet ETH\n\nHead over to [faucets.chain.link](https://faucets.chain.link/) and get some tesnet ETH. You should see the ETH show up in your metamask.\n\n2. Deploy\n\n```\nmake deploy ARGS=\"--network sepolia\"\n```\n\n## Scripts\n\nInstead of scripts, we can directly use the `cast` command to interact with the contract. \n\nFor example, on Sepolia:\n\n1. Get some WETH \n\n```\ncast send 0xdd13E55209Fd76AfE204dBda4007C227904f0a81 \"deposit()\" --value 0.1ether --rpc-url $SEPOLIA_RPC_URL --private-key $PRIVATE_KEY\n```\n\n2. Approve the WETH\n\n```\ncast send 0xdd13E55209Fd76AfE204dBda4007C227904f0a81 \"approve(address,uint256)\" 0x091EA0838eBD5b7ddA2F2A641B068d6D59639b98 1000000000000000000 --rpc-url $SEPOLIA_RPC_URL --private-key $PRIVATE_KEY\n```\n\n3. Deposit and Mint DSC\n\n```\ncast send 0x091EA0838eBD5b7ddA2F2A641B068d6D59639b98 \"depositCollateralAndMintDsc(address,uint256,uint256)\" 0xdd13E55209Fd76AfE204dBda4007C227904f0a81 100000000000000000 10000000000000000 --rpc-url $SEPOLIA_RPC_URL --private-key $PRIVATE_KEY\n```\n\n\n## Estimate gas\n\nYou can estimate how much gas things cost by running:\n\n```\nforge snapshot\n```\n\nAnd you'll see and output file called `.gas-snapshot`\n\n\n# Formatting\n\n\nTo run code formatting:\n```\nforge fmt\n```\n","updatedAt":"2023-09-06T17:05:43.511Z","company":"Cyfrin","name":"Foundry DeFi Stablecoin CodeHawks Audit Contest","logo":null,"logoImgPublicId":"company/ih18uvo1h1ghc95fvk7h","featuredImgPublicId":"featured/gdfphxqlz74ozvuzwbvr","forceFeatured":false,"reward":15000,"rewardHighMedium":14000,"rewardLow":1000,"rewardCommunityJudging":0,"maxRewardedCommunityJudgingPosition":5,"xpBoost":null,"communityJudgingScoreToXpMultiplier":null,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2023-07-foundry-defi-stablecoin","telegram":"","discord":"https://discord.gg/NhVAmtvnzr","twitter":"cyfrinaudits","github":"cyfrin","linkedIn":"cyfrin","email":"","startDate":"2023-07-24T04:00:00.000Z","endDate":"2023-08-05T04:00:00.000Z","communityJudgingEnabled":false,"communityJudgingStartDate":null,"communityJudgingEndDate":null,"userId":"cljx5xan10002kx0877m20mbo","leadJudgeId":null,"firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":false,"cjEligibilityPreviousValidSubmission":false,"cjEligibilityPreviousMonetaryReward":false},{"id":"cljyfxlc40003jq082s0wemya","createdAt":"2023-07-11T15:22:01.920Z","description":"This project is meant to enable smart contract auditors (sellers) and smart contract protocols looking for audits (buyers) to connect using a credibly neutral option, with optional arbitration.\n\n","content":"# CodeHawks Escrow Contract - Competition Details\n\n
\n

\n\n $\"CodeHawks$ \n\n

\n
\n\n## Contest Details \n\n- Total Prize Pool: $40,000\n - HM Awards: $37,000\n - LQAG Awards: $3,000\n- Starts July 24, 2023\n- Ends August 5th, 2023\n- nSLOC: ~182\n- Complexity Score: ~106\n\n### Project Overview\n\n**Actors**\n\n* Buyer: The purchaser of services, in this scenario, a project purchasing an audit.\n* Seller: The seller of services, in this scenario, an auditor willing to audit a project.\n* Arbiter: An impartial, trusted actor who can resolve disputes between the Buyer and Seller.\n\n**Design considerations**\n* The Arbiter is only compensated the `arbiterFee` amount if a dispute occurs.\n* Once a dispute has been initiated it can not be canceled.\n* ERC777 tokens should not be used as tokens for the `Escrow` contract given that it enables a malicious buyer to DOS `Escrow::resolveDispute`\n* In case a smart contract calls `EscrowFactory::newEscrow`, given that the caller of this contract is in control of the salt, frontrunning is a possibility.\n\n### Workflows\n\n**Create an `Escrow`**\n\n1. Buyer approves the payment contract to be handled by `EscrowFactory`.\n2. Buyer calls `EscrowFactory::newEscrow`, inputs:\n 1. The price.\n 2. The payment token.\n 3. The seller (auditor or person in charge of the audit).\n 4. Arbiter.\n 5. Arbiter fee: Fee to pay in case of a dispute is initialized.\n 6. Salt: for `create2` `Escrow` deployment.\n\n\n**Expected sucessful workflow**\n\n1. The buyer creates an `Escrow` contract through `EscrowFactory::newEscrow`, depositing the funds.\n2. The seller sends the buyer the report (off-chain).\n3. The buyer acknowledges this report on-chain by calling `Escrow::confirmReceipt`. This sends the funds to the seller.\n\n\n**Expected dispute workflow**\n\n1. The buyer creates an `Escrow` contract through `EscrowFactory::newEscrow`, depositing the funds.\n2. For any reason, the buyer or the seller can initiate a dispute through `Escrow::initiateDispute`.\n3. The arbiter confers with both parties offchain. Arbiter then calls `Escrow::resolveDispute`, reimbursing either side accordingly, emptying the `Escrow`.\n\n\n## Submissions \n\n- Submit to [CodeHawks](https://www.codehawks.com/contests/cljyfxlc40003jq082s0wemya)\n\n## In Scope\n\nAll contracts in `src` are in scope.\n\n*Note on `script` folder*:\nThe contracts in `script` are the scripts you can assume are going to be used to deploy and interact with the contracts. If they have an issue that will affect the overall security of the system, they are in scope. However, if they have a security issue that only affects the script and not the overall deployment of the escrow protocol, it is out of scope.\n\n## Known Issues\n\n* **Addresses other than the zero address (for example 0xdead) could prevent disputes from being resolved** - Before the `buyer` deploys a new `Escrow`, the `buyer` and `seller` should agree to the terms for the `Escrow`. If the `buyer` accidentally or maliciously deploys an `Escrow` with incorrect `arbiter` details, then the `seller` could refuse to provide their services. Given that the `buyer` is the actor deploying the new `Escrow` and locking the funds, it's in their best interest to deploy this correctly.\n* **Large arbiter fee results in little/no `seller` payment** - In this scenario, the `seller` can decide to not perform the audit. If this is the case, the only way the `buyer` can receive any of their funds back is by initiating the dispute process, in which the `buyer` loses a large portion of their deposited funds to the `arbiter`. Therefore, the `buyer` is disincentivized to deploy a new `Escrow` in such a way.\n* **Tokens with callbacks allow malicious sellers to DOS dispute resolutions** - Each supported token will be vetted to be supported. ERC777 should be discouraged.\n* **`buyer` never calls `confirmReceipt`** - The terms of the `Escrow` are agreed upon by the `buyer` and `seller` before deploying it. The onus is on the `seller` to perform due diligence on the `buyer` and their off-chain identity/reputation before deciding to supply the `buyer` with their services.\n* **`salt` input when creating an `Escrow` can be front-run**\n* **`arbiter` is a trusted role**\n* **User error such as `buyer` calling `confirmReceipt` too soon**\n* **Non-`tokenAddress` funds locked**\n\n# About\n\nThis project is meant to enable smart contract auditors (sellers) and smart contract protocols looking for audits (buyers) to connect using a credibly neutral option, with optional arbitration.\n\n- [CodeHawks Escrow Contract - Competition Details](#codehawks-escrow-contract---competition-details)\n - [Contest Details](#contest-details)\n - [Project Overview](#project-overview)\n - [Workflows](#workflows)\n - [Submissions](#submissions)\n - [In Scope](#in-scope)\n - [Known Issues](#known-issues)\n- [About](#about)\n- [Getting Started](#getting-started)\n - [Requirements](#requirements)\n - [Quickstart](#quickstart)\n- [Usage](#usage)\n - [Testing](#testing)\n - [Test Coverage](#test-coverage)\n - [Start a local node](#start-a-local-node)\n - [Deploy](#deploy)\n - [Deploy - Other Network](#deploy---other-network)\n- [Deployment to a testnet or mainnet](#deployment-to-a-testnet-or-mainnet)\n - [Estimate gas](#estimate-gas)\n- [Formatting](#formatting)\n- [Acknowledgements](#acknowledgements)\n\n# Getting Started\n\n## Requirements\n\n- [git](https://git-scm.com/book/en/v2/Getting-Started-Installing-Git)\n - You'll know you did it right if you can run `git --version` and you see a response like `git version x.x.x`\n- [foundry](https://getfoundry.sh/)\n - You'll know you did it right if you can run `forge --version` and you see a response like `forge 0.2.0 (816e00b 2023-03-16T00:05:26.396218Z)`\n\n## Quickstart\n\n```\ngit clone https://github.com/Cyfrin/2023-07-escrow \ncd escrow \nforge build\n```\n\n# Usage\n\n## Testing\n\n```\nforge test\n```\n\n### Test Coverage\n\n```\nforge coverage\n```\n\nand for coverage based testing: \n\n```\nforge coverage --report debug\n```\n\n\n## Start a local node\n\n```\nmake anvil\n```\n\n## Deploy\n\nThis will default to your local node. You need to have it running in another terminal in order for it to deploy.\n\n```\nmake deploy\n```\n\n## Deploy - Other Network\n\n[See below](#deployment-to-a-testnet-or-mainnet)\n\n\n\n# Deployment to a testnet or mainnet\n\n1. Setup environment variables\n\nYou'll want to set your `SEPOLIA_RPC_URL` and `PRIVATE_KEY` as environment variables. You can add them to a `.env` file, similar to what you see in `.env.example`.\n\n- `PRIVATE_KEY`: The private key of your account (like from [metamask](https://metamask.io/)). **NOTE:** FOR DEVELOPMENT, PLEASE USE A KEY THAT DOESN'T HAVE ANY REAL FUNDS ASSOCIATED WITH IT.\n - You can [learn how to export it here](https://metamask.zendesk.com/hc/en-us/articles/360015289632-How-to-Export-an-Account-Private-Key).\n- `SEPOLIA_RPC_URL`: This is url of the goerli testnet node you're working with. You can get setup with one for free from [Alchemy](https://alchemy.com/?a=673c802981)\n\nOptionally, add your `ETHERSCAN_API_KEY` if you want to verify your contract on [Etherscan](https://etherscan.io/).\n\n1. Get testnet ETH\n\nHead over to [faucets.chain.link](https://faucets.chain.link/) and get some tesnet ETH. You should see the ETH show up in your metamask.\n\n2. Deploy\n\n```\nmake deploy ARGS=\"--network sepolia\"\n```\n\n## Estimate gas\n\nYou can estimate how much gas things cost by running:\n\n```\nforge snapshot\n```\n\nAnd you'll see and output file called `.gas-snapshot`\n\n\n# Formatting\n\n\nTo run code formatting:\n```\nforge fmt\n```\n\n\n# Acknowledgements\n- Inspiration for the codebase from [Ross Campbell](https://www.linkedin.com/in/ross-campbell-058153aa/)\n","updatedAt":"2023-09-06T17:39:47.404Z","company":"Cyfrin","name":"CodeHawks Escrow Contract - Competition Details","logo":null,"logoImgPublicId":"company/clgyfdhp5rqfd5f6yh4t","featuredImgPublicId":"featured/qtotiakge38nykhuf9qx","forceFeatured":false,"reward":40000,"rewardHighMedium":37000,"rewardLow":3000,"rewardCommunityJudging":0,"maxRewardedCommunityJudgingPosition":5,"xpBoost":null,"communityJudgingScoreToXpMultiplier":null,"currency":"USDC","githubUrl":"https://github.com/Cyfrin/2023-07-escrow","telegram":"","discord":"https://discord.gg/NhVAmtvnzr","twitter":"cyfrinaudits","github":"cyfrin","linkedIn":"cyfrin","email":"","startDate":"2023-07-24T04:00:00.000Z","endDate":"2023-08-05T04:00:00.000Z","communityJudgingEnabled":false,"communityJudgingStartDate":null,"communityJudgingEndDate":null,"userId":"cljx5xan10002kx0877m20mbo","leadJudgeId":null,"firstFlight":false,"formalVerification":false,"draft":false,"privateSubmissionsToggle":false,"privateSubmissionsPublicAfterFinalisationToggle":false,"resultStatus":"FINAL","gasXpRate":1,"lowXpRate":2,"mediumXpRate":20,"highXpRate":100,"cjEligibilityContestParticipation":false,"cjEligibilityPreviousValidSubmission":false,"cjEligibilityPreviousMonetaryReward":false}]}}]

Deivitto