From 81171331903bb4c54a81c887d6a7f9158579daaf Mon Sep 17 00:00:00 2001 From: pandadefi <87183122+pandadefi@users.noreply.github.com> Date: Wed, 26 Nov 2025 15:29:15 +0000 Subject: [PATCH] rename to yaudit --- .gitignore | 2 + README.md | 6 +- content/2022-03-Bunni-Zap.md | 6 +- content/2022-03-Ohm.md | 6 +- content/2022-04-Ohm-Bond.md | 6 +- content/2022-04-veYFI.md | 156 +++++++++--------- content/2022-05-OpenMEVRouter.md | 6 +- content/2022-06-LevGeist.md | 22 +-- content/2022-06-Singularity.md | 58 +++---- content/2022-06-Superfluid.md | 32 ++-- content/2022-06-Yearn-BalancerLPFactory.md | 10 +- content/2022-08-Bunni.md | 6 +- content/2022-08-Timeless-Yield-Daddy.md | 6 +- content/2022-09-yFu-NFT.md | 6 +- content/2022-10-NounsDAO-Token-Buyer.md | 6 +- content/2022-11-Yearn-Stargate-Strategy.md | 54 +++--- content/2022-12-GET-Protocol-Staking.md | 12 +- content/2022-12-Gro-Protocol.md | 6 +- content/2022-12-LlamaPayV2.md | 12 +- content/2022-12-RageTrade.md | 6 +- content/2023-01-LlamaLendV2.md | 14 +- content/2023-01-TempleDAO-Origami.md | 6 +- content/2023-02-RageTrade-Upgrade.md | 8 +- content/2023-02-TempleDAO-Origami-Recheck.md | 8 +- content/2023-04-Exit10.md | 14 +- content/2023-04-Incubator-DAO.md | 6 +- content/2023-05-Sonne.md | 10 +- content/2023-05-timeless-gauges.md | 6 +- content/2023-06-RAMSES.md | 6 +- content/2023-06-RLN.md | 11 +- content/2023-06-Sickle.md | 6 +- content/2023-06-Spartan-ECDSA.md | 18 +- content/2023-06-VMEX-incentives.md | 12 +- content/2023-06-VMEX.md | 12 +- content/2023-06-Yearn-v3.md | 6 +- content/2023-07-Bunni-Oracle.md | 10 +- content/2023-07-TempleDAO-Lending.md | 12 +- content/2023-08-KEOM-upgrade.md | 8 +- content/2023-08-TempleDAO-Lending-Recheck.md | 12 +- content/2023-10-Dopex-rDPX-v2.md | 6 +- content/2023-10-DopexV2-CLAMM.md | 8 +- content/2023-10-DopexV2-rDPX-upgrade.md | 6 +- content/2023-10-Sickle-Update.md | 6 +- content/2023-12-Euler-EVC.md | 6 +- content/2023-12-dopex-v2-automator.md | 6 +- content/2024-01-Inverse-sDOLA.md | 8 +- content/2024-01-Peapods-yAudit-Report.md | 12 +- content/2024-01-yPrisma-Recheck.md | 6 +- content/2024-01-yPrisma.md | 6 +- content/2024-02-Obelisk.md | 6 +- content/2024-03-1upYFI.md | 6 +- content/2024-03-Cove.md | 8 +- content/2024-03-EulerV2.md | 6 +- content/2024-03-TLX.md | 6 +- content/2024-05-Heroglyphs.md | 6 +- content/2024-05-Sickle-3.md | 6 +- content/2024-05-Summa-Va.md | 96 +++++------ content/2024-05-Summa-Vb.md | 24 +-- content/2024-05-Yearn-STB-yAudit-report.md | 6 +- content/2024-06-Asymmetry-veASF.md | 6 +- ...2024-06-Multiplier-Technologies-Recheck.md | 10 +- ...-Origami-Oracles-Adapters-yAudit-Report.md | 6 +- content/2024-06-Sickle-4.md | 48 +++--- content/2024-08-Euler-Yield-Aggregator.md | 44 +++-- content/2024-08-Goldilocks.md | 6 +- content/2024-09-Euler-Hook-Target-Firewall.md | 6 +- content/2024-09-Euler-PendleOracle.md | 6 +- content/2024-09-Euler-price-oracles-update.md | 6 +- content/2024-09-Qantura-rebalance.md | 6 +- content/2024-10-Euler-ERC20-Wrapper-Locked.md | 6 +- content/2024-10-Flower.md | 6 +- content/2024-10-GuessOurBlock.md | 4 +- content/2024-10-Obelisk.md | 6 +- content/2024-10-Sickle-Strategies.md | 6 +- content/2024-10-Superform.md | 6 +- content/2024-11-MarginZero.md | 4 +- content/2024-11-Olympus-Emission-Manager.md | 8 +- content/2024-11-napier.md | 8 +- content/2024-12-OpenState.md | 4 +- content/2024-12-ResupplyFinance.md | 7 +- content/2025-01-Asymmetry-USA-d.md | 12 +- content/2025-01-Royco-CCDM-MerkleVault.md | 6 +- content/2025-01-Royco-CCDM.md | 4 +- content/2025-01-Sofa-Protocol.md | 4 +- content/2025-02-Olympus-CoolerV2.md | 57 +++---- content/2025-02-Origami-hOHM.md | 66 ++++---- content/2025-03-Bearn.md | 50 +++--- content/2025-03-Beefy-Sonic.md | 55 +++--- content/2025-03-CAP-PremainnetVault.md | 31 ++-- content/2025-03-Goldilocks-ivault4626.md | 17 +- ...25-03-Olympus-Cooler-Migrator-Composite.md | 13 +- content/2025-03-Origami-hOHM-Migrator.md | 10 +- content/2025-04-Asymmetry-dASF.md | 32 ++-- content/2025-04-Ooga-Booga.md | 34 ++-- content/2025-04-Sickle.md | 55 +++--- content/2025-04-Twyne.md | 43 +++-- content/2025-05-Asymmetry-USDaf-V2.md | 35 ++-- content/2025-05-CAP-PremainnetVault-update.md | 34 ++-- content/2025-05-Cozy-Safety-Module.md | 39 ++--- ...25-05-Cozy-Safety-module-Reward-Manager.md | 36 ++-- content/2025-05-HAI-Oracle.md | 29 ++-- content/2025-05-Olympus-CCIP.md | 45 ++--- content/2025-06-UnKat.md | 32 ++-- content/2025-06-usdaf-2-pr2.md | 23 ++- content/2025-07-centrifuge.md | 4 +- content/2025-08-Twyne-incremental.md | 4 +- content/2025-08-haiVELO-V2.md | 2 +- 107 files changed, 909 insertions(+), 921 deletions(-) diff --git a/.gitignore b/.gitignore index eef9112..93b8dd9 100644 --- a/.gitignore +++ b/.gitignore @@ -42,3 +42,5 @@ yarn-error.log* # typescript *.tsbuildinfo next-env.d.ts + +.vscode \ No newline at end of file diff --git a/README.md b/README.md index d11b1b7..3303b00 100644 --- a/README.md +++ b/README.md @@ -1,7 +1,7 @@ # Content for yAudit Reports site -[Dev Site](https://dev-reports-electisec.netlify.app/) - [![Netlify Status](https://api.netlify.com/api/v1/badges/209b2813-cdf4-4e13-8e27-475706b103fd/deploy-status)](https://app.netlify.com/sites/dev-reports-electisec/deploys) +[Dev Site](https://dev-reports-yAudit.netlify.app/) - [![Netlify Status](https://api.netlify.com/api/v1/badges/209b2813-cdf4-4e13-8e27-475706b103fd/deploy-status)](https://app.netlify.com/sites/dev-reports-yAudit/deploys) -[Prod Site](https://reports.yaudit.dev/) - [![Netlify Status](https://api.netlify.com/api/v1/badges/55557632-17ca-4cbd-a915-84289b4abd1d/deploy-status)](https://app.netlify.com/sites/electisec-reports-site/deploys) +[Prod Site](https://reports.yaudit.dev/) - [![Netlify Status](https://api.netlify.com/api/v1/badges/55557632-17ca-4cbd-a915-84289b4abd1d/deploy-status)](https://app.netlify.com/sites/yAudit-reports-site/deploys) -Navigate to [content/](https://github.com/electisec/reports/tree/main/content) to find reports in `markdown` +Navigate to [content/](https://github.com/yAudit/reports/tree/main/content) to find reports in `markdown` diff --git a/content/2022-03-Bunni-Zap.md b/content/2022-03-Bunni-Zap.md index f7ab165..ae16586 100644 --- a/content/2022-03-Bunni-Zap.md +++ b/content/2022-03-Bunni-Zap.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-03-Bunni-Zap -description: Bunni Zap Electisec Report +description: Bunni Zap yAudit Report nav_order: 20 image: assets/images/logo.png --- -# Electisec Bunni Zap Review +# yAudit Bunni Zap Review **Review Resources:** @@ -42,7 +42,7 @@ After the findings were presented to the Bunni Zap team, fixes were made and inc This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Bunni Zap and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Bunni Zap and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2022-03-Ohm.md b/content/2022-03-Ohm.md index 6680301..23c66ab 100644 --- a/content/2022-03-Ohm.md +++ b/content/2022-03-Ohm.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-03-Ohm -description: OlympusGive Electisec Report +description: OlympusGive yAudit Report nav_order: 2 image: assets/images/logo.png --- -# Electisec Ohm Review +# yAudit Ohm Review **Review Resources:** @@ -57,7 +57,7 @@ https://github.com/OlympusDAO/olympus-contracts/pull/288 The review was a time-limited review to provide rapid feedback on potential vulnerabilities. The review was not a full audit. The review did not explore all potential attack vectors or areas of vulnerability and may not have identified all potential issues. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. Olympus and third parties should use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. Olympus and third parties should use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2022-04-Ohm-Bond.md b/content/2022-04-Ohm-Bond.md index a544540..b9663d1 100644 --- a/content/2022-04-Ohm-Bond.md +++ b/content/2022-04-Ohm-Bond.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-04-Ohm-Bond -description: Olympus Bond Electisec Report +description: Olympus Bond yAudit Report nav_order: 3 image: assets/images/logo.png --- -# Electisec Olympus Bond Review +# yAudit Olympus Bond Review **Review Resources:** @@ -42,7 +42,7 @@ After the findings were presented to the Olympus Bond team, fixes were made and The review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third party users that the code has been audited nor that the code is free from defects. By deploying or using the code, Olympus DAO and and users agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third party users that the code has been audited nor that the code is free from defects. By deploying or using the code, Olympus DAO and and users agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2022-04-veYFI.md b/content/2022-04-veYFI.md index cad6f24..73893ef 100644 --- a/content/2022-04-veYFI.md +++ b/content/2022-04-veYFI.md @@ -1,12 +1,12 @@ --- tags: ["vyper"] title: 2022-04-veYFI -description: veYFI Electisec Report +description: veYFI yAudit Report nav_order: 4 image: assets/images/logo.png --- -# Electisec veYFI Review +# yAudit veYFI Review **Review Resources:** None provided beyond the code repository @@ -40,7 +40,7 @@ After the findings were presented to the veYFI team, fixes were made and include The review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third party users that the code has been audited nor that the code is free from defects. By deploying or using the code, Yearn and users agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third party users that the code has been audited nor that the code is free from defects. By deploying or using the code, Yearn and users agree to use the code at their own risk. ## Code Evaluation Matrix @@ -77,7 +77,7 @@ PR #99 moved veYFI to off-chain voting. Discussions with the veYFI team confirme #### Proof of concept -The [VoteDelegation.sol contract](https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VoteDelegation.sol) has functions including `delegate()` and `removeDelegation()`, but the VoteDelegation.sol contract does not have any interaction with the snapshot [DelegateRegistry contract](https://etherscan.io/address/0x469788fE6E9E9681C6ebF3bF78e7Fd26Fc015446#code). Because there are no contract calls to snapshot.org contracts, snapshot.org will not register any vote delegation. +The [VoteDelegation.sol contract](https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VoteDelegation.sol) has functions including `delegate()` and `removeDelegation()`, but the VoteDelegation.sol contract does not have any interaction with the snapshot [DelegateRegistry contract](https://etherscan.io/address/0x469788fE6E9E9681C6ebF3bF78e7Fd26Fc015446#code). Because there are no contract calls to snapshot.org contracts, snapshot.org will not register any vote delegation. #### Impact @@ -187,11 +187,11 @@ The boosted balance for rewards is computed as `balance * 0.4 + totalSupply * ve #### Proof of concept -Boosted Balance equation: https://github.com/Electisec-Residents/veYFI/blob/7846291efec36638eae32ac8798544050ca20877/contracts/Gauge.sol#L302 +Boosted Balance equation: https://github.com/yAudit-Residents/veYFI/blob/7846291efec36638eae32ac8798544050ca20877/contracts/Gauge.sol#L302 -Deposit Update Reward call: https://github.com/Electisec-Residents/veYFI/blob/7846291efec36638eae32ac8798544050ca20877/contracts/Gauge.sol#L351 +Deposit Update Reward call: https://github.com/yAudit-Residents/veYFI/blob/7846291efec36638eae32ac8798544050ca20877/contracts/Gauge.sol#L351 -Total Supply increase: https://github.com/Electisec-Residents/veYFI/blob/7846291efec36638eae32ac8798544050ca20877/contracts/Gauge.sol#L362 +Total Supply increase: https://github.com/yAudit-Residents/veYFI/blob/7846291efec36638eae32ac8798544050ca20877/contracts/Gauge.sol#L362 #### Impact @@ -216,14 +216,14 @@ The `_getReward()` function in Gauge.sol uses the wrong account address twice, w #### Proof of concept The \_account variable should be used in this line instead of msg.sender -https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L512 +https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L512 ``` IExtraReward(extraRewards[i]).getRewardFor(msg.sender); ``` The \_account variable should be used in this line instead of msg.sender -https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L501 +https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L501 ``` IVotingEscrow(veToken).deposit_for(msg.sender, reward); @@ -247,7 +247,7 @@ This issue is similar to the high risk voting issue but relates to a difference #### Proof of concept -The [VoteDelegation.sol contract](https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VoteDelegation.sol) has functions including `delegate()` and `removeDelegation()`, but the VoteDelegation.sol contract does not have any interaction with the snapshot [DelegateRegistry contract](https://etherscan.io/address/0x469788fE6E9E9681C6ebF3bF78e7Fd26Fc015446#code). Because the actual act of voting is planned to happen off-chain with snapshot.org, snapshot.org needs to recognize what a valid vote or delegation is in the snapshot that it takes for each proposal. Currently there is no option in the snapshot.org delegation approach for an "until" value. Factoring in the "until" value could be implemented in a custom snapshot.org voting strategy, but because no such strategy is mentioned anywhere in the veYFI repository, it is expected that this has not been considered. +The [VoteDelegation.sol contract](https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VoteDelegation.sol) has functions including `delegate()` and `removeDelegation()`, but the VoteDelegation.sol contract does not have any interaction with the snapshot [DelegateRegistry contract](https://etherscan.io/address/0x469788fE6E9E9681C6ebF3bF78e7Fd26Fc015446#code). Because the actual act of voting is planned to happen off-chain with snapshot.org, snapshot.org needs to recognize what a valid vote or delegation is in the snapshot that it takes for each proposal. Currently there is no option in the snapshot.org delegation approach for an "until" value. Factoring in the "until" value could be implemented in a custom snapshot.org voting strategy, but because no such strategy is mentioned anywhere in the veYFI repository, it is expected that this has not been considered. #### Impact @@ -286,7 +286,7 @@ The risk for this vector is increased when combined with finding Low #3, because #### Proof of concept The penalty_ratio equation -https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L570 +https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L570 #### Impact @@ -339,12 +339,12 @@ The boosted balance for rewards is computed as `balance * 0.4 + totalSupply * ve #### Proof of concept -Equation to compute Total Supply: https://github.com/Electisec-Residents/veYFI/blob/7846291efec36638eae32ac8798544050ca20877/contracts/VotingEscrow.vy#L756 +Equation to compute Total Supply: https://github.com/yAudit-Residents/veYFI/blob/7846291efec36638eae32ac8798544050ca20877/contracts/VotingEscrow.vy#L756 (`t_i` is truncated to a value in weeks at L748 and L750.) -Equation to compute Balance: https://github.com/Electisec-Residents/veYFI/blob/7846291efec36638eae32ac8798544050ca20877/contracts/VotingEscrow.vy#L677 +Equation to compute Balance: https://github.com/yAudit-Residents/veYFI/blob/7846291efec36638eae32ac8798544050ca20877/contracts/VotingEscrow.vy#L677 -`_t` is set to block.timestamp for balance computation: https://github.com/Electisec-Residents/veYFI/blob/7846291efec36638eae32ac8798544050ca20877/contracts/VotingEscrow.vy#L647 +`_t` is set to block.timestamp for balance computation: https://github.com/yAudit-Residents/veYFI/blob/7846291efec36638eae32ac8798544050ca20877/contracts/VotingEscrow.vy#L647 #### Impact @@ -389,7 +389,7 @@ The `_lockingRatio()` function of Gauge.sol returns a ratio based on the amount #### Proof of concept The `_lockingRatio()` function returns PRECISON_FACTOR, equivalent to locking for the MAX_TIME value, when the ve token is undergoing migration: -https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L221 +https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L221 Instead, it would be better to revert in this case so that the ve token can be finished without any users taking advantage of this edge case. @@ -430,10 +430,10 @@ if (block.timestamp < periodFinish) { ``` BaseGauge.sol line that can be unchecked -https://github.com/Electisec-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L79 +https://github.com/yAudit-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L79 Gauge.sol line that can be unchecked -https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L229 +https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L229 #### Impact @@ -454,7 +454,7 @@ Using a compound comparison such as `≥` or `≤` uses more gas than a simple c #### Proof of concept The `_notifyRewardAmount()` function in BaseGauge.sol contains -https://github.com/Electisec-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L170-L177 +https://github.com/yAudit-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L170-L177 ``` if (block.timestamp >= periodFinish) { @@ -502,11 +502,11 @@ The gas savings comes from the removal of a temporary variable. The value of `j+ There are 4 instances of this in Gauge.sol and 1 instance in VoteDelegation.sol -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L161 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L357 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L386 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L511 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VoteDelegation.sol#L121 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L161 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L357 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L386 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L511 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VoteDelegation.sol#L121 #### Impact @@ -528,13 +528,13 @@ If there is no risk of a function accidentally receiving ether, such as a functi The following functions have the onlyOwner modifier and can be marked as payable -- `setVe()` https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Registry.sol#L49 -- `addVaultToRewards()` https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Registry.sol#L67 -- `removeVaultFromRewards()` https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Registry.sol#L94 -- `setVe()` https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VeYfiRewards.sol#L30 -- `setVe()` https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L110 -- `setDuration()` https://github.com/Electisec-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L73 -- `sweep()` https://github.com/Electisec-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L111 +- `setVe()` https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Registry.sol#L49 +- `addVaultToRewards()` https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Registry.sol#L67 +- `removeVaultFromRewards()` https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Registry.sol#L94 +- `setVe()` https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VeYfiRewards.sol#L30 +- `setVe()` https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L110 +- `setDuration()` https://github.com/yAudit-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L73 +- `sweep()` https://github.com/yAudit-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L111 #### Impact @@ -556,10 +556,10 @@ Using `> 0` is less gas efficient than using `!= 0` when comparing a uint to zer Four instances of this were found -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L353 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L382 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L497 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/ExtraReward.sol#L123 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L353 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L382 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L497 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/ExtraReward.sol#L123 #### Impact @@ -604,8 +604,8 @@ The boostedBalanceOf function and deposit function of Gauge.sol should be declar There are two public functions that can be external -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L287 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L317 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L287 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L317 #### Impact @@ -627,12 +627,12 @@ The VotingEscrow.vy contract contains some functions that primarily serve as com The following functions include comments indicating they are fulling or partially used for Aragon compatibility, and may not otherwise be necessary: -1. `version` state variable and `_version` init parameter https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L155 -2. `controller()` https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L129-L131 -3. `transfersEnabled()` https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L129-L131 -4. `balanceOf()` https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L650 -5. `totalSupply()` https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L772 -6. `changeController()` https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L831-L837 +1. `version` state variable and `_version` init parameter https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L155 +2. `controller()` https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L129-L131 +3. `transfersEnabled()` https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L129-L131 +4. `balanceOf()` https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L650 +5. `totalSupply()` https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L772 +6. `changeController()` https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L831-L837 #### Impact @@ -689,8 +689,8 @@ The BaseGauge.sol `queueNewRewards()` function contains duplicated code. This ca The logic for the case `block.timestamp >= periodFinish` and `(distributedSoFar * 12) / 10 < _amount` is the same, so they can be placed into the same if statement. -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L146-L150 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L156-L162 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L146-L150 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L156-L162 The revised `queueNewRewards()` function can look like this @@ -740,7 +740,7 @@ The BaseGauge.sol `setDuration()` function can use a minor gas savings. #### Proof of concept Existing code -https://github.com/Electisec-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L80-L84 +https://github.com/yAudit-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L80-L84 Modified code to use local variable instead of state variable in emit @@ -755,7 +755,7 @@ emit DurationUpdated(newDuration, newRate); ``` A similar type of improvement can be made in Registry.sol -https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Registry.sol#L95-L96 +https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Registry.sol#L95-L96 The code can be modified to ``` @@ -869,10 +869,10 @@ There is no zero check in `setDuration()` in BaseGauge.sol. If a duration of zer #### Proof of concept If `block.timestamp < periodFinish`, then the code will check if newDuration is zero, but this check will not happen if the if statement is skipped when `block.timestamp > periodFinish` -https://github.com/Electisec-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L73 +https://github.com/yAudit-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L73 This can cause problems in other functions that divide by the duration -https://github.com/Electisec-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L170-L177 +https://github.com/yAudit-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L170-L177 #### Impact @@ -893,29 +893,29 @@ There are some typos that have no impact on code functionality, but fixes could #### Proof of concept 1. The MAX_DELAGATED variable should be spelled MAX_DELEGATED - https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VoteDelegation.sol#L16 + https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VoteDelegation.sol#L16 2. betwwen should be between - https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L324 + https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L324 3. The last sentence in the ExtraReward.sol contract needs to be fixed, most likely by removing the words "Gauge will". It reads "Gauge will this contract is used behind multiple delegate proxies." - https://github.com/Electisec-Residents/veYFI/blob/master/contracts/ExtraReward.sol#L13-L14 + https://github.com/yAudit-Residents/veYFI/blob/master/contracts/ExtraReward.sol#L13-L14 4. "claimm veYFI and aditional reward" should be "claim veYFI and additional reward" (two typos) - https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L373 + https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L373 5. Triger should be Trigger - https://github.com/Electisec-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L131 + https://github.com/yAudit-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L131 6. veYFITotalSypply should be veYFITotalSupply - https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L284 + https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L284 7. "rewards are distributed during 7 days" should says "rewards are distributed during reward duration" because duration is a variable and could change - https://github.com/Electisec-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L12 + https://github.com/yAudit-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L12 8. "over a week" should say "over the reward duration" because duration is a variable and could change - https://github.com/Electisec-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L130 + https://github.com/yAudit-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L130 9. "restart a new week" should say "restart a new reward duration" because duration is a variable and could change - https://github.com/Electisec-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L154 + https://github.com/yAudit-Residents/veYFI/blob/master/contracts/BaseGauge.sol#L154 10. A reference to CRV exists in the vyper code. Change ERC20CRV to ERC20YFI - https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L152 + https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L152 11. "earning for an account" should be "earnings for an account" - https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L248-L249 + https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L248-L249 12. "address acccount" should be "address account" - https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L219 + https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L219 #### Impact @@ -937,14 +937,14 @@ Constant variables should be used in place of magic numbers to prevent typos. Th The value 1e18 appears throughout the contracts -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VeYfiRewards.sol#L62 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VeYfiRewards.sol#L69 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L245 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L274 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L280 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/ExtraReward.sol#L75 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/ExtraReward.sol#L86 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/ExtraReward.sol#L92 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VeYfiRewards.sol#L62 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VeYfiRewards.sol#L69 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L245 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L274 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L280 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/ExtraReward.sol#L75 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/ExtraReward.sol#L86 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/ExtraReward.sol#L92 #### Impact @@ -966,9 +966,9 @@ There are three `_updateReward()` functions in veYFI. The Gauge.sol `_updateRewa The three different `_updateReward()` functions -1. https://github.com/Electisec-Residents/veYFI/blob/master/contracts/ExtraReward.sol#L44 -2. https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VeYfiRewards.sol#L36 -3. https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L183 +1. https://github.com/yAudit-Residents/veYFI/blob/master/contracts/ExtraReward.sol#L44 +2. https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VeYfiRewards.sol#L36 +3. https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L183 #### Impact @@ -1002,12 +1002,12 @@ This is the check in Curve: The check does not exist in the same locations in the veYFI VotingEscrow contract: -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L458 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L496 -- https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L512 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L458 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L496 +- https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L512 If this check is added to veYFI, it should also be added to createLockFor, a function that Curve does not have: -https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L477 +https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L477 #### Impact @@ -1028,7 +1028,7 @@ The veYFI contract can be migrated. The migrator contract will need to implement #### Proof of concept The `migrateLock()` call in the existing veYFI code: -https://github.com/Electisec-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L606 +https://github.com/yAudit-Residents/veYFI/blob/master/contracts/VotingEscrow.vy#L606 #### Impact @@ -1049,7 +1049,7 @@ The `withdraw()` function of Gauge.sol can use -= to reduce code complexity. #### Proof of concept The `+=` operator is used often in veYFI, but the `-=` operator is not used in this line -https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L391 +https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L391 ``` _balances[msg.sender] = _balances[msg.sender] - _amount; @@ -1080,7 +1080,7 @@ The `depositFor()` function in Gauge.sol allows the `_updateReward()` function t #### Proof of concept The `depositFor()` function: -https://github.com/Electisec-Residents/veYFI/blob/master/contracts/Gauge.sol#L344 +https://github.com/yAudit-Residents/veYFI/blob/master/contracts/Gauge.sol#L344 #### Impact diff --git a/content/2022-05-OpenMEVRouter.md b/content/2022-05-OpenMEVRouter.md index df2bb99..6617fbc 100644 --- a/content/2022-05-OpenMEVRouter.md +++ b/content/2022-05-OpenMEVRouter.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-05-OpenMEV -description: OpenMEV Electisec Report +description: OpenMEV yAudit Report nav_order: 5 image: assets/images/logo.png --- -# Electisec OpenMEV Review +# yAudit OpenMEV Review **Review Resources:** @@ -42,7 +42,7 @@ After the findings were presented to the OpenMEV team, fixes were made and inclu The review was a time-limited review to provide rapid feedback on potential vulnerabilities. The review was not a full audit. The review did not explore all potential attack vectors or areas of vulnerability and may not have identified all potential issues. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. Manifold and third parties should use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. Manifold and third parties should use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2022-06-LevGeist.md b/content/2022-06-LevGeist.md index 94917b1..4cb1bed 100644 --- a/content/2022-06-LevGeist.md +++ b/content/2022-06-LevGeist.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-06-LevGeist -description: LevGeist Electisec Report +description: LevGeist yAudit Report nav_order: 7 image: assets/images/logo.png --- -# Electisec LevGeist Review +# yAudit LevGeist Review **Review Resources:** Documentation was provided @@ -31,19 +31,19 @@ Documentation was provided **Yearn LevGeist** -The levgeist branch of the Yearn-contracts [Repo](https://github.com/Electisec-block-2/yearnV2-gen-lev-lending/tree/levgeist) was reviewed over 11 days. The contracts were reviewed by 1 auditor and several Fellows from June 13 to June 24, 2022. The repository was under active development during the review, but the review was limited to commit [6c43c39c2e9cfcfb329edf3678843c5b57095dcf](https://github.com/Electisec-block-2/yearnV2-gen-lev-lending/tree/levgeist). +The levgeist branch of the Yearn-contracts [Repo](https://github.com/yAudit-block-2/yearnV2-gen-lev-lending/tree/levgeist) was reviewed over 11 days. The contracts were reviewed by 1 auditor and several Fellows from June 13 to June 24, 2022. The repository was under active development during the review, but the review was limited to commit [6c43c39c2e9cfcfb329edf3678843c5b57095dcf](https://github.com/yAudit-block-2/yearnV2-gen-lev-lending/tree/levgeist). ## Scope -[Code Repo](https://github.com/Electisec-block-2/yearnV2-gen-lev-lending/tree/levgeist) +[Code Repo](https://github.com/yAudit-block-2/yearnV2-gen-lev-lending/tree/levgeist) The review covered contracts modified by the pull request at above specific commit and focused on the contracts directory. -After the findings were presented to the Yearn team, fixes were made and included up to [commit 6c43c39c2e9cfcfb329edf3678843c5b57095dcf](https://github.com/Electisec-block-2/yearnV2-gen-lev-lending/tree/levgeist). Fixes were reviewed to confirm whether they remedied the original finding, but a new security review was not performed on the revised code (e.g. to determine whether new vulnerabilities were introduced by the fixes). +After the findings were presented to the Yearn team, fixes were made and included up to [commit 6c43c39c2e9cfcfb329edf3678843c5b57095dcf](https://github.com/yAudit-block-2/yearnV2-gen-lev-lending/tree/levgeist). Fixes were reviewed to confirm whether they remedied the original finding, but a new security review was not performed on the revised code (e.g. to determine whether new vulnerabilities were introduced by the fixes). The review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third party users that the code has been audited nor that the code is free from defects. By deploying or using the code, yearn and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third party users that the code has been audited nor that the code is free from defects. By deploying or using the code, yearn and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -210,7 +210,7 @@ Delete lines 254 to 257. This issue is also present in LevAave between lines 307 #### Proof of concept -On line 336 https://github.com/Electisec-block-2/yearnV2-gen-lev-lending/blob/levgeist/contracts/Strategy.sol#L336 the function checks if the want balance is sufficient to cover the amountNeeded, this is set as `wantBalance > _amountNeeded`. If wantBalance is the same as \_amountNeeded the strategy still has sufficient funds to cover the withdraw, meaning the logic that follows this if statement is unnecessary. +On line 336 https://github.com/yAudit-block-2/yearnV2-gen-lev-lending/blob/levgeist/contracts/Strategy.sol#L336 the function checks if the want balance is sufficient to cover the amountNeeded, this is set as `wantBalance > _amountNeeded`. If wantBalance is the same as \_amountNeeded the strategy still has sufficient funds to cover the withdraw, meaning the logic that follows this if statement is unnecessary. #### Impact @@ -349,8 +349,8 @@ emit SetRewardBehavior(_swapRouter, _minRewardToSell); #### Impact Variable shadowing might lead to some confusion and unexpected behaviour. -https://github.com/Electisec-block-2/yearnV2-gen-lev-lending/blob/6c43c39c2e9cfcfb329edf3678843c5b57095dcf/contracts/Strategy.sol#L187 -https://github.com/Electisec-block-2/yearnV2-gen-lev-lending/blob/6c43c39c2e9cfcfb329edf3678843c5b57095dcf/contracts/Strategy.sol#L197 +https://github.com/yAudit-block-2/yearnV2-gen-lev-lending/blob/6c43c39c2e9cfcfb329edf3678843c5b57095dcf/contracts/Strategy.sol#L187 +https://github.com/yAudit-block-2/yearnV2-gen-lev-lending/blob/6c43c39c2e9cfcfb329edf3678843c5b57095dcf/contracts/Strategy.sol#L197 #### Recommendation @@ -414,6 +414,6 @@ Monitor the LP profile of the GEIST/FTM pair and if liquidity drops too far then Acknowledged -## About Electisec +## About yAudit -[Electisec](https://electisec.com/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. Electisec includes [a fellowship program](https://electisec.com/fellowship-program/), a residents program, and [a guest auditor program](https://electisec.com/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to Electisec for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. +[yAudit](https://yaudit.dev/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. yAudit includes [a fellowship program](https://yaudit.dev/fellowship-program/), a residents program, and [a guest auditor program](https://yaudit.dev/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to yAudit for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. diff --git a/content/2022-06-Singularity.md b/content/2022-06-Singularity.md index f82a02f..5a49c8f 100644 --- a/content/2022-06-Singularity.md +++ b/content/2022-06-Singularity.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-06-Singularity -description: Singularity Electisec Report +description: Singularity yAudit Report nav_order: 6 image: assets/images/logo.png --- -# Electisec Singularity v2 Review +# yAudit Singularity v2 Review **Review Resources:** @@ -42,7 +42,7 @@ image: assets/images/logo.png The Singularity v2 protocol is an AMM providing single-sided ERC20 token pools. These pools allow users to perform single-sided deposits, without a token pair counterpart as required in AMMs like Uniswap or Sushiswap. Singularity v2 uses a collateralization ratio with a custom curve to calculate the fees for deposit, withdraw, and swap operations. Singularity v2 is not permissionless and relies on an admin to create new pools, pause pools, and set deposit/withdraw caps. The design of Singularity v2 is similar to Uniswap in that users interact with a router and a factory creates new pools for new tokens. -The main branch of the Singularity v2 [Repo](https://github.com/revenant-finance/singularity-v2) was reviewed over 15 days. The code review was performed by 2 auditors between June 12 and June 27, 2022. A number of Electisec Fellows also reviewed the contracts and contributed over 50 man hours. The repository was under active development during the review, but the review was limited to [one specific commit](https://github.com/revenant-finance/singularity-v2/commit/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361). +The main branch of the Singularity v2 [Repo](https://github.com/revenant-finance/singularity-v2) was reviewed over 15 days. The code review was performed by 2 auditors between June 12 and June 27, 2022. A number of yAudit Fellows also reviewed the contracts and contributed over 50 man hours. The repository was under active development during the review, but the review was limited to [one specific commit](https://github.com/revenant-finance/singularity-v2/commit/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361). ## Scope @@ -59,7 +59,7 @@ After the findings were presented to the Singularity v2 team, fixes were made an The review was a time-limited review to provide rapid feedback on potential vulnerabilities. The review was not a full audit. The review did not explore all potential attack vectors or areas of vulnerability and may not have identified all potential issues. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. Singularity and third parties should use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. Singularity and third parties should use the code at their own risk. ## Code Evaluation Matrix @@ -70,7 +70,7 @@ Electisec and the auditors make no warranties regarding the security of the code | Complexity | Average | The Factory and Router contracts have relatively low complexity because they are mostly forked from Uniswap, but the Pool contract has substantial complexity. The complexity arises from the collateralization ratio's impact on fees and slippage and the interactions between different Singularity pools during swap operations. More extensive modeling of this complexity should be performed in order to prevent unexpected edge cases from resulting in loss of user value. | | Libraries | Average | Singularity v2 relies on some solmate contracts (for ERC20, ReentrancyGuard, FixedPointMathLib) and Chainlink integration. This is an average number of dependencies compared to similar protocols. Because the solmate libraries are copied into the Singularity project manually, they should be checked for vulnerabilities or updated versions before production release. | | Decentralization | Average | The protocol relies on an admin to create new pools, pause/unpause pools, and perform other actions. While this is a less decentralized design than a DEX like Uniswap, if the admin role is assigned to a trusted multisig, the centralization level would be comparable to other similar protocols. Additional checks on certain admin-controlled values would increase user trust that the admin would have more limited abilities to modify fees. | -| Code stability | Average | The lack of updated documentation and recent changes demonstrate the protocol is still under development. A dev branch was created while the Electisec review was ongoing with some changes applied to this branch. | +| Code stability | Average | The lack of updated documentation and recent changes demonstrate the protocol is still under development. A dev branch was created while the yAudit review was ongoing with some changes applied to this branch. | | Documentation | Low | There is a significant lack of NatSpec comments around the functions in all contracts. NatSpec documentation should be added for all functions. Beyond comments in the contracts, some of [the online documentation](https://docs.revenantlabs.io/singularity/) was outdated compared to the implementation in the code. | | Monitoring | Good | Events are emitted consistently from all functions that control value transfers. | | Testing and verification | Average | The test coverage [is over 90%](https://github.com/revenant-finance/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/coverage/contracts/index.html) for the entire protocol. Despite the high amount of coverage, the findings in this report demonstrate that the tests should cover more edge cases than they currently do. | @@ -258,7 +258,7 @@ Acknowledged ### 1. High - allPrices gas grieving causes complete loss of on-chain oracle (devtooligan) -The use of an unbound array to store price data for the on-chain oracle in SingularityOracle.sol for the `allPrices` mapping state variable is problematic as it increases the gas cost of calling `getLatestRound()` every time a new price is added. This problem stems from the fact that the array of `PriceData` structs from `allPrices` is [copied to memory](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L40) in `getLatestRound()` +The use of an unbound array to store price data for the on-chain oracle in SingularityOracle.sol for the `allPrices` mapping state variable is problematic as it increases the gas cost of calling `getLatestRound()` every time a new price is added. This problem stems from the fact that the array of `PriceData` structs from `allPrices` is [copied to memory](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L40) in `getLatestRound()` #### Proof of concept @@ -276,19 +276,19 @@ At some point, the `getLatestRound()` function will no longer be callable as the #### Recommendation -An immediate fix would be to [change line 40 in SingularityOracle.sol](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L40) to use _storage_ instead of _memory_. This would then use a pointer to the storage location instead and eliminate the need to copy it to memory. +An immediate fix would be to [change line 40 in SingularityOracle.sol](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L40) to use _storage_ instead of _memory_. This would then use a pointer to the storage location instead and eliminate the need to copy it to memory. ```solidity PriceData[] storage prices = allPrices[token]; // proposed change ``` -However, we also noted that in the two places in the code where an `allPrices` array is accessed, only the last element is used. As such, we propose changing the `allPrices` mapping value to be a single `PriceData` instead of an array `PriceData[]` as [it is currently declared on line 24](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L24). +However, we also noted that in the two places in the code where an `allPrices` array is accessed, only the last element is used. As such, we propose changing the `allPrices` mapping value to be a single `PriceData` instead of an array `PriceData[]` as [it is currently declared on line 24](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L24). ```solidity mapping(address => PriceData) public allPrices; // proposed change ``` -If the mapping gets updated, the [getLatestRound()](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L40) and [pushPrice()](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L70) logic would have to be updated to reference a single `PriceData` and not the last element of a `PriceData[]` array. +If the mapping gets updated, the [getLatestRound()](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L40) and [pushPrice()](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L70) logic would have to be updated to reference a single `PriceData` and not the last element of a `PriceData[]` array. ##### Developer response @@ -387,13 +387,13 @@ Acknowledged, will fix via off-chain oracle ### 3. High - Incorrect tolerance for price reported by Chainlink Oracle (blockdev) -When the latest price is fetched from Chainlink Oracle, it is verified that it does not deviate beyond a certain tolerance threshold from the price reported before. [SingularityOracle.sol#L21](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L21) defines this tolerance as 1.5% — +When the latest price is fetched from Chainlink Oracle, it is verified that it does not deviate beyond a certain tolerance threshold from the price reported before. [SingularityOracle.sol#L21](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L21) defines this tolerance as 1.5% — ```solidity uint256 public maxPriceTolerance = 0.015 ether; // 1.5% ``` -However, the way it's applied to calculate the deviation at [SingularityOracle.sol#L43](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L43) is incorrect — +However, the way it's applied to calculate the deviation at [SingularityOracle.sol#L43](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L43) is incorrect — ```solidity uint256 percentDiff = (priceDiff * 1 ether) / (price * 100); @@ -414,7 +414,7 @@ uint256 priceDiff = price > chainlinkPrice ? price - chainlinkPrice : chainlinkP uint256 percentDiff = (priceDiff * 1 ether) / (price * 100); ``` -Here `chainlinkPrice` deviates by 10% from `price`. Following the way [SingularityOracle.sol](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol) calculates the deviation, `percentDiff` turns out be less than `maxPriceToTolerance` which is not the intended result. +Here `chainlinkPrice` deviates by 10% from `price`. Following the way [SingularityOracle.sol](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol) calculates the deviation, `percentDiff` turns out be less than `maxPriceToTolerance` which is not the intended result. A full PoC can be found here: https://github.com/0xbok/singularity-v2/blob/21793993f634a385fb3ef18198a2761d732d91b5/foundry-test/Contract.t.sol#L305-L317 @@ -424,7 +424,7 @@ High. In situations where an asset price is too volatile, or chainlink oracle mi #### Recommendation -Change the way `priceDiff` is calculated at [SingularityOracle.sol#L43](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L43) to +Change the way `priceDiff` is calculated at [SingularityOracle.sol#L43](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol#L43) to ```solidity uint256 percentDiff = (priceDiff * 1 ether) / price; @@ -440,7 +440,7 @@ A transaction containing a potentially unbounded loop can cause it to run out of #### Proof of concept -[SingularityFactory.sol#L111-L119](https://github.com/Electisec-block-2/singularity-v2/blob/main/contracts/SingularityFactory.sol#L111-L119) has a `collectFees()` function which collects the protocol fee from all the pools in a single transaction. +[SingularityFactory.sol#L111-L119](https://github.com/yAudit-block-2/singularity-v2/blob/main/contracts/SingularityFactory.sol#L111-L119) has a `collectFees()` function which collects the protocol fee from all the pools in a single transaction. ```solidity function collectFees() external override onlyAdmin { @@ -1029,11 +1029,11 @@ Fixed in commit ff71a174560ff12077b1ad48bfd964a97b9d097c ### 1. Low - Missing two-step transfer ownership pattern (blockdev, SaharAP) -[SingularityFactory.sol](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityFactory.sol) and [SingularityOracle.sol](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol) has several functions which can only be called by its `admin`. The `admin` is first set via its contructor. The current admin can set another address as `admin` by calling `setAdmin()` function. If an inaccessible address is passed to this function, all the privileged functionality will be permanently lost. +[SingularityFactory.sol](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityFactory.sol) and [SingularityOracle.sol](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol) has several functions which can only be called by its `admin`. The `admin` is first set via its contructor. The current admin can set another address as `admin` by calling `setAdmin()` function. If an inaccessible address is passed to this function, all the privileged functionality will be permanently lost. #### Proof of concept -[SingularityFactory.sol#L81](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityFactory.sol#L81) and [SingularityOracle.sol](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol) use `setAdmin()` to set `admin` to a new address — +[SingularityFactory.sol#L81](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityFactory.sol#L81) and [SingularityOracle.sol](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityOracle.sol) use `setAdmin()` to set `admin` to a new address — ```solidity function setAdmin(address _admin) external override onlyAdmin { @@ -1058,7 +1058,7 @@ Performing multiplication before division is generally better to avoid loss of p #### Proof of concept -In the following code in [`getSlippageIn`](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L357) function there is a division before multiplication for computing `slippageIn` +In the following code in [`getSlippageIn`](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L357) function there is a division before multiplication for computing `slippageIn` ```solidity // Calculate G' @@ -1069,7 +1069,7 @@ slippageIn = amount.mulWadDown(gPrime); ``` ّFirst, `amount` should be multiplied by gDiff and then divided by `(afterCollateralizationRatio - currentCollateralizationRatio)`. -[`getSlippageOut`](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L379) function also has this problem for computing `slippageOut`. +[`getSlippageOut`](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L379) function also has this problem for computing `slippageOut`. #### Impact @@ -1597,13 +1597,13 @@ Since Solidity v0.8, arithmetic operations revert on underflow and overflow. If Instances where `unchecked` can be used — -- [SingularityPool.sol#L185](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L185) +- [SingularityPool.sol#L185](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L185) ```solidity uint256 amountPostSlippage = amount - slippage; ``` -- [SingularyPool.sol#L252-L256](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L252-L256) +- [SingularyPool.sol#L252-L256](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L252-L256) ```solidity if (decimals <= 18) { @@ -1614,7 +1614,7 @@ Instances where `unchecked` can be used — ``` -- [SingularityPool.sol#L300](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L300) and [SingularityPool.sol#L335](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L335) +- [SingularityPool.sol#L300](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L300) and [SingularityPool.sol#L335](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L335) ```solidity fee = feeA - feeB; @@ -1638,7 +1638,7 @@ Reading calldata is cheaper than reading from memory. So, to iterate on a callda #### Proof of concept -- [SingularityFactory.sol#L123-L124](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityFactory.sol#L123-L124), [SingularityFactory.sol#L136-L137](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityFactory.sol#L136-L137), [SingularityFactory.sol#L150-L151](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityFactory.sol#L150-L151) +- [SingularityFactory.sol#L123-L124](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityFactory.sol#L123-L124), [SingularityFactory.sol#L136-L137](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityFactory.sol#L136-L137), [SingularityFactory.sol#L150-L151](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityFactory.sol#L150-L151) ```solidity uint256 length = tokens.length; @@ -1663,7 +1663,7 @@ Fixed in commit 5d91208a816f8229b4389b4d48048465816f2356 #### Proof of concept -SingularityPool.sol has [`getDepositFee()`](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L302-L304) and [`getWithdrawalFee()`](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L337-L339) have named return variable `fee` which is assigned as follows: +SingularityPool.sol has [`getDepositFee()`](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L302-L304) and [`getWithdrawalFee()`](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol#L337-L339) have named return variable `fee` which is assigned as follows: ```solidity if (feeA > feeB) { @@ -1723,7 +1723,7 @@ To save gas, it's better to give infinite token approval to a contract when comp #### Proof of concept -For every swap and deposit, `SingularityRouter.sol` increases its token allowance to the related pools at [SingularityRouter.sol#L101](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityRouter.sol#L101) and [SingularityRouter.sol#L134](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityRouter.sol#L134). +For every swap and deposit, `SingularityRouter.sol` increases its token allowance to the related pools at [SingularityRouter.sol#L101](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityRouter.sol#L101) and [SingularityRouter.sol#L134](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityRouter.sol#L134). This costs extra gas when compared to the case where the router gives infinite approval only once. @@ -1733,7 +1733,7 @@ Gas Savings #### Recommendation -Remove lines [SingularityRouter.sol#L101](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityRouter.sol#L101) and [SingularityRouter.sol#L134](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityRouter.sol#L134). +Remove lines [SingularityRouter.sol#L101](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityRouter.sol#L101) and [SingularityRouter.sol#L134](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityRouter.sol#L134). Add this function to `SingularityRouter.sol` — @@ -1766,7 +1766,7 @@ Public state variable `tranche` has been assigned just once in the constructor o #### Proof of concept -[`tranche`](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityFactory.sol#L41) has been assigned just once in the constructor and it is defined as public state variable. +[`tranche`](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityFactory.sol#L41) has been assigned just once in the constructor and it is defined as public state variable. #### Impact @@ -1984,7 +1984,7 @@ Acknowledged ### 1. Informational - Incorrect balance accounting for fee-on-transfer and rebasing tokens (blockdev) -[SingularityPool.sol](https://github.com/Electisec-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol) does not support creating pools for ERC20 tokens which take fee on transfer. To transfer tokens, the pool uses `safeTransfer()` function which internally calls ERC20's `transfer()` function. If the token takes a fee on transfer, this call still succeeds but the pool might receive fewer tokens than intended. +[SingularityPool.sol](https://github.com/yAudit-block-2/singularity-v2/blob/a3cdbc5515374c9e1792b3cb94ff1b084a9a1361/contracts/SingularityPool.sol) does not support creating pools for ERC20 tokens which take fee on transfer. To transfer tokens, the pool uses `safeTransfer()` function which internally calls ERC20's `transfer()` function. If the token takes a fee on transfer, this call still succeeds but the pool might receive fewer tokens than intended. There is a safeguard since the protocol team decides which token will have a pool, but a fee can be turned on after a pool is created. This is also a risk with proxy and rebasing tokens. @@ -2136,6 +2136,6 @@ The oracles should also be rigorously tested. The "on-chain oracle" is not in a I really liked the design of the system, and the code was well written and easy to read. My main concerns are around the economics and system design. Singularity is designed around a very particular curve and the choices that led to this curve being used are not clear. The parameters seem to be changing from time to time and it is unclear if one set is superior to another. There has been care put into protecting LPs, with specific attention paid to the collateralization ratio. However, it is not obvious to me that optimizing purely on the cRatio is the best move. It seems like this can be done to users' detriment (incentivizes low liquidity, high cRatio pools). I would also encourage the authors to comment the code in depth, and keep the code and documentation in sync. -## About Electisec +## About yAudit -[Electisec](https://electisec.com/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. Electisec includes [a fellowship program](https://electisec.com/fellowship-program/), a residents program, and [a guest auditor program](https://electisec.com/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to Electisec for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. +[yAudit](https://yaudit.dev/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. yAudit includes [a fellowship program](https://yaudit.dev/fellowship-program/), a residents program, and [a guest auditor program](https://yaudit.dev/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to yAudit for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. diff --git a/content/2022-06-Superfluid.md b/content/2022-06-Superfluid.md index ccc93af..1c7050d 100644 --- a/content/2022-06-Superfluid.md +++ b/content/2022-06-Superfluid.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-06-Superfluid -description: Superfluid Electisec Report +description: Superfluid yAudit Report nav_order: 8 image: assets/images/logo.png --- -# Electisec Superfluid Review +# yAudit Superfluid Review **Review Resources:** @@ -44,7 +44,7 @@ Superfluid enables programmable cashflows that stream continuously. This is done ![Superfluid Host](https://3591469525-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2F-MKEcOOf_qoYMObicyRu%2Fuploads%2FfpT5qWsN1ki9HBO6RksU%2Fimage.png?alt=media&token=e7a56fbf-ce55-4dff-9fcb-37152c8ff4d2) -The main branch of the Superfluid [Repo](https://github.com/superfluid-finance/protocol-monorepo) was reviewed over 14 days. The code review was performed by 2 residents between June 27 and July 10, 2022. A number of Electisec Fellows also reviewed the contracts and contributed over 40 man hours. The repository was under active development during the review, but the review was limited to [one specific commit](https://github.com/superfluid-finance/protocol-monorepo/tree/8534dba06f6040bb31e2db69175ac3097430c528). +The main branch of the Superfluid [Repo](https://github.com/superfluid-finance/protocol-monorepo) was reviewed over 14 days. The code review was performed by 2 residents between June 27 and July 10, 2022. A number of yAudit Fellows also reviewed the contracts and contributed over 40 man hours. The repository was under active development during the review, but the review was limited to [one specific commit](https://github.com/superfluid-finance/protocol-monorepo/tree/8534dba06f6040bb31e2db69175ac3097430c528). ## Scope @@ -60,7 +60,7 @@ The Superfluid.sol contract in the scope of this review did not store any value The review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the fellows make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the fellows do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Superfluid and users of the contracts agree to use the code at their own risk. +yAudit and the fellows make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the fellows do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Superfluid and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -387,7 +387,7 @@ If an argument is only read in a function, it's cheaper to read it from `calldat #### Proof of concept -These are the functions using `memory` arguments: [`batchCall()`](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L813), [`forwardBatchCall()`](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L821), [`_batchCall()`](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L764), [`decodeCtx()`](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L744), [`_decodeCtx()`](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L888), +These are the functions using `memory` arguments: [`batchCall()`](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L813), [`forwardBatchCall()`](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L821), [`_batchCall()`](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L764), [`decodeCtx()`](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L744), [`_decodeCtx()`](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L888), #### Impact @@ -403,7 +403,7 @@ If a variable is used in a certain branch, it saves gas to compute that variable #### Proof of concept -In function [`registerAppWithKey()`](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L313), `configKey` is computed each time, but is used only when `APP_WHITE_LISTING_ENABLED` is true. So the gas spent on computing `configKey` is wasted when `APP_WHITE_LISTING_ENABLED` is false. +In function [`registerAppWithKey()`](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L313), `configKey` is computed each time, but is used only when `APP_WHITE_LISTING_ENABLED` is true. So the gas spent on computing `configKey` is wasted when `APP_WHITE_LISTING_ENABLED` is false. #### Impact @@ -446,7 +446,7 @@ Utilize custom errors instead of `require()` with revert strings. ### 5. Gas - Using >0 for unsigned integers (SaharAP) -`!= 0` is a cheaper operation compared to `>0`, when dealing with uint. `>0` can be replaced with `!= 0` for gas optimization. The `>0` has been used in many places in Superfluid contract such as [here](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L344) and [here](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L373). +`!= 0` is a cheaper operation compared to `>0`, when dealing with uint. `>0` can be replaced with `!= 0` for gas optimization. The `>0` has been used in many places in Superfluid contract such as [here](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L344) and [here](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L373). #### Impact @@ -460,7 +460,7 @@ Replace `>0` with `!=0` when comparing unsigned integer variables to save gas. I have seen other Solidity coders using unchecked increment in for loop to save gas, in case the upper limit has already been checked. -An example would be in [SlotsBitmapLibrary.sol](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/libs/SlotsBitmapLibrary.sol#L36), +An example would be in [SlotsBitmapLibrary.sol](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/libs/SlotsBitmapLibrary.sol#L36), since `slotId < _MAX_NUM_SLOTS`, we could use unchecked to wrap `++slotId`. The same could be applied to a couple of other places. #### Impact @@ -886,9 +886,9 @@ An address configured by governance can register multiple SuperApps. #### Proof of concept -Governance's owner can call [`setConfig()`](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/gov/SuperfluidGovernanceBase.sol#L109) to allow an address `a` (hashed into `key`) to register a SuperApp with Superfluid.sol (host). The `value` parameter is the timestamp until which the address can register the app. +Governance's owner can call [`setConfig()`](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/gov/SuperfluidGovernanceBase.sol#L109) to allow an address `a` (hashed into `key`) to register a SuperApp with Superfluid.sol (host). The `value` parameter is the timestamp until which the address can register the app. -`a` can initiate a transaction to register multiple apps through [`registerAppWithKey()`](https://github.com/Electisec-block-2/protocol-monorepo/blob/dev/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L310) as long as `block.timestamp` <= `value`. +`a` can initiate a transaction to register multiple apps through [`registerAppWithKey()`](https://github.com/yAudit-block-2/protocol-monorepo/blob/dev/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L310) as long as `block.timestamp` <= `value`. #### Impact @@ -903,15 +903,15 @@ Instead of delegating the responsibility of registering SuperApps to an address, ### 3. Informational - Valid context is not checked before modifying it (blockdev) -Each function which modifies `_ctxStamp` in Superfluid.sol forces on it an initial state. [`appCallbackPop()`](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L531) is the only function which lets an agreement to modify it without verifying the initial state. +Each function which modifies `_ctxStamp` in Superfluid.sol forces on it an initial state. [`appCallbackPop()`](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L531) is the only function which lets an agreement to modify it without verifying the initial state. #### Proof of concept -For reference, [`appCallbackPush()`](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L513) has asserts a valid context through `assertValidCtx(ctx)`. There is no such verification for `appCallbackPop()`. +For reference, [`appCallbackPush()`](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L513) has asserts a valid context through `assertValidCtx(ctx)`. There is no such verification for `appCallbackPop()`. #### Impact -Informational. This issue is known to the team as all the calls to `appCallbackPop()` ([AgreementLibrary.sol#L104](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/agreements/AgreementLibrary.sol#L104) and [AgreementLibrary.sol#L149](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/agreements/AgreementLibrary.sol#L149)) come with the following comment — +Informational. This issue is known to the team as all the calls to `appCallbackPop()` ([AgreementLibrary.sol#L104](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/agreements/AgreementLibrary.sol#L104) and [AgreementLibrary.sol#L149](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/agreements/AgreementLibrary.sol#L149)) come with the following comment — ``` // [SECURITY] NOTE: ctx should be const, do not modify it ever to ensure callback stack correctness @@ -927,7 +927,7 @@ There are typos in require strings. #### Proof of concept -`agreeement` ([Superfluid.sol#L1053](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L1053) and [Superfluid.sol#L1063](https://github.com/Electisec-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L1063)) might be better spelled as `agreement`. +`agreeement` ([Superfluid.sol#L1053](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L1053) and [Superfluid.sol#L1063](https://github.com/yAudit-block-2/protocol-monorepo/blob/8534dba06f6040bb31e2db69175ac3097430c528/packages/ethereum-contracts/contracts/superfluid/Superfluid.sol#L1063)) might be better spelled as `agreement`. #### Impact @@ -1102,6 +1102,6 @@ contract ContractTest is DSTest { ``` -## About Electisec +## About yAudit -[Electisec](https://electisec.com/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. Electisec includes [a fellowship program](https://electisec.com/fellowship-program/), a residents program, and [a guest auditor program](https://electisec.com/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to Electisec for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. +[yAudit](https://yaudit.dev/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. yAudit includes [a fellowship program](https://yaudit.dev/fellowship-program/), a residents program, and [a guest auditor program](https://yaudit.dev/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to yAudit for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. diff --git a/content/2022-06-Yearn-BalancerLPFactory.md b/content/2022-06-Yearn-BalancerLPFactory.md index 832acbd..52453e3 100644 --- a/content/2022-06-Yearn-BalancerLPFactory.md +++ b/content/2022-06-Yearn-BalancerLPFactory.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-06-Yearn-BalancerLPFactory -description: Yearn BalancerLPFactory Strategy Electisec Report +description: Yearn BalancerLPFactory Strategy yAudit Report nav_order: 9 image: assets/images/logo.png --- -# Electisec Yearn BalancerLpFactory Review +# yAudit Yearn BalancerLpFactory Review **Review Resources:** @@ -42,7 +42,7 @@ After the findings were presented to the Yearn dev, fixes were made and included The review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third party users that the code has been audited nor that the code is free from defects. By deploying or using the code, yearn and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third party users that the code has been audited nor that the code is free from defects. By deploying or using the code, yearn and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -742,6 +742,6 @@ Now these functions consume same amount of gas irrespective of the array length. A well written contract with little critical issues. Good news being, some of the more concerning parts of code stability actually happens to be with regards to governance params on CRV / CVX, which is fine. On review, I'm happy that wavey (contract dev) was able to patch many things mentioned in the report. No code review was done on the patches, however. -## About Electisec +## About yAudit -[Electisec](https://electisec.com/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. Electisec includes [a fellowship program](https://electisec.com/fellowship-program/), a residents program, and [a guest auditor program](https://electisec.com/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to Electisec for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. +[yAudit](https://yaudit.dev/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. yAudit includes [a fellowship program](https://yaudit.dev/fellowship-program/), a residents program, and [a guest auditor program](https://yaudit.dev/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to yAudit for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. diff --git a/content/2022-08-Bunni.md b/content/2022-08-Bunni.md index 68e9851..e3e514c 100644 --- a/content/2022-08-Bunni.md +++ b/content/2022-08-Bunni.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-08-Bunni -description: Bunni Electisec Report +description: Bunni yAudit Report nav_order: 9 image: assets/images/logo.png --- -# Electisec Bunni Review +# yAudit Bunni Review **Review Resources:** @@ -41,7 +41,7 @@ The commit reviewed was fc3535c35ca182dee5684e0a9dd9c152cc33047e. The review cov This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. Bunni and third parties should use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. Bunni and third parties should use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2022-08-Timeless-Yield-Daddy.md b/content/2022-08-Timeless-Yield-Daddy.md index 1ca806e..b0b2aa1 100644 --- a/content/2022-08-Timeless-Yield-Daddy.md +++ b/content/2022-08-Timeless-Yield-Daddy.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-08-Timeless-Yield-Daddy -description: Timeless Yield Daddy Electisec Report +description: Timeless Yield Daddy yAudit Report nav_order: 10 image: assets/images/logo.png --- -# Electisec Timeless Yield Daddy Review +# yAudit Timeless Yield Daddy Review **Review Resources:** None beyond the code repositories @@ -54,7 +54,7 @@ No other protocol ERC4626 wrappers are to be reviewed in Yield Daddy, such as th This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Yield Daddy and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Yield Daddy and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2022-09-yFu-NFT.md b/content/2022-09-yFu-NFT.md index 0ba18ce..8831ceb 100644 --- a/content/2022-09-yFu-NFT.md +++ b/content/2022-09-yFu-NFT.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-09-yFu-NFT -description: yFu NFT Electisec Report +description: yFu NFT yAudit Report nav_order: 10 image: assets/images/logo.png --- -# Electisec yFu NFT Review +# yAudit yFu NFT Review **Review Resources:** None beyond the code repositories @@ -40,7 +40,7 @@ After the findings were presented to the yFu team, fixes were made and included The review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third party users that the code has been audited nor that the code is free from defects. By deploying or using the code, yFu and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third party users that the code has been audited nor that the code is free from defects. By deploying or using the code, yFu and users of the contracts agree to use the code at their own risk. ## Findings Explanation diff --git a/content/2022-10-NounsDAO-Token-Buyer.md b/content/2022-10-NounsDAO-Token-Buyer.md index 0e55ba8..1e99985 100644 --- a/content/2022-10-NounsDAO-Token-Buyer.md +++ b/content/2022-10-NounsDAO-Token-Buyer.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-10-NounsDAO-Token-Buyer -description: NounsDAO Token Buyer Electisec Report +description: NounsDAO Token Buyer yAudit Report nav_order: 10 image: assets/images/logo.png --- -# Electisec NounsDAO Token Buyer Review +# yAudit NounsDAO Token Buyer Review **Review Resources:** @@ -43,7 +43,7 @@ After the findings were presented to the NounsDAO team, fixes were made and incl This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, NounsDAO and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, NounsDAO and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2022-11-Yearn-Stargate-Strategy.md b/content/2022-11-Yearn-Stargate-Strategy.md index 3c808d1..33cbaf9 100644 --- a/content/2022-11-Yearn-Stargate-Strategy.md +++ b/content/2022-11-Yearn-Stargate-Strategy.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-11-Yearn-Stargate-Strategy -description: Yearn Stargate Strategy Electisec Report +description: Yearn Stargate Strategy yAudit Report nav_order: 11 image: assets/images/logo.png --- -# Electisec Yearn Stargate Strategy Review +# yAudit Yearn Stargate Strategy Review **Review Resources:** @@ -36,7 +36,7 @@ image: assets/images/logo.png The Yearn Finance Stargate Strategy generates yield from the Stargate protocol. The strategy is currently designed for USDC and USDT on Ethereum Mainnet but the strategy may be deployed to other chains, such as Optimism or Arbitrum, in the future. The yield is generated in two ways: from STG staking rewards (using a modified MasterChef contract) and from a portion of the 0.06% bridge fee collected by Stargate that is redistributed back to the liquidity pools. -The contracts of the Yearn Finance Stargate Strategy [Repo](https://github.com/newmickymousse/yearn-stargate) were reviewed over 14 days. The code review was performed between November 20 and December 4, 2022. A number of Electisec Fellows from Fellowship block 4 also reviewed the contracts and contributed over 40 man hours. The repository was under active development during the review, but the review was limited to the latest commit at the start of the review. This was [commit bcbc1ddbe8973b55a6178f5e07177332938f0cd2](https://github.com/newmickymousse/yearn-stargate/commit/bcbc1ddbe8973b55a6178f5e07177332938f0cd2) for the Yearn Finance Stargate Strategy repo. +The contracts of the Yearn Finance Stargate Strategy [Repo](https://github.com/newmickymousse/yearn-stargate) were reviewed over 14 days. The code review was performed between November 20 and December 4, 2022. A number of yAudit Fellows from Fellowship block 4 also reviewed the contracts and contributed over 40 man hours. The repository was under active development during the review, but the review was limited to the latest commit at the start of the review. This was [commit bcbc1ddbe8973b55a6178f5e07177332938f0cd2](https://github.com/newmickymousse/yearn-stargate/commit/bcbc1ddbe8973b55a6178f5e07177332938f0cd2) for the Yearn Finance Stargate Strategy repo. ## Scope @@ -52,7 +52,7 @@ The Yearn Stargate strategy is only deployed on Ethereum mainnet for USDC and US This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, the Yearn Stargate Strategy and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, the Yearn Stargate Strategy and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -168,8 +168,8 @@ Acknowledged. The two (2) edge cases highlighted are valid. However, to our know ### 4. Low - Variables set to Ethereum addresses (spalen) -At [L99 `healthCheck`](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L99) -and [L100 `baseFeeOracle`](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L100) +At [L99 `healthCheck`](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L99) +and [L100 `baseFeeOracle`](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L100) variable are set to specific addresses that existing on Ethereum. #### Technical Details @@ -191,11 +191,11 @@ Acknowledged. This is a good point and these addresses will be removed in effort ### 5. Low - Emergency unstake forgoes extra rewards even when they can be claimed (shung) -[`_emergencyUnstakeLP`](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L468) function forgoes pending rewards even if the rewards can be harvested safely. This will result in migration to always lose pending rewards. +[`_emergencyUnstakeLP`](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L468) function forgoes pending rewards even if the rewards can be harvested safely. This will result in migration to always lose pending rewards. #### Technical Details -`_emergencyUnstakeLP` is an internal function executed during [migration](https://github.com/yearn/yearn-vaults/blob/74364b2c33bd0ee009ece975c157f065b592eeaf/contracts/BaseStrategy.sol#L879), or during [admin-initiated emergency exits](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L306). In the former case, migration can be required even if the staker contract is still functional and is receiving rewards. In the latter case, admin can call emergency unstake by mistake when the rewards are still claimable. In both cases, pending rewards will be discarded and irrecoverably stuck in the Stargate LP staker contract. +`_emergencyUnstakeLP` is an internal function executed during [migration](https://github.com/yearn/yearn-vaults/blob/74364b2c33bd0ee009ece975c157f065b592eeaf/contracts/BaseStrategy.sol#L879), or during [admin-initiated emergency exits](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L306). In the former case, migration can be required even if the staker contract is still functional and is receiving rewards. In the latter case, admin can call emergency unstake by mistake when the rewards are still claimable. In both cases, pending rewards will be discarded and irrecoverably stuck in the Stargate LP staker contract. #### Impact @@ -366,7 +366,7 @@ Use [unchecked block](https://docs.soliditylang.org/en/latest/control-structures 1. [\_amountFreed is set in `prepareReturn()`](https://github.com/newmickymousse/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L210-L215) but is never used after that point. The variable and the lines setting it can be deleted to save gas. -2. [In `withdrawSome()`](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L279-L287), `_liquidatedAmount` is used only to return the proper value, and in on branch of the if statement `_liquidatedAmount` is set to `_liquidAssets`. Instead of creating a new temporary variable `_liquidAssets`, use `_liquidatedAmount` instead and change the if statement logic to +2. [In `withdrawSome()`](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L279-L287), `_liquidatedAmount` is used only to return the proper value, and in on branch of the if statement `_liquidatedAmount` is set to `_liquidAssets`. Instead of creating a new temporary variable `_liquidAssets`, use `_liquidatedAmount` instead and change the if statement logic to ```diff - uint256 _liquidAssets = balanceOfWant() - _preWithdrawWant; @@ -383,7 +383,7 @@ Use [unchecked block](https://docs.soliditylang.org/en/latest/control-structures } ``` -3. At [L218](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L218) +3. At [L218](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L218) there is no need define `_liquidWant` and call `balanceOfWant()`. Recalculate `_ wantBalance` after L213. Remove variable `_liquidWant` and use `_wantBalance` instead. @@ -459,7 +459,7 @@ Gas savings. #### Recommendation -Before [L265](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L265) +Before [L265](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L265) exit for 0 input value. After this check, if statement at L266 can be removed. ```solidity @@ -667,7 +667,7 @@ Consider the differences between tokens and chains when deploying this strategy ### 10. Informational - Rename variable (spalen) -Rename variable `_liquidAssets` at [L279](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L279). +Rename variable `_liquidAssets` at [L279](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L279). #### Technical Details @@ -683,7 +683,7 @@ Rename to `_liquidatedAssets`. ### 11. Informational - Use vault decimals (spalen) -At [L98](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L98) +At [L98](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L98) `want` decimals is fetched by importing `IERC20Metadata` but this data is already stored in vault. #### Technical Details @@ -696,7 +696,7 @@ Simpler code with less imports. #### Recommendation -Replace [L98](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L98) +Replace [L98](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L98) and remove interface IERC20Metadata import as well as file. ```solidity @@ -705,8 +705,8 @@ and remove interface IERC20Metadata import as well as file. ### 12. Informational - Use explicit uint type (spalen) -At [L383](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L383) -and [L387](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L387) +At [L383](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L383) +and [L387](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L387) uint alias is used for uint256. The rest of the contract uses explicit uint256. #### Technical Details @@ -827,7 +827,7 @@ Governance could take the reward tokens earned by the strategy. #### Technical Details `BaseStrategy` contract [has a virtual function](https://github.com/yearn/yearn-vaults/blob/74364b2c33bd0ee009ece975c157f065b592eeaf/contracts/BaseStrategy.sol#L923) to define which tokens cannot be swept by the governance. -The `Strategy` contract [does not honor this](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L372) by not setting the reward token as protected. +The `Strategy` contract [does not honor this](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L372) by not setting the reward token as protected. #### Impact @@ -835,7 +835,7 @@ Informational. #### Recommendation -Return the `reward` token address [in `protectedTokens` function](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L372). +Return the `reward` token address [in `protectedTokens` function](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L372). ### 17. Informational - Reverts are missing reason string (shung) @@ -843,7 +843,7 @@ Most of the `require` statements in the contract are missing a reason string. La #### Technical Details -There are five instances of this issue ([1](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L74), [2](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L119), [3](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L137), [4](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L388), [5](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L407)). +There are five instances of this issue ([1](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L74), [2](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L119), [3](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L137), [4](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L388), [5](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L407)). #### Impact @@ -859,7 +859,7 @@ Add a second argument in `require` statements to return a reason string. Alterna #### Technical Details -In assembly, `create` does not revert when a deployment fails. It instead [returns zero address](https://docs.soliditylang.org/en/latest/yul.html#evm-dialect). This is currently not an issue because there is an implicit check due to [the call made to the `newStrategy`](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L156). However, not having an explicit check might cause this to be overlooked in future refactorings of the code. +In assembly, `create` does not revert when a deployment fails. It instead [returns zero address](https://docs.soliditylang.org/en/latest/yul.html#evm-dialect). This is currently not an issue because there is an implicit check due to [the call made to the `newStrategy`](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L156). However, not having an explicit check might cause this to be overlooked in future refactorings of the code. #### Impact @@ -867,7 +867,7 @@ Informational. #### Recommendation -Add an explicit check [to ensure `newStrategy` address is non-zero](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L153). Alternatively, clarify with a comment that the external call to the `newStrategy` also acts a check for ensuring `create` did not fail. +Add an explicit check [to ensure `newStrategy` address is non-zero](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L153). Alternatively, clarify with a comment that the external call to the `newStrategy` also acts a check for ensuring `create` did not fail. ### 19. Informational - Missing Zero-Address Check (hasanza) @@ -966,13 +966,13 @@ Informational. #### Recommendation -Remove [the line with encoder pragma](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L4). +Remove [the line with encoder pragma](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L4). ### 24. Informational - Constant is not named in capital letters (shung) #### Technical Details -The official Solidity style guide [recommends using all capital letters for contants](https://docs.soliditylang.org/en/v0.8.17/style-guide.html#constants). However, the constant [`max`](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L24) does not adhere to this guideline. +The official Solidity style guide [recommends using all capital letters for contants](https://docs.soliditylang.org/en/v0.8.17/style-guide.html#constants). However, the constant [`max`](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L24) does not adhere to this guideline. #### Impact @@ -986,7 +986,7 @@ Rename the variable accordingly. #### Technical Details -The [`receive()`](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L406) function allows the Strategy contract to receive ETH from the WETH contract when the want token is WETH. However, anyone can send ETH to the contract via the `receive()` function as the address that sends the ETH isn't checked. +The [`receive()`](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L406) function allows the Strategy contract to receive ETH from the WETH contract when the want token is WETH. However, anyone can send ETH to the contract via the `receive()` function as the address that sends the ETH isn't checked. #### Impact @@ -1008,7 +1008,7 @@ receive() external payable { #### Technical Details -In the [`_ldToLp`](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L387-L391) function the value returned is calculated by first dividing and then multiplying. This could lead to precision loss when `liquidityPool.convertRate() != 1`. If the `convertRate()` changes, the [`_ldToLp`](https://github.com/Electisec-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L387-L391) function will return lower value than expected. +In the [`_ldToLp`](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L387-L391) function the value returned is calculated by first dividing and then multiplying. This could lead to precision loss when `liquidityPool.convertRate() != 1`. If the `convertRate()` changes, the [`_ldToLp`](https://github.com/yAudit-block-4/yearn-stargate/blob/bcbc1ddbe8973b55a6178f5e07177332938f0cd2/contracts/Strategy.sol#L387-L391) function will return lower value than expected. #### Impact @@ -1043,6 +1043,6 @@ The meaning of Delta credit in Stargate is not clear and should be better explai Overall, the code is clean but there is room for multiple small gas optimizations and cleaning up unused stuff. Tests are well-written and cover all main cases. -## About Electisec +## About yAudit -[Electisec](https://electisec.com/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. Electisec includes [a fellowship program](https://electisec.com/fellowship-program/), a residents program, and [a guest auditor program](https://electisec.com/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to Electisec for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. +[yAudit](https://yaudit.dev/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. yAudit includes [a fellowship program](https://yaudit.dev/fellowship-program/), a residents program, and [a guest auditor program](https://yaudit.dev/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to yAudit for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. diff --git a/content/2022-12-GET-Protocol-Staking.md b/content/2022-12-GET-Protocol-Staking.md index 6edd5fe..c9c501f 100644 --- a/content/2022-12-GET-Protocol-Staking.md +++ b/content/2022-12-GET-Protocol-Staking.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-12-GET-Protocol-Staking -description: GET Protocol Electisec Report +description: GET Protocol yAudit Report nav_order: 12 image: assets/images/logo.png --- -# Electisec GET Protocol Staking Review +# yAudit GET Protocol Staking Review **Review Resources:** @@ -39,7 +39,7 @@ image: assets/images/logo.png GET Protocol provides a ticketing service that uses ERC721 tokens. This review focused on the GET Locked Revenue Distribution token, which will enable staking of the existing GET token to align incentives of GET token holders with GET's objectives and future trajectory. -The contracts of the [GET Protocol Locked Revenue Distribution token](https://github.com/GETProtocolDAO/locked-revenue-distribution-token) were reviewed over 8 days. The code review was performed by 1 auditor and several Fellows between December 5 and December 12, 2022. In addition, one guest auditor and a number of Electisec Fellows from Fellowship block 4 also reviewed the contracts and contributed over 60 man hours. The repository was under active development during the review, but the review was limited to the latest commit at the start of the review. This was commit ab272ced94d6bc8cc1ded2664408a3fa7ce67128 for the [Locked Revenue Distribution Token repository](https://github.com/GETProtocolDAO/locked-revenue-distribution-token). +The contracts of the [GET Protocol Locked Revenue Distribution token](https://github.com/GETProtocolDAO/locked-revenue-distribution-token) were reviewed over 8 days. The code review was performed by 1 auditor and several Fellows between December 5 and December 12, 2022. In addition, one guest auditor and a number of yAudit Fellows from Fellowship block 4 also reviewed the contracts and contributed over 60 man hours. The repository was under active development during the review, but the review was limited to the latest commit at the start of the review. This was commit ab272ced94d6bc8cc1ded2664408a3fa7ce67128 for the [Locked Revenue Distribution Token repository](https://github.com/GETProtocolDAO/locked-revenue-distribution-token). ## Scope @@ -59,7 +59,7 @@ Any code not included in these contracts, such as voting and proposal functions, This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, GET Protocol and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, GET Protocol and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -1269,6 +1269,6 @@ The GET Locked Revenue Distribution Token builds on strong foundations, using ex Overall, the code is well documented and makes good use of existing libraries and projects. I liked the use of RDT as I feel it helped protect against potential vault entry timing abuse issues, although I do have some trepidations about the complexities multi-chain voting may introduce. -## About Electisec +## About yAudit -[Electisec](https://electisec.com/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. Electisec includes [a fellowship program](https://electisec.com/fellowship-program/), a residents program, and [a guest auditor program](https://electisec.com/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to Electisec for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. +[yAudit](https://yaudit.dev/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. yAudit includes [a fellowship program](https://yaudit.dev/fellowship-program/), a residents program, and [a guest auditor program](https://yaudit.dev/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to yAudit for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. diff --git a/content/2022-12-Gro-Protocol.md b/content/2022-12-Gro-Protocol.md index 3425e4c..59ad4a0 100644 --- a/content/2022-12-Gro-Protocol.md +++ b/content/2022-12-Gro-Protocol.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-12-Gro-Protocol -description: Gro Protocol Electisec Report +description: Gro Protocol yAudit Report nav_order: 14 image: assets/images/logo.png --- -# Electisec Gro Protocol Review +# yAudit Gro Protocol Review **Review Resources:** @@ -46,7 +46,7 @@ After the findings were presented to the Gro Protocol team, fixes were made and This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Gro Protocol and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Gro Protocol and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2022-12-LlamaPayV2.md b/content/2022-12-LlamaPayV2.md index cbe9126..d7ca382 100644 --- a/content/2022-12-LlamaPayV2.md +++ b/content/2022-12-LlamaPayV2.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-12-LlamaPay-V2 -description: LlamaPay V2 Electisec Report +description: LlamaPay V2 yAudit Report nav_order: 13 image: assets/images/logo.png --- -# Electisec Llamapay V2 Review +# yAudit Llamapay V2 Review **Review Resources:** @@ -81,9 +81,9 @@ At a lower level, `_updateStream()` plays an important role in updating the stre After the findings were presented to the LlamaPay development team, fixes were made and included in several PRs. -This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. The review was a pro bono effort and is not guaranteed to follow the same process or to have been reviewed for the same amount of time as a typical Electisec audit. +This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. The review was a pro bono effort and is not guaranteed to follow the same process or to have been reviewed for the same amount of time as a typical yAudit audit. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, LlamaPay V2 and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, LlamaPay V2 and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -1418,6 +1418,6 @@ Overall, the code is easy to understand and well designed. Adding documentation LlamaPay V2 is building on the solid foundation of LlamaPay V1. Some of the design differences still have some rough edges to iron out, but the overall approach is reasonable. One of the difficult elements in this code is validating that the payment stream can only follow a specific call flow where unintended call flows should not be possible. This requires extensive testing for the many permutations and possible edge cases. Visualizing and documentating how the call flow should look could help create positive and negative tests to validate the code matches the intended flow. -## About Electisec +## About yAudit -[Electisec](https://electisec.com/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. Electisec includes [a fellowship program](https://electisec.com/fellowship-program/), a residents program, and [a guest auditor program](https://electisec.com/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to Electisec for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. +[yAudit](https://yaudit.dev/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. yAudit includes [a fellowship program](https://yaudit.dev/fellowship-program/), a residents program, and [a guest auditor program](https://yaudit.dev/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to yAudit for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. diff --git a/content/2022-12-RageTrade.md b/content/2022-12-RageTrade.md index 4268087..4f163fd 100644 --- a/content/2022-12-RageTrade.md +++ b/content/2022-12-RageTrade.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-12-RageTrade -description: Rage Trade Electisec Report +description: Rage Trade yAudit Report nav_order: 15 image: assets/images/logo.png --- -# Electisec Rage Trade Review +# yAudit Rage Trade Review **Review Resources:** @@ -37,7 +37,7 @@ The scope of the review consisted of all the contracts in the repo at the specif This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisecs and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Rage Trade and users of the contracts agree to use the code at their own risk. +yAudits and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Rage Trade and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2023-01-LlamaLendV2.md b/content/2023-01-LlamaLendV2.md index e71f70c..22c1c85 100644 --- a/content/2023-01-LlamaLendV2.md +++ b/content/2023-01-LlamaLendV2.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-01-LlamaLend-V2 -description: LlamaLend V2 Electisec Report +description: LlamaLend V2 yAudit Report nav_order: 16 image: assets/images/logo.png --- -# Electisec LlamaLend V2 Review +# yAudit LlamaLend V2 Review **Review Resources:** @@ -32,7 +32,7 @@ image: assets/images/logo.png LlamaLend is a protocol to borrow ETH against NFTs. Most of the NFT liquidity protocols don't support small collections and need oracle support. LlamaLend allows anyone to run their own oracle for any collection, so NFT projects can create pools to let their holders borrow ETH against the NFTs instead of selling. -The contracts of the LlamaLend [Repo](https://github.com/LlamaLend/contracts/tree/eb8034f88a410d0dd3d6bce4e442cc69e0e12ea3) were reviewed by 2 auditors and 1 Electisec Fellow between January 9, 2023 and January 20, 2023. The review was limited to the latest commit at the start of the review. This was [commit eb8034f88a410d0dd3d6bce4e442cc69e0e12ea3](https://github.com/LlamaLend/contracts/tree/eb8034f88a410d0dd3d6bce4e442cc69e0e12ea3) for the LlamaLend repo. +The contracts of the LlamaLend [Repo](https://github.com/LlamaLend/contracts/tree/eb8034f88a410d0dd3d6bce4e442cc69e0e12ea3) were reviewed by 2 auditors and 1 yAudit Fellow between January 9, 2023 and January 20, 2023. The review was limited to the latest commit at the start of the review. This was [commit eb8034f88a410d0dd3d6bce4e442cc69e0e12ea3](https://github.com/LlamaLend/contracts/tree/eb8034f88a410d0dd3d6bce4e442cc69e0e12ea3) for the LlamaLend repo. ## Scope @@ -54,9 +54,9 @@ One key variable in the LlamaLend design is the limitation on the amount that ca ![currentDailyBorrows mechanics visualization](../public/assets/llamalend/daily-borrowed.png) -This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. The review was a pro bono effort and is not guaranteed to follow the same process or to have been reviewed for the same amount of time as a typical Electisec audit. +This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. The review was a pro bono effort and is not guaranteed to follow the same process or to have been reviewed for the same amount of time as a typical yAudit audit. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Rage Trade and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Rage Trade and users of the contracts agree to use the code at their own risk. ## Findings Explanation @@ -586,6 +586,6 @@ The protocol's design is intelligent and puts well-reasoned trust on different a The LlamaLend protocol takes a very simplistic approach to a lending and borrowing protocol, removing substantial amounts of complexity that many other borrowing protocols implement. While this simplification does cut a couple of corners, the compromises seem reasonable given the scale and intended use cases of the protocol. -## About Electisec +## About yAudit -[Electisec](https://electisec.com/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. Electisec includes [a fellowship program](https://electisec.com/fellowship-program/), a residents program, and [a guest auditor program](https://electisec.com/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to Electisec for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. +[yAudit](https://yaudit.dev/) is an ecosystem initiative started by Yearn Finance and its ecosystem partners to bootstrap sustainable and collaborative blockchain security reviews and to nurture aspiring security talent. yAudit includes [a fellowship program](https://yaudit.dev/fellowship-program/), a residents program, and [a guest auditor program](https://yaudit.dev/guest-auditor-program/). In the fellowship program, fellows perform a series of periodic security reviews and presentations during the program. Residents are past fellows who continue to gain experience by performing security reviews of contracts submitted to yAudit for review (such as this contract). Guest auditors are experts with a track record in the security space who temporarily assist with the review efforts. diff --git a/content/2023-01-TempleDAO-Origami.md b/content/2023-01-TempleDAO-Origami.md index aea2d42..7774586 100644 --- a/content/2023-01-TempleDAO-Origami.md +++ b/content/2023-01-TempleDAO-Origami.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-01-TempleDao-Origami -description: Temple DAO Origami Electisec Report +description: Temple DAO Origami yAudit Report nav_order: 17 image: assets/images/logo.png --- -# Electisec Temple DAO Origami Review +# yAudit Temple DAO Origami Review **Review Resources:** @@ -42,7 +42,7 @@ After the findings were presented to the Temple DAO team, fixes were made and in This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Temple DAO and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Temple DAO and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2023-02-RageTrade-Upgrade.md b/content/2023-02-RageTrade-Upgrade.md index 7252384..c61bdb9 100644 --- a/content/2023-02-RageTrade-Upgrade.md +++ b/content/2023-02-RageTrade-Upgrade.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-02-RageTrade -description: Rage Trade Upgrade Electisec Report +description: Rage Trade Upgrade yAudit Report nav_order: 19 image: assets/images/logo.png --- -# Electisec Rage Trade Upgrade Review +# yAudit Rage Trade Upgrade Review **Review Resources:** @@ -32,11 +32,11 @@ The contracts of the Rage Trade [Repo](https://github.com/RageTrade/delta-neutra ## Scope -The scope of the review consisted of all the contracts in the repo at the specific commit. The goal was the review the changes made since the previous Electisec review. Most of the contract changes were made in [PR #71](https://github.com/RageTrade/delta-neutral-gmx-vaults/pull/71) and [PR #84](https://github.com/RageTrade/delta-neutral-gmx-vaults/pull/84). After the findings were presented to the Rage Trade team, fixes were made and included in several PRs. +The scope of the review consisted of all the contracts in the repo at the specific commit. The goal was the review the changes made since the previous yAudit review. Most of the contract changes were made in [PR #71](https://github.com/RageTrade/delta-neutral-gmx-vaults/pull/71) and [PR #84](https://github.com/RageTrade/delta-neutral-gmx-vaults/pull/84). After the findings were presented to the Rage Trade team, fixes were made and included in several PRs. This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Rage Trade and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Rage Trade and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2023-02-TempleDAO-Origami-Recheck.md b/content/2023-02-TempleDAO-Origami-Recheck.md index 4836350..cb55de1 100644 --- a/content/2023-02-TempleDAO-Origami-Recheck.md +++ b/content/2023-02-TempleDAO-Origami-Recheck.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-02-TempleDao-Origami-Recheck -description: Temple DAO Origami Recheck Electisec Report +description: Temple DAO Origami Recheck yAudit Report nav_order: 18 image: assets/images/logo.png --- -# Electisec Temple DAO Origami Recheck Review +# yAudit Temple DAO Origami Recheck Review **Review Resources:** @@ -32,7 +32,7 @@ The contracts of the Temple DAO Origami [Repo](https://github.com/TempleDAO/orig This was the second review of the Temple DAO Origami [Repo](https://github.com/TempleDAO/origami). -Temple DAO fixed the issues from the first report so Electisec did a review of these mitigations by comparing changes made from commit [a31d192ab54ca7d21f2dee30c630a6ec1843b646](https://github.com/TempleDAO/origami/tree/a31d192ab54ca7d21f2dee30c630a6ec1843b646/apps/protocol), which was the commit of the first review, to commit [5ddb424ca1cba8698a51fc21510c1891598a7f09](https://github.com/TempleDAO/origami/tree/5ddb424ca1cba8698a51fc21510c1891598a7f09/apps/protocol), which was the commit that included the mitigations. +Temple DAO fixed the issues from the first report so yAudit did a review of these mitigations by comparing changes made from commit [a31d192ab54ca7d21f2dee30c630a6ec1843b646](https://github.com/TempleDAO/origami/tree/a31d192ab54ca7d21f2dee30c630a6ec1843b646/apps/protocol), which was the commit of the first review, to commit [5ddb424ca1cba8698a51fc21510c1891598a7f09](https://github.com/TempleDAO/origami/tree/5ddb424ca1cba8698a51fc21510c1891598a7f09/apps/protocol), which was the commit that included the mitigations. ## Scope @@ -45,7 +45,7 @@ After the findings were presented to the Temple DAO team, fixes were made and in This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Temple DAO and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Temple DAO and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2023-04-Exit10.md b/content/2023-04-Exit10.md index cad79dc..48fc19a 100644 --- a/content/2023-04-Exit10.md +++ b/content/2023-04-Exit10.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-04-Exit10 -description: Exit10 Electisec Report +description: Exit10 yAudit Report nav_order: 22 image: assets/images/logo.png --- -# Electisec Exit10 Review +# yAudit Exit10 Review **Review Resources:** @@ -34,7 +34,7 @@ Exit10 provides a novel and gamified approach for users to gain exposure to and ![Exit10 Overview](../public/assets/exit10/diagram1.png) -The contracts of the Exit10 [Repo](https://github.com/open-bakery/exit10-protocol) were reviewed over 14 days. The code review was performed by 2 auditors between April 17 and April 30, 2023. Fellows from Electisec Block 5 additionally joined the review. The repository was under active development during the review, but the review was limited to the latest commit at the start of the review. This was commit [0b3c2782c5a93d2218234bc70fee31ec32f9e337](https://github.com/open-bakery/exit10-protocol/tree/0b3c2782c5a93d2218234bc70fee31ec32f9e337) for the Exit10 repo. One file from the uniswap-v3-swapper repository at commit [4a3d2c9af49285b0e5cbdbe819f264c13241d017](https://github.com/open-bakery/uniswap-v3-swapper/tree/4a3d2c9af49285b0e5cbdbe819f264c13241d017) was also in scope. +The contracts of the Exit10 [Repo](https://github.com/open-bakery/exit10-protocol) were reviewed over 14 days. The code review was performed by 2 auditors between April 17 and April 30, 2023. Fellows from yAudit Block 5 additionally joined the review. The repository was under active development during the review, but the review was limited to the latest commit at the start of the review. This was commit [0b3c2782c5a93d2218234bc70fee31ec32f9e337](https://github.com/open-bakery/exit10-protocol/tree/0b3c2782c5a93d2218234bc70fee31ec32f9e337) for the Exit10 repo. One file from the uniswap-v3-swapper repository at commit [4a3d2c9af49285b0e5cbdbe819f264c13241d017](https://github.com/open-bakery/uniswap-v3-swapper/tree/4a3d2c9af49285b0e5cbdbe819f264c13241d017) was also in scope. ## Scope @@ -49,7 +49,7 @@ After the findings were presented to the Exit10 team, fixes were made and includ This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Exit10 and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Exit10 and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -276,7 +276,7 @@ However, [`claimAndDistributeFees()`](https://github.com/open-bakery/exit10-prot This will work on Ethereum mainnet as the address of [USDC](https://etherscan.io/address/0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48) is lower than the address of [WETH](https://etherscan.io/address/0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2), meaning `token0` is "token out", but will fail on Optimism where the address of [USDC](https://optimistic.etherscan.io/address/0x7f5c764cbc14f9669b88837ca1490cca17c31607) is greater than the address of [WETH](https://optimistic.etherscan.io/address/0x4200000000000000000000000000000000000006). -The following test simulates an scenario where `token0` is WETH and `token1` is USDC by forking Optimism. The call to `claimAndDistributeFees()` will revert as FeeSplitter.sol will try to pull more funds than available from the Exit10.sol contract. Full test suite is available [here](https://github.com/Electisec-block-5/Exit10-code/blob/audit/adriro/exit10-protocol/test/AuditFork.t.sol). +The following test simulates an scenario where `token0` is WETH and `token1` is USDC by forking Optimism. The call to `claimAndDistributeFees()` will revert as FeeSplitter.sol will try to pull more funds than available from the Exit10.sol contract. Full test suite is available [here](https://github.com/yAudit-block-5/Exit10-code/blob/audit/adriro/exit10-protocol/test/AuditFork.t.sol). ```solidity function test_Exit10_claimAndDistributeFees_IncorrectTokenOrder() public { @@ -585,7 +585,7 @@ The `updateFees()` function present in FeeSplitter.sol is used to swap fees to E This function can be abused by a malicious actor to dilute the reward process by calling it with a zero amount. This action won't increase the amount of rewards, but will extend the reward period, effectively lowering the reward rate. Current stakers will need to wait an additional period to claim their rewards. -In [this test](https://github.com/Electisec-block-5/Exit10-code/blob/audit/adriro/exit10-protocol/test/Audit.t.sol#L59), the issue is triggered each day using a reward duration of 10 days, and produces the following log: +In [this test](https://github.com/yAudit-block-5/Exit10-code/blob/audit/adriro/exit10-protocol/test/Audit.t.sol#L59), the issue is triggered each day using a reward duration of 10 days, and produces the following log:
Logs: @@ -1834,7 +1834,7 @@ Using the [withdraw()](https://github.com/open-bakery/exit10-protocol/blob/0b3c2 If the caller receives control during the call to `_safeClaimRewards()` (which transfers the reward token), an attacker can reenter the function and execute the claim again, since the state hasn't been updated yet, in particular line 104 which tracks how many rewards have been already sent to the user. -A test with a proof of concept for this issue is available [here](https://github.com/Electisec-block-5/Exit10-code/blob/audit/adriro/exit10-protocol/test/AuditMasterchef.t.sol#L101). +A test with a proof of concept for this issue is available [here](https://github.com/yAudit-block-5/Exit10-code/blob/audit/adriro/exit10-protocol/test/AuditMasterchef.t.sol#L101). #### Impact diff --git a/content/2023-04-Incubator-DAO.md b/content/2023-04-Incubator-DAO.md index 7cb12dc..c5c1087 100644 --- a/content/2023-04-Incubator-DAO.md +++ b/content/2023-04-Incubator-DAO.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-04-Incubator-DAO -description: Incubator DAO Electisec Report +description: Incubator DAO yAudit Report nav_order: 21 image: assets/images/logo.png --- -# Electisec Incubator DAO Review +# yAudit Incubator DAO Review **Review Resources:** @@ -43,7 +43,7 @@ There were no tests provided with the repository, but the auditors wrote tests t This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Incubator DAO and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Incubator DAO and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2023-05-Sonne.md b/content/2023-05-Sonne.md index cf0b3e6..e6ddd6d 100644 --- a/content/2023-05-Sonne.md +++ b/content/2023-05-Sonne.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-05-Sonne -description: Sonne Electisec Report +description: Sonne yAudit Report nav_order: 23 image: assets/images/logo.png --- -# Electisec Sonne Finance Review +# yAudit Sonne Finance Review **Review Resources:** @@ -42,7 +42,7 @@ The liquidity generation event and other contracts in the sonne-token github rep This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Sonne Finance and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Sonne Finance and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -594,7 +594,7 @@ The SUSD and LUSD Chainlink data feeds are monitored feeds, not a verified feeds #### Technical Details -The lowest risk and highest quality tier for Chainlink oracles are verified feeds. Monitored Chainlink feeds are the second highest quality tier of oracles, but they carry additional risk and are still under review. Because a [common weakness for Compound forks](https://github.com/Electisec-Residents/defi-fork-bugs#compound) is oracle manipulation leading to the draining of many markets, the Sonne protocol is only as robust as its weakest oracle. Using Chainlink oracles that introduce extra risk is problematic. Screenshots of the Chainlink documentation at the time of the review is below. +The lowest risk and highest quality tier for Chainlink oracles are verified feeds. Monitored Chainlink feeds are the second highest quality tier of oracles, but they carry additional risk and are still under review. Because a [common weakness for Compound forks](https://github.com/yAudit-Residents/defi-fork-bugs#compound) is oracle manipulation leading to the draining of many markets, the Sonne protocol is only as robust as its weakest oracle. Using Chainlink oracles that introduce extra risk is problematic. Screenshots of the Chainlink documentation at the time of the review is below. Chainlink documentation about data feed quality @@ -841,7 +841,7 @@ There is no clear public documentation describing how new markets are added to S #### Technical Details -One of the [top causes of Compound fork hacks](https://github.com/Electisec-Residents/defi-fork-bugs) is reentrancy bugs, because Compound does not follow the checks-effects-interaction pattern. This means that if a Sonne market is created with a token that allows reentrancy, such as an ERC777 token, this can put the protocol funds at risk. Compound has a clear process for adding new markets that includes creating [a public governance proposal](https://compound.finance/governance/proposals/83). [Compound is aware of this risk](https://www.comp.xyz/t/reentrancy-protection-currently-broken/2573) but has chosen not to fix it in their code. +One of the [top causes of Compound fork hacks](https://github.com/yAudit-Residents/defi-fork-bugs) is reentrancy bugs, because Compound does not follow the checks-effects-interaction pattern. This means that if a Sonne market is created with a token that allows reentrancy, such as an ERC777 token, this can put the protocol funds at risk. Compound has a clear process for adding new markets that includes creating [a public governance proposal](https://compound.finance/governance/proposals/83). [Compound is aware of this risk](https://www.comp.xyz/t/reentrancy-protection-currently-broken/2573) but has chosen not to fix it in their code. #### Impact diff --git a/content/2023-05-timeless-gauges.md b/content/2023-05-timeless-gauges.md index a15efbd..2662411 100644 --- a/content/2023-05-timeless-gauges.md +++ b/content/2023-05-timeless-gauges.md @@ -1,12 +1,12 @@ --- tags: ["vyper"] title: 2023-05-Timeless-Gauge -description: Timeless Finance Gauge Electisec Report +description: Timeless Finance Gauge yAudit Report nav_order: 24 image: assets/images/logo.png --- -# Electisec Timeless Finance Gauge Review +# yAudit Timeless Finance Gauge Review **Review Resources:** @@ -162,7 +162,7 @@ The scope of the review consisted of the following contracts in three different This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Timeless Finance and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Timeless Finance and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2023-06-RAMSES.md b/content/2023-06-RAMSES.md index 2bf560b..84b2fa4 100644 --- a/content/2023-06-RAMSES.md +++ b/content/2023-06-RAMSES.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-06-RAMSES -description: RAMSES Electisec Report +description: RAMSES yAudit Report nav_order: 28 image: assets/images/logo.png --- -# Electisec RAMSES Review +# yAudit RAMSES Review **Review Resources:** @@ -44,7 +44,7 @@ After the findings were presented to the RAMSES team, fixes were made and includ This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, RAMSES and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, RAMSES and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2023-06-RLN.md b/content/2023-06-RLN.md index 8583a3c..6056957 100644 --- a/content/2023-06-RLN.md +++ b/content/2023-06-RLN.md @@ -1,12 +1,12 @@ --- tags: ["zk", "circom", "solidity"] title: 2023-06-RLN -description: Rate Limiting Nullifier Electisec Report +description: Rate Limiting Nullifier yAudit Report nav_order: 16 image: assets/images/logo.png --- -# Electisec Rate Limiting Nullifier (RLN) Review +# yAudit Rate Limiting Nullifier (RLN) Review Review Resources: @@ -87,7 +87,7 @@ After the findings were presented to the RLN team, fixes were made and included This code review is for identifying potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, RLN and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, RLN and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -597,11 +597,11 @@ Over the course of the audit, in addition to a manual review of the code, we app ### Results -The relevant findings from each tool were already included in the report. +The relevant findings from each tool were already included in the report. Below is the full output of each tool. -### 1. Circomspect +### 1. Circomspect [circomspect : A static analyzer and linter for the Circom zero-knowledge DSL](https://github.com/trailofbits/circomspect) @@ -666,4 +666,3 @@ circomspect: 1 issue found. ### 2. Ecne The Circom circuits were compiled to non-optimized R1CS constraints system and then they were tested for `Weak Verification` to check for any bad constraints or underconstraints. All the circuits passed the [Ecne](https://github.com/franklynwang/EcneProject) tests without any mis- or under-constraints. This verifies that R1CS equations of the given circuits uniquely produce outputs given specific inputs. - diff --git a/content/2023-06-Sickle.md b/content/2023-06-Sickle.md index d8f663f..0717fa4 100644 --- a/content/2023-06-Sickle.md +++ b/content/2023-06-Sickle.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-06-Sickle -description: Sickle Electisec Report +description: Sickle yAudit Report nav_order: 29 image: assets/images/logo.png --- -# Electisec Sickle Review +# yAudit Sickle Review **Review Resources:** @@ -66,7 +66,7 @@ After the findings were presented to the Sickle team, fixes were made and includ This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Sickle team and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Sickle team and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2023-06-Spartan-ECDSA.md b/content/2023-06-Spartan-ECDSA.md index 37b3c49..98c50f4 100644 --- a/content/2023-06-Spartan-ECDSA.md +++ b/content/2023-06-Spartan-ECDSA.md @@ -1,12 +1,12 @@ --- tags: ["zk", "circom", "solidity"] title: 2023-06-Spartan-ECDSA -description: Spartan ECDSA Electisec Report +description: Spartan ECDSA yAudit Report nav_order: 16 image: assets/images/logo.png --- -# Electisec Spartan-ecdsa Review +# yAudit Spartan-ecdsa Review Review Resources: @@ -78,7 +78,7 @@ After the findings were presented to the Spartan-ecdsa team, fixes were made and This review is for identifying potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Spartan-ecdsa and users of the circuits agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Spartan-ecdsa and users of the circuits agree to use the code at their own risk. ## Code Evaluation Matrix @@ -186,7 +186,7 @@ Reported by [Antonio Viggiano](https://github.com/aviggiano), [Igor Line](https: ### 3. High - Under constrained circuits compromising the soundness of the system -In the file [mul.circom](https://github.com/electisec/spartan-ecdsa/blob/main/packages/circuits/eff_ecdsa_membership/secp256k1/mul.circom), the signals `slo` & `shi` are assigned but not constrained. +In the file [mul.circom](https://github.com/yAudit/spartan-ecdsa/blob/main/packages/circuits/eff_ecdsa_membership/secp256k1/mul.circom), the signals `slo` & `shi` are assigned but not constrained. #### Technical Details @@ -211,9 +211,9 @@ Circuits do not check whether the point $(x,y)$ is on the curve $E$. #### Technical Details -The pair $(x,y)$ forms a group $G$ of order $N$ under $E(\mathbb{F}_p)/\mathcal{P}$ where $E$ - represents an elliptic curve, $x, y < P$, $\mathbb{F}_p$ denotes a finite field, and $\mathcal{P}$ - represents the prime order of the base point. There is no check validating that $(x,y)$ $\in$ $G$. +The pair $(x,y)$ forms a group $G$ of order $N$ under $E(\mathbb{F}_p)/\mathcal{P}$ where $E$ +represents an elliptic curve, $x, y < P$, $\mathbb{F}_p$ denotes a finite field, and $\mathcal{P}$ +represents the prime order of the base point. There is no check validating that $(x,y)$ $\in$ $G$. #### Impact @@ -273,11 +273,11 @@ Reported by [Bahurum](https://github.com/bahurum), [0xnagu](https://github.com/t ### 1. Informational - Over-allocation of circom components -In [mul.circom:Secp256k1Mul](https://github.com/electisec/spartan-ecdsa/blob/main/packages/circuits/eff_ecdsa_membership/secp256k1/mul.circom), the value `accIncomplete` and `PComplete` are over-allocated. +In [mul.circom:Secp256k1Mul](https://github.com/yAudit/spartan-ecdsa/blob/main/packages/circuits/eff_ecdsa_membership/secp256k1/mul.circom), the value `accIncomplete` and `PComplete` are over-allocated. #### Technical Details -In [mul.circom:Secp256k1Mul](https://github.com/electisec/spartan-ecdsa/blob/main/packages/circuits/eff_ecdsa_membership/secp256k1/mul.circom), the value `accIncomplete` and `PComplete` are over-allocated. +In [mul.circom:Secp256k1Mul](https://github.com/yAudit/spartan-ecdsa/blob/main/packages/circuits/eff_ecdsa_membership/secp256k1/mul.circom), the value `accIncomplete` and `PComplete` are over-allocated. ``` component accIncomplete[bits]; diff --git a/content/2023-06-VMEX-incentives.md b/content/2023-06-VMEX-incentives.md index 5a17d39..2d41eef 100644 --- a/content/2023-06-VMEX-incentives.md +++ b/content/2023-06-VMEX-incentives.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-06-VMEX-incentives -description: VMEX Incentives Electisec Report +description: VMEX Incentives yAudit Report nav_order: 26 image: assets/images/logo.png --- -# Electisec VMEX Incentives Review +# yAudit VMEX Incentives Review **Review Resources:** @@ -54,7 +54,7 @@ After the findings were presented to the VMEX team, fixes were made and included This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, VMEX and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, VMEX and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -64,11 +64,11 @@ Electisec and the auditors make no warranties regarding the security of the code | Mathematics | Medium | One of the findings in the report is related to a division rounding error. | | Complexity | Good | See the Final Remarks section. The auditors felt as though the same technical outcome could have been achieved with a less complex solution. | | Libraries | Good | The libraries used in the pull request are appropriate and used correctly. | -| Decentralization | Low | Similar to the first VMEX report produced by Electisec, there are trusted actors in the system who have a high degree of power. | +| Decentralization | Low | Similar to the first VMEX report produced by yAudit, there are trusted actors in the system who have a high degree of power. | | Code stability | Medium | There were a few minor commits added to the PR after the audit commenced. | | Documentation | Good | The documentation supplied was insightful and the comments in the pull request provide useful context. | | Monitoring | Average | The core functions of the ExternalRewardDistributor emit events. | -| Testing and verification | Average | Similar to the first VMEX report produced by Electisec. Increased code coverage is suggested and would have caught some of the issues. | +| Testing and verification | Average | Similar to the first VMEX report produced by yAudit. Increased code coverage is suggested and would have caught some of the issues. | ## Findings Explanation @@ -737,7 +737,7 @@ Update the design of the contract to make this feature possible. Fixed in this commit: [457bcfa66ae6b36ff5426a718e3806849d226fd4](https://github.com/VMEX-finance/vmex/pull/145/commits/457bcfa66ae6b36ff5426a718e3806849d226fd4). -#### Electisec Response +#### yAudit Response Multiple findings were found in the new features added by this fix: diff --git a/content/2023-06-VMEX.md b/content/2023-06-VMEX.md index 81ad914..3e60f2a 100644 --- a/content/2023-06-VMEX.md +++ b/content/2023-06-VMEX.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-06-VMEX -description: VMEX Electisec Report +description: VMEX yAudit Report nav_order: 25 image: assets/images/logo.png --- -# Electisec VMEX Review +# yAudit VMEX Review **Review Resources:** @@ -35,7 +35,7 @@ Here is an overview of Vmex: Here is an overview of the reward distribution system to incentivize liquidity: ![Reward Overview](../public/assets/VMEX/IncentivizedAssets.png) -The contracts of the VMEX [Repo](https://github.com/VMEX-finance/vmex/tree/e1c910c6cda1988524841684ed1f37fd649450b3) were reviewed over 20 days. The code review was performed by 3 auditors between April 10 and May 7, 2023. Fellows from Electisec Block 5 additionally joined the review. The repository was under active development during the review, but the review was limited to the latest commit at the start of the review. This was commit [e1c910c6cda1988524841684ed1f37fd649450b3](https://github.com/VMEX-finance/vmex/tree/e1c910c6cda1988524841684ed1f37fd649450b3) for the VMEX repo. +The contracts of the VMEX [Repo](https://github.com/VMEX-finance/vmex/tree/e1c910c6cda1988524841684ed1f37fd649450b3) were reviewed over 20 days. The code review was performed by 3 auditors between April 10 and May 7, 2023. Fellows from yAudit Block 5 additionally joined the review. The repository was under active development during the review, but the review was limited to the latest commit at the start of the review. This was commit [e1c910c6cda1988524841684ed1f37fd649450b3](https://github.com/VMEX-finance/vmex/tree/e1c910c6cda1988524841684ed1f37fd649450b3) for the VMEX repo. ## Scope @@ -97,7 +97,7 @@ After the findings were presented to the VMEX team, fixes were made and included This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, VMEX and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, VMEX and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -386,7 +386,7 @@ To be safe from reentrancy attack, you can follow one of these recommendations: We used `remove_liquidity_one_coin()` but it reverts for an unknown reason for some tokens. Thus, we structured the reentrancy guard to also try remove_liquidity. Fix in commit [204b369f278c204f6fd76ea82e489a79fe930f02](VMEX-finance/vmex@204b369). -#### Electisec Response +#### yAudit Response Since there are many different configurations in this fix commit, we recommend adding tests with different Curve pools. @@ -414,7 +414,7 @@ Add a time lock to tranche admin functionalities which change how users are char I think tranche admins can still do the attack with the timelock. There's nothing in contract code that forces tranche admins to tell users that they plan on changing parameters, so in the end they can still change it under the radar. Thus, I changed it such that they can't change it at all once there is liquidity in the pool. Fixed in [PR 154](https://github.com/VMEX-finance/vmex/pull/154). -#### Electisec Response +#### yAudit Response This fix is a nice trade off where tranche admins lose some capabilities but users are protected. One drawback of this approach is that the tranche admin can frontrun the deposit going into an empty tranche. diff --git a/content/2023-06-Yearn-v3.md b/content/2023-06-Yearn-v3.md index cecd6e3..1aa5118 100644 --- a/content/2023-06-Yearn-v3.md +++ b/content/2023-06-Yearn-v3.md @@ -1,12 +1,12 @@ --- tags: ["solidity", "vyper"] title: 2023-06-Yearn-v3 -description: Yearn v3 Electisec Report +description: Yearn v3 yAudit Report nav_order: 27 image: assets/images/logo.png --- -# Electisec Yearn v3 Review +# yAudit Yearn v3 Review **Review Resources:** @@ -57,7 +57,7 @@ After the findings were presented to the Yearn Finance team, fixes were made and This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Yearn Finance and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Yearn Finance and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2023-07-Bunni-Oracle.md b/content/2023-07-Bunni-Oracle.md index aa29fd9..291cc6c 100644 --- a/content/2023-07-Bunni-Oracle.md +++ b/content/2023-07-Bunni-Oracle.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-07-Bunni-Oracle -description: Timeless Bunni Oracle Electisec Report +description: Timeless Bunni Oracle yAudit Report nav_order: 30 image: assets/images/logo.png --- -# Electisec Timeless Bunni Oracle Review +# yAudit Timeless Bunni Oracle Review **Review Resources:** @@ -40,7 +40,7 @@ After the findings were presented to the Timeless team, fixes were made and incl This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Timeless and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Timeless and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -156,7 +156,7 @@ Low. Fixed at commit [1daca0f17dc1350be8b40fcefd40347d612ce840](https://github.com/timeless-fi/bunni-oracle/commit/1daca0f17dc1350be8b40fcefd40347d612ce840). -#### Electisec Response +#### yAudit Response Reviewed. Circle has since launched native USDC on more chains including Arbitrum. This means that USDC has two versions (bridged and native). Please ensure you are using the intended address. @@ -190,7 +190,7 @@ If AMPL/USD oracle is not supposed to be used with this contract, future oracle Fixed at [5c40aa17bad00ef694fc8d5578ce6cf3e1e2b5d4](https://github.com/timeless-fi/bunni-oracle/commit/5c40aa17bad00ef694fc8d5578ce6cf3e1e2b5d4). -#### Electisec Response +#### yAudit Response Chainlink feed decimals are hardcoded for popular tokens. For Ethereum mainnet and Arbitrum, these values are correct, but make sure to verify the correctness before deploying on new chains. You can add such a check in the deploy script. diff --git a/content/2023-07-TempleDAO-Lending.md b/content/2023-07-TempleDAO-Lending.md index ffe54b0..19950de 100644 --- a/content/2023-07-TempleDAO-Lending.md +++ b/content/2023-07-TempleDAO-Lending.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-07-TempleDAO-Lending -description: TempleDAO Lending Electisec Report +description: TempleDAO Lending yAudit Report nav_order: 31 image: assets/images/logo.png --- -# Electisec TempleDAO Lending Review +# yAudit TempleDAO Lending Review **Review Resources:** @@ -50,7 +50,7 @@ Note that the deployment scripts were not in a finalized state at the commit has This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, TempleDAO and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, TempleDAO and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -234,7 +234,7 @@ Return Value: 10600 The TPI value is [assumed to be equal to the price of TEMPLE](https://github.com/TempleDAO/temple/blob/b015cd5d1df122ad5fbe0f94fb5bd070db27e335/protocol/contracts/v2/templeLineOfCredit/TempleLineOfCredit.sol#L583) when the value of TEMPLE collateral is calculated in TempleLineOfCredit.sol. This is in contrast to lending protocols such as Compound Finance, which use the current price of a token from Chainlink to determine the value of user collateral. It is possible, in fact likely, that the TPI value is greater than the value of TEMPLE based on the spot price of the Balancer pool. The graph illustrating the variation of the two prices is found on [TempleDAO's homepage](https://templedao.link/). -![TPI-price](https://github.com/Electisec/temple-lending-report/assets/6261182/1e23c13d-7c65-46a5-8760-21447105da3c) +![TPI-price](https://github.com/yAudit/temple-lending-report/assets/6261182/1e23c13d-7c65-46a5-8760-21447105da3c) If the difference between the spot price in the Balancer pool and the TLC is too great, an arbitrageur can leave the protocol with bad debt. Consider a scenario where TPI was at $1, the spot price of TEMPLE is $0.90, and the TPI was just raised by governance to $1.15: @@ -1211,7 +1211,7 @@ The two return value structs are [defined in IBalancerVault.sol](https://github. In comparison, these structs should have the same types according to [the Balancer docs](https://docs.balancer.fi/reference/contracts/query-functions.html#overview). -![types](https://github.com/Electisec/temple-lending-report/assets/6261182/ccdb241c-df13-47e6-8318-47e0e28e64f5) +![types](https://github.com/yAudit/temple-lending-report/assets/6261182/ccdb241c-df13-47e6-8318-47e0e28e64f5) The on-chain Balancer implementations of [`JoinPoolRequest`](https://etherscan.io/address/0xE39B5e3B6D74016b2F6A9673D7d7493B6DF549d5#code#F5#L382) and [ExitPoolRequest](https://etherscan.io/address/0xE39B5e3B6D74016b2F6A9673D7d7493B6DF549d5#code#F5#L431) also shows consistency in variable types between the structs, although type `IAsset` is used instead of type `address`. @@ -1285,7 +1285,7 @@ The ability to borrow DAI from TempleLineOfCredit.sol is similar to other protoc [The values set in the deployment script](https://github.com/TempleDAO/temple/blob/b015cd5d1df122ad5fbe0f94fb5bd070db27e335/protocol/scripts/deploys/v2/sepolia/07-tlc-IRM-linear-kink.ts#L22-L25) for LinearWithKinkInterestRateModel.sol result in a significantly different borrowing curve compared to Compound v2 and Aave DAI markets. Consider the goals and risk implications of the current choices to determine how closely TempleDAO aims to align with these other protocols to remain competitive and maintain a utilization ratio in line with the DAO's goals. If the lowest borrowing rate at zero utilization is 5%, this may be too high of a borrowing rate with current market conditions to remain competitive. Compound and Aave regularly modify the values that determine their borrowing curves based on feedback from Gauntlet that accounts for current market conditions. -![lending_curves](https://github.com/Electisec/temple-lending-report/assets/6261182/cf764ccb-4dfc-4c24-ab30-f90cb3228484) +![lending_curves](https://github.com/yAudit/temple-lending-report/assets/6261182/cf764ccb-4dfc-4c24-ab30-f90cb3228484) The suggestion to lower the interest rate at zero utilization is only valid with the current Maker DSR rate of 3.19%. If Maker increases the DSR rate, such as with [the recent eDSR proposal](https://forum.makerdao.com/t/request-for-gov12-1-2-edit-to-the-stability-scope-to-quickly-implement-enhanced-dsr/21405) that passed, then a different y-intercept value would make sense nearer to whatever base rate DAI in the TempleDAO base strategy is earning. diff --git a/content/2023-08-KEOM-upgrade.md b/content/2023-08-KEOM-upgrade.md index 7ba4b28..4f6a298 100644 --- a/content/2023-08-KEOM-upgrade.md +++ b/content/2023-08-KEOM-upgrade.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-08-KEOM-upgrade -description: KEOM Upgrade Electisec Report +description: KEOM Upgrade yAudit Report nav_order: 33 image: assets/images/logo.png --- -# Electisec KEOM Upgrade Review +# yAudit KEOM Upgrade Review **Review Resources:** @@ -42,7 +42,7 @@ After the findings were presented to the KEOM team, fixes were made and included This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, KEOM and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, KEOM and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -442,7 +442,7 @@ If the protocol plans to support adding hundreds of markets in the future, add g #### Developer Response -In case that we add hundreds of markets, we will probably change the implementation of this function and hire Electisec for another audit :) +In case that we add hundreds of markets, we will probably change the implementation of this function and hire yAudit for another audit :) ### 8. Informational - Typos diff --git a/content/2023-08-TempleDAO-Lending-Recheck.md b/content/2023-08-TempleDAO-Lending-Recheck.md index da38ad3..b0d7db6 100644 --- a/content/2023-08-TempleDAO-Lending-Recheck.md +++ b/content/2023-08-TempleDAO-Lending-Recheck.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-08-TempleDAO-Lending -description: TempleDAO Lending Electisec Report +description: TempleDAO Lending yAudit Report nav_order: 32 image: assets/images/logo.png --- -# Electisec TempleDAO Lending Recheck Review +# yAudit TempleDAO Lending Recheck Review **Review Resources:** @@ -37,9 +37,9 @@ TempleDAO provides investors with a protocol that aims to provide a stable form 1. The strategy architecture, which allows the Treasury Reserves Vault (TRV) to invest assets to generate yield that accrues to the treasury. 2. The RAMOS AMO, which provides price stabilization by managing the TEMPLE-DAI Balancer pool. -The contracts of the TempleDAO [Repo](https://github.com/TempleDAO/temple) were reviewed over 2 days. The code review was performed by 2 auditors between August 24 and August 25, 2023. The repository was under active development during the review, but the review was limited to the latest commit at the start of the review. This was commit [7ed36cb8a1f42145ba66f70e31c51a3f774d6bed](https://github.com/TempleDAO/temple/tree/7ed36cb8a1f42145ba66f70e31c51a3f774d6bed) for the TempleDAO repo. Because this was the second time that Electisec was reviewing this code, the primary focus of this audit was a review of the mitigation changes addressing issues from the original full audit by Electisec. These changes are found in [PR #842](https://github.com/TempleDAO/temple/pull/842). +The contracts of the TempleDAO [Repo](https://github.com/TempleDAO/temple) were reviewed over 2 days. The code review was performed by 2 auditors between August 24 and August 25, 2023. The repository was under active development during the review, but the review was limited to the latest commit at the start of the review. This was commit [7ed36cb8a1f42145ba66f70e31c51a3f774d6bed](https://github.com/TempleDAO/temple/tree/7ed36cb8a1f42145ba66f70e31c51a3f774d6bed) for the TempleDAO repo. Because this was the second time that yAudit was reviewing this code, the primary focus of this audit was a review of the mitigation changes addressing issues from the original full audit by yAudit. These changes are found in [PR #842](https://github.com/TempleDAO/temple/pull/842). -TempleDAO fixed the issues from the first report in [pull request #842](https://github.com/TempleDAO/temple/pull/842) and Electisec did a review of these mitigations by comparing changes made from commit b015cd5d1df122ad5fbe0f94fb5bd070db27e335, which was the commit of the first review, to commit 7ed36cb8a1f42145ba66f70e31c51a3f774d6bed, which was the commit that included the mitigations. +TempleDAO fixed the issues from the first report in [pull request #842](https://github.com/TempleDAO/temple/pull/842) and yAudit did a review of these mitigations by comparing changes made from commit b015cd5d1df122ad5fbe0f94fb5bd070db27e335, which was the commit of the first review, to commit 7ed36cb8a1f42145ba66f70e31c51a3f774d6bed, which was the commit that included the mitigations. ## Scope @@ -52,7 +52,7 @@ Note that the deployment scripts were not in a finalized state at the commit has This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, TempleDAO and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, TempleDAO and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -490,6 +490,6 @@ Instead, this is intentionally left to the strategy to decide if it needs to do The issues raised in the first audit report were successfully mitigated, as evidence by the lack of any findings above the low risk categorization. There were some very minor improvements that could be made, but no substantial risks were observed during the audit. -The changeset also included an important refactor to the TempleDebtToken.sol contract to introduce the "cache struct" pattern, already employed in the TempleLineOfCredit.sol contract. This set of modifications were not a suggestion from the previous Electisec report, but were grouped in with the other changes during the audit. With the intention of lowering gas costs, this pattern initializes a shared structure that pre-fetches storage variables that are frequently accessed in the course of different functions to have them cached in a structure stored in memory. While this approach effectively reduces gas consumption, it is important to note that it adds complexity while reasoning about the contract's functionality, and could be more error prone compared to direct storage access. It is also fair to mention that, in some cases, code complexity was reduced due to having certain calculations already available in the cache structure. Such an example is the `_burn()` function, which is now simpler and easier to read. +The changeset also included an important refactor to the TempleDebtToken.sol contract to introduce the "cache struct" pattern, already employed in the TempleLineOfCredit.sol contract. This set of modifications were not a suggestion from the previous yAudit report, but were grouped in with the other changes during the audit. With the intention of lowering gas costs, this pattern initializes a shared structure that pre-fetches storage variables that are frequently accessed in the course of different functions to have them cached in a structure stored in memory. While this approach effectively reduces gas consumption, it is important to note that it adds complexity while reasoning about the contract's functionality, and could be more error prone compared to direct storage access. It is also fair to mention that, in some cases, code complexity was reduced due to having certain calculations already available in the cache structure. Such an example is the `_burn()` function, which is now simpler and easier to read. One suggestion to streamline a similar future audit that is focused on mitigations is to better correlate specific commit hashes or smaller PRs to every issue in the original audit report. The approach used prior to this audit was to group all changes into a single PR, which is also useful, but improving the developer response comments under each issue in the original report to point directly at the changes made only to address that specific issue could have reduced the effort needed to validate the mitigations. diff --git a/content/2023-10-Dopex-rDPX-v2.md b/content/2023-10-Dopex-rDPX-v2.md index 544a998..0e1d81e 100644 --- a/content/2023-10-Dopex-rDPX-v2.md +++ b/content/2023-10-Dopex-rDPX-v2.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-10-Dopex-rDPX-v2 -description: Dopex rDPX v2 Electisec Report +description: Dopex rDPX v2 yAudit Report nav_order: 38 image: assets/images/logo.png --- -# Electisec Dopex rDPX v2 Review +# yAudit Dopex rDPX v2 Review **Review Resources:** @@ -43,7 +43,7 @@ The majority of the rDPX v2 repository was out of scope of this review because i This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Dopex and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Dopex and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2023-10-DopexV2-CLAMM.md b/content/2023-10-DopexV2-CLAMM.md index a9ebf11..4ea1873 100644 --- a/content/2023-10-DopexV2-CLAMM.md +++ b/content/2023-10-DopexV2-CLAMM.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-10-Dopex-CLAMM -description: Dopex V2 CLAMM Electisec Report +description: Dopex V2 CLAMM yAudit Report nav_order: 36 image: assets/images/logo.png --- -# Electisec Dopex V2 CLAMM Review +# yAudit Dopex V2 CLAMM Review **Review Resources:** @@ -30,7 +30,7 @@ image: assets/images/logo.png Dopex V2 CLAMM provides a solution to solve the on-chain options liquidity issue, by using Uniswap V3 liquidity positions as collateral for writing options. With this approach, an option is purchased at a specific strike price against a Uniswap V3 LP previously deposited into CLAMM. The liquidity is borrowed from the corresponding tick and withdrawn from the AMM. The tokens are no longer participating in liquidity provision, and the CLAMM LPs are paid a fixed premium base which is converted into an LP position. When the current price surpasses the strike price, Traders can take a profit, in this case, the unwrapped liquidity is swapped into an asset, and the profit is sent to the trader, and the rest is LPed back to the AMM. The premium paid for this operation is far more than the fees the position might have earned while in the AMM. If the Uniswap V3 liquidity position are not used by any options, the liquidity position will still earn fees as it normally would in Uniswap V3. -![clamm_arch](https://github.com/Electisec/dopex-v2-clamm-report/assets/116267321/5f5ba136-4a54-4f85-90eb-cccd5170a1af) +![clamm_arch](https://github.com/yAudit/dopex-v2-clamm-report/assets/116267321/5f5ba136-4a54-4f85-90eb-cccd5170a1af) The contracts of the Dopex V2 CLAMM [Repo](https://github.com/dopex-io/dopex-v2-clamm) were reviewed over 21 days. The code review was performed by 3 auditors between October 20 and November 10, 2023. The repository was under active development during the review, but the review was limited to the latest commit at the start of the review. This was commit [ceb91c7d403da4a3b3eea831c195305e6a5362f9](https://github.com/dopex-io/dopex-v2-clamm/commit/ceb91c7d403da4a3b3eea831c195305e6a5362f9) for the Dopex V2 CLAMM repo. @@ -48,7 +48,7 @@ After the findings were presented to the Dopex V2 CLAMM team, fixes were made an This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Dopex V2 CLAMM and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Dopex V2 CLAMM and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2023-10-DopexV2-rDPX-upgrade.md b/content/2023-10-DopexV2-rDPX-upgrade.md index fb571cf..ba15fd5 100644 --- a/content/2023-10-DopexV2-rDPX-upgrade.md +++ b/content/2023-10-DopexV2-rDPX-upgrade.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-10-DopexV2-rDPX-upgrade -description: Dopex V2 rDPX Upgrade Electisec Report +description: Dopex V2 rDPX Upgrade yAudit Report nav_order: 37 image: assets/images/logo.png --- -# Electisec Dopex RDPX Token Review +# yAudit Dopex RDPX Token Review **Review Resources:** @@ -42,7 +42,7 @@ After the findings were presented to the Dopex team, fixes were made and include This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Dopex and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Dopex and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2023-10-Sickle-Update.md b/content/2023-10-Sickle-Update.md index 397a9bc..2e00bb1 100644 --- a/content/2023-10-Sickle-Update.md +++ b/content/2023-10-Sickle-Update.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-10-Sickle-Update -description: Sickle Update Electisec Report +description: Sickle Update yAudit Report nav_order: 38 image: assets/images/logo.png --- -# Electisec Sickle Update Review +# yAudit Sickle Update Review **Review Resources:** @@ -58,7 +58,7 @@ After the findings were presented to the Sickle team, fixes were made and includ This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Sickle and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Sickle and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2023-12-Euler-EVC.md b/content/2023-12-Euler-EVC.md index d363ef2..e14026b 100644 --- a/content/2023-12-Euler-EVC.md +++ b/content/2023-12-Euler-EVC.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-12-Euler-EVC -description: Euler EVC Electisec Report +description: Euler EVC yAudit Report nav_order: 39 image: assets/images/logo.png --- -# Electisec Euler EVC Review +# yAudit Euler EVC Review **Review Resources:** @@ -55,7 +55,7 @@ After the findings were presented to the Euler team, fixes were made and include This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2023-12-dopex-v2-automator.md b/content/2023-12-dopex-v2-automator.md index f197e20..342b050 100644 --- a/content/2023-12-dopex-v2-automator.md +++ b/content/2023-12-dopex-v2-automator.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2023-12-Dopex-v2-Automator -description: Dopex v2 Automator Electisec Report +description: Dopex v2 Automator yAudit Report nav_order: 39 image: assets/images/logo.png --- -# Electisec Orange Finance Dopex V2 Automator Review +# yAudit Orange Finance Dopex V2 Automator Review **Review Resources:** @@ -44,7 +44,7 @@ After the findings were presented to the Orange Finance team, fixes were made an This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Orange Finance and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Orange Finance and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-01-Inverse-sDOLA.md b/content/2024-01-Inverse-sDOLA.md index 6f66c39..f0c19a9 100644 --- a/content/2024-01-Inverse-sDOLA.md +++ b/content/2024-01-Inverse-sDOLA.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-01-Inverse-sDOLA -description: Inverse Finance DOLA Savings Electisec Report +description: Inverse Finance DOLA Savings yAudit Report nav_order: 46 image: assets/images/logo.png --- -# Electisec Inverse Finance DOLA Savings Review +# yAudit Inverse Finance DOLA Savings Review **Review Resources:** @@ -42,7 +42,7 @@ After the findings were presented to the Dola savings team, fixes were made and This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Inverse Finance and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Inverse Finance and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -556,4 +556,4 @@ Addressed in https://github.com/InverseFinance/dola-savings/pull/7/commits/85938 ## Final remarks -The Electisec of Inverse Finance's Dola Savings platform, conducted by adriro and pandadefi, provided a thorough examination of its smart contracts. The audit, spanning three days, uncovered a range of findings from high to low impact, alongside gas-saving and informational insights. Critical vulnerabilities, such as the susceptibility of the sDola vault to inflation attacks and the potential manipulation of sDola in lending-borrowing markets, were promptly addressed. Lower-impact issues, focusing on aspects like checks and function optimizations, were also noted for improvement. The audit emphasizes the platform's strong foundation in smart contract development and its commitment to security, efficiency, and continuous improvement. +The yAudit of Inverse Finance's Dola Savings platform, conducted by adriro and pandadefi, provided a thorough examination of its smart contracts. The audit, spanning three days, uncovered a range of findings from high to low impact, alongside gas-saving and informational insights. Critical vulnerabilities, such as the susceptibility of the sDola vault to inflation attacks and the potential manipulation of sDola in lending-borrowing markets, were promptly addressed. Lower-impact issues, focusing on aspects like checks and function optimizations, were also noted for improvement. The audit emphasizes the platform's strong foundation in smart contract development and its commitment to security, efficiency, and continuous improvement. diff --git a/content/2024-01-Peapods-yAudit-Report.md b/content/2024-01-Peapods-yAudit-Report.md index c986638..ad0a0f4 100644 --- a/content/2024-01-Peapods-yAudit-Report.md +++ b/content/2024-01-Peapods-yAudit-Report.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-01-Peapods -description: Peapods Electisec Report +description: Peapods yAudit Report nav_order: 40 image: assets/images/logo.png --- -# Electisec Peapods Review +# yAudit Peapods Review **Review Resources:** @@ -77,7 +77,7 @@ After the findings were presented to the Peapods team, fixes were made and inclu This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Peapods and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Peapods and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -189,7 +189,7 @@ function test_StealWithWeightShift() public { vm.prank(deployer); index = new WeightedIndex( - "Electisec", + "yAudit", "YAT", fees, tokens, @@ -1538,7 +1538,7 @@ When deploying a pod, the deployer can decide what tokens the pod will hold. Add weights[1] = 70; index = new WeightedIndex( - "Electisec", + "yAudit", "YAT", fees, tokens, @@ -1631,7 +1631,7 @@ Acknowledged but we are okay leaving as is for now. ## Final remarks -The Electisec team conducted an extensive review of the protocol contracts focused around the weighted pods functionality, leading to multiple issues of different severity. +The yAudit team conducted an extensive review of the protocol contracts focused around the weighted pods functionality, leading to multiple issues of different severity. It is refreshing to see a protocol that embraces decentralization and doesn't rely on upgradeable contracts or trusted entities. However, this approach brings its own challenges, as observed in the fee processing logic that feeds reward distribution. Lack of slippage, highlighted in M-6, is a consequence of the difficulties in executing fair on-chain swaps as part of an automated process during the protocol's lifecycle. diff --git a/content/2024-01-yPrisma-Recheck.md b/content/2024-01-yPrisma-Recheck.md index 41fd539..712877e 100644 --- a/content/2024-01-yPrisma-Recheck.md +++ b/content/2024-01-yPrisma-Recheck.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-01-yPrisma-Recheck -description: yPrisma Recheck Electisec Report +description: yPrisma Recheck yAudit Report nav_order: 49 image: assets/images/logo.png --- -# Electisec YearnBoostedStaker Recheck Review +# yAudit YearnBoostedStaker Recheck Review **Review Resources:** @@ -53,7 +53,7 @@ After the findings were presented to the Yearn Finance team, fixes were made and This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Yearn Finance and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Yearn Finance and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-01-yPrisma.md b/content/2024-01-yPrisma.md index 5931bb0..22aefd7 100644 --- a/content/2024-01-yPrisma.md +++ b/content/2024-01-yPrisma.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-01-yPrisma -description: yPrisma Electisec Report +description: yPrisma yAudit Report nav_order: 48 image: assets/images/logo.png --- -# Electisec yPrisma Review +# yAudit yPrisma Review **Review Resources:** @@ -42,7 +42,7 @@ After the findings were presented to the yearn finance team, fixes were made and This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, yearn finance and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, yearn finance and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-02-Obelisk.md b/content/2024-02-Obelisk.md index e1e754c..cbf1aef 100644 --- a/content/2024-02-Obelisk.md +++ b/content/2024-02-Obelisk.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-02-Obelisk -description: Obelisk Electisec Report +description: Obelisk yAudit Report nav_order: 41 image: assets/images/logo.png --- -# Electisec Obelisk Review +# yAudit Obelisk Review **Review Resources:** @@ -59,7 +59,7 @@ After the findings were presented to the Obelisk team, fixes were made and inclu This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Obelisk and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Obelisk and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-03-1upYFI.md b/content/2024-03-1upYFI.md index 5287bb7..3632cea 100644 --- a/content/2024-03-1upYFI.md +++ b/content/2024-03-1upYFI.md @@ -1,12 +1,12 @@ --- tags: ["vyper"] title: 2024-03-1upYFI -description: 1upYFI Electisec Report +description: 1upYFI yAudit Report nav_order: 2 image: assets/images/logo.png --- -# Electisec Yearn 1UP Review +# yAudit Yearn 1UP Review **Review Resources:** @@ -51,7 +51,7 @@ After the findings were presented to the Yearn 1UP team, fixes were made and inc This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Yearn 1UP and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Yearn 1UP and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-03-Cove.md b/content/2024-03-Cove.md index f84aca6..da8b60a 100644 --- a/content/2024-03-Cove.md +++ b/content/2024-03-Cove.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-03-Cove -description: Cove Electisec Report +description: Cove yAudit Report nav_order: 53 image: assets/images/logo.png --- -# Electisec Cove Boosties Review +# yAudit Cove Boosties Review **Review Resources:** @@ -55,7 +55,7 @@ After the findings were presented to the Cove team, fixes were made and included This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Cove and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Cove and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -1022,7 +1022,7 @@ Fixed in: ## Final Remarks -The Cove Boosties protocol enables the optimization of Yearn V3 dYFI emissions, allowing users to deposit their Yearn gauge tokens and benefit from protocol-owned veYFI boost. The Electisec team conducted a comprehensive review of the contracts related to the distribution of rewards within the protocol. +The Cove Boosties protocol enables the optimization of Yearn V3 dYFI emissions, allowing users to deposit their Yearn gauge tokens and benefit from protocol-owned veYFI boost. The yAudit team conducted a comprehensive review of the contracts related to the distribution of rewards within the protocol. At its core, BaseRewardsGauge.sol provides an implementation of the classic staking algorithm in a multi-reward token fashion. This serves as the foundation for the two versions of the vault that handle both auto-compounded and non-autocompounded variants. Additionally, the Cove team introduced a revamped version of Sushi's MiniChef contract, intended to handle incentive programs for the COVE token. diff --git a/content/2024-03-EulerV2.md b/content/2024-03-EulerV2.md index 487f460..4162464 100644 --- a/content/2024-03-EulerV2.md +++ b/content/2024-03-EulerV2.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-03-EulerV2 -description: Euler v2 Electisec Report +description: Euler v2 yAudit Report nav_order: 54 image: assets/images/logo.png --- -# Electisec Euler v2 Review +# yAudit Euler v2 Review **Review Resources:** @@ -189,7 +189,7 @@ The review was done to identify potential vulnerabilities in the code. While not During the review, the auditors presented their findings to the Euler team, which provided commentary and fixed the findings across several PRs. -Electisec and the auditors, committed to transparency, make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Euler and users of the contracts agree to use the code at their own risk. +yAudit and the auditors, committed to transparency, make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Euler and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-03-TLX.md b/content/2024-03-TLX.md index 38202dc..cc18781 100644 --- a/content/2024-03-TLX.md +++ b/content/2024-03-TLX.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-03-TLX -description: TLX Electisec Report +description: TLX yAudit Report nav_order: 42 image: assets/images/logo.png --- -# Electisec TLX Review +# yAudit TLX Review **Review Resources:** @@ -82,7 +82,7 @@ After the findings were presented to the TLX team, fixes were made and included This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, TLX and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, TLX and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-05-Heroglyphs.md b/content/2024-05-Heroglyphs.md index 83ac821..6d86c40 100644 --- a/content/2024-05-Heroglyphs.md +++ b/content/2024-05-Heroglyphs.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-05-Heroglyphs -description: Heroglyphs Electisec Report +description: Heroglyphs yAudit Report nav_order: 54 image: assets/images/logo.png --- -# Electisec Heroglyphs Review +# yAudit Heroglyphs Review **Review Resources:** @@ -86,7 +86,7 @@ After the findings were presented to the Heroglyphs team, fixes were made and in This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Heroglyphs and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Heroglyphs and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-05-Sickle-3.md b/content/2024-05-Sickle-3.md index e9973f8..a29cf89 100644 --- a/content/2024-05-Sickle-3.md +++ b/content/2024-05-Sickle-3.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-05-Sickle-3 -description: Sickle-3 Electisec report +description: Sickle-3 yAudit report nav_order: 53 image: assets/images/logo.png --- -# Electisec Sickle Review +# yAudit Sickle Review **Review Resources:** @@ -138,7 +138,7 @@ After the findings were presented to the Sickle team, fixes were made and includ This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, vfat, and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, vfat, and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-05-Summa-Va.md b/content/2024-05-Summa-Va.md index 2f9af1b..282a5bd 100644 --- a/content/2024-05-Summa-Va.md +++ b/content/2024-05-Summa-Va.md @@ -1,12 +1,12 @@ --- tags: ["zk", "halo2", "solidity"] title: 2024-05-Summa-Va -description: Summa Va Electisec Report +description: Summa Va yAudit Report nav_order: 16 image: assets/images/logo.png --- -# Electisec Summa Review - MST-based Protocol +# yAudit Summa Review - MST-based Protocol Auditors: @@ -171,22 +171,22 @@ After the findings were presented to the Summa team, fixes were made and include This code review is for identifying potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged parties could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent or imply to third parties that the code has been audited or that the code is free from defects. By deploying or using the code, Summa Solvency and users of the contracts/circuits agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent or imply to third parties that the code has been audited or that the code is free from defects. By deploying or using the code, Summa Solvency and users of the contracts/circuits agree to use the code at their own risk. ## Code Evaluation Matrix --- -| Category | Mark | Description | -| ------------------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | -| Mathematics | Good | No significant mathematical components were involved | -| Complexity | Good | The code is easy to understand and closely follows the specification | -| Libraries | Low | Although no serious issues have been found in the dependencies, the codebase makes use of unaudited versions of [halo2](https://github.com/summa-dev/halo2) , [halo2-kzg-srs](https://github.com/han0110/halo2-kzg-srs), and [halo2-solidity-verifier](https://github.com/summa-dev/halo2-solidity-verifier), which is not recommended for production | -| Cryptography | Good | Merkle Sum Trees inherit strong cryptographic properties from the hash functions used. Here, the codebase makes use of the Poseidon hash function known for its efficiency, zk-friendliness, and resistance against various cryptanalytic attacks. Even with a change in its magic numbers, the hash function yields a security of `127 bits`. However, it's essential to note that cryptographic algorithms and functions are always subject to ongoing analysis, and new attacks or weaknesses may be discovered in the future. | -| Code stability | Good | The code was reviewed at a specific commit. The code did not change during the review. Moreover, it is not likely to change significantly with addition of features or updates | -| Documentation | Good | Summa codebase comprises a centralized and up-to-date [Gitbook documentation](https://summa.gitbook.io/summa/v/1). However, we recommend aggregating the limitations and the attack vectors of the Summa Protocol in the documentation. We found only one discrepancy with regards to the documentation here [Informational#2](#2-informational-inclusionverifieryulnot-generated). | -| Monitoring | N/A | The protocol is intended to be integrated by other systems or dApps which will be responsible for the monitoring | -| Testing and verification | Average | The protocol contains only a few tests for the circuits. It is recommended to add more tests to increase the test coverage. When it comes to circuits, we believe it is necessary to develop an adversarial testing process, especially focused on malicious prover behavior. We raised the following PRs to increase code coverage & emphasize testing - [#3](https://github.com/electisec/summa-solvency-diffie/pull/3), [#5](https://github.com/electisec/summa-solvency-schneier/pull/5), [#8](https://github.com/electisec/summa-solvency-schneier/pull/8/files), [#17](https://github.com/electisec/summa-solvency-schneier/pull/17). We also recommend [fuzz testing](#fuzz-testing) and incorporating tools we used in [Automated Testing](#automated-testing) in Summa's software development lifecycle to produce secure code | +| Category | Mark | Description | +| ------------------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Mathematics | Good | No significant mathematical components were involved | +| Complexity | Good | The code is easy to understand and closely follows the specification | +| Libraries | Low | Although no serious issues have been found in the dependencies, the codebase makes use of unaudited versions of [halo2](https://github.com/summa-dev/halo2) , [halo2-kzg-srs](https://github.com/han0110/halo2-kzg-srs), and [halo2-solidity-verifier](https://github.com/summa-dev/halo2-solidity-verifier), which is not recommended for production | +| Cryptography | Good | Merkle Sum Trees inherit strong cryptographic properties from the hash functions used. Here, the codebase makes use of the Poseidon hash function known for its efficiency, zk-friendliness, and resistance against various cryptanalytic attacks. Even with a change in its magic numbers, the hash function yields a security of `127 bits`. However, it's essential to note that cryptographic algorithms and functions are always subject to ongoing analysis, and new attacks or weaknesses may be discovered in the future. | +| Code stability | Good | The code was reviewed at a specific commit. The code did not change during the review. Moreover, it is not likely to change significantly with addition of features or updates | +| Documentation | Good | Summa codebase comprises a centralized and up-to-date [Gitbook documentation](https://summa.gitbook.io/summa/v/1). However, we recommend aggregating the limitations and the attack vectors of the Summa Protocol in the documentation. We found only one discrepancy with regards to the documentation here [Informational#2](#2-informational-inclusionverifieryulnot-generated). | +| Monitoring | N/A | The protocol is intended to be integrated by other systems or dApps which will be responsible for the monitoring | +| Testing and verification | Average | The protocol contains only a few tests for the circuits. It is recommended to add more tests to increase the test coverage. When it comes to circuits, we believe it is necessary to develop an adversarial testing process, especially focused on malicious prover behavior. We raised the following PRs to increase code coverage & emphasize testing - [#3](https://github.com/yAudit/summa-solvency-diffie/pull/3), [#5](https://github.com/yAudit/summa-solvency-schneier/pull/5), [#8](https://github.com/yAudit/summa-solvency-schneier/pull/8/files), [#17](https://github.com/yAudit/summa-solvency-schneier/pull/17). We also recommend [fuzz testing](#fuzz-testing) and incorporating tools we used in [Automated Testing](#automated-testing) in Summa's software development lifecycle to produce secure code | # Automated Testing @@ -252,8 +252,8 @@ We recommend that a range check is done inside the circuit or inside the smart c #### Refer -- [Guarantee usernames stays inside field](https://github.com/electisec/summa-solvency-schneier/issues/13) by [sebastiantf](https://github.com/sebastiantf) -- [Possible Overflow in username in big_intify_username combined with calling big_uint_to_fp](https://github.com/electisec/summa-solvency-diffie/issues/16) by [parsley](https://github.com/bbresearcher) +- [Guarantee usernames stays inside field](https://github.com/yAudit/summa-solvency-schneier/issues/13) by [sebastiantf](https://github.com/sebastiantf) +- [Possible Overflow in username in big_intify_username combined with calling big_uint_to_fp](https://github.com/yAudit/summa-solvency-diffie/issues/16) by [parsley](https://github.com/bbresearcher) ## 2. High: Sum Balance Overflow @@ -261,7 +261,7 @@ The lack of in-circuit range check for the sum of balances posesses a risk of ov #### Refer -- [Sum Balance Overflow](https://github.com/electisec/summa-solvency-diffie/issues/10) by [zeroqn](https://github.com/zeroqn) +- [Sum Balance Overflow](https://github.com/yAudit/summa-solvency-diffie/issues/10) by [zeroqn](https://github.com/zeroqn) ## 3. High: Inconsistency in range checks @@ -271,7 +271,7 @@ Root's max balance is `(NLEVEL - 1) * m` as can be inferred from circuits/contra #### Refer -- [Inconsistency in range checks](https://github.com/electisec/summa-solvency-Turing/issues/14) by [y5yash](https://github.com/Y5Yash) +- [Inconsistency in range checks](https://github.com/yAudit/summa-solvency-Turing/issues/14) by [y5yash](https://github.com/Y5Yash) ## Low @@ -298,7 +298,7 @@ In the code [here](https://github.com/summa-dev/summa-solvency/blob/master/zk_pr #### Refer -- [Mixed endian usage in code](https://github.com/electisec/summa-solvency-diffie/issues/17) by [parsely](https://github.com/bbresearcher) +- [Mixed endian usage in code](https://github.com/yAudit/summa-solvency-diffie/issues/17) by [parsely](https://github.com/bbresearcher) ## Informational @@ -308,7 +308,7 @@ The [range check](https://github.com/summa-dev/summa-solvency/blob/52373464b7ac4 #### Refer -- [Range check uses lookup_any instead of lookup](https://github.com/electisec/summa-solvency-schneier/issues/18) By [obatirou](https://github.com/obatirou) +- [Range check uses lookup_any instead of lookup](https://github.com/yAudit/summa-solvency-schneier/issues/18) By [obatirou](https://github.com/obatirou) ## 2. Informational: `InclusionVerifier.yul`not generated @@ -318,35 +318,35 @@ It is mentioned in the Summa Book on the [summa-solvency page](https://summa.git #### Refer -- [`InclusionVerifier.yul`not generated](https://github.com/electisec/summa-solvency-schneier/issues/16) by [flyingnobita](https://github.com/flyingnobita) +- [`InclusionVerifier.yul`not generated](https://github.com/yAudit/summa-solvency-schneier/issues/16) by [flyingnobita](https://github.com/flyingnobita) ## 3. Informational: Improvement to public inputs in contract -The [`publicInputs`](https://github.com/electisec/summa-solvency/blob/95d63fe1a55935542810138aa5d8de7f50f4e94b/contracts/src/Summa.sol#L193) input to the contract is taken as an array. But its not a homogenous array. The expected [public inputs](https://summa.gitbook.io/summa-book/circuits/merkle-sum-tree-inclusion#public-inputs-outputs) are: user leaf hash, MST root followed by root balances: [Refer #L188-L197](https://github.com/electisec/summa-solvency/blob/95d63fe1a55935542810138aa5d8de7f50f4e94b/contracts/src/Summa.sol#L188-L197) +The [`publicInputs`](https://github.com/yAudit/summa-solvency/blob/95d63fe1a55935542810138aa5d8de7f50f4e94b/contracts/src/Summa.sol#L193) input to the contract is taken as an array. But its not a homogenous array. The expected [public inputs](https://summa.gitbook.io/summa-book/circuits/merkle-sum-tree-inclusion#public-inputs-outputs) are: user leaf hash, MST root followed by root balances: [Refer #L188-L197](https://github.com/yAudit/summa-solvency/blob/95d63fe1a55935542810138aa5d8de7f50f4e94b/contracts/src/Summa.sol#L188-L197) Since they are not homogenous or not values that have the same meaning, it might be better DX/UX to have them as separate meaningful inputs and combine them into an array within the function before submitting them to the verifier. #### Refer -- [Improvement to public inputs in contract](https://github.com/electisec/summa-solvency-schneier/issues/12) By [sebastiantf](https://github.com/sebastiantf) +- [Improvement to public inputs in contract](https://github.com/yAudit/summa-solvency-schneier/issues/12) By [sebastiantf](https://github.com/sebastiantf) ## 4. Informational: Use only mapping for `addressOwnershipProofs` -Currently both the array [`addressOwnershipProofs`](https://github.com/electisec/summa-solvency/blob/95d63fe1a55935542810138aa5d8de7f50f4e94b/contracts/src/Summa.sol#L68) and the mapping [`_ownershipProofByAddress`](https://github.com/electisec/summa-solvency/blob/95d63fe1a55935542810138aa5d8de7f50f4e94b/contracts/src/Summa.sol#L83C41-L83C65) are being used to track address ownership proofs. But the use of both seems unnecessary, inefficient and error-prone. Storing address proofs on chain when the rounds become much more frequent would be highly inefficient. +Currently both the array [`addressOwnershipProofs`](https://github.com/yAudit/summa-solvency/blob/95d63fe1a55935542810138aa5d8de7f50f4e94b/contracts/src/Summa.sol#L68) and the mapping [`_ownershipProofByAddress`](https://github.com/yAudit/summa-solvency/blob/95d63fe1a55935542810138aa5d8de7f50f4e94b/contracts/src/Summa.sol#L83C41-L83C65) are being used to track address ownership proofs. But the use of both seems unnecessary, inefficient and error-prone. Storing address proofs on chain when the rounds become much more frequent would be highly inefficient. We recommend removing the array, modifying the mapping to store the `AddressOwnershipProof` struct as an efficient and simpler alternative. #### Refer -- [Use only mapping for `addressOwnershipProofs`](https://github.com/electisec/summa-solvency-schneier/issues/11) by [sebastiantf](https://github.com/sebastiantf) +- [Use only mapping for `addressOwnershipProofs`](https://github.com/yAudit/summa-solvency-schneier/issues/11) by [sebastiantf](https://github.com/sebastiantf) ## 5. Informational: `Summa.sol` : Improvements to generating the `addressHash` -The hash calculation of the `cexAddress` at [Summa.sol#L117](https://github.com/electisec/summa-solvency-schneier/blob/95d63fe1a55935542810138aa5d8de7f50f4e94b/contracts/src/Summa.sol#L117) does not take into consideration the chain of the address. Considering a multi chain architecture, using at least two distinct identifiers for generating the hash enhances security and prevents potential collisions or misuse. +The hash calculation of the `cexAddress` at [Summa.sol#L117](https://github.com/yAudit/summa-solvency-schneier/blob/95d63fe1a55935542810138aa5d8de7f50f4e94b/contracts/src/Summa.sol#L117) does not take into consideration the chain of the address. Considering a multi chain architecture, using at least two distinct identifiers for generating the hash enhances security and prevents potential collisions or misuse. #### Refer -- [`Summa.sol` : Issue with `submitProofOfAddressOwnership()`](https://github.com/electisec/summa-solvency-schneier/issues/7) by [zzzuhaibmohd](https://github.com/zzzuhaibmohd) +- [`Summa.sol` : Issue with `submitProofOfAddressOwnership()`](https://github.com/yAudit/summa-solvency-schneier/issues/7) by [zzzuhaibmohd](https://github.com/zzzuhaibmohd) ## 6. Informational: `Summa.sol` : Ownable: Does not implement 2-Step Process for transferring ownership @@ -357,18 +357,18 @@ While the probability of this happening is highly unlikely, we recommend followi #### Refer -- [`Summa.sol` : Ownable: Does not implement 2-Step-Process for transferring ownership](https://github.com/electisec/summa-solvency-schneier/issues/6) by [zzzuhaibmohd](https://github.com/zzzuhaibmohd) +- [`Summa.sol` : Ownable: Does not implement 2-Step-Process for transferring ownership](https://github.com/yAudit/summa-solvency-schneier/issues/6) by [zzzuhaibmohd](https://github.com/zzzuhaibmohd) ## 7. Informational: Summa.sol : Potential `Summa::submitCommitment()` Gas limits -[`Summa::submitCommitment()`](https://github.com/electisec/summa-solvency/blob/main/contracts/src/Summa.sol#L144) takes in two arrays and loops once over them. [`rootBalances`](https://github.com/electisec/summa-solvency-schneier/blob/95d63fe1a55935542810138aa5d8de7f50f4e94b/contracts/src/Summa.sol#L146-L147) array contains the root balances of each cryptocurrency. [`cryptocurrencies`](https://github.com/electisec/summa-solvency/blob/95d63fe1a55935542810138aa5d8de7f50f4e94b/contracts/src/Summa.sol#L159-L171) array contains details of each cryptocurrency: `name`, `chain`. There could be practical limitations to the number of `rootBalances` and `cryptocurrencies` that could be submitted in a single txn, imposed by block gas limits +[`Summa::submitCommitment()`](https://github.com/yAudit/summa-solvency/blob/main/contracts/src/Summa.sol#L144) takes in two arrays and loops once over them. [`rootBalances`](https://github.com/yAudit/summa-solvency-schneier/blob/95d63fe1a55935542810138aa5d8de7f50f4e94b/contracts/src/Summa.sol#L146-L147) array contains the root balances of each cryptocurrency. [`cryptocurrencies`](https://github.com/yAudit/summa-solvency/blob/95d63fe1a55935542810138aa5d8de7f50f4e94b/contracts/src/Summa.sol#L159-L171) array contains details of each cryptocurrency: `name`, `chain`. There could be practical limitations to the number of `rootBalances` and `cryptocurrencies` that could be submitted in a single txn, imposed by block gas limits -According to [Coingecko](https://www.coingecko.com/en/exchanges/binance), Binance hosts 376 cryptocurrencies. After a stress test in [PR#5](https://github.com/electisec/summa-solvency-schneier/pull/5), it is known that 402 is the maximum number of cryptocurrencies before overflowing 30M block gas limit. To compute proof of solvency for the entire state of the exchange at a given time, it might be necessary to split the submission into multiple commitments for the same `timestamp`. +According to [Coingecko](https://www.coingecko.com/en/exchanges/binance), Binance hosts 376 cryptocurrencies. After a stress test in [PR#5](https://github.com/yAudit/summa-solvency-schneier/pull/5), it is known that 402 is the maximum number of cryptocurrencies before overflowing 30M block gas limit. To compute proof of solvency for the entire state of the exchange at a given time, it might be necessary to split the submission into multiple commitments for the same `timestamp`. #### Refer -- [Potential `Summa::submitCommitment()` Gas limits](https://github.com/electisec/summa-solvency-schneier/issues/4) by [sebastiantf](https://github.com/sebastiantf) -- [test: submitting large no. of cryptocurrencies in single commitment](https://github.com/electisec/summa-solvency-schneier/pull/5) by [sebastiantf](https://github.com/sebastiantf) +- [Potential `Summa::submitCommitment()` Gas limits](https://github.com/yAudit/summa-solvency-schneier/issues/4) by [sebastiantf](https://github.com/sebastiantf) +- [test: submitting large no. of cryptocurrencies in single commitment](https://github.com/yAudit/summa-solvency-schneier/pull/5) by [sebastiantf](https://github.com/sebastiantf) ## 8. Informational: Use constants to denote magic numbers in PoseidonChip @@ -383,7 +383,7 @@ The [Poseidon chip](https://github.com/summa-dev/summa-solvency/blob/master/zk_p #### Refer -- [Magic numbers used in code of MST Circuit to create PoseidonChip](https://github.com/electisec/summa-solvency-diffie/issues/15) by [parsely](https://github.com/bbresearcher) +- [Magic numbers used in code of MST Circuit to create PoseidonChip](https://github.com/yAudit/summa-solvency-diffie/issues/15) by [parsely](https://github.com/bbresearcher) ## 9. Informational: Missing validation for `timestamp`, `mstLevels` and `currenciesCount` @@ -428,7 +428,7 @@ Likewise we would also need the following checks : #### Refer -- [Review of the `Summa.sol` smart contract](https://github.com/electisec/summa-solvency-diffie/issues/12) by [hrishibhat](https://github.com/hrishibhat) +- [Review of the `Summa.sol` smart contract](https://github.com/yAudit/summa-solvency-diffie/issues/12) by [hrishibhat](https://github.com/hrishibhat) # Final remarks @@ -437,7 +437,7 @@ Likewise we would also need the following checks : - The Merkle Sum Tree is a cryptographic structure which inherits the security properties of the Poseidon hash function - Social engineering attacks are still a valid way to break the system. The custodian could omit a section of users who do not verify their inclusion proofs. - The library used for trusted setup - [halo2-kzg-srs](https://github.com/han0110/halo2-kzg-srs) is unaudited & it's contents are unreliable as there is no checksum available to validate its contents -- Overall, the code demonstrates good implementation of mathematical operations and basic functionality. However, it could benefit from more extensive documentation, testing and additional tools such as [polyexen](https://github.com/electisec/summa-solvency-diffie/pull/5) to view cell data. +- Overall, the code demonstrates good implementation of mathematical operations and basic functionality. However, it could benefit from more extensive documentation, testing and additional tools such as [polyexen](https://github.com/yAudit/summa-solvency-diffie/pull/5) to view cell data. # Appendix @@ -516,7 +516,7 @@ Out of the `3566` unconstrained cells found, these are the common weaknesses poi - `unconstrained cell in "permute state"` is a false positive which arises from the `permute state` region of the Poseidon Chip. -Here’s the complete [report](https://github.com/electisec/summa-audit-report/blob/main/appendix/V1/Halo2-Analyzer/output.md). +Here’s the complete [report](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V1/Halo2-Analyzer/output.md). ### 2. Polyexen-demo @@ -530,30 +530,30 @@ Polyexen (Polynomial Expression Engine) transforms circuits designed with the Ha We used polyexen-demo to debug the assignments & double check the constraints. Here’s the output : -- Fixed Columns - [CSV](https://github.com/electisec/summa-audit-report/blob/main/appendix/V1/Polyexen/mst_fixed.csv) -- Lookup constraints - [mst_lookups.toml](https://github.com/electisec/summa-audit-report/blob/main/appendix/V1/Polyexen/mst_lookups.toml) -- Gate constraints - [mst_polys.toml](https://github.com/electisec/summa-audit-report/blob/main/appendix/V1/Polyexen/mst_polys.toml) -- Copy constraints - [mst.toml](https://github.com/electisec/summa-audit-report/blob/main/appendix/V1/Polyexen/mst.toml) +- Fixed Columns - [CSV](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V1/Polyexen/mst_fixed.csv) +- Lookup constraints - [mst_lookups.toml](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V1/Polyexen/mst_lookups.toml) +- Gate constraints - [mst_polys.toml](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V1/Polyexen/mst_polys.toml) +- Copy constraints - [mst.toml](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V1/Polyexen/mst.toml) ### 3. NPM Audit -`npm audit` scans your project's dependencies for known security vulnerabilities, reports them with severity levels, and suggests fixes. It helps keep your Node.js application secure by identifying and addressing potential risks in your packages. View the complete report of security vulnerabilities in the `contracts` package [here](https://github.com/electisec/summa-audit-report/blob/main/appendix/V1/npm-audit/output.md) +`npm audit` scans your project's dependencies for known security vulnerabilities, reports them with severity levels, and suggests fixes. It helps keep your Node.js application secure by identifying and addressing potential risks in your packages. View the complete report of security vulnerabilities in the `contracts` package [here](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V1/npm-audit/output.md) ### 4. Cargo Audit -`cargo audit` scans your Rust project's dependencies for known security vulnerabilities, reports them with severity levels, and suggests fixes. It helps keep your Rust application secure by identifying and addressing potential risks in your crates. View the complete report of security vulnerabilities in `zk-prover` and `backend` [here](https://github.com/electisec/summa-audit-report/blob/main/appendix/V1/cargo-audit/output.md). +`cargo audit` scans your Rust project's dependencies for known security vulnerabilities, reports them with severity levels, and suggests fixes. It helps keep your Rust application secure by identifying and addressing potential risks in your crates. View the complete report of security vulnerabilities in `zk-prover` and `backend` [here](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V1/cargo-audit/output.md). ### 5. Clippy -`clippy` is a linter for Rust that checks your code for common mistakes and style issues. It provides helpful suggestions to improve your code quality and maintainability. Using `clippy` helps ensure your Rust code is clean, efficient, and follows best practices. Here's the [report](https://github.com/electisec/summa-audit-report/blob/main/appendix/V1/clippy/output.md). +`clippy` is a linter for Rust that checks your code for common mistakes and style issues. It provides helpful suggestions to improve your code quality and maintainability. Using `clippy` helps ensure your Rust code is clean, efficient, and follows best practices. Here's the [report](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V1/clippy/output.md). ## B - Fuzz Testing Fuzzing is a testing technique that tries to find bugs by repeatedly executing test cases and mutating them. Classically, it is used in C/C++ codebases to detect segmentation faults, buffer overflows, and other memory corruption vulnerabilities. In Rust, we can use it to find runtime errors. -We set up a fuzz test suite using `cargo fuzz` (which uses `libfuzzer-sys`) for Merkle Sum Tree implementation, Range check & it’s utilities. We initialized a basic fuzz suite in [PR#18](https://github.com/electisec/summa-solvency-diffie/pull/18) and in [PR#3](https://github.com/electisec/summa-solvency-Turing/pull/3) with a [Setup Tutorial](https://github.com/electisec/summa-solvency-Turing/pull/3/files#diff-f91a5e0dcdf679d481a8eaf944ca24572fe682b1ca746dd39136b612c8dcaa55). Furthermore, fuzz tests for `merkle_sum_tree`, `utils`, `csv_parser` were included in [PR#6](https://github.com/electisec/summa-solvency-diffie/pull/6). +We set up a fuzz test suite using `cargo fuzz` (which uses `libfuzzer-sys`) for Merkle Sum Tree implementation, Range check & it’s utilities. We initialized a basic fuzz suite in [PR#18](https://github.com/yAudit/summa-solvency-diffie/pull/18) and in [PR#3](https://github.com/yAudit/summa-solvency-Turing/pull/3) with a [Setup Tutorial](https://github.com/yAudit/summa-solvency-Turing/pull/3/files#diff-f91a5e0dcdf679d481a8eaf944ca24572fe682b1ca746dd39136b612c8dcaa55). Furthermore, fuzz tests for `merkle_sum_tree`, `utils`, `csv_parser` were included in [PR#6](https://github.com/yAudit/summa-solvency-diffie/pull/6). -Upon fuzzing the `utils` in [PR#6](https://github.com/electisec/summa-solvency-diffie/pull/6/files#diff-9412e8e264746a8c097d218a1de08b4db7b899a6479e16486fced43f653cfee2), there seems to be a little discrepency in the bytes to Fp conversion cycle. An assertion fails when comparing an empty string's bytes ([]) to the result of converting that empty string to a `BigUint` and then back to bytes, which results in [0]. This happens because converting an empty string to a `BigUint` using `BigUint::from(0u8)` creates a `BigUint` representing 0, which converts back to [0] instead of an empty array. To fix this, we need to ensure that converting an empty string to a `BigUint` and back maintains consistency with the original input. +Upon fuzzing the `utils` in [PR#6](https://github.com/yAudit/summa-solvency-diffie/pull/6/files#diff-9412e8e264746a8c097d218a1de08b4db7b899a6479e16486fced43f653cfee2), there seems to be a little discrepency in the bytes to Fp conversion cycle. An assertion fails when comparing an empty string's bytes ([]) to the result of converting that empty string to a `BigUint` and then back to bytes, which results in [0]. This happens because converting an empty string to a `BigUint` using `BigUint::from(0u8)` creates a `BigUint` representing 0, which converts back to [0] instead of an empty array. To fix this, we need to ensure that converting an empty string to a `BigUint` and back maintains consistency with the original input. ## C - Code Coverage @@ -563,7 +563,7 @@ We used [cargo-llvm-cov](https://github.com/taiki-e/cargo-llvm-cov) to generate We raised the following pull requests to increase code coverage & emphasize testing. -- [PR#3](https://github.com/electisec/summa-solvency-diffie/pull/3) to increase code coverage for `merkle_sum_tree` -- [PR#17](https://github.com/electisec/summa-solvency-schneier/pull/17) to add end-to-end testing with full prover and verifier (instead of mock prover). -- [PR#8](https://github.com/electisec/summa-solvency-schneier/pull/8/files) to include cost estimation for circuits using `CircuitCost` -- [PR#5](https://github.com/electisec/summa-solvency-schneier/pull/5) is a stress test to determine the potential gas limits of `Summa::submitCommitment()` +- [PR#3](https://github.com/yAudit/summa-solvency-diffie/pull/3) to increase code coverage for `merkle_sum_tree` +- [PR#17](https://github.com/yAudit/summa-solvency-schneier/pull/17) to add end-to-end testing with full prover and verifier (instead of mock prover). +- [PR#8](https://github.com/yAudit/summa-solvency-schneier/pull/8/files) to include cost estimation for circuits using `CircuitCost` +- [PR#5](https://github.com/yAudit/summa-solvency-schneier/pull/5) is a stress test to determine the potential gas limits of `Summa::submitCommitment()` diff --git a/content/2024-05-Summa-Vb.md b/content/2024-05-Summa-Vb.md index ed2a116..070ff0b 100644 --- a/content/2024-05-Summa-Vb.md +++ b/content/2024-05-Summa-Vb.md @@ -1,12 +1,12 @@ --- tags: ["zk", "halo2", "solidity"] title: 2024-05-Summa-Vb -description: Summa Vb Electisec Report +description: Summa Vb yAudit Report nav_order: 16 image: assets/images/logo.png --- -# Electisec Summa Review - KZG-based Protocol +# yAudit Summa Review - KZG-based Protocol Auditors: @@ -164,7 +164,7 @@ After the findings were presented to the Summa team, fixes were made and include This code review is for identifying potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged parties could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent or imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Summa Solvency and users of the contracts/circuits agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent or imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Summa Solvency and users of the contracts/circuits agree to use the code at their own risk. ## Code Evaluation Matrix @@ -528,7 +528,7 @@ unconstrained cell in "Perform range check on balance 0 of user 1" region: Colum unconstrained cell in "Perform range check on balance 0 of user 1" region: Column { index: 5, column_type: Advice } (rotation: 0) -- very likely a bug. ``` -Here's the complete [report](https://github.com/electisec/summa-audit-report/blob/main/appendix/V2/Halo2-analyzer/output.md) +Here's the complete [report](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V2/Halo2-analyzer/output.md) ### 2. Polyexen-demo @@ -542,28 +542,28 @@ Polyexen (Polynomial Expression Engine) transforms circuits designed with the Ha We used polyexen-demo to debug the assignments & double check the constraints. Here’s the output : -- Fixed Columns - [CSV](https://github.com/electisec/summa-audit-report/blob/main/appendix/V2/Polyexen/ugc_fixed.csv) -- Lookup constraints - [ugc_lookups.toml](https://github.com/electisec/summa-audit-report/blob/main/appendix/V2/Polyexen/ugc_lookups.toml) -- Gate constraints - [ugc_polys.toml](https://github.com/electisec/summa-audit-report/blob/main/appendix/V2/Polyexen/ugc_polys.toml) -- Copy constraints - [ugc.toml](https://github.com/electisec/summa-audit-report/blob/main/appendix/V2/Polyexen/ugc.toml) +- Fixed Columns - [CSV](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V2/Polyexen/ugc_fixed.csv) +- Lookup constraints - [ugc_lookups.toml](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V2/Polyexen/ugc_lookups.toml) +- Gate constraints - [ugc_polys.toml](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V2/Polyexen/ugc_polys.toml) +- Copy constraints - [ugc.toml](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V2/Polyexen/ugc.toml) ### 3. Highlighter Highlighter is a python script which runs against a HALO2 (or Rust) project and will highlight any code that may need to be checked a bit closer -Highlighter works on a set of rules to look for error prone areas such as incorrect endianness, improper use of `unwrap`, finding `TODO` comments which might signify incomplete code, overflows & underflows. Here's the complete [report](https://github.com/electisec/summa-audit-report/blob/main/appendix/V2/Highlighter/output.md) of the findings by Highlighter. +Highlighter works on a set of rules to look for error prone areas such as incorrect endianness, improper use of `unwrap`, finding `TODO` comments which might signify incomplete code, overflows & underflows. Here's the complete [report](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V2/Highlighter/output.md) of the findings by Highlighter. ### 4. NPM Audit -`npm audit` scans your project's dependencies for known security vulnerabilities, reports them with severity levels, and suggests fixes. It helps keep your Node.js application secure by identifying and addressing potential risks in your packages. View the complete report of security vulnerabilities in the `contracts` package [here](https://github.com/electisec/summa-audit-report/blob/main/appendix/V2/npm-audit/output.md) +`npm audit` scans your project's dependencies for known security vulnerabilities, reports them with severity levels, and suggests fixes. It helps keep your Node.js application secure by identifying and addressing potential risks in your packages. View the complete report of security vulnerabilities in the `contracts` package [here](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V2/npm-audit/output.md) ### 5. Cargo Audit -`cargo audit` scans your Rust project's dependencies for known security vulnerabilities, reports them with severity levels, and suggests fixes. It helps keep your Rust application secure by identifying and addressing potential risks in your crates. View the complete report of security vulnerabilities in `prover` and `backend` [here](https://github.com/electisec/summa-audit-report/blob/main/appendix/V2/cargo-audit/output.md). +`cargo audit` scans your Rust project's dependencies for known security vulnerabilities, reports them with severity levels, and suggests fixes. It helps keep your Rust application secure by identifying and addressing potential risks in your crates. View the complete report of security vulnerabilities in `prover` and `backend` [here](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V2/cargo-audit/output.md). ### 6. Clippy -`clippy` is a linter for Rust that checks your code for common mistakes and style issues. It provides helpful suggestions to improve your code quality and maintainability. Using `clippy` helps ensure your Rust code is clean, efficient, and follows best practices. Here's the [report](https://github.com/electisec/summa-audit-report/blob/main/appendix/V2/clippy/output.md). +`clippy` is a linter for Rust that checks your code for common mistakes and style issues. It provides helpful suggestions to improve your code quality and maintainability. Using `clippy` helps ensure your Rust code is clean, efficient, and follows best practices. Here's the [report](https://github.com/yAudit/summa-audit-report/blob/main/appendix/V2/clippy/output.md). ## B - Fuzz Testing diff --git a/content/2024-05-Yearn-STB-yAudit-report.md b/content/2024-05-Yearn-STB-yAudit-report.md index 40db83f..9edeba2 100644 --- a/content/2024-05-Yearn-STB-yAudit-report.md +++ b/content/2024-05-Yearn-STB-yAudit-report.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2022-05-Yearn-STB -description: Yearn STB Electisec Report +description: Yearn STB yAudit Report nav_order: 7 image: assets/images/logo.png --- -# Electisec Yearn - STB Review +# yAudit Yearn - STB Review **Review Resources:** @@ -44,7 +44,7 @@ After the findings were presented to the Yearn - STB team, fixes were made and i This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Yearn - STB and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Yearn - STB and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-06-Asymmetry-veASF.md b/content/2024-06-Asymmetry-veASF.md index 813c7d1..4b92d68 100644 --- a/content/2024-06-Asymmetry-veASF.md +++ b/content/2024-06-Asymmetry-veASF.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-05-Asymmetry -description: Electisec Asymmetry veASF Review +description: yAudit Asymmetry veASF Review nav_order: 6 image: assets/images/logo.png --- -# Electisec Asymmetry veASF Review +# yAudit Asymmetry veASF Review **Review Resources:** @@ -50,7 +50,7 @@ After the findings were presented to the asymmetry team, fixes were made and inc This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, asymmetry veASF and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, asymmetry veASF and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-06-Multiplier-Technologies-Recheck.md b/content/2024-06-Multiplier-Technologies-Recheck.md index ffe126c..d5ddad7 100644 --- a/content/2024-06-Multiplier-Technologies-Recheck.md +++ b/content/2024-06-Multiplier-Technologies-Recheck.md @@ -1,16 +1,16 @@ --- tags: ["solidity"] title: 2024-06-Multiplier-Technologies-Recheck -description: Multiplier Technologies Lending Base Layer Recheck Electisec report +description: Multiplier Technologies Lending Base Layer Recheck yAudit report nav_order: 63 image: assets/images/logo.png --- -# Electisec Multiplier Technologies Lending Base Layer Recheck Review +# yAudit Multiplier Technologies Lending Base Layer Recheck Review **Review Resources:** -- Previous Multiplier Technologies audit report by Electisec +- Previous Multiplier Technologies audit report by yAudit - Internal design docs were shared **Auditors:** @@ -69,7 +69,7 @@ After the findings were presented to the Multiplier Technologies team, fixes wer This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Multiplier Technologies and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Multiplier Technologies and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -829,7 +829,7 @@ Acknowledged. We believe that our chosen trust assumptions strike a reasonable b ## Final Remarks -The mitigations introduced in response to the findings in the first Electisec audit report fixed nearly all of the original issues identified. Only a few remaining items need to be modified slightly. Some larger refactoring changes were made, such as using transient storage and removing the adapter design entirely. Still, these changes have been made properly without adding notable new issues. +The mitigations introduced in response to the findings in the first yAudit audit report fixed nearly all of the original issues identified. Only a few remaining items need to be modified slightly. Some larger refactoring changes were made, such as using transient storage and removing the adapter design entirely. Still, these changes have been made properly without adding notable new issues. The MT Lending Base Layer code does meet the requirements outlined in the whitepaper provided by the development team, which was one of the primary goals of this audit. diff --git a/content/2024-06-Origami-Oracles-Adapters-yAudit-Report.md b/content/2024-06-Origami-Oracles-Adapters-yAudit-Report.md index c293538..0f9bf19 100644 --- a/content/2024-06-Origami-Oracles-Adapters-yAudit-Report.md +++ b/content/2024-06-Origami-Oracles-Adapters-yAudit-Report.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 6-2024-Origami-Oracles-Adapters -description: Origami Oracles Adapters Electisec Report +description: Origami Oracles Adapters yAudit Report nav_order: 71 image: assets/images/logo.png --- -# Electisec Origami oracles adapters Review +# yAudit Origami oracles adapters Review **Review Resources:** @@ -45,7 +45,7 @@ src/exchange-rate-adapters/ This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Origami oracles adapters and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Origami oracles adapters and users of the contracts agree to use the code at their own risk. ## Oracle analysis diff --git a/content/2024-06-Sickle-4.md b/content/2024-06-Sickle-4.md index 4c5d452..ceed07a 100644 --- a/content/2024-06-Sickle-4.md +++ b/content/2024-06-Sickle-4.md @@ -1,10 +1,10 @@ --- tags: ["solidity"] title: 2024-06-Sickle-4 -description: Sickle-4 Electisec report +description: Sickle-4 yAudit report --- -# Electisec Sickle Review +# yAudit Sickle Review **Review Resources:** @@ -18,7 +18,7 @@ description: Sickle-4 Electisec report ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -53,22 +53,21 @@ After the findings were presented to the Vfat team, fixes were made and included This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Sickle and users of the contracts agree to use the code at their own risk. - +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Sickle and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | One of the challenges in attacking the Sickle protocol is that the Sickles are partitioned by user, and only whitelisted strategies can multi-call into the Sickles. These whitelisted strategies can only interact with whitelisted connectors. However, one bug was related to missing multi-sig threshold logic. | -| Mathematics | Good | There are very few complex mathematical operations in the code reviewed. | -| Complexity | Medium | There is complexity around the flow of funds between the user, their Sickle, the flashloan provider, and the DeFi protocol that the Sickle interacts with. | -| Libraries | Average | Well-known libraries such as OpenZeppelin and Solmate are used. The team did write their own multi-sig rather than using an established multi-sig. This was done because established multisigs are not deployed on networks of interest to the Vfat team. | -| Decentralization | Good | A multi-sig was introduced to decentralize certain actions taken by the protocol. | -| Code stability | Good | Changes were made to the code base during the review but not to the contracts in scope. | -| Documentation | Low | No documentation was provided for the in-scope contracts. However, many of the functions in the contracts in scope contained NatSpec. | -| Monitoring | Low | Few of the functions in the contracts in scope contain events. | -| Testing and verification | Average | The contracts in scope range from 40% to 100% test coverage. | +| Category | Mark | Description | +| ------------------------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Access Control | Good | One of the challenges in attacking the Sickle protocol is that the Sickles are partitioned by user, and only whitelisted strategies can multi-call into the Sickles. These whitelisted strategies can only interact with whitelisted connectors. However, one bug was related to missing multi-sig threshold logic. | +| Mathematics | Good | There are very few complex mathematical operations in the code reviewed. | +| Complexity | Medium | There is complexity around the flow of funds between the user, their Sickle, the flashloan provider, and the DeFi protocol that the Sickle interacts with. | +| Libraries | Average | Well-known libraries such as OpenZeppelin and Solmate are used. The team did write their own multi-sig rather than using an established multi-sig. This was done because established multisigs are not deployed on networks of interest to the Vfat team. | +| Decentralization | Good | A multi-sig was introduced to decentralize certain actions taken by the protocol. | +| Code stability | Good | Changes were made to the code base during the review but not to the contracts in scope. | +| Documentation | Low | No documentation was provided for the in-scope contracts. However, many of the functions in the contracts in scope contained NatSpec. | +| Monitoring | Low | Few of the functions in the contracts in scope contain events. | +| Testing and verification | Average | The contracts in scope range from 40% to 100% test coverage. | ## Findings Explanation @@ -93,11 +92,11 @@ None. #### Technical Details -The `SickleMultisig` has a `threshold` state variable, which ensures the correct number of signers have signed a proposal before it can be executed. However, this state variable is unused throughout the contract, particularly when executing a transaction. +The `SickleMultisig` has a `threshold` state variable, which ensures the correct number of signers have signed a proposal before it can be executed. However, this state variable is unused throughout the contract, particularly when executing a transaction. #### Impact -High. A transaction can be executed without the required number of signatures. +High. A transaction can be executed without the required number of signatures. #### Recommendation @@ -207,6 +206,7 @@ Low. While multiple tokens can be passed to the strategy call, the Morpho provid #### Recommendation Add a check for the Morpho provider statement: + ```diff } else if (providerType == FlashloanProvider.MORPHO) { + if (assets.length != 1) revert NotSingleAsset(); @@ -265,7 +265,6 @@ e.g. cache the array length before the for loop and remove loop variable initial Fixed in https://github.com/vfat-io/sickle-contracts/pull/249 - ### 2. Gas - Simplify redundant logic in `callbackSafetyCheck()` There is redundancy in the logic of `callbackSafetyCheck()`. @@ -280,7 +279,7 @@ Gas savings. #### Recommendation -Remove the redundant check: +Remove the redundant check: ```diff modifier callbackSafetyCheck(bytes memory params) { @@ -363,7 +362,8 @@ Gas savings. #### Recommendation -Remove the `if (result.length == 0) revert();` checks in: +Remove the `if (result.length == 0) revert();` checks in: + - [`_call()`](https://github.com/vfat-io/sickle-contracts/blob/72c8dcc06a71e816ff8a08ced4413b3ffce94421/contracts/governance/SickleMultisig.sol#L299) - [`_delegateTo()`](https://github.com/vfat-io/sickle-contracts/blob/72c8dcc06a71e816ff8a08ced4413b3ffce94421/contracts/strategies/modules/DelegateModule.sol#L12) - [`multicall()`](https://github.com/vfat-io/sickle-contracts/blob/72c8dcc06a71e816ff8a08ced4413b3ffce94421/contracts/base/NonDelegateMulticall.sol#L70) @@ -379,8 +379,8 @@ Partially fixed in https://github.com/vfat-io/sickle-contracts/pull/244/files #### Technical Details -* `ZapModule` in LendingStructs.sol is unused. -* `IERC20` and `SafeTransferLib` in FlashloanInitiator are unused. +- `ZapModule` in LendingStructs.sol is unused. +- `IERC20` and `SafeTransferLib` in FlashloanInitiator are unused. #### Impact @@ -469,4 +469,4 @@ Fixed in https://github.com/vfat-io/sickle-contracts/pull/246 ## Final Remarks -The new flashloan strategies that interact with the Sickles had few major bugs found due to the secure nature of the Sickle architecture. The major bugs that were found were in the new multi-sig contract, which does not interact with the Sickle architecture. +The new flashloan strategies that interact with the Sickles had few major bugs found due to the secure nature of the Sickle architecture. The major bugs that were found were in the new multi-sig contract, which does not interact with the Sickle architecture. diff --git a/content/2024-08-Euler-Yield-Aggregator.md b/content/2024-08-Euler-Yield-Aggregator.md index 2f7f9cb..8faa9de 100644 --- a/content/2024-08-Euler-Yield-Aggregator.md +++ b/content/2024-08-Euler-Yield-Aggregator.md @@ -19,7 +19,7 @@ description: Euler Yield Aggregator Report ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -27,7 +27,7 @@ description: Euler Yield Aggregator Report The Yield Aggregator is an open-source protocol for permissionless risk curation on top of [ERC4626 vaults](https://eips.ethereum.org/EIPS/eip-4626)(strategies). Although it is initially designed to be integrated with [Euler V2 vaults](https://github.com/euler-xyz/euler-vault-kit), technically, it supports any other vault as long as it is ERC4626 compliant. -The Yield Aggregator is an ERC4626 vault; any risk curator can deploy one through the factory. Each vault has one loan asset and can allocate deposits to multiple strategies. The aggregator vaults are noncustodial and immutable instances that offer users an easy way to provide liquidity and passively earn yield. +The Yield Aggregator is an ERC4626 vault; any risk curator can deploy one through the factory. Each vault has one loan asset and can allocate deposits to multiple strategies. The aggregator vaults are noncustodial and immutable instances that offer users an easy way to provide liquidity and passively earn yield. The contracts of the Yield Aggregator [repository](https://github.com/euler-xyz/yield-aggregator) were reviewed over eight days. Two auditors performed the code review between August 26th and September 4th, 2024. The repository was under active development during the review, but the review was limited to the latest commit at the start. This was commit [a00602c3429cdddaa1cbfe3c741705823cd2923e](https://github.com/euler-xyz/yield-aggregator/commit/a00602c3429cdddaa1cbfe3c741705823cd2923e) for the Yield Aggregator repository. @@ -66,22 +66,21 @@ After the findings were presented to the Euler team, fixes were made and include This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Euler and users of the contracts agree to use the code at their own risk. - +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Euler and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | Proper access control is enforced using roles (RBAC). | -| Mathematics | Good | The implementation doesn't involve complex math operations. | +| Category | Mark | Description | +| ------------------------ | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Access Control | Good | Proper access control is enforced using roles (RBAC). | +| Mathematics | Good | The implementation doesn't involve complex math operations. | | Complexity | Average | We identified several issues stemming from the logic in the harvest and rebalance functions, which could impact general accounting and adherence to the ERC-4626 standard. | -| Libraries | Good | The protocol uses an up-to-date version of the OpenZeppelin library. | -| Decentralization | Average | Centralized functionalities are limited to the vault and strategies configuration. Wrong configuration could affect user's safety. | -| Code stability | Good | The codebase remained stable during the review. | -| Documentation | Good | The contracts are documented using NatSpec. Additional resources include the whitepaper and a specification document. | -| Monitoring | Good | Multiple events are emitted through the protocol life-cycle. | -| Testing and verification | Good | The codebase has an extensive testing suite, including unit, integration, fuzz, and invariant tests. | +| Libraries | Good | The protocol uses an up-to-date version of the OpenZeppelin library. | +| Decentralization | Average | Centralized functionalities are limited to the vault and strategies configuration. Wrong configuration could affect user's safety. | +| Code stability | Good | The codebase remained stable during the review. | +| Documentation | Good | The contracts are documented using NatSpec. Additional resources include the whitepaper and a specification document. | +| Monitoring | Good | Multiple events are emitted through the protocol life-cycle. | +| Testing and verification | Good | The codebase has an extensive testing suite, including unit, integration, fuzz, and invariant tests. | ## Findings Explanation @@ -215,7 +214,6 @@ Low. The `maxWithdraw()` and `maxRedeem()` functions could potentially return an Consider applying the same logic used in the `withdraw()` and `redeem()` functions to the `maxWithdraw()` and `maxRedeem()` implementations to ensure consistency with the expected withdrawal behavior. Alternatively, ensure this is properly documented as it deviates from the expected standard behavior. - #### Developer Response Fixed in [https://github.com/euler-xyz/yield-aggregator/pull/62](https://github.com/euler-xyz/yield-aggregator/pull/62). @@ -359,7 +357,7 @@ Given that the YieldAggregatorVault.sol contract overrides the `deposit()` and ` ```solidity 54: function deposit(uint256 _assets, address _receiver) public virtual override nonReentrant returns (uint256) { 55: _callHooksTarget(Constants.DEPOSIT, _msgSender()); -56: +56: 57: uint256 maxAssets = _maxDeposit(); 58: if (_assets > maxAssets) { 59: revert Errors.ERC4626ExceededMaxDeposit(_receiver, _assets, maxAssets); @@ -371,7 +369,7 @@ Given that the YieldAggregatorVault.sol contract overrides the `deposit()` and ` ```solidity 72: function mint(uint256 _shares, address _receiver) public virtual override nonReentrant returns (uint256) { 73: _callHooksTarget(Constants.MINT, _msgSender()); -74: +74: 75: uint256 maxShares = _maxMint(); 76: if (_shares > maxShares) { 77: revert Errors.ERC4626ExceededMaxMint(_receiver, _shares, maxShares); @@ -458,7 +456,7 @@ Acknowledged. The `setPerformanceFee()` function can only be called by an addres The function [`adjustAllocationPoints()`](https://github.com/euler-xyz/yield-aggregator/blob/a00602c3429cdddaa1cbfe3c741705823cd2923e/src/module/Strategy.sol#L27-L27) allows to update the allocation points for a strategy. It can be called only by the `GUARDIAN` role. -The `STRATEGY_OPERATOR` is in charge of adding and removing strategies. By not being able to call `adjustAllocationPoints(),` he won't be able to correct allocation points for a strategy that was added with the wrong amount, or that needs to be updated. He also won't be able to remove a strategy, as it can only be removed if there are 0 funds allocated to it. +The `STRATEGY_OPERATOR` is in charge of adding and removing strategies. By not being able to call `adjustAllocationPoints(),` he won't be able to correct allocation points for a strategy that was added with the wrong amount, or that needs to be updated. He also won't be able to remove a strategy, as it can only be removed if there are 0 funds allocated to it. This limits the `STRATEGY_OPERATOR` role and will require the `GUARDIAN` for "safe" operations, which might not be ideal. @@ -472,7 +470,7 @@ Allow the `STRATEGY_OPERATOR` to call `adjustAllocationPoints()`. #### Developer Response -Acknowledged. The roles system is designed in a granular way to ensure maximum safety for the users and to decrease the chance of any rug-pull like scenario. +Acknowledged. The roles system is designed in a granular way to ensure maximum safety for the users and to decrease the chance of any rug-pull like scenario. For that reason, strategy allocation points update is left outside of the `STRATEGY_OPERATOR` privileges. @@ -545,15 +543,15 @@ When losses are deducted through [`_deductLoss()`](https://github.com/euler-xyz/ ```solidity 45: uint256 totalAssetsDepositedCache = $.totalAssetsDeposited; 46: uint256 totalNotDistributed = _totalAssetsAllocatable() - totalAssetsDepositedCache; -47: +47: 48: // set interestLeft to zero, will be updated to the right value during _gulp() 49: $.interestLeft = 0; 50: if (_lossAmount > totalNotDistributed) { 51: _lossAmount -= totalNotDistributed; -52: +52: 53: // socialize the loss 54: $.totalAssetsDeposited = totalAssetsDepositedCache - _lossAmount; -55: +55: 56: emit Events.DeductLoss(_lossAmount); 57: } ``` @@ -589,7 +587,7 @@ Call `_updateInterestAccrued()` when deactivating a strategy in `toggleStrategyE emit Events.ToggleStrategyEmergencyStatus(_strategy, true); } else { -``` +``` #### Developer Response diff --git a/content/2024-08-Goldilocks.md b/content/2024-08-Goldilocks.md index 0d2cc43..12359d4 100644 --- a/content/2024-08-Goldilocks.md +++ b/content/2024-08-Goldilocks.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-08-Goldilocks -description: Goldilocks Electisec report +description: Goldilocks yAudit report nav_order: 64 image: assets/images/logo.png --- -# Electisec Goldilocks Review +# yAudit Goldilocks Review **Review Resources:** @@ -65,7 +65,7 @@ After the findings were presented to the Goldilocks team, fixes were made and in This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Goldilocks and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Goldilocks and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-09-Euler-Hook-Target-Firewall.md b/content/2024-09-Euler-Hook-Target-Firewall.md index 9c8dda0..c3f3ae5 100644 --- a/content/2024-09-Euler-Hook-Target-Firewall.md +++ b/content/2024-09-Euler-Hook-Target-Firewall.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 9-2024-Euler-Hook-Target-Firewall -description: Euler Hook Target Firewall Electisec Report +description: Euler Hook Target Firewall yAudit Report nav_order: 71 image: assets/images/logo.png --- -# Electisec Euler Hook Target Firewall Review +# yAudit Euler Hook Target Firewall Review **Review Resources:** @@ -42,7 +42,7 @@ After the findings were presented to the Euler Hook Target Firewall team, fixes This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Euler Hook Target Firewall and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Euler Hook Target Firewall and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-09-Euler-PendleOracle.md b/content/2024-09-Euler-PendleOracle.md index a24f477..c956ee6 100644 --- a/content/2024-09-Euler-PendleOracle.md +++ b/content/2024-09-Euler-PendleOracle.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 9-2024-Pendle-Oracle -description: Pendle Oracle Electisec Report +description: Pendle Oracle yAudit Report nav_order: 71 image: assets/images/logo.png --- -# Electisec Euler PendleOracle Review +# yAudit Euler PendleOracle Review **Review Resources:** @@ -42,7 +42,7 @@ After the findings were presented to the Euler team, fixes were made and include This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Euler PendleOracle and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Euler PendleOracle and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-09-Euler-price-oracles-update.md b/content/2024-09-Euler-price-oracles-update.md index ecc71ca..6aee95a 100644 --- a/content/2024-09-Euler-price-oracles-update.md +++ b/content/2024-09-Euler-price-oracles-update.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 9-2024-Euler-Price-Oracles -description: Euler Price Oracles Electisec Report +description: Euler Price Oracles yAudit Report nav_order: 71 image: assets/images/logo.png --- -# Electisec Euler Price Oracles Update Review +# yAudit Euler Price Oracles Update Review **Review Resources:** @@ -50,7 +50,7 @@ After the findings were presented to the Euler team, fixes were made and include This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Euler and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Euler and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-09-Qantura-rebalance.md b/content/2024-09-Qantura-rebalance.md index 7e3fb38..e0a3cfc 100644 --- a/content/2024-09-Qantura-rebalance.md +++ b/content/2024-09-Qantura-rebalance.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 9-2024-Qantura -description: Qantura Electisec Report +description: Qantura yAudit Report nav_order: 71 image: assets/images/logo.png --- -# Electisec Qantura Rebalance Review +# yAudit Qantura Rebalance Review **Review Resources:** @@ -51,7 +51,7 @@ After the findings were presented to the Qantura Rebalance team, fixes were made This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Qantura Rebalance and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Qantura Rebalance and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-10-Euler-ERC20-Wrapper-Locked.md b/content/2024-10-Euler-ERC20-Wrapper-Locked.md index e9fa3f2..eddf52b 100644 --- a/content/2024-10-Euler-ERC20-Wrapper-Locked.md +++ b/content/2024-10-Euler-ERC20-Wrapper-Locked.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-10-Euler-ERC20-Wrapper-Locked -description: Euler ERC20 Wrapper Locked Electisec Report +description: Euler ERC20 Wrapper Locked yAudit Report nav_order: 11 image: assets/images/logo.png --- -# Electisec Euler ERC20 Wrapper Locked - Review +# yAudit Euler ERC20 Wrapper Locked - Review **Review Resources:** @@ -43,7 +43,7 @@ After the findings were presented to the Euler team, fixes were made and include This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Euler and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Euler and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-10-Flower.md b/content/2024-10-Flower.md index cbda61e..4adfbb7 100644 --- a/content/2024-10-Flower.md +++ b/content/2024-10-Flower.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-10-Flower -description: Flower Electisec Report +description: Flower yAudit Report nav_order: 71 image: assets/images/logo.png --- -# Electisec Flower Review +# yAudit Flower Review **Review Resources:** @@ -55,7 +55,7 @@ After the findings were presented to the Flower team, fixes were made and includ This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Flower and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Flower and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-10-GuessOurBlock.md b/content/2024-10-GuessOurBlock.md index 55d8661..1ca1bef 100644 --- a/content/2024-10-GuessOurBlock.md +++ b/content/2024-10-GuessOurBlock.md @@ -6,7 +6,7 @@ nav_order: 71 image: assets/images/logo.png --- -# Electisec GuessOurBlock Review +# yAudit GuessOurBlock Review **Review Resources:** @@ -52,7 +52,7 @@ After the findings were presented to the GuessOurBlock team, fixes were made and This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, GuessOurBlock and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, GuessOurBlock and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-10-Obelisk.md b/content/2024-10-Obelisk.md index ebb4a35..7095047 100644 --- a/content/2024-10-Obelisk.md +++ b/content/2024-10-Obelisk.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-10-Obelisk -description: Obelisk Electisec Report +description: Obelisk yAudit Report nav_order: 71 image: assets/images/logo.png --- -# Electisec Obelisk Review +# yAudit Obelisk Review **Review Resources:** @@ -63,7 +63,7 @@ After the findings were presented to the Obelisk team, fixes were made and inclu This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Obelisk and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Obelisk and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-10-Sickle-Strategies.md b/content/2024-10-Sickle-Strategies.md index 8c88750..b7113c6 100644 --- a/content/2024-10-Sickle-Strategies.md +++ b/content/2024-10-Sickle-Strategies.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-10-Sickle-Strategies -description: Sickle Strategies Electisec Report +description: Sickle Strategies yAudit Report nav_order: 71 image: assets/images/logo.png --- -# Electisec Sickle Strategies Review +# yAudit Sickle Strategies Review **Review Resources:** @@ -66,7 +66,7 @@ After the findings were presented to the Sickle team, fixes were made and includ This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Sickle and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Sickle and users of the contracts agree to use the code at their own risk.
diff --git a/content/2024-10-Superform.md b/content/2024-10-Superform.md index 18831c9..d458679 100644 --- a/content/2024-10-Superform.md +++ b/content/2024-10-Superform.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-10-Superform -description: Superform Electisec Report +description: Superform yAudit Report nav_order: 71 image: assets/images/logo.png --- -# Electisec Superform Router Plus and Super Vaults Review +# yAudit Superform Router Plus and Super Vaults Review **Review Resources:** @@ -63,7 +63,7 @@ After the findings were presented to the Superform team, fixes were made and inc This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, TODO_protocol_name and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, TODO_protocol_name and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-11-MarginZero.md b/content/2024-11-MarginZero.md index c1a26f6..d1d0aa9 100644 --- a/content/2024-11-MarginZero.md +++ b/content/2024-11-MarginZero.md @@ -6,7 +6,7 @@ nav_order: 73 image: assets/images/logo.png --- -# Electisec MarginZero Review +# yAudit MarginZero Review **Review Resources:** @@ -61,7 +61,7 @@ After the findings were presented to the MarginZero team, fixes were made and in This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, MarginZero and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, MarginZero and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-11-Olympus-Emission-Manager.md b/content/2024-11-Olympus-Emission-Manager.md index a1a4224..9f8b189 100644 --- a/content/2024-11-Olympus-Emission-Manager.md +++ b/content/2024-11-Olympus-Emission-Manager.md @@ -1,12 +1,12 @@ --- tags: ["solidity"] title: 2024-11-Olympus-Emission-Manager -description: Olympus Emission Manager Electisec report +description: Olympus Emission Manager yAudit report nav_order: 75 image: assets/images/logo.png --- -# Electisec Olympus Emission Manager Review +# yAudit Olympus Emission Manager Review **Review Resources:** @@ -47,7 +47,7 @@ After the findings were presented to the Olympus team, fixes were made and inclu This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Olympus and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Olympus and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -238,6 +238,6 @@ Update the variable name such that it reflects the true nature of the variable. Olympus uses the point-in-time price for the reserve asset, however, this is not susceptible to oracle manipulation due to the fact that the price is supplied by Chainlink and the keeper updates the price in the same transaction in which the price is used. -A gOHM flashloan attack to increase the supply and therefore the OHM emitted by the Emission Manager was discussed with the team. This was left out of the report because it was reported in a prior Electisec report and had already been acknowledged by the team. +A gOHM flashloan attack to increase the supply and therefore the OHM emitted by the Emission Manager was discussed with the team. This was left out of the report because it was reported in a prior yAudit report and had already been acknowledged by the team. In general, the code is extensively unit and fuzz tested. However, the auditors suggest that fork testing be done prior to deployment as it may have detected the sole critical finding in the report prior to the audit engagement. diff --git a/content/2024-11-napier.md b/content/2024-11-napier.md index 2d96ced..0748009 100644 --- a/content/2024-11-napier.md +++ b/content/2024-11-napier.md @@ -6,7 +6,7 @@ nav_order: 74 image: assets/images/logo.png --- -# Electisec Napier V2 Review +# yAudit Napier V2 Review **Review Resources:** @@ -22,7 +22,7 @@ image: assets/images/logo.png {: .no_toc } 1. TOC -{:toc} + {:toc} ## Review Summary @@ -101,7 +101,7 @@ After the findings were presented to the Napier V2 team, fixes were made and inc This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Napier V2 and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Napier V2 and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -212,7 +212,7 @@ The split fee is checked to differ from zero on update but not on initialization #### Technical Details -The `_splitRatio` parameter is validated to be different than zero in [`updateFeeSplitRatio()`](https://github.com/napierfi/napier-v2/blob/audit/Electisec/src/modules/FeeModule.sol#L87) but no check is done in [`initialize()`](https://github.com/napierfi/napier-v2/blob/audit/Electisec/src/modules/FeeModule.sol#L33), allowing the split to be initially zero. +The `_splitRatio` parameter is validated to be different than zero in [`updateFeeSplitRatio()`](https://github.com/napierfi/napier-v2/blob/audit/yAudit/src/modules/FeeModule.sol#L87) but no check is done in [`initialize()`](https://github.com/napierfi/napier-v2/blob/audit/yAudit/src/modules/FeeModule.sol#L33), allowing the split to be initially zero. #### Impact diff --git a/content/2024-12-OpenState.md b/content/2024-12-OpenState.md index 85b102d..4d2e754 100644 --- a/content/2024-12-OpenState.md +++ b/content/2024-12-OpenState.md @@ -6,7 +6,7 @@ nav_order: 76 image: assets/images/logo.png --- -# Electisec OpenState Review +# yAudit OpenState Review **Review Resources:** @@ -76,7 +76,7 @@ After the findings were presented to the OpenState team, fixes were made and inc This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, OpenState and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, OpenState and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2024-12-ResupplyFinance.md b/content/2024-12-ResupplyFinance.md index 0b86da7..2f38902 100644 --- a/content/2024-12-ResupplyFinance.md +++ b/content/2024-12-ResupplyFinance.md @@ -4,7 +4,7 @@ title: 2024-12-Resupply Finance description: Resupply Finance Report --- -# Electisec Resupply Finance Review +# yAudit Resupply Finance Review **Review Resources:** @@ -17,10 +17,11 @@ description: Resupply Finance Report - Spalen ## Table of Contents + {: .no_toc } 1. TOC -{:toc} + {:toc} ## Review Summary @@ -94,7 +95,7 @@ After the findings were presented to the Resupply Finance team, fixes were made This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Resupply Finance and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Resupply Finance and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2025-01-Asymmetry-USA-d.md b/content/2025-01-Asymmetry-USA-d.md index 64fe3fa..aaccc9c 100644 --- a/content/2025-01-Asymmetry-USA-d.md +++ b/content/2025-01-Asymmetry-USA-d.md @@ -4,7 +4,7 @@ title: 2025-01-Asymmetry-USA.d description: Security review of the USA.d / USDaf v1 --- -# Electisec USA.d Review +# yAudit USA.d Review **Review Resources:** @@ -20,7 +20,7 @@ description: Security review of the USA.d / USDaf v1 {: .no_toc } 1. TOC -{:toc} + {:toc} ## Review Summary @@ -59,7 +59,7 @@ After the findings were presented to the USA.d team, fixes were made and include This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, USA.d and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, USA.d and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix @@ -80,11 +80,11 @@ Electisec and the auditors make no warranties regarding the security of the code Findings are broken down into sections by their respective impact: - Critical, High, Medium, Low impact - - These are findings that range from attacks that may cause loss of funds, impact control/ownership of the contracts, or cause any unintended consequences/actions that are outside the scope of the requirements. + - These are findings that range from attacks that may cause loss of funds, impact control/ownership of the contracts, or cause any unintended consequences/actions that are outside the scope of the requirements. - Gas savings - - Findings that can improve the gas efficiency of the contracts. + - Findings that can improve the gas efficiency of the contracts. - Informational - - Findings including recommendations and best practices. + - Findings including recommendations and best practices. --- diff --git a/content/2025-01-Royco-CCDM-MerkleVault.md b/content/2025-01-Royco-CCDM-MerkleVault.md index 93e9d0f..594c912 100644 --- a/content/2025-01-Royco-CCDM-MerkleVault.md +++ b/content/2025-01-Royco-CCDM-MerkleVault.md @@ -1,10 +1,10 @@ --- tags: ["solidity", "layerzero", "berachain"] title: 2025-01-Royco-CCDM -description: Royco CCDM Merkle Vault Electisec Report +description: Royco CCDM Merkle Vault yAudit Report --- -# Electisec Royco CCDM Merkle Vault Review +# yAudit Royco CCDM Merkle Vault Review **Review Resources:** @@ -18,7 +18,7 @@ description: Royco CCDM Merkle Vault Electisec Report ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary diff --git a/content/2025-01-Royco-CCDM.md b/content/2025-01-Royco-CCDM.md index 1d037b5..0371c33 100644 --- a/content/2025-01-Royco-CCDM.md +++ b/content/2025-01-Royco-CCDM.md @@ -1,10 +1,10 @@ --- tags: ["solidity", "layerzero", "berachain"] title: 2025-01-Royco-CCDM -description: Royco CCDM Electisec Report +description: Royco CCDM yAudit Report --- -# Electisec Royco CCDM Review +# yAudit Royco CCDM Review **Review Resources:** diff --git a/content/2025-01-Sofa-Protocol.md b/content/2025-01-Sofa-Protocol.md index 37cf5e7..c9c63ba 100644 --- a/content/2025-01-Sofa-Protocol.md +++ b/content/2025-01-Sofa-Protocol.md @@ -18,7 +18,7 @@ description: Sofa Protocol Report ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -54,7 +54,7 @@ After the findings were presented to the SOFA team, fixes were made and included This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, SOFA and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, SOFA and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix diff --git a/content/2025-02-Olympus-CoolerV2.md b/content/2025-02-Olympus-CoolerV2.md index 4bb3c07..c74f681 100644 --- a/content/2025-02-Olympus-CoolerV2.md +++ b/content/2025-02-Olympus-CoolerV2.md @@ -4,7 +4,7 @@ title: 2025-02-Olympus-Cooler-V2 description: Security review of Olympus Cooler V2 protocol --- -# Electisec Olympus Cooler V2 Review +# yAudit Olympus Cooler V2 Review **Review Resources:** @@ -19,7 +19,7 @@ description: Security review of Olympus Cooler V2 protocol ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -67,22 +67,21 @@ After the findings were presented to the Olympus team, fixes were made and inclu This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Olympus and users of the contracts agree to use the code at their own risk. - +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Olympus and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | The protocol implements proper role-based access control for administrative functions. Only one minor issue was found with authorization deadline checks. | -| Mathematics | Good | The interest calculations and liquidation mechanisms appear to be implemented correctly, with only a minor edge case identified related to small amounts of burns during liquidations. | -| Complexity | Good | The codebase demonstrates appropriate complexity for its functionality, with a clear separation of concerns between components. | -| Libraries | Good | The protocol uses established libraries well and includes custom utility libraries like CompoundedInterest and SafeCast for specific needs. | -| Decentralization | Good | The system includes proper governance controls while balancing admin functions and user autonomy. | -| Code stability | Good | The codebase appears stable, with minimal issues identified during the audit period. | -| Documentation | Good | The code includes appropriate documentation and external resources were provided to help understand the system architecture. | -| Monitoring | Good | The protocol implements proper event emission for key state changes, facilitating off-chain monitoring. | -| Testing and verification | Good | The codebase was well-tested before the audit. | +| Category | Mark | Description | +| ------------------------ | ---- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Access Control | Good | The protocol implements proper role-based access control for administrative functions. Only one minor issue was found with authorization deadline checks. | +| Mathematics | Good | The interest calculations and liquidation mechanisms appear to be implemented correctly, with only a minor edge case identified related to small amounts of burns during liquidations. | +| Complexity | Good | The codebase demonstrates appropriate complexity for its functionality, with a clear separation of concerns between components. | +| Libraries | Good | The protocol uses established libraries well and includes custom utility libraries like CompoundedInterest and SafeCast for specific needs. | +| Decentralization | Good | The system includes proper governance controls while balancing admin functions and user autonomy. | +| Code stability | Good | The codebase appears stable, with minimal issues identified during the audit period. | +| Documentation | Good | The code includes appropriate documentation and external resources were provided to help understand the system architecture. | +| Monitoring | Good | The protocol implements proper event emission for key state changes, facilitating off-chain monitoring. | +| Testing and verification | Good | The codebase was well-tested before the audit. | ## Findings Explanation @@ -96,12 +95,15 @@ Findings are broken down into sections by their respective impact: - Findings including recommendations and best practices. --- + ## Critical Findings None + ## High Findings None + ## Medium Findings ### 1. Medium - Front-running liquidation with delegation can revert liquidation @@ -113,6 +115,7 @@ Liquidation can be prevented by frontrunning the liquidation transaction with de The [`_undelegateForLiquidation`](https://github.com/OlympusDAO/olympus-v3/blob/6b702f06d5bf90e8729d8b8b7baaeaffd54383fd/src/policies/cooler/MonoCooler.sol#L1018-L1018) function in `MonoCooler.sol` is vulnerable to a frontrunning attack that could prevent legitimate liquidations. The issue arises when a user-facing liquidation is frontrunning the liquidation transaction by modifying their delegations (e.g., changing delegation addresses or amounts). Let's say we have a user with the following state: + - Total collateral: 100 gOHM - Delegated to Bob: 80 gOHM - Undelegated: 20 gOHM @@ -120,16 +123,16 @@ Let's say we have a user with the following state: The user's position becomes liquidatable. A liquidator submits a transaction to batchLiquidate with a delegation request to undelegate 80 gOHM from Bob. However, the user sees this pending transaction and frontruns it with their own transaction that: + - Undelegates 70 gOHM from Bob - Delegates 70 gOHM to Alice -Now, when the liquidator's transaction executes: + Now, when the liquidator's transaction executes: The request to undelegate 80 gOHM from Bob will fail because there are only 10 gOHM delegated to Bob now. the liquidation will fail. - #### Impact -Medium. +Medium. #### Recommendation @@ -139,14 +142,12 @@ When a position is liquidable, allow only the owner to add funds to prevent liqu Fixed [#53](https://github.com/OlympusDAO/olympus-v3/pull/53/files) - ## Low Findings ### 1. Low - Add an upper limit #### Technical Details - The `setInterestRateWad()` function in MonoCooler.sol allows an admin to set any interest rate without an upper bound. While this requires admin privileges, having no maximum cap creates unnecessary risk if the admin role is compromised or if a mistake is made. ``` @@ -154,7 +155,7 @@ File: MonoCooler.sol 651: function setInterestRateWad(uint96 newInterestRate) external override onlyAdminRole { 652: // Force an update of state on the old rate first. 653: _globalStateRW(); -654: +654: 655: emit InterestRateSet(newInterestRate); 656: interestRateWad = newInterestRate; 657: } @@ -162,7 +163,6 @@ File: MonoCooler.sol [MonoCooler.sol#L651-L657](https://github.com/OlympusDAO/olympus-v3/blob/6b702f06d5bf90e8729d8b8b7baaeaffd54383fd/src/policies/cooler/MonoCooler.sol#L651-L657) - #### Impact Low. @@ -188,7 +188,7 @@ The [`batchLiquidate()`](https://github.com/OlympusDAO/olympus-v3/blob/6b702f06d 585: if (totalCollateralClaimed > 0) { 586: // Unstake and burn gOHM holdings. 587: uint128 gOhmToBurn = totalCollateralClaimed - totalLiquidationIncentive; -588: +588: 589: if (gOhmToBurn > 0) { 590: _COLLATERAL_TOKEN.safeApprove(address(_STAKING), gOhmToBurn); 591: MINTR.burnOhm( @@ -196,7 +196,7 @@ The [`batchLiquidate()`](https://github.com/OlympusDAO/olympus-v3/blob/6b702f06d 593: _STAKING.unstake(address(this), gOhmToBurn, false, false) 594: ); 595: } -596: +596: 597: totalCollateral -= totalCollateralClaimed; 598: } ``` @@ -222,9 +222,9 @@ Given this relation is not 1:1, a non-zero amount of gOHM could be unstaked as a 52: uint256 amount_ 53: ) external override permissioned onlyWhileActive { 54: if (amount_ == 0) revert MINTR_ZeroAmount(); -55: +55: 56: ohm.burnFrom(from_, amount_); -57: +57: 58: emit Burn(msg.sender, from_, amount_); 59: } ``` @@ -312,8 +312,6 @@ Use [unchecked block](https://docs.soliditylang.org/en/latest/control-structures Fixed [197564ea](https://github.com/OlympusDAO/olympus-v3/pull/46/commits/197564ea653191b6de9d7229b72426533dd1efbb). - - ## Informational Findings ### 1. Informational - Authorization check incorrectly handles authorization deadline @@ -369,8 +367,7 @@ Double-check if anything should be paused while disabled, or replace PolicyEnabl #### Developer Response -Fixed [cdaae3](https://github.com/OlympusDAO/olympus-v3/commit/cdaae3ba5993424172fb94c79fd6aedaf9a3a5ad) - +Fixed [cdaae3](https://github.com/OlympusDAO/olympus-v3/commit/cdaae3ba5993424172fb94c79fd6aedaf9a3a5ad) ## Final remarks diff --git a/content/2025-02-Origami-hOHM.md b/content/2025-02-Origami-hOHM.md index a242949..2dda3a1 100644 --- a/content/2025-02-Origami-hOHM.md +++ b/content/2025-02-Origami-hOHM.md @@ -4,7 +4,7 @@ title: 02-205-Origami-hOHM description: Security review of Origami hOHM protocol --- -# Electisec Origami hOHM Review +# yAudit Origami hOHM Review **Review Resources:** @@ -18,7 +18,7 @@ description: Security review of Origami hOHM protocol ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -56,22 +56,21 @@ After the findings were presented to the Origami hOHM team, fixes were made and This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Origami hOHM and users of the contracts agree to use the code at their own risk. - +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Origami hOHM and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | Proper access control is implemented using the OrigamiElevatedAccess mixin. | -| Mathematics | Average | Some rounding issues were detected in the Tokenized Balance Sheet contract. | -| Complexity | Good | Complexity is handled with a modular architecture and well-balanced separation of concerns, enabling the potential reuse of the Tokenized Balance Sheet logic. | -| Libraries | Good | The contracts integrate with the OpenZeppelin and LayerZero V2 libraries. | -| Decentralization | Average | Part of the vault's lifecycle requires privileged access. | -| Code stability | Good | Contracts remained stable throughout the revision. | -| Documentation | Good | Documentation at the source code level is excellent. Additionally, high-level specs for the system were provided. | -| Monitoring | Good | Proper monitoring events for key operations are in place. | -| Testing and verification | Good | The codebase includes a unit and invariant test suite with good coverage. | +| Category | Mark | Description | +| ------------------------ | ------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Access Control | Good | Proper access control is implemented using the OrigamiElevatedAccess mixin. | +| Mathematics | Average | Some rounding issues were detected in the Tokenized Balance Sheet contract. | +| Complexity | Good | Complexity is handled with a modular architecture and well-balanced separation of concerns, enabling the potential reuse of the Tokenized Balance Sheet logic. | +| Libraries | Good | The contracts integrate with the OpenZeppelin and LayerZero V2 libraries. | +| Decentralization | Average | Part of the vault's lifecycle requires privileged access. | +| Code stability | Good | Contracts remained stable throughout the revision. | +| Documentation | Good | Documentation at the source code level is excellent. Additionally, high-level specs for the system were provided. | +| Monitoring | Good | Proper monitoring events for key operations are in place. | +| Testing and verification | Good | The codebase includes a unit and invariant test suite with good coverage. | ## Findings Explanation @@ -111,7 +110,7 @@ Suppose we have the following scenario: - `tokenAmount = 4` - `shares = joinWithToken(tokenAmount) = roundDown(tokenAmount * totalSupply / inputTokenBalance) = roundDown(4 * 2 / 5) = 1`. - `exitWithShares(shares) = roundUp(shares * inputTokenBalance / totalSupply) = roundUp(1 * 5 / 2) = 3` - + This means we got four tokens as a liability when we joined and deposited only three tokens when we exited. The same happens with [`exitWithToken()`](https://github.com/TempleDAO/origami/blob/6b0e28eb43cd32f0bf61c600d9c9e561df6796de/apps/protocol/contracts/common/OrigamiTokenizedBalanceSheetVault.sol#L327) as it always rounds up the number of required shares. This is fine when the input token is an asset since the vault should ensure the user gets burned at least the returned value. However, it has the opposite effect when the input token is a liability since the value is now being deposited into the vault. @@ -174,24 +173,24 @@ Given a specific available share capacity, the implementation of [`_maxJoinWithT 491: ) internal virtual view returns (uint256 maxTokens) { 492: // If the token balance of the requested token is zero then cannot join 493: if (cache.inputTokenBalance == 0) return 0; -494: +494: 495: // If this is an unknown asset then return zero 496: (bool inputIsAsset, bool inputIsLiability) = isBalanceSheetToken(cache.inputTokenAddress); 497: if (!(inputIsAsset || inputIsLiability)) return 0; -498: +498: 499: uint256 maxTotalSupply_ = maxTotalSupply(); 500: if (maxTotalSupply_ == type(uint256).max) return maxTotalSupply_; -501: +501: 502: uint256 availableShares = _availableSharesCapacity(cache.totalSupply, maxTotalSupply_); -503: +503: 504: // When calculating the max assets or liabilities amount, if the input token is: 505: // - an asset: ROUND_UP (assets are pulled from the caller) 506: // - a liability: ROUND_DOWN (liabilities sent to recipient) 507: // Shares are rounded down within previewJoinWithToken, so can be rounded up when determining 508: // the max here. 509: return _convertSharesToOneToken({ -510: shares: availableShares.inverseSubtractBps(feeBps, OrigamiMath.Rounding.ROUND_UP), -511: cache: cache, +510: shares: availableShares.inverseSubtractBps(feeBps, OrigamiMath.Rounding.ROUND_UP), +511: cache: cache, 512: rounding: inputIsAsset ? OrigamiMath.Rounding.ROUND_UP : OrigamiMath.Rounding.ROUND_DOWN 513: }); 514: } @@ -203,8 +202,8 @@ Given a specific available share capacity, the implementation of [`_maxJoinWithT 847: _Cache memory cache, 848: OrigamiMath.Rounding rounding 849: ) private pure returns (uint256) { -850: // An initial seed deposit is required first. -851: // In the case of a new asset added to an existing vault, a donation of tokens +850: // An initial seed deposit is required first. +851: // In the case of a new asset added to an existing vault, a donation of tokens 852: // must be added to the vault first. 853: return cache.inputTokenBalance == 0 854: ? 0 @@ -232,12 +231,12 @@ The same happens in `maxExitWithToken()` but for liabilities. The implementation 600: // If this is an unknown asset then return zero 601: (bool inputIsAsset, bool inputIsLiability) = isBalanceSheetToken(cache.inputTokenAddress); 602: if (!(inputIsAsset || inputIsLiability)) return 0; -603: +603: 604: // Special case for address(0), unlimited 605: if (sharesOwner == address(0)) return type(uint256).max; -606: +606: 607: uint256 shares = balanceOf(sharesOwner); -608: +608: 609: // When calculating the max assets or liabilities amount, if the input token is: 610: // - an asset: ROUND_DOWN (assets are sent to the recipient) 611: // - a liability: ROUND_DOWN (liabilities are pulled from the caller) @@ -249,7 +248,7 @@ The same happens in `maxExitWithToken()` but for liabilities. The implementation 617: cache: cache, 618: rounding: inputIsAsset ? OrigamiMath.Rounding.ROUND_DOWN : OrigamiMath.Rounding.ROUND_UP 619: }); -620: +620: 621: // Return the minimum of the available balance of the requested token in the balance sheet 622: // and the derived amount from the available shares 623: return maxFromShares < cache.inputTokenBalance ? maxFromShares : cache.inputTokenBalance; @@ -279,9 +278,11 @@ None. #### Technical Details In the `OlympusCoolerDelegation` library, there is a potential integer overflow risk when converting from uint256 to int256 in the `_syncDelegationRequest` function: + ```solidity int256 delta = int256(newDelegationAmount) - int256(existingDelegationAmount); ``` + This is unlikely to be problematic in the current Olympus implementation, as the gOHM token amounts will never approach these extreme values. However, as this library could be reused in other contexts with different tokens, it represents a potential vulnerability if used with tokens that have very large supplies or amounts. #### Impact @@ -351,7 +352,6 @@ Acknowledged. Not really an issue. When the vault is being unwound, the exit fee #### Technical Details - ```solidity File: contracts/common/OrigamiTokenizedBalanceSheetVault.sol @@ -378,6 +378,7 @@ File: contracts/investments/OrigamiInvestmentVault.sol ``` [OrigamiInvestmentVault.sol#L57](https://github.com/TempleDAO/origami/blob/6b0e28eb43cd32f0bf61c600d9c9e561df6796de/apps/protocol/contracts/investments/OrigamiInvestmentVault.sol#L57), [OrigamiInvestmentVault.sol#L65](https://github.com/TempleDAO/origami/blob/6b0e28eb43cd32f0bf61c600d9c9e561df6796de/apps/protocol/contracts/investments/OrigamiInvestmentVault.sol#L65), [OrigamiInvestmentVault.sol#L105](https://github.com/TempleDAO/origami/blob/6b0e28eb43cd32f0bf61c600d9c9e561df6796de/apps/protocol/contracts/investments/OrigamiInvestmentVault.sol#L105) + #### Impact Informational. @@ -396,7 +397,6 @@ The identifier is imported but never used within the file. #### Technical Details - ```solidity File: contracts/common/OrigamiTokenizedBalanceSheetVault.sol @@ -421,10 +421,8 @@ Fixed in [08e9579](https://github.com/TempleDAO/origami/pull/1341/commits/08e957 Unused error is defined and can be removed. - #### Technical Details - ```solidity File: contracts/interfaces/common/IOrigamiTokenizedBalanceSheetVault.sol @@ -459,7 +457,7 @@ The implementation of [`_syncSavings()`](https://github.com/TempleDAO/origami/bl 543: function _syncSavings(uint256 requiredDebtTokenBalance) private { 544: IERC4626 _savingsVault = debtTokenSavingsVault; 545: if (address(_savingsVault) == address(0)) return; -546: +546: 547: uint256 _debtTokenBalance = debtToken.balanceOf(address(this)); 548: if (_debtTokenBalance > requiredDebtTokenBalance) { 549: // deposit any surplus into savings @@ -468,7 +466,7 @@ The implementation of [`_syncSavings()`](https://github.com/TempleDAO/origami/bl 552: // withdraw deficit from savings. Cap to the max amount which can be withdrawn. 553: uint256 delta = requiredDebtTokenBalance - _debtTokenBalance; 554: uint256 maxWithdraw = _savingsVault.maxWithdraw(address(this)); -555: if (delta > maxWithdraw) delta = maxWithdraw; +555: if (delta > maxWithdraw) delta = maxWithdraw; 556: if (delta > 0) { 557: _savingsVault.withdraw(delta, address(this), address(this)); 558: } diff --git a/content/2025-03-Bearn.md b/content/2025-03-Bearn.md index 6a5a8b1..e14180c 100644 --- a/content/2025-03-Bearn.md +++ b/content/2025-03-Bearn.md @@ -4,7 +4,7 @@ title: 2025-03-Bearn-yBGT description: Audit report for Bearn yBGT, a liquid wrapper for BGT on Berachain --- -# Electisec yBGT Review +# yAudit yBGT Review **Review Resources:** @@ -19,7 +19,7 @@ description: Audit report for Bearn yBGT, a liquid wrapper for BGT on Berachain ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -46,6 +46,7 @@ src/ ``` From the yearn tokenized-strategy-periphery codebase, the following contracts were reviewed: + ``` src/ ├── Bases/ @@ -59,22 +60,21 @@ After the findings were presented to the yBGT team, fixes were made and included This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, yBGT and users of the contracts agree to use the code at their own risk. - +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, yBGT and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | The codebase implements proper authorization patterns and role-based access control. Privileged functions are protected with appropriate modifiers. | -| Mathematics | Good | The mathematical operations in the contracts appear sound, with proper consideration for precision and edge cases. | +| Category | Mark | Description | +| ------------------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Access Control | Good | The codebase implements proper authorization patterns and role-based access control. Privileged functions are protected with appropriate modifiers. | +| Mathematics | Good | The mathematical operations in the contracts appear sound, with proper consideration for precision and edge cases. | | Complexity | Average | While most functions are reasonably straightforward, some components, like the reward distribution and voting management, introduce moderate complexity that requires careful implementation. | -| Libraries | Good | The project appropriately uses established libraries and components, particularly from the Yearn ecosystem. | -| Decentralization | Average | The protocol has some centralized components managed by privileged roles but also incorporates decentralized governance mechanisms through BGT voting. | -| Code stability | Good | The codebase appears stable with well-defined interfaces and consistent implementation patterns. | -| Documentation | Good | Functions and contracts have appropriate comments explaining their purpose and behavior. The overall architecture is well documented. | -| Monitoring | Good | The contracts implement sufficient events for tracking important state changes and user interactions. | -| Testing and verification | Low | Test coverage exists but could benefit from more comprehensive testing of edge cases and integration scenarios. | +| Libraries | Good | The project appropriately uses established libraries and components, particularly from the Yearn ecosystem. | +| Decentralization | Average | The protocol has some centralized components managed by privileged roles but also incorporates decentralized governance mechanisms through BGT voting. | +| Code stability | Good | The codebase appears stable with well-defined interfaces and consistent implementation patterns. | +| Documentation | Good | Functions and contracts have appropriate comments explaining their purpose and behavior. The overall architecture is well documented. | +| Monitoring | Good | The contracts implement sufficient events for tracking important state changes and user interactions. | +| Testing and verification | Low | Test coverage exists but could benefit from more comprehensive testing of edge cases and integration scenarios. | ## Findings Explanation @@ -88,9 +88,11 @@ Findings are broken down into sections by their respective impact: - Findings including recommendations and best practices. --- + ## Critical Findings None + ## High Findings ### 1. High - `BearnVoterManager` sets incorrect address as auction's receiver @@ -156,11 +158,11 @@ Execute the balance read correctly by reading the `BearnVault`'s balance. ```diff @@ -258,7 +258,7 @@ contract BearnVoterManager is Authorized { ); - + // Transfer Full balance of honey to styBGT to account for auctions. - uint256 amount = honey.balanceOf(address(this)); + uint256 amount = honey.balanceOf(address(bearnVoter)); - + // Send rewards to styBGT if (amount > 0) { ``` @@ -174,6 +176,7 @@ Fixed https://github.com/Bearn-Sucks/yBGT/commit/d693c8e4ec2a2bcfa045b171896252a Currently, BearnBGT (yBGT) users face a significant limitation: they are locked into the protocol without a reliable way to signal their intention to withdraw or exit when their BGT tokens are being used for voting. The existing `redeem()` function only allows the withdrawal of unboosted (non-voting) BGT tokens. This means users can be effectively trapped in the protocol if most or all of their yBGT is used for governance voting. This creates several problems: + 1. Users cannot reliably exit their positions 2. The protocol lacks transparency on withdrawal demand 3. There's no mechanism to prioritize and fulfill withdrawal requests as tokens become available @@ -181,7 +184,6 @@ This creates several problems: #### Technical Details - The current implementation in `BearnBGT.sol` has a `redeem()` function that checks the available unboosted balance and only allows withdrawal up to that amount: ```solidity @@ -210,7 +212,6 @@ function redeem(uint256 amount) external returns (uint256 outputAmount) { This means that if all tokens are being used for voting (boosted), users cannot withdraw them. - #### Impact Medium. Decreases trust in the protocol due to uncertainty about liquidity @@ -218,12 +219,15 @@ Medium. Decreases trust in the protocol due to uncertainty about liquidity #### Recommendation Implement a Withdrawal Queue similar to Lido's approach with the following components: + 1. Withdrawal Request Queue + - Allow users to enter a queue for withdrawals that exceed current unboosted balance - Users specify the amount to withdraw and receive a withdrawal NFT/receipt as proof - This signals intent without immediate execution 2. Withdrawal Fulfillment Logic + - Newly emitted BGT should first fulfill pending withdrawal requests before being used for voting - The vote operator should be able to see pending withdrawal requests and their total amount - Implement logic to gradually unboost to fulfill withdrawal requests over time @@ -238,7 +242,6 @@ The logic for the withdrawal queue can be added to the current system, and we pl Even if redemptions become necessary now, reports are also permissionless. This is when BGT is claimed and becomes unboosted, so redemptions could be paired with permissionless reports to free up unboosted BGT. - ## Low Findings ### 1. Low - Unbounded `rewardTokens` array in `addReward` can lead to DOS @@ -247,11 +250,13 @@ Even if redemptions become necessary now, reports are also permissionless. This The addReward function in the TokenizedStaker contract allows the management role to add new reward tokens to the contract. There's no limit to how many reward tokens can be added, and the `_updateReward` function iterates through all tokens in the rewardTokens array: + ```solidity File: TokenizedStaker.sol 362: for (uint256 i; i < rewardTokens.length; ++i) { 363: address _rewardToken = rewardTokens[i]; ``` + #### Impact Low. @@ -314,7 +319,6 @@ function recoverERC20( } ``` - The issue is that even after recovering a reward token, it remains in the `rewardTokens` array and continues to be processed during reward updates and claims. This creates several inefficiencies: 1. Failed token transfers may occur in `_getRewardFor` if all of a reward token was recovered @@ -369,8 +373,8 @@ Gas savings. Modify `BearnVoteManager.activateBoost` and `BearnVoteManager.dropBoost` to interact directly with `BGT`, invoking the corresponding methods, taking care to specify the `BearnVoter` contract as the `user` parameter for such calls. #### Developer Response -Fixed https://github.com/Bearn-Sucks/yBGT/commit/d693c8e4ec2a2bcfa045b171896252a75d7b9671 +Fixed https://github.com/Bearn-Sucks/yBGT/commit/d693c8e4ec2a2bcfa045b171896252a75d7b9671 ## Informational Findings @@ -391,13 +395,14 @@ Informational. Implement a `getOneRewardFor` method to offer authorized accounts the same functionality, allowing them to claim only one reward token on a user's behalf. #### Developer Response + Acknowledged ### 2. Informational - Missing event logs #### Technical Details -1. When modifying the `TokenizedStaker.claimForRecipient` mapping via [`TokenizedStaker.setClaimFor`](https://github.com/yearn/tokenized-strategy-periphery/blob/7d8559d6e6efd5e9d7d43b7354f9926e2ff9f63b/src/Bases/Staker/TokenizedStaker.sol#L474-L479) or [`TokenizedStaker.setClaimForSelf`](https://github.com/yearn/tokenized-strategy-periphery/blob/7d8559d6e6efd5e9d7d43b7354f9926e2ff9f63b/src/Bases/Staker/TokenizedStaker.sol#L486-L488), no event log is emitted to signal the storage modification to off-chain components. +1. When modifying the `TokenizedStaker.claimForRecipient` mapping via [`TokenizedStaker.setClaimFor`](https://github.com/yearn/tokenized-strategy-periphery/blob/7d8559d6e6efd5e9d7d43b7354f9926e2ff9f63b/src/Bases/Staker/TokenizedStaker.sol#L474-L479) or [`TokenizedStaker.setClaimForSelf`](https://github.com/yearn/tokenized-strategy-periphery/blob/7d8559d6e6efd5e9d7d43b7354f9926e2ff9f63b/src/Bases/Staker/TokenizedStaker.sol#L486-L488), no event log is emitted to signal the storage modification to off-chain components. 2. When adding a reward via [`TokenizedReward.addReward`](https://github.com/yearn/tokenized-strategy-periphery/blob/7d8559d6e6efd5e9d7d43b7354f9926e2ff9f63b/src/Bases/Staker/TokenizedStaker.sol#L410-L416), no event is emitted. #### Impact @@ -410,6 +415,7 @@ Informational. 2. Define a `RewardTokenAdded(address _rewardToken, address _rewardsDistributor, uint256 _rewardsDuration)` event and log it at the end of [`_addReward`](https://github.com/yearn/tokenized-strategy-periphery/blob/7d8559d6e6efd5e9d7d43b7354f9926e2ff9f63b/src/Bases/Staker/TokenizedStaker.sol#L419-L437). #### Developer Response + Acknowledged ## Final remarks diff --git a/content/2025-03-Beefy-Sonic.md b/content/2025-03-Beefy-Sonic.md index ed28e34..3eaa0d1 100644 --- a/content/2025-03-Beefy-Sonic.md +++ b/content/2025-03-Beefy-Sonic.md @@ -4,7 +4,7 @@ title: 2025-03-Beefy-Sonic description: Beefy Sonic Report --- -# Electisec Beefy Sonic Review +# yAudit Beefy Sonic Review **Review Resources:** @@ -18,7 +18,7 @@ description: Beefy Sonic Report ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -47,22 +47,21 @@ After the findings were presented to the Beefy team, fixes were made and include This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Beefy and users of the contracts agree to use the code at their own risk. - +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Beefy and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | Well-implemented role system with owner, keeper and ERC-7540 controller and operator. Critical functions have appropriate access controls. | -| Mathematics | Good | No complex math operations. Proper handling of decimals and precision (1e18). Safe operations for fee calculations and share/asset conversions. | -| Complexity | Good | Generally clean code structure. Some complexity is added by slashing management, but it's well handled through dedicated functions. | -| Libraries | Good | Good use of OpenZeppelin's battle-tested contracts (ERC4626, Upgradeable patterns, SafeERC20). | -| Decentralization | Medium | While staking is permissionless, significant power remains with admin roles. | -| Code stability | Good | Proper use of UUPS upgrade pattern. Well-structured storage layout. Clear separation of concerns. | -| Documentation | Low | Minimal inline documentation. Complex mechanisms (e.g., slashing management) need better documentation. Missing architectural overview and detailed specifications. | -| Monitoring | Good | Key events are emitted. | -| Testing and verification | Medium | High test coverage, but it lacks fuzzing and invariant testing. | +| Category | Mark | Description | +| ------------------------ | ------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Access Control | Good | Well-implemented role system with owner, keeper and ERC-7540 controller and operator. Critical functions have appropriate access controls. | +| Mathematics | Good | No complex math operations. Proper handling of decimals and precision (1e18). Safe operations for fee calculations and share/asset conversions. | +| Complexity | Good | Generally clean code structure. Some complexity is added by slashing management, but it's well handled through dedicated functions. | +| Libraries | Good | Good use of OpenZeppelin's battle-tested contracts (ERC4626, Upgradeable patterns, SafeERC20). | +| Decentralization | Medium | While staking is permissionless, significant power remains with admin roles. | +| Code stability | Good | Proper use of UUPS upgrade pattern. Well-structured storage layout. Clear separation of concerns. | +| Documentation | Low | Minimal inline documentation. Complex mechanisms (e.g., slashing management) need better documentation. Missing architectural overview and detailed specifications. | +| Monitoring | Good | Key events are emitted. | +| Testing and verification | Medium | High test coverage, but it lacks fuzzing and invariant testing. | ## Findings Explanation @@ -81,7 +80,7 @@ Findings are broken down into sections by their respective impact: ### 1. Medium - `harvest()` can be gamed to gain previously accumulated rewards -The harvest mechanism combines reward claiming and delegation into a single atomic operation. This design can dilute rewards when validator capacity is full, as new users can back-run validator additions to capture accumulated rewards. +The harvest mechanism combines reward claiming and delegation into a single atomic operation. This design can dilute rewards when validator capacity is full, as new users can back-run validator additions to capture accumulated rewards. #### Technical Details @@ -230,7 +229,7 @@ Medium. Users monitoring slashing events will be able to bypass socialization. #### Recommendation -Check if socialization is ongoing for a validator before continuing the loop and revert if that's the case. +Check if socialization is ongoing for a validator before continuing the loop and revert if that's the case. #### Developer Response @@ -303,7 +302,6 @@ function _claim(uint256 startIndex, uint256 endIndex) private { Acknowledged. We probably won't add this just due to contract size constraints and the fact that its very unlikely an array can get to a size where this is an issue. - ## Gas Saving Findings ### 1. Gas - Fail earlier @@ -345,12 +343,11 @@ function setLiquidityFee(uint256 _liquidityFee) external onlyOwner { Acknowledged. - ### 2. Gas - Inverse check order in `_onlyOperatorOrController()` #### Technical Details - In the modifier [`_onlyOperatorOrController()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L88-L88), the condition can be modified to first check `_controller != msg.sender` as the `controller` will most likely always be the `msg.sender`, and it will save a storage read. +In the modifier [`_onlyOperatorOrController()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L88-L88), the condition can be modified to first check `_controller != msg.sender` as the `controller` will most likely always be the `msg.sender`, and it will save a storage read. #### Impact @@ -370,13 +367,13 @@ Fixed in [PR#32](https://github.com/beefyfinance/beefy-sonic/pull/32). Throughout the contract, storage variables are sometimes accessed multiple times inside the same function. Consider caching them to save storage read. - - In [`_claim()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L704-L704) `validator.id` is used multiple times - - In [`_getValidatorToDeposit()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L165-L165) `validators.length` is used multiple times. - - In [`_requestRedeem()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L225-L225) `$.wId` might be read and updated multiple times in the loop. - - In [`completeSlashedValidatorWithdraw()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L435-L435) `stakingContract` is used multiple times. - - In [`_removeRequest()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L503-L503) `pendingRequests.length` is used multiple times. - - In [`_chargeFees()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L722-L722) `liquidityFee` is used multiple times. - - In [`addValidator()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L901-L901) `validators.length` is used multiple times. +- In [`_claim()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L704-L704) `validator.id` is used multiple times +- In [`_getValidatorToDeposit()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L165-L165) `validators.length` is used multiple times. +- In [`_requestRedeem()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L225-L225) `$.wId` might be read and updated multiple times in the loop. +- In [`completeSlashedValidatorWithdraw()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L435-L435) `stakingContract` is used multiple times. +- In [`_removeRequest()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L503-L503) `pendingRequests.length` is used multiple times. +- In [`_chargeFees()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L722-L722) `liquidityFee` is used multiple times. +- In [`addValidator()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L901-L901) `validators.length` is used multiple times. #### Impact @@ -390,7 +387,6 @@ Cache the storage variable in memory. Acknowledged. - ### 4. Gas - `lockedProfit()` not needed inside `harvest()` #### Technical Details @@ -624,7 +620,6 @@ Define constants for all magic numbers: Acknowledged. - ### 7. Informational - Incorrect events emission #### Technical Details @@ -724,7 +719,7 @@ Fixed in [PR#35](https://github.com/beefyfinance/beefy-sonic/pull/35). The function [`_requestRedeem()`](https://github.com/beefyfinance/beefy-sonic/blob/ed087129fb81f38c66b323ecd4a01f430bb97a8c/contracts/BeefySonic.sol#L225-L225) saves the timestamp at which the request can be executed using the `withdrawDuration()` inside `claimableTimestamp`. -However, this value may change if the Sonic admins update it, resulting in an incorrect `claimableTimestamp`. +However, this value may change if the Sonic admins update it, resulting in an incorrect `claimableTimestamp`. Users who requested before the `withdrawDuration()` update may think they can claim, but it will revert, or may think they can't claim even though it's actually available, depending on whether the value was increased or decreased. diff --git a/content/2025-03-CAP-PremainnetVault.md b/content/2025-03-CAP-PremainnetVault.md index bc233ad..9ff607d 100644 --- a/content/2025-03-CAP-PremainnetVault.md +++ b/content/2025-03-CAP-PremainnetVault.md @@ -4,7 +4,7 @@ title: 2025-03-CAP-PremainnetVault description: CAP Pre-mainnet vault report --- -# Electisec CAP Pre-Mainnet Vault Review +# yAudit CAP Pre-Mainnet Vault Review **Review Resources:** @@ -18,7 +18,7 @@ description: CAP Pre-mainnet vault report ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -41,22 +41,21 @@ After the findings were presented to the CAP team, fixes were made and included This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, CAP and users of the contracts agree to use the code at their own risk. - +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, CAP and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | Access control mechanisms are implemented appropriately where necessary. | -| Mathematics | Good | No complex calculations are involved. | -| Complexity | Good | The codebase is simple and easy to understand. | -| Libraries | Good | Utilizes OpenZeppelin and LayerZero libraries for security and best practices. | -| Decentralization | Good | Users can withdraw funds even if the owner does not unlock transfers. | -| Code stability | Good | The codebase was stable during the audit. | -| Documentation | Good | Well-documented with NatSpec comments, with only minor omissions. | -| Monitoring | Good | Events are emitted within state-changing functions. | -| Testing and verification | Average | Includes unit tests but lacks invariant testing and fuzzing. | +| Category | Mark | Description | +| ------------------------ | ------- | ------------------------------------------------------------------------------ | +| Access Control | Good | Access control mechanisms are implemented appropriately where necessary. | +| Mathematics | Good | No complex calculations are involved. | +| Complexity | Good | The codebase is simple and easy to understand. | +| Libraries | Good | Utilizes OpenZeppelin and LayerZero libraries for security and best practices. | +| Decentralization | Good | Users can withdraw funds even if the owner does not unlock transfers. | +| Code stability | Good | The codebase was stable during the audit. | +| Documentation | Good | Well-documented with NatSpec comments, with only minor omissions. | +| Monitoring | Good | Events are emitted within state-changing functions. | +| Testing and verification | Average | Includes unit tests but lacks invariant testing and fuzzing. | ## Findings Explanation @@ -261,5 +260,3 @@ Fixed in https://github.com/cap-labs-dev/cap-contracts/pull/78. ## Final remarks The CAP Pre-Mainnet Vault provides users with a simple vault contract to participate in the CAP Pre-Mainnet campaign. The codebase is small and simple, with minimal functionalities. Users can deposit and withdraw(after the campaign ends) from the vault without any conversions or loss of assets. The CAP team promptly addressed the identified issues and found no severe vulnerabilities. - - diff --git a/content/2025-03-Goldilocks-ivault4626.md b/content/2025-03-Goldilocks-ivault4626.md index c252ca9..46028e5 100644 --- a/content/2025-03-Goldilocks-ivault4626.md +++ b/content/2025-03-Goldilocks-ivault4626.md @@ -4,7 +4,7 @@ title: 2025-03-Goldilocks-ivault4626 description: Goldilocks ivault4626 Report --- -# Electisec Goldilocks ivault4626 Review +# yAudit Goldilocks ivault4626 Review **Review Resources:** @@ -18,7 +18,7 @@ description: Goldilocks ivault4626 Report ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -36,7 +36,7 @@ After the findings were presented to the Goldilocks team, fixes were made and in This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Goldilocks and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Goldilocks and users of the contracts agree to use the code at their own risk. ## Findings Explanation @@ -73,7 +73,7 @@ Change the logic in the `_unstakableYT()` function to correctly return the maxim ```solidity /// @notice Calculate the maximum amount of YT the user can unstake -function _unstakableYT(address user, uint256 unstakeAmount) internal view returns (uint256) { +function _unstakableYT(address user, uint256 unstakeAmount) internal view returns (uint256) { return FixedPointMathLib.min(unstakeAmount, ytStaked[user]); } ``` @@ -86,7 +86,7 @@ Fixed [here](https://github.com/0xgeeb/goldilocks-core/commit/5f820457f3a5c824fa #### Technical Details -The flow [`buyYT()`](https://github.com/0xgeeb/goldilocks-core/blob/022263468c7d21afceb44d0ac9ba0ea8a1beedf8/src/core/goldivault/Goldivault4626.sol#L181) can be optimized to minimize pay deposit and withdraw fees to `depositVault`. Vault used in [tests](https://github.com/0xgeeb/goldilocks-core/blob/022263468c7d21afceb44d0ac9ba0ea8a1beedf8/test/integration/BeraborrowGoldivault.t.sol#L49C26-L49C68) has a withdraw fee. +The flow [`buyYT()`](https://github.com/0xgeeb/goldilocks-core/blob/022263468c7d21afceb44d0ac9ba0ea8a1beedf8/src/core/goldivault/Goldivault4626.sol#L181) can be optimized to minimize pay deposit and withdraw fees to `depositVault`. Vault used in [tests](https://github.com/0xgeeb/goldilocks-core/blob/022263468c7d21afceb44d0ac9ba0ea8a1beedf8/test/integration/BeraborrowGoldivault.t.sol#L49C26-L49C68) has a withdraw fee. After the [swap](https://github.com/0xgeeb/goldilocks-core/blob/022263468c7d21afceb44d0ac9ba0ea8a1beedf8/src/core/goldivault/Goldivault4626.sol#L204) from `ot` to `depositVault` token, the user redeems vault tokens and pays withdraw fee. Sends the received `depositToken` to the contract which deposits it back to the same `depositVault`. The user can send `depositVault` tokens directly to the contract without paying the fees. @@ -115,7 +115,6 @@ Change the lines [206-210](https://github.com/0xgeeb/goldilocks-core/blob/022263 Fixed [here](https://github.com/0xgeeb/goldilocks-core/commit/9654d590a5456645604c7eedf2e6322d56500745). - ### 3. Medium - Vault is losing asset in the sell flow #### Technical Details @@ -209,7 +208,7 @@ function _redeemOwnership(uint256 amount, bool checkVaultConclusion) internal { #### Developer Response -Acknowledged, we decided to remove unstakableYT [here](https://github.com/0xgeeb/goldilocks-core/commit/b78ccf00f48040047622d8d585011c1cb3324b13) and will make it clear on the UI that YT should be staked before selling or redeeming. +Acknowledged, we decided to remove unstakableYT [here](https://github.com/0xgeeb/goldilocks-core/commit/b78ccf00f48040047622d8d585011c1cb3324b13) and will make it clear on the UI that YT should be staked before selling or redeeming. ### 2. Low - Incorrect check for a flash loan amount @@ -227,7 +226,7 @@ Use `previewRedeem()` which accounts for withdrawal fees. ```diff - if(ERC4626(depositVault).convertToAssets(ERC20(depositVault).balanceOf(address(this))) < dtNeeded) revert FlashLoanFailed(); -+ if(ERC4626(depositVault).previewRedeem(ERC20(depositVault).balanceOf(address(this))) < dtNeeded) revert FlashLoanFailed(); ++ if(ERC4626(depositVault).previewRedeem(ERC20(depositVault).balanceOf(address(this))) < dtNeeded) revert FlashLoanFailed(); ``` #### Developer Response @@ -344,7 +343,7 @@ Informational. #### Recommendation -Rename the variable `tokenDecimals` to `inputRatioAmount` or something similar. +Rename the variable `tokenDecimals` to `inputRatioAmount` or something similar. #### Developer Response diff --git a/content/2025-03-Olympus-Cooler-Migrator-Composite.md b/content/2025-03-Olympus-Cooler-Migrator-Composite.md index 8865fb7..6fdf6d8 100644 --- a/content/2025-03-Olympus-Cooler-Migrator-Composite.md +++ b/content/2025-03-Olympus-Cooler-Migrator-Composite.md @@ -4,7 +4,7 @@ title: 2025-03-Olympus-Cooler-Migrator-and-Composite description: Olympus Migrator and Composite features for Cooler protocol --- -# Electisec Olympus Cooler - Migrator and Composite Review +# yAudit Olympus Cooler - Migrator and Composite Review **Review Resources:** @@ -18,7 +18,7 @@ None beyond the code repositories. ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -44,6 +44,7 @@ src/policies/cooler ``` **Migrator** + ``` src/policies/cooler/ |── CoolerV2Migrator.sol @@ -53,7 +54,7 @@ After the findings were presented to the Olympus team, fixes were made and inclu This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Olympus and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Olympus and users of the contracts agree to use the code at their own risk. ## Findings Explanation @@ -172,7 +173,7 @@ An attacker can abuse the migration process to tamper with other users' delegati #### Technical Details -The migration process allows users to set a new owner when loans are migrated to the Cooler V2. +The migration process allows users to set a new owner when loans are migrated to the Cooler V2. Since the process involves applying delegations and borrowing USDS, the new owner of the position must authorize the migrator contract to operate on their behalf, either by bundling the required signature in the migration or by calling `setAuthorization()` before starting the process. @@ -193,6 +194,7 @@ Fixed in [PR#57](https://github.com/OlympusDAO/olympus-v3/pull/57). ## Medium Findings None + ## Low Findings ### 1. Low - Missing USDS approval to Sky Migrator @@ -242,7 +244,7 @@ MonoCooler's [`repay()`](https://github.com/OlympusDAO/olympus-v3/blob/12d5f2ab2 470: // Cap the amount to be repaid to the current debt as of this block 471: if (repayAmount < latestDebt) { 472: amountRepaid = repayAmount; -473: +473: 474: // Ensure the minimum debt amounts are still maintained 475: unchecked { 476: aState.debtCheckpoint = _accountDebtCheckpoint = latestDebt - amountRepaid; @@ -289,6 +291,7 @@ if (authorization.account != address(0)) { COOLER.setAuthorizationWithSig(authorization, signature); } ``` + [CoolerComposites.sol#L41-L41](https://github.com/OlympusDAO/olympus-v3/blob/12d5f2ab2a187aafd6041c2b12b291b281506e31/src/policies/cooler/CoolerComposites.sol#L41-L41) [CoolerComposites.sol#L58-L58](https://github.com/OlympusDAO/olympus-v3/blob/12d5f2ab2a187aafd6041c2b12b291b281506e31/src/policies/cooler/CoolerComposites.sol#L58-L58) diff --git a/content/2025-03-Origami-hOHM-Migrator.md b/content/2025-03-Origami-hOHM-Migrator.md index 7507fd1..135cab1 100644 --- a/content/2025-03-Origami-hOHM-Migrator.md +++ b/content/2025-03-Origami-hOHM-Migrator.md @@ -4,7 +4,7 @@ title: 2025-03-Origami-hOHM-Migrator description: Security review of the Origami hOHM Migrator contract --- -# Electisec Origami hOHM Migrator Review +# yAudit Origami hOHM Migrator Review **Review Resources:** @@ -18,7 +18,7 @@ description: Security review of the Origami hOHM Migrator contract ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -40,7 +40,7 @@ After the findings were presented to the Origami hOHM Migrator team, fixes were This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Origami hOHM Migrator and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Origami hOHM Migrator and users of the contracts agree to use the code at their own risk. ## Findings Explanation @@ -97,7 +97,7 @@ Remove the type cast. Fixed in [2b076d1c](https://github.com/TempleDAO/origami/pull/1404/commits/2b076d1c3ddd1f387fd1c3937c7b0ad0ed85ce20). -### 2. Gas - Replace _`clearinghouses` with three constants +### 2. Gas - Replace \_`clearinghouses` with three constants #### Technical Details @@ -159,4 +159,4 @@ None. ## Final Remarks -Electisec reviewed the Origami Cooler migrator mechanism and found no major security issues or vulnerabilities in its implementation. +yAudit reviewed the Origami Cooler migrator mechanism and found no major security issues or vulnerabilities in its implementation. diff --git a/content/2025-04-Asymmetry-dASF.md b/content/2025-04-Asymmetry-dASF.md index bbc5d66..42d483b 100644 --- a/content/2025-04-Asymmetry-dASF.md +++ b/content/2025-04-Asymmetry-dASF.md @@ -4,7 +4,7 @@ title: 2025-04-Asymmetry-dASF description: Asymmetry dASF Security Review --- -# Electisec Asymmetry dASF Review +# yAudit Asymmetry dASF Review **Review Resources:** @@ -18,7 +18,7 @@ None beyond the code repositories. ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -54,21 +54,20 @@ After the findings were presented to the Asymmetry team, fixes were made and inc This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Asymmetry and users of the contracts agree to use the code at their own risk. - +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Asymmetry and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | The Ownable2Step logic in Solidity and Vyper variants provides suitable access control. | -| Mathematics | Average | A rounded division during dASF redemption might lead to overcharging users. | -| Complexity | Good | Contracts are well-designed and easy to understand. | -| Libraries | Good | The Solidity contract uses the OpenZeppelin library. No libraries are present in the Vyper implementation. | -| Decentralization | Average | While contracts are mostly permissionless, governance can enable privileged accounts to redeem dASF for free. | -| Code stability | Good | The codebase remained stable throughout the review. | -| Documentation | Average | Although no high-level documentation was provided, the contracts include inline comments describing their intended behavior. | -| Monitoring | Good | Monitoring events are in place, despite missing logging at initialization. | +| Category | Mark | Description | +| ------------------------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Access Control | Good | The Ownable2Step logic in Solidity and Vyper variants provides suitable access control. | +| Mathematics | Average | A rounded division during dASF redemption might lead to overcharging users. | +| Complexity | Good | Contracts are well-designed and easy to understand. | +| Libraries | Good | The Solidity contract uses the OpenZeppelin library. No libraries are present in the Vyper implementation. | +| Decentralization | Average | While contracts are mostly permissionless, governance can enable privileged accounts to redeem dASF for free. | +| Code stability | Good | The codebase remained stable throughout the review. | +| Documentation | Average | Although no high-level documentation was provided, the contracts include inline comments describing their intended behavior. | +| Monitoring | Good | Monitoring events are in place, despite missing logging at initialization. | | Testing and verification | Average | The codebase includes a testing suite with several tests that fork mainnet. However, coverage is not comprehensive as there aren't many tests exploring different execution paths, particularly in the price feed and flash dump contracts, which only have one test case each. | ## Findings Explanation @@ -200,7 +199,7 @@ Consider adding the fee to the repayment amount so the implementation continues #### Developer Response -Will use a different provider if they do so. +Will use a different provider if they do so. ### 2. Informational - Missing events for parameters during construction @@ -211,7 +210,6 @@ While setters emit events, parameters defined in constructors don't emit initial - [ownable_2step.vy#L47](https://github.com/asymmetryfinance/dASF/blob/e41a1c6b5b8bb7dc8d54de134374f50fd49b4582/src/ownable_2step.vy#L47) - [redemption.vy#L105-L109](https://github.com/asymmetryfinance/dASF/blob/e41a1c6b5b8bb7dc8d54de134374f50fd49b4582/src/redemption.vy#L105-L109) - #### Impact Informational. @@ -250,7 +248,7 @@ Fixed [here](https://github.com/asymmetryfinance/dASF/pull/1/commits/92d937346d4 When calling the function [`redeem()`](https://github.com/asymmetryfinance/dASF/blob/e41a1c6b5b8bb7dc8d54de134374f50fd49b4582/src/redemption.vy#L166-L166), the user will pay a certain amount of USAD depending on the current price of ASF and the number of weeks to lock them for. -There is currently no way for a user to input the maximum price of USAD he is willing to pay to redeem his DASF. If the price fluctuates or the discount changes while the transaction is being confirmed, a user may pay a slightly higher or lower price than expected. +There is currently no way for a user to input the maximum price of USAD he is willing to pay to redeem his DASF. If the price fluctuates or the discount changes while the transaction is being confirmed, a user may pay a slightly higher or lower price than expected. #### Impact diff --git a/content/2025-04-Ooga-Booga.md b/content/2025-04-Ooga-Booga.md index a35b82b..6c7d025 100644 --- a/content/2025-04-Ooga-Booga.md +++ b/content/2025-04-Ooga-Booga.md @@ -4,7 +4,7 @@ title: 2025-04-Ooga-Booga description: Ooga Booga's staking and rewards distribution review --- -# Electisec Ooga Booga Review +# yAudit Ooga Booga Review **Review Resources:** @@ -18,7 +18,7 @@ description: Ooga Booga's staking and rewards distribution review ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -45,22 +45,21 @@ After the findings were presented to the Ooga Booga team, fixes were made and in This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Ooga Booga and users of the contracts agree to use the code at their own risk. - +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Ooga Booga and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | The contracts correctly use access control checks on functions that need them. | -| Mathematics | Good | Correctly implemented mathematical relations are in the reviewed contracts. | +| Category | Mark | Description | +| ------------------------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Access Control | Good | The contracts correctly use access control checks on functions that need them. | +| Mathematics | Good | Correctly implemented mathematical relations are in the reviewed contracts. | | Complexity | Average | A straightforward staking algorithm is implemented, which presents a linear unvesting schedule. However, the complexity of the reward distribution cycle mechanism led to several findings. | -| Libraries | Good | The protocol builds on the OpenZeppelin library. | -| Decentralization | Average | Authorized parties are provided with the power to execute delicate configuration changes to the reviewed contracts. | -| Code stability | Good | The protocol's code is forked from deployed contracts with minor naming and contract configuration modifications. | -| Documentation | Average | Contracts have adequate inline comments, but no high-level documentation was provided. | -| Monitoring | Good | The reviewed contracts correctly emit events for crucial actions and state changes. | -| Testing and verification | Low | The provided contracts lack any tests. Developing a strong test suite with high line, function, and branch coverage is strongly encouraged. | +| Libraries | Good | The protocol builds on the OpenZeppelin library. | +| Decentralization | Average | Authorized parties are provided with the power to execute delicate configuration changes to the reviewed contracts. | +| Code stability | Good | The protocol's code is forked from deployed contracts with minor naming and contract configuration modifications. | +| Documentation | Average | Contracts have adequate inline comments, but no high-level documentation was provided. | +| Monitoring | Good | The reviewed contracts correctly emit events for crucial actions and state changes. | +| Testing and verification | Low | The provided contracts lack any tests. Developing a strong test suite with high line, function, and branch coverage is strongly encouraged. | ## Findings Explanation @@ -132,6 +131,7 @@ The [`emergencyWithdrawAll()`](https://github.com/0xoogabooga/oogabooga-token-co 268: _safeTokenTransfer(token, msg.sender, balance); 269: } ``` + ```solidity 274: function emergencyWithdrawAll() external nonReentrant onlyOwner { 275: for (uint256 index = 0; index < _distributedTokens.length(); ++index) { @@ -207,7 +207,7 @@ Amended as per recommendation from auditors. ```solidity 157: function pendingRewardsAmount(address token, address userAddress) external view returns (uint256) { 158: if (totalAllocation == 0) { -159: return 0; // AUDIT no allocation => no pending rewards? - what about user.pendingRewards? +159: return 0; // AUDIT no allocation => no pending rewards? - what about user.pendingRewards? 160: } ... 187: } @@ -260,7 +260,7 @@ The calculation of `userSOOGAAllocation.mul(accRewardsPerShare).div(1e18)` is re ```solidity 499: uint256 pending = 500: user.pendingRewards.add(userSOOGAAllocation.mul(accRewardsPerShare).div(1e18).sub(user.rewardDebt)); -501: +501: 502: user.pendingRewards = 0; 503: user.rewardDebt = userSOOGAAllocation.mul(accRewardsPerShare).div(1e18); ``` @@ -397,7 +397,7 @@ Amended as per recommendation from auditors. Once the first cycle has begun, if no account triggers a call to `_updateRewardsInfo`, the contract will fail to detect that the first cycle has already started. It will ultimately detect a cycle change once the cycle has begun and stream rewards starting from the beginning of the second cycle. -This occurs because cycle changes are detected by checking that `block.timestamp > currentCycleStartTime + _cycleDurationSeconds`. Because `currentCycleStartTime = startTime` is written within the contract's constructor, no cycle change will be computed until after `currentCycleStartTime + _cycleDurationSeconds`. +This occurs because cycle changes are detected by checking that `block.timestamp > currentCycleStartTime + _cycleDurationSeconds`. Because `currentCycleStartTime = startTime` is written within the contract's constructor, no cycle change will be computed until after `currentCycleStartTime + _cycleDurationSeconds`. Note that this also applies to users who have created allocations **before** `startTime` and plan on simply collecting fees after the first cycle has passed. diff --git a/content/2025-04-Sickle.md b/content/2025-04-Sickle.md index df439db..b007536 100644 --- a/content/2025-04-Sickle.md +++ b/content/2025-04-Sickle.md @@ -1,10 +1,10 @@ --- tags: ["solidity", "uniswap-v4", "uniswap-v3", "curve"] title: 2025-04-Sickle -description: Sickle Electisec Report +description: Sickle yAudit Report --- -# Electisec Sickle Uniswap and Curve integrations Review +# yAudit Sickle Uniswap and Curve integrations Review **Review Resources:** @@ -18,7 +18,7 @@ description: Sickle Electisec Report ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -57,21 +57,21 @@ After the findings were presented to the Sickle team, fixes were made and includ This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Sickle and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Sickle and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | Correct access control is implemented within the reviewed contracts. | -| Mathematics | Average| Simple mathematical relations are used within the reviewed contracts. Incorrect decimal precision adjustment issues were identified when interacting with non-standard ERC20 tokens. | -| Complexity | Average | The reviewed contracts present a high degree of complexity, given that the system's architecture forces the used abstractions to integrate correctly with existing contracts, both internal and external to Sickle. | -| Libraries | Good | The reviewed contracts make use of the well-established Solmate and OpenZeppelin libraries. | +| Category | Mark | Description | +| ------------------------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Access Control | Good | Correct access control is implemented within the reviewed contracts. | +| Mathematics | Average | Simple mathematical relations are used within the reviewed contracts. Incorrect decimal precision adjustment issues were identified when interacting with non-standard ERC20 tokens. | +| Complexity | Average | The reviewed contracts present a high degree of complexity, given that the system's architecture forces the used abstractions to integrate correctly with existing contracts, both internal and external to Sickle. | +| Libraries | Good | The reviewed contracts make use of the well-established Solmate and OpenZeppelin libraries. | | Decentralization | Average | Interacting with the system may result in rather complex processes if not initiated via Sickle's UI; nonetheless, users are granted full power and control over how their Sickle interacts with integrated protocols and assets. Key changes to registries must be executed via a timelock, granting users a time buffer to take necessary actions and precautions if need be. | -| Code stability | Good | The codebase remained stable throughout the review. | -| Documentation | Average | Accurate NATSPEC documentation is present within the main entry points and key data structure definitions. | -| Monitoring | Average | The system correctly emits logs for key changes and interactions. | -| Testing and verification | Average | The reviewed contracts have been tested with unit and integration tests. The lack of unit tests for key, non-standard scenarios revealed higher severity issues. | +| Code stability | Good | The codebase remained stable throughout the review. | +| Documentation | Average | Accurate NATSPEC documentation is present within the main entry points and key data structure definitions. | +| Monitoring | Average | The system correctly emits logs for key changes and interactions. | +| Testing and verification | Average | The reviewed contracts have been tested with unit and integration tests. The lack of unit tests for key, non-standard scenarios revealed higher severity issues. | ## Findings Explanation @@ -105,6 +105,7 @@ Hard-coding the input amount as `1e18` stands to create a significant error in t The curve pool will interpret `1e18` as a `10 ** (18 - token.decimals())` input amount, which will generate an error in the reported price's value and magnitude. The method does this when requesting both the direct and inverse price for two assets: + - [direct](https://github.com/vfat-io/sickle-contracts/blob/8ce412b25614ba8f6b01cd6406bc740926e6fadf/contracts/connectors/curve/CurvePoolConnector.sol#L75) - [inverse](https://github.com/vfat-io/sickle-contracts/blob/8ce412b25614ba8f6b01cd6406bc740926e6fadf/contracts/connectors/curve/CurvePoolConnector.sol#L83) @@ -120,7 +121,7 @@ Refactor the highlighted method to read the number of decimals used by the input @@ -14,6 +14,10 @@ struct CurveSwapExtraData { int128 j; } - + +interface IERC20Decimals { + function decimals() external view returns(uint256); +} @@ -173,6 +174,7 @@ Note that this issue is not present for ERC20 tokens, given that the exact amoun #### PoC Create a foundry project with Uniswap v4 libraries: + ```sh forge init univ4-testing cd univ4-testing @@ -181,11 +183,13 @@ forge install https://github.com/Uniswap/v4-periphery ``` Create a new test file: + ```sh touch test/PoC.t.sol ``` Within the newly created file, insert the following content: + ```solidity // SPDX-License-Identifier: UNLICENSED pragma solidity ^0.8.13; @@ -234,7 +238,7 @@ contract PoC is Test { vm.deal(alice, 1 << 128); deal(usdc, alice, 1 << 128); - + assertGt(address(posm).code.length, 0); vm.prank(alice); IERC20(usdc).approve(address(permit2), type(uint).max); @@ -261,7 +265,7 @@ contract PoC is Test { PoolKey memory key = posm.poolKeys(bytes25(poolId)); params[0] = abi.encode( - key, + key, tickLower, tickUpper, liq, @@ -313,6 +317,7 @@ contract PoC is Test { ``` Execute the PoC: + ``` forge t --mt test_excess_eth_is_claimable_by_third_party -vv ``` @@ -374,7 +379,7 @@ Because a Curve pool's `get_dy` method returns a raw amount of tokens, `amountOu 1. If `amountOut1` is expressed with `18` decimals of precision, `price` will have precisely `18` decimals of precision, as expected. 2. If `amountOut1` is **not** expressed with `18` decimals of precision, `price` will be expressed in `18 - baseToken.decimals()`. - - In the case in which `baseTokens.decimals() > 18`, `price` risks being rounded down to `0`, making the transaction revert with an `InvalidPrice()` error. + - In the case in which `baseTokens.decimals() > 18`, `price` risks being rounded down to `0`, making the transaction revert with an `InvalidPrice()` error. #### Impact @@ -388,7 +393,7 @@ Refactor the inversion to use `18 + baseToken.decimals()` in the numerator so th @@ -14,6 +14,10 @@ struct CurveSwapExtraData { int128 j; } - + +interface IERC20Decimals { + function decimals() external view returns(uint256); +} @@ -406,7 +411,7 @@ Refactor the inversion to use `18 + baseToken.decimals()` in the numerator so th + + price = 10 ** (18 + baseTokenDecimals) / amountOut1; } - + if (price == 0) { ``` @@ -454,8 +459,7 @@ Fixed in commit [5205655](https://github.com/vfat-io/sickle-contracts/commit/520 Connectors that implement the [`ILiquidityConnector`](https://github.com/vfat-io/sickle-contracts/blob/8ce412b25614ba8f6b01cd6406bc740926e6fadf/contracts/interfaces/ILiquidityConnector.sol) interface may be used by the [`SwapLib`](https://github.com/vfat-io/sickle-contracts/blob/8ce412b25614ba8f6b01cd6406bc740926e6fadf/contracts/libraries/SwapLib.sol) library to execute one or many swaps on the connector's target protocol. Since [`SwapLib._swap()`](https://github.com/vfat-io/sickle-contracts/blob/8ce412b25614ba8f6b01cd6406bc740926e6fadf/contracts/libraries/SwapLib.sol#L44-L83) correctly handles and sets token approvals for the Sickle before calling a connector's swap function, connectors generally do not need to manage approvals themselves. This is the case for [`UniswapV2Connector`](), which does not contain any calls to `IERC20.approve()`. -However, this is not true for `UniswapV3Connector`: its `swapExactTokensForTokens()` method explicitly approves the swap router before performing the swap. - +However, this is not true for `UniswapV3Connector`: its `swapExactTokensForTokens()` method explicitly approves the swap router before performing the swap. ```solidity 86: function swapExactTokensForTokens( @@ -485,7 +489,6 @@ Additionally, given that `IERC20.approve()` is used expecting a `bool` return va As a result, because `SwapLib` has already set a non-zero allowance, transactions involving tokens that require allowances first to be reset to `0` before being updated — such as USDT — will fail. Furthermore, since `IERC20.approve()` is called with the expectation that it returns a `bool`, using non-standard tokens that do not return any data from `approve()` will also cause the transaction to fail. - #### Impact Medium. `UniswapV3Connector.swapExactTokensForTokens` will malfunction when using non-standard tokens. @@ -498,7 +501,6 @@ Conform to the standard connector behavior of not setting an allowance, given th Fixed in commit [39a80a4](https://github.com/vfat-io/sickle-contracts/commit/39a80a425eaae610914ef9aa41cce29fd68c013f). - ## Low Findings ### 1. Low - Different representations of native `ETH` could lead to transaction failure @@ -730,7 +732,7 @@ Adapt the `_checkMsgValue()` call to also consider `UNISWAP_ETH` as native curre ) public payable checkTransferFrom(tokenIn, amountIn) { - _checkMsgValue(amountIn, tokenIn == ETH); + _checkMsgValue(amountIn, tokenIn == ETH || tokenIn == UNISWAP_ETH); - + _transferTokenFromUser(tokenIn, amountIn, strategy, feeSelector); } ``` @@ -1126,7 +1128,7 @@ Fixed in commit [c3596f7](https://github.com/vfat-io/sickle-contracts/commit/c35 #### Technical Details -While `TransferLib.chargeFee()` returns a number of tokens to which the protocol's fees have been subtracted, the batch method `TransferLib.chargeFees()` doesn't return any data. +While `TransferLib.chargeFee()` returns a number of tokens to which the protocol's fees have been subtracted, the batch method `TransferLib.chargeFees()` doesn't return any data. #### Impact @@ -1304,7 +1306,6 @@ Provide `deadline = block.timestamp` instead of `deadline = block.timestamp + 1` Fixed in commit [05baa1d](https://github.com/vfat-io/sickle-contracts/commit/05baa1d0ee11f8c435209ab21553c2f8af41e3a9). - ### 9. Informational - Implement hooks validation in `UniswapV4Connector` The `UniswapV4Connector` contract accepts and processes arbitrary hooks without any validation mechanism. diff --git a/content/2025-04-Twyne.md b/content/2025-04-Twyne.md index 389a6d9..09dee43 100644 --- a/content/2025-04-Twyne.md +++ b/content/2025-04-Twyne.md @@ -4,7 +4,7 @@ title: 2025-04-Twyne description: Twyne Protocol Security Review --- -# Electisec Twyne Review +# yAudit Twyne Review **Review Resources:** @@ -18,7 +18,7 @@ description: Twyne Protocol Security Review ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -55,22 +55,21 @@ After the findings were presented to the Twyne team, fixes were made and include This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Twyne and users of the contracts agree to use the code at their own risk. - +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Twyne and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | Proper access control is in place to secure governance actions and borrower access to the collateral vault. | -| Mathematics | Average | Potential overflows were identified in the implementation of some calculations. | -| Complexity | Average | The novel mechanics and the non-standard usage of the vault increase complexity. | -| Libraries | Good | The implementation uses the OpenZeppelin library and integrates with Euler's EVC and EVK. | -| Decentralization | Good | Privileged actions are kept at a minimum to adjust protocol-wide settings. Users can unwind their position if the protocol is paused. | -| Code stability | Good | The codebase remained stable throughout the review. | -| Documentation | Good | Detailed documentation about the protocol and the mathematical foundations were presented to the auditors. | -| Monitoring | Low | At the start of the audit, the code was missing events, preventing accessible off-chain monitoring. This was fixed during the review, greatly improving off-chain monitoring capabilities. | -| Testing and verification | Good | The codebase includes a comprehensive testing suite with good coverage. The team has informed us that an invariant test suite is being developed. | +| Category | Mark | Description | +| ------------------------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | +| Access Control | Good | Proper access control is in place to secure governance actions and borrower access to the collateral vault. | +| Mathematics | Average | Potential overflows were identified in the implementation of some calculations. | +| Complexity | Average | The novel mechanics and the non-standard usage of the vault increase complexity. | +| Libraries | Good | The implementation uses the OpenZeppelin library and integrates with Euler's EVC and EVK. | +| Decentralization | Good | Privileged actions are kept at a minimum to adjust protocol-wide settings. Users can unwind their position if the protocol is paused. | +| Code stability | Good | The codebase remained stable throughout the review. | +| Documentation | Good | Detailed documentation about the protocol and the mathematical foundations were presented to the auditors. | +| Monitoring | Low | At the start of the audit, the code was missing events, preventing accessible off-chain monitoring. This was fixed during the review, greatly improving off-chain monitoring capabilities. | +| Testing and verification | Good | The codebase includes a comprehensive testing suite with good coverage. The team has informed us that an invariant test suite is being developed. | ## Findings Explanation @@ -115,16 +114,16 @@ Example: LTVtwyne=95% LTVLiquidationAave=80% LTVBorrowAave=78% Buffer=98% Deposit=100$ reserve=30$ total=130$ borrow=95$ -Collateral vault: 100 * .95 >= 95 -> can't be liquidated -Target vault: 130 * (80% * 98%) > 95 -> can't be externally liquidated +Collateral vault: 100 _ .95 >= 95 -> can't be liquidated +Target vault: 130 _ (80% \* 98%) > 95 -> can't be externally liquidated The reserve should be around ~22$, but we borrowed a little over (excess credit). No one calls `rebalance()`, and the price drops by 5%. Deposit=95$ reserve=28.5$ total=123.5$ borrow=95$ -Collateral vault: 95 * .95 < 95 -> can be liquidated but liquidator **won't make a profit** -123.5 * (80% * 98%) > 95 -> can't be externally liquidated +Collateral vault: 95 _ .95 < 95 -> can be liquidated but liquidator **won't make a profit** +123.5 _ (80% \* 98%) > 95 -> can't be externally liquidated We end up in a case where the vault is between both liquidations. The lenders can't call `rebalance()` at this point, as releasing assets from the collateral vault will result in a negative health factor position from the external protocol's perspective, meaning the call will revert. So, we have to wait for the collateral value to increase. Hence, it becomes profitable to liquidate on Twyne or to decrease enough for the external liquidation to trigger, but at the cost of the intermediate vault lenders. @@ -147,8 +146,8 @@ Fixed in [PR #14](https://github.com/0xTwyne/twyne-contracts-v1/pull/14) & [PR # The Twyne implementation relies on two pricing paths: -1) `asset() -> intermediateVault.UOA()` (`eWETH -> USD`) -2) `targetAsset -> asset().asset()` (`USDC -> WETH`) +1. `asset() -> intermediateVault.UOA()` (`eWETH -> USD`) +2. `targetAsset -> asset().asset()` (`USDC -> WETH`) The first path should be covered by the configuration in [`newIntermediateVault()`](https://github.com/0xTwyne/twyne-contracts-v1/blob/d8bc90af6d16e85b80cb79cb4f899ba1fcc27bc2/script/TwyneDeployEulerIntegration.s.sol#L197-L199). @@ -316,7 +315,7 @@ Apply the changes suggested. #### Developer Response -Fixed in [PR #8](https://github.com/0xTwyne/twyne-contracts-v1/pull/8) & [PR #18](https://github.com/0xTwyne/twyne-contracts-v1/pull/18). +Fixed in [PR #8](https://github.com/0xTwyne/twyne-contracts-v1/pull/8) & [PR #18](https://github.com/0xTwyne/twyne-contracts-v1/pull/18). ### 2. Gas - Unnecessary check in `checkLiqLTVByCollateralVault()` diff --git a/content/2025-05-Asymmetry-USDaf-V2.md b/content/2025-05-Asymmetry-USDaf-V2.md index d93f1b4..fc6e64a 100644 --- a/content/2025-05-Asymmetry-USDaf-V2.md +++ b/content/2025-05-Asymmetry-USDaf-V2.md @@ -4,7 +4,7 @@ title: 2025-05-Asymmetry-USDaf-V2 description: Asymmetry USDaf V2 Security Review --- -# Electisec Asymmetry USDaf V2 Review +# yAudit Asymmetry USDaf V2 Review **Review Resources:** @@ -18,13 +18,13 @@ description: Asymmetry USDaf V2 Security Review ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary **USDaf** -USDaf is a synthetic dollar, part of a collateralized debt position (CDP), backed by a stablecoin and BTC basket. +USDaf is a synthetic dollar, part of a collateralized debt position (CDP), backed by a stablecoin and BTC basket. The codebase is forked from Liquity V2 (codename _bold_) and adjusted to include the collateral changes. @@ -66,22 +66,21 @@ After the findings were presented to the Asymmetry team, fixes were made and inc This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Asymmetry and users of the contracts agree to use the code at their own risk. - +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Asymmetry and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | Most changes don't require access control. The InterestRouter contract, owned by the Asymmetry multisig, acts as the Liquity Governance replacement. | -| Mathematics | Good | No arithmetic issues were detected. | -| Complexity | Average | While the changes do not involve an increase in complexity, it is important to note that Liquity itself is a complex protocol. | -| Libraries | Good | The codebase relies on the OpenZeppelin library. | -| Decentralization | Good | The protocol inherits the decentralized nature of Liquity. | -| Code stability | Good | No changes were made to the contract during the review. | -| Documentation | Good | Being a Liquity fork, there is plenty of documentation available. | -| Monitoring | Good | Monitoring events are correctly emitted. | -| Testing and verification | Average | Even though Liquity has been extensively tested, additional testing of the zapper and pricing functionality is recommended. | +| Category | Mark | Description | +| ------------------------ | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- | +| Access Control | Good | Most changes don't require access control. The InterestRouter contract, owned by the Asymmetry multisig, acts as the Liquity Governance replacement. | +| Mathematics | Good | No arithmetic issues were detected. | +| Complexity | Average | While the changes do not involve an increase in complexity, it is important to note that Liquity itself is a complex protocol. | +| Libraries | Good | The codebase relies on the OpenZeppelin library. | +| Decentralization | Good | The protocol inherits the decentralized nature of Liquity. | +| Code stability | Good | No changes were made to the contract during the review. | +| Documentation | Good | Being a Liquity fork, there is plenty of documentation available. | +| Monitoring | Good | Monitoring events are correctly emitted. | +| Testing and verification | Average | Even though Liquity has been extensively tested, additional testing of the zapper and pricing functionality is recommended. | ## Findings Explanation @@ -206,7 +205,7 @@ Some changes in Liquity's zappers can be adapted to the USDaf zapper. #### Technical Details -- Include the original caller address in the index when opening a trove: +- Include the original caller address in the index when opening a trove: - [WETHZapper.sol#L32](https://github.com/asymmetryfinance/USDaf-v2/blob/cc3bd0537ad4555c34ab58ca285c11284c252fec/contracts/src/Zappers/WETHZapper.sol#L32) - Ensure the zapper contract is the actual receiver when redeeming assets: - [WETHZapper.sol#L92](https://github.com/asymmetryfinance/USDaf-v2/blob/cc3bd0537ad4555c34ab58ca285c11284c252fec/contracts/src/Zappers/WETHZapper.sol#L92) @@ -231,7 +230,7 @@ Fixed in [65d46f5](https://github.com/asymmetryfinance/USDaf-v2/commit/65d46f594 [The USDS oracle currently uses the DAI Chainlink price feed](https://github.com/asymmetryfinance/USDaf-v2/blob/cc3bd0537ad4555c34ab58ca285c11284c252fec/contracts/src/PriceFeeds/USDaf/SusdsOracle.sol#L10-L10). -USDS and DAI are convertible, and some existing lending markets, such as AAVE and Morpho, use DAI price feeds to price USDS. +USDS and DAI are convertible, and some existing lending markets, such as AAVE and Morpho, use DAI price feeds to price USDS. However, given Liquity's immutable nature, if the DAI to USDS convertibility were to change, it could become dangerous for the protocol to keep using the DAI price feed. diff --git a/content/2025-05-CAP-PremainnetVault-update.md b/content/2025-05-CAP-PremainnetVault-update.md index c6f5d63..3f8894b 100644 --- a/content/2025-05-CAP-PremainnetVault-update.md +++ b/content/2025-05-CAP-PremainnetVault-update.md @@ -4,7 +4,7 @@ title: 2025-05-CAP-PremainnetVault-update description: CAP Pre-mainnet vault update report --- -# Electisec CAP Pre-Mainnet Vault Update Review +# yAudit CAP Pre-Mainnet Vault Update Review **Review Resources:** @@ -18,7 +18,7 @@ description: CAP Pre-mainnet vault update report ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -40,21 +40,21 @@ After the findings were presented to the CAP team, fixes were made and included This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, CAP and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, CAP and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | Access control mechanisms are implemented appropriately where necessary. | -| Mathematics | Good | No complex calculations are involved. | -| Complexity | Good | The codebase is simple and easy to understand. | -| Libraries | Good | Utilizes OpenZeppelin and LayerZero libraries for security and best practices. | -| Decentralization | Good | Users can withdraw funds even if the owner does not unlock transfers. | -| Code stability | Good | The codebase was stable during the audit. | -| Documentation | Good | Well-documented with NatSpec comments, with only minor omissions. | -| Monitoring | Good | Events are emitted within state-changing functions. | -| Testing and verification | Average | Includes unit tests but lacks invariant testing and fuzzing. | +| Category | Mark | Description | +| ------------------------ | ------- | ------------------------------------------------------------------------------ | +| Access Control | Good | Access control mechanisms are implemented appropriately where necessary. | +| Mathematics | Good | No complex calculations are involved. | +| Complexity | Good | The codebase is simple and easy to understand. | +| Libraries | Good | Utilizes OpenZeppelin and LayerZero libraries for security and best practices. | +| Decentralization | Good | Users can withdraw funds even if the owner does not unlock transfers. | +| Code stability | Good | The codebase was stable during the audit. | +| Documentation | Good | Well-documented with NatSpec comments, with only minor omissions. | +| Monitoring | Good | Events are emitted within state-changing functions. | +| Testing and verification | Average | Includes unit tests but lacks invariant testing and fuzzing. | ## Findings Explanation @@ -107,7 +107,7 @@ Fixed in [PR#154](https://github.com/cap-labs-dev/cap-contracts/pull/154). #### Technical Details -Variables [`asset`, `cap` and `stakedCap` are cast](https://github.com/cap-labs-dev/cap-contracts/blob/5ddb865c429c6c9216e60c5e5e3d70f695bc9285/contracts/testnetCampaign/PreMainnetVault.sol#L90-L91) to address types. Instead of casting variables to address type, input parameters that are of the correct type can be used instead. +Variables [`asset`, `cap` and `stakedCap` are cast](https://github.com/cap-labs-dev/cap-contracts/blob/5ddb865c429c6c9216e60c5e5e3d70f695bc9285/contracts/testnetCampaign/PreMainnetVault.sol#L90-L91) to address types. Instead of casting variables to address type, input parameters that are of the correct type can be used instead. #### Impact @@ -115,7 +115,7 @@ Gas savings. #### Recommendation -Use address variable `_asset ` instead of `asset`, _cap` instead of `cap` and `_stakedCap` instead of `stakedCap` [when approving](https://github.com/cap-labs-dev/cap-contracts/blob/5ddb865c429c6c9216e60c5e5e3d70f695bc9285/contracts/testnetCampaign/PreMainnetVault.sol#L90-L91) to save gas. +Use address variable `_asset ` instead of `asset`, \_cap`instead of`cap`and`\_stakedCap`instead of`stakedCap` [when approving](https://github.com/cap-labs-dev/cap-contracts/blob/5ddb865c429c6c9216e60c5e5e3d70f695bc9285/contracts/testnetCampaign/PreMainnetVault.sol#L90-L91) to save gas. #### Developer Response @@ -147,7 +147,7 @@ Fixed in [PR#155](https://github.com/cap-labs-dev/cap-contracts/pull/155). #### Technical Details -Immutable [`cap` variable](https://github.com/cap-labs-dev/cap-contracts/blob/5ddb865c429c6c9216e60c5e5e3d70f695bc9285/contracts/testnetCampaign/PreMainnetVault.sol#L29C29-L29C32) is defined as `IVault`. Later in the contract, it is [cast to `IMinter`](https://github.com/cap-labs-dev/cap-contracts/blob/5ddb865c429c6c9216e60c5e5e3d70f695bc9285/contracts/testnetCampaign/PreMainnetVault.sol#L127). +Immutable [`cap` variable](https://github.com/cap-labs-dev/cap-contracts/blob/5ddb865c429c6c9216e60c5e5e3d70f695bc9285/contracts/testnetCampaign/PreMainnetVault.sol#L29C29-L29C32) is defined as `IVault`. Later in the contract, it is [cast to `IMinter`](https://github.com/cap-labs-dev/cap-contracts/blob/5ddb865c429c6c9216e60c5e5e3d70f695bc9285/contracts/testnetCampaign/PreMainnetVault.sol#L127). #### Impact diff --git a/content/2025-05-Cozy-Safety-Module.md b/content/2025-05-Cozy-Safety-Module.md index 3a4173d..2f299ae 100644 --- a/content/2025-05-Cozy-Safety-Module.md +++ b/content/2025-05-Cozy-Safety-Module.md @@ -4,7 +4,7 @@ title: 2025-05-Cozy-safety-module description: cozy safety module report --- -# Electisec Cozy safety module Review +# yAudit Cozy safety module Review **Review Resources:** @@ -19,7 +19,7 @@ description: cozy safety module report ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -57,26 +57,26 @@ src/ ├── StateChanger.sol ├── StateTransitionsLib.sol ``` + After the findings were presented to the Cozy safety module team, fixes were made and included in several PRs. This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Cozy safety module and users of the contracts agree to use the code at their own risk. - +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Cozy safety module and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | Role-based permissions well implemented with a clear ownership model. | -| Mathematics | Average | Potential rounding issues in redemption calculations affecting invariants. | -| Complexity | Good | Clean architecture with well-defined responsibilities. | -| Libraries | Average | Some unnecessary imports and dependencies. | -| Decentralization | Average | Governance actors can significantly impact the safety module by pausing it or adding Trigger and Payout addresses, which reduces the level of decentralization. | -| Code stability | Good | The codebase remained stable, with little to no new development introduced during the review. | -| Documentation | Good | Inline comments and function documentation are present. | -| Monitoring | Good | Good event coverage. | -| Testing and verification | Average | Good test coverage and invariant suite, but some findings suggest room for improvement, such as integration tests. | +| Category | Mark | Description | +| ------------------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Access Control | Good | Role-based permissions well implemented with a clear ownership model. | +| Mathematics | Average | Potential rounding issues in redemption calculations affecting invariants. | +| Complexity | Good | Clean architecture with well-defined responsibilities. | +| Libraries | Average | Some unnecessary imports and dependencies. | +| Decentralization | Average | Governance actors can significantly impact the safety module by pausing it or adding Trigger and Payout addresses, which reduces the level of decentralization. | +| Code stability | Good | The codebase remained stable, with little to no new development introduced during the review. | +| Documentation | Good | Inline comments and function documentation are present. | +| Monitoring | Good | Good event coverage. | +| Testing and verification | Average | Good test coverage and invariant suite, but some findings suggest room for improvement, such as integration tests. | ## Findings Explanation @@ -90,6 +90,7 @@ Findings are broken down into sections by their respective impact: - Findings including recommendations and best practices. --- + ## Critical Findings None. @@ -246,7 +247,6 @@ File: src/CozySafetyModuleManager.sol [CozySafetyModuleManager.sol#L176](https://github.com/Cozy-Finance/cozy-safety-module-private/blob/638f6e740cedc07e8a96071fc628c792ef3710ab/src/CozySafetyModuleManager.sol#L176) - #### Impact Gas savings. @@ -297,6 +297,7 @@ Fixed: https://github.com/Cozy-Finance/cozy-safety-module-private/pull/126. #### Technical Details The `_getCallerRole` function currently uses a temporary variable `role_` to store the caller's role before returning it. This approach requires an unnecessary variable declaration and multiple assignments, resulting in higher gas costs. + ```solidity File: StateChanger.sol 119: function _getCallerRole(address who_) internal view returns (CallerRole) { @@ -460,7 +461,6 @@ File: src/lib/StateChanger.sol [src/lib/StateChanger.sol#L7](https://github.com/Cozy-Finance/cozy-safety-module-private/blob/638f6e740cedc07e8a96071fc628c792ef3710ab/src/lib/StateChanger.sol#L7) - #### Impact Informational. @@ -475,7 +475,6 @@ Fixed: https://github.com/Cozy-Finance/cozy-safety-module-private/pull/123. ### 2. Informational - Typos - #### Technical Details ```solidity @@ -487,7 +486,6 @@ File: src/lib/Redeemer.sol [src/lib/Redeemer.sol#L95](https://github.com/Cozy-Finance/cozy-safety-module-private/blob/638f6e740cedc07e8a96071fc628c792ef3710ab/src/lib/Redeemer.sol#L95) - #### Impact informational. @@ -500,7 +498,6 @@ Fix the typo. Fixed: https://github.com/Cozy-Finance/cozy-safety-module-private/pull/124. - ### 3. Informational - `else` block unnecessary By eliminating the `else` block and directly returning the values from the `if`-block, one level of nesting can be removed: @@ -539,7 +536,6 @@ File: src/lib/SafetyModuleInspector.sol [src/lib/SafetyModuleInspector.sol#L86](https://github.com/Cozy-Finance/cozy-safety-module-private/blob/638f6e740cedc07e8a96071fc628c792ef3710ab/src/lib/SafetyModuleInspector.sol#L86) - #### Impact Informational. @@ -552,7 +548,6 @@ Remove the else block. Fixed: https://github.com/Cozy-Finance/cozy-safety-module-private/pull/125. - ### 4. Informational - Rename `redemptionAmount_` parameter inside `updateRedemptionsAfterTrigger()` #### Technical Details diff --git a/content/2025-05-Cozy-Safety-module-Reward-Manager.md b/content/2025-05-Cozy-Safety-module-Reward-Manager.md index 0e4e1db..4f53c22 100644 --- a/content/2025-05-Cozy-Safety-module-Reward-Manager.md +++ b/content/2025-05-Cozy-Safety-module-Reward-Manager.md @@ -4,7 +4,7 @@ title: 2025-05-Cozy-safety-module-reward-manager description: Cozy safety module reward manager report --- -# Electisec Cozy safety module reward manager Review +# yAudit Cozy safety module reward manager Review **Review Resources:** @@ -18,7 +18,7 @@ description: Cozy safety module reward manager report ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -70,22 +70,21 @@ After the findings were presented to the Cozy team, fixes were made and included This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Cozy safety module reward manager and users of the contracts agree to use the code at their own risk. - +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Cozy safety module reward manager and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | Role-based permissions well implemented with a clear ownership model. | -| Mathematics | Good | The mathematical calculations appear correct, and no arithmetic issues were identified. | +| Category | Mark | Description | +| ------------------------ | ------- | ------------------------------------------------------------------------------------------------------------------------------------------ | +| Access Control | Good | Role-based permissions well implemented with a clear ownership model. | +| Mathematics | Good | The mathematical calculations appear correct, and no arithmetic issues were identified. | | Complexity | Average | Supporting multiple staked and reward tokens increases complexity. Certain architectural choices also contribute to this added complexity. | -| Libraries | Average | Some unnecessary imports and dependencies. | -| Decentralization | Good | Protocol allows permissionless operation with appropriate governance. | -| Code stability | Good | The codebase remained stable, with little to no new development introduced during the review. | -| Documentation | Good | Inline comments and function documentation are present. | -| Monitoring | Good | Good event coverage. | -| Testing and verification | Good | Good test coverage and invariant suite. Be cautious when using mock contracts for testing. | +| Libraries | Average | Some unnecessary imports and dependencies. | +| Decentralization | Good | Protocol allows permissionless operation with appropriate governance. | +| Code stability | Good | The codebase remained stable, with little to no new development introduced during the review. | +| Documentation | Good | Inline comments and function documentation are present. | +| Monitoring | Good | Good event coverage. | +| Testing and verification | Good | Good test coverage and invariant suite. Be cautious when using mock contracts for testing. | ## Findings Explanation @@ -99,6 +98,7 @@ Findings are broken down into sections by their respective impact: - Findings including recommendations and best practices. --- + ## Critical Findings None. @@ -133,7 +133,6 @@ Call `_dripAndApplyPendingDrippedRewards()` before updating a users rewards if t Acknowledged. We will leave the implementation unchanged. We had discussed this at time of design and wanted to keep it as is. One can obviously always explicitly claim rewards prior to transferring stake receipt tokens if desired. - ## Gas Saving Findings ### 1. Gas - Structs can be packed into fewer storage slots @@ -142,7 +141,6 @@ Each slot saved can avoid an extra Gsset (**20000 gas**) for the first setting o #### Technical Details - ```solidity File: src/lib/RewardsDistributor.sol @@ -195,7 +193,6 @@ File: src/lib/structs/Rewards.sol [src/lib/structs/Rewards.sol#L41](https://github.com/Cozy-Finance/cozy-safety-module-rewards-manager/blob/5ca18ab03f8430be7285097eca83d86fb52e3700/src/lib/structs/Rewards.sol#L41) - #### Impact Gas savings. @@ -222,7 +219,7 @@ Since the stkToken is always worth 1 - 1 underlying asset, the library can be re - Additionally, multiple contracts have unused imports. Consider removing them: -All of the imports missing: +All of the imports missing: ```solidity File: src/interfaces/IDepositorEvents.sol @@ -286,7 +283,6 @@ File: src/lib/Staker.sol [src/lib/Staker.sol#L11](https://github.com/Cozy-Finance/cozy-safety-module-rewards-manager/blob/5ca18ab03f8430be7285097eca83d86fb52e3700/src/lib/Staker.sol#L11) - #### Impact Informational. @@ -340,5 +336,5 @@ Fixed: https://github.com/Cozy-Finance/cozy-safety-module-rewards-manager/pull/5 ## Final remarks -The Cozy Safety Module Reward Manager features a robust codebase with a comprehensive test suite; no critical vulnerabilities were found. However, the auditors caution against the extensive use of mock contracts in testing, as they may not always accurately reflect real conditions and the additional complexity introduced by certain reward computation mechanisms. The team provided extra fixes that were not +The Cozy Safety Module Reward Manager features a robust codebase with a comprehensive test suite; no critical vulnerabilities were found. However, the auditors caution against the extensive use of mock contracts in testing, as they may not always accurately reflect real conditions and the additional complexity introduced by certain reward computation mechanisms. The team provided extra fixes that were not directly linked to findings, and these commits were also reviewed, up to [PR#63](https://github.com/Cozy-Finance/cozy-safety-module-rewards-manager/pull/63). diff --git a/content/2025-05-HAI-Oracle.md b/content/2025-05-HAI-Oracle.md index 46fffcf..5fa258a 100644 --- a/content/2025-05-HAI-Oracle.md +++ b/content/2025-05-HAI-Oracle.md @@ -4,7 +4,7 @@ title: 2025-05-Pessimistic-Velodrome-LP-Oracle description: Security review of the Pessimistic Velodrome LP Oracle used in the HAI protocol --- -# Electisec Pessimistic Velodrome LP Oracle Review +# yAudit Pessimistic Velodrome LP Oracle Review **Review Resources:** @@ -18,7 +18,7 @@ description: Security review of the Pessimistic Velodrome LP Oracle used in the ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -43,22 +43,21 @@ After the findings were presented to the HAI team, fixes were made and included This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, HAI and users of the contracts agree to use the code at their own risk. - +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, HAI and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | Proper access control rules are in place. | -| Mathematics | Good | Mathematical operations are correctly implemented. | -| Complexity | Good | The codebase is straightforward and easy to follow. | -| Libraries | Good | The implementation uses the OpenZeppelin library and a copy of the fixed point utilities from Solmate. | -| Decentralization | Average | While the state is mostly immutable, the contract relies on an operator to record daily lows. | -| Code stability | Good | The codebase remained stable throughout the review. | -| Documentation | Good | The _readme_ includes a good description of the design and mathematical concepts applied in the Oracle, with proper references to its sources. | -| Monitoring | Good | Appropriate events are emitted for off-chain monitoring. | -| Testing and verification | Average | While the original implementation has an extensive set of tests, these were not ported to the new "single" variant of the Oracle. | +| Category | Mark | Description | +| ------------------------ | ------- | ---------------------------------------------------------------------------------------------------------------------------------------------- | +| Access Control | Good | Proper access control rules are in place. | +| Mathematics | Good | Mathematical operations are correctly implemented. | +| Complexity | Good | The codebase is straightforward and easy to follow. | +| Libraries | Good | The implementation uses the OpenZeppelin library and a copy of the fixed point utilities from Solmate. | +| Decentralization | Average | While the state is mostly immutable, the contract relies on an operator to record daily lows. | +| Code stability | Good | The codebase remained stable throughout the review. | +| Documentation | Good | The _readme_ includes a good description of the design and mathematical concepts applied in the Oracle, with proper references to its sources. | +| Monitoring | Good | Appropriate events are emitted for off-chain monitoring. | +| Testing and verification | Average | While the original implementation has an extensive set of tests, these were not ported to the new "single" variant of the Oracle. | ## Findings Explanation diff --git a/content/2025-05-Olympus-CCIP.md b/content/2025-05-Olympus-CCIP.md index 209d223..2ccfa67 100644 --- a/content/2025-05-Olympus-CCIP.md +++ b/content/2025-05-Olympus-CCIP.md @@ -4,7 +4,7 @@ title: 2025-05-Olympus-CCIP description: Olympus OHM bridge using CCIP --- -# Electisec Olympus OHM CCIP PR#69 Review +# yAudit Olympus OHM CCIP PR#69 Review **Review Resources:** @@ -18,7 +18,7 @@ description: Olympus OHM bridge using CCIP ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -32,7 +32,6 @@ The PR of the Olympus OHM CCIP [Repo](https://github.com/OlympusDAO/olympus-v3) The scope of the review consisted of the following contracts at the specific commit: - ``` src/ ├── periphery/ @@ -51,7 +50,7 @@ src/ This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Olympus OHM CCIP and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, Olympus OHM CCIP and users of the contracts agree to use the code at their own risk. ## Findings Explanation @@ -71,12 +70,15 @@ Findings are broken down into sections by their respective impact: ## Critical Findings None + ## High Findings None + ## Medium Findings None + ## Low Findings ### 1. Low - SVM trusted remotes can't be revoked @@ -116,12 +118,12 @@ Modify the method to allow writing any boolean value to the remote's `isSet` fie } @@ -49,7 +49,7 @@ interface ICCIPCrossChainBridge { - + event TrustedRemoteEVMSet(uint64 indexed dstChainSelector, address indexed to); - + - event TrustedRemoteSVMSet(uint64 indexed dstChainSelector, bytes32 indexed to); + event TrustedRemoteSVMSet(uint64 indexed dstChainSelector, bytes32 indexed to, bool isSet); - + event MessageFailed(bytes32 messageId); ``` @@ -132,6 +134,7 @@ Fixed in [PR#72](https://github.com/OlympusDAO/olympus-v3/pull/72). ## Gas Saving Findings None + ## Informational Findings ### 1. Informational - CCIPCrossChainBridge allows an empty cross-chain sender to pass verification @@ -172,31 +175,31 @@ Informational Modify the `PeripheryEnabler` contract, adding a `supportInterface(bytes4)` method, e.g.: - ```diff +```diff @@ -88,4 +88,8 @@ abstract contract PeripheryEnabler is IEnabler { - // Emit the disabled event - emit Disabled(); - } + // Emit the disabled event + emit Disabled(); + } + + function supportsInterface(bytes4 interfaceId_) public view virtual returns(bool) { + return interfaceId_ == type(IEnabler).interfaceId; + } - } +} @@ -460,10 +460,11 @@ contract CCIPCrossChainBridge is CCIPReceiver, PeripheryEnabler, Owned, ICCIPCro - return i_ccipRouter; - } - + return i_ccipRouter; + } + - function supportsInterface(bytes4 interfaceId_) public view virtual override returns (bool) { + function supportsInterface(bytes4 interfaceId_) public view virtual override(CCIPReceiver, PeripheryEnabler) returns (bool) { - return - interfaceId_ == type(ICCIPCrossChainBridge).interfaceId || + return + interfaceId_ == type(ICCIPCrossChainBridge).interfaceId || - super.supportsInterface(interfaceId_); -+ CCIPReceiver.supportsInterface(interfaceId_) || ++ CCIPReceiver.supportsInterface(interfaceId_) || + PeripheryEnabler.supportsInterface(interfaceId_); - } - - // ========= ENABLER FUNCTIONS ========= // + } + + // ========= ENABLER FUNCTIONS ========= // ``` #### Developer Response diff --git a/content/2025-06-UnKat.md b/content/2025-06-UnKat.md index 2df1122..f4b4ac7 100644 --- a/content/2025-06-UnKat.md +++ b/content/2025-06-UnKat.md @@ -4,7 +4,7 @@ title: 2025-06-UnKat description: Review of the UnKat protocol --- -# Electisec UnKat Review +# yAudit UnKat Review **Review Resources:** @@ -18,7 +18,7 @@ description: Review of the UnKat protocol ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -45,22 +45,21 @@ After the findings were presented to the UnKat team, fixes were made and include This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, UnKat and users of the contracts agree to use the code at their own risk. - +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, UnKat and users of the contracts agree to use the code at their own risk. ## Code Evaluation Matrix -| Category | Mark | Description | -| ------------------------ | ------- | ----------- | -| Access Control | Good | Access control is implemented correctly to limit access to the functions. Each user is the owner of their own UnKatVault. Claiming rewards is public, allowing anyone to claim rewards regardless of the vault owner; no rewards are locked to the vault owner. | -| Mathematics | Good | Only basic math is used | -| Complexity | Good | The contracts are simple and easy to understand. | -| Libraries | Good | The contracts use the OpenZeppelin contracts for main functionalities. The Merkl library is used for compatibility when accessing Merkl rewards. | -| Decentralization | Average | The admin can limit the deployment of new UnKatVaults and change fees. | -| Code stability | Good | No additional changes were made to the contracts repository during the review. | -| Documentation | Good | All contract functions are documented. | -| Monitoring | Good | All actions are logged using events. | -| Testing and verification | Average | The tests cover all functions and use fuzzing. | +| Category | Mark | Description | +| ------------------------ | ------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | +| Access Control | Good | Access control is implemented correctly to limit access to the functions. Each user is the owner of their own UnKatVault. Claiming rewards is public, allowing anyone to claim rewards regardless of the vault owner; no rewards are locked to the vault owner. | +| Mathematics | Good | Only basic math is used | +| Complexity | Good | The contracts are simple and easy to understand. | +| Libraries | Good | The contracts use the OpenZeppelin contracts for main functionalities. The Merkl library is used for compatibility when accessing Merkl rewards. | +| Decentralization | Average | The admin can limit the deployment of new UnKatVaults and change fees. | +| Code stability | Good | No additional changes were made to the contracts repository during the review. | +| Documentation | Good | All contract functions are documented. | +| Monitoring | Good | All actions are logged using events. | +| Testing and verification | Average | The tests cover all functions and use fuzzing. | ## Findings Explanation @@ -139,7 +138,6 @@ Save `tokens.length` into a local variable. Acknowledged. - ## Informational Findings ### 1. Informational - Call-Blacklist may be inadequate @@ -148,7 +146,7 @@ UnKatVault’s multicall employs a blacklist to block direct calls to core contr #### Technical Details - In UnKatVault.multicall, every entry in the targets array is checked only against a fixed set of forbidden addresses: +In UnKatVault.multicall, every entry in the targets array is checked only against a fixed set of forbidden addresses: ``` require( diff --git a/content/2025-06-usdaf-2-pr2.md b/content/2025-06-usdaf-2-pr2.md index 05db459..a6ef010 100644 --- a/content/2025-06-usdaf-2-pr2.md +++ b/content/2025-06-usdaf-2-pr2.md @@ -4,7 +4,7 @@ title: 2025-06-Asymmetry USDAF v2 PR#2 description: The pull request introduces a new oracle and adjusts the oracle stallness checks --- -# Electisec USDAF PR#2 Review +# yAudit USDAF PR#2 Review **Review Resources:** @@ -18,7 +18,7 @@ description: The pull request introduces a new oracle and adjusts the oracle sta ## Table of Contents 1. TOC -{:toc} + {:toc} ## Review Summary @@ -32,7 +32,6 @@ The PR of the USDAF [Repo](https://github.com/asymmetryfinance/USDaf-v2) was rev The scope of the review consisted of the following contracts at the specific commit: - ``` contracts ├── script @@ -44,11 +43,12 @@ contracts ├── ERC4626Oracle.sol └── StyBoldOracle.sol ``` + After the findings were presented to the USDAF team, fixes were made and included in the existing PR or inside new PRs. This review is a code review to identify potential vulnerabilities in the code. The reviewers did not investigate security practices or operational security and assumed that privileged accounts could be trusted. The reviewers did not evaluate the security of the code relative to a standard or specification. The review may not have identified all potential attack vectors or areas of vulnerability. -Electisec and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. Electisec and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, USDAF and users of the contracts agree to use the code at their own risk. +yAudit and the auditors make no warranties regarding the security of the code and do not warrant that the code is free from defects. yAudit and the auditors do not represent nor imply to third parties that the code has been audited nor that the code is free from defects. By deploying or using the code, USDAF and users of the contracts agree to use the code at their own risk. ## Findings Explanation @@ -64,15 +64,19 @@ Findings are broken down into sections by their respective impact: - Findings including recommendations and best practices. --- + ## Critical Findings None + ## High Findings None + ## Medium Findings None + ## Low Findings ### 1. Low - Narrow staleness tolerance in BTCPriceFeed @@ -98,6 +102,7 @@ Fixed in [f07b514](https://github.com/asymmetryfinance/USDaf-v2/commit/f07b5148a ## Gas Saving Findings None + ## Informational Findings ### 1. Informational - `SusdsOracle` should use `USDS` CL price feed @@ -108,15 +113,15 @@ None #### Impact -Informational. +Informational. #### Recommendation -Update the Chainlink price feed address for `USDS` to `0xfF30586cD0F29eD462364C7e81375FC0C71219b1`. +Update the Chainlink price feed address for `USDS` to `0xfF30586cD0F29eD462364C7e81375FC0C71219b1`. #### Developer Response -Fixed: [81209aea1b9c93e048a38fa1811b454feb8b086a](https://github.com/asymmetryfinance/USDaf-v2/commit/81209aea1b9c93e048a38fa1811b454feb8b086a) +Fixed: [81209aea1b9c93e048a38fa1811b454feb8b086a](https://github.com/asymmetryfinance/USDaf-v2/commit/81209aea1b9c93e048a38fa1811b454feb8b086a) ### 2. Informational - Specify all the assumptions in `ERC4626Oracle.latestRoundData()` @@ -144,7 +149,8 @@ uint8 assetDecimals = IERC20Metadata(TOKEN.asset()).decimals(); answer = answer * int256(TOKEN.convertToAssets(10 ** TOKEN.decimals())) / int256(10 ** assetDecimals); ``` -Or, at least, specify all the assumptions in the comment: +Or, at least, specify all the assumptions in the comment: + ```solidity // assumes that `TOKEN` and `TOKEN.asset()` have 18 decimals answer = answer * int256(TOKEN.convertToAssets(_WAD)) / int256(_WAD); @@ -154,7 +160,6 @@ answer = answer * int256(TOKEN.convertToAssets(_WAD)) / int256(_WAD); won't fix - ### 3. Informational - Hardcoded Assumption on BOLD Solvency #### Technical Details diff --git a/content/2025-07-centrifuge.md b/content/2025-07-centrifuge.md index d22ff76..b44bd98 100644 --- a/content/2025-07-centrifuge.md +++ b/content/2025-07-centrifuge.md @@ -1,11 +1,11 @@ --- tags: ["solidity"] title: 2025-07-Centrifuge -description: Electisec Centrifuge report +description: yAudit Centrifuge report ---

This browser does not support PDFs. Please download the PDF to view it: Download PDF.

- \ No newline at end of file + diff --git a/content/2025-08-Twyne-incremental.md b/content/2025-08-Twyne-incremental.md index 59971bb..10efc0a 100644 --- a/content/2025-08-Twyne-incremental.md +++ b/content/2025-08-Twyne-incremental.md @@ -1,11 +1,11 @@ --- tags: ["solidity"] title: 2025-08-Twyne-incremental -description: Electisec Twyne incremental report +description: yAudit Twyne incremental report ---

This browser does not support PDFs. Please download the PDF to view it: Download PDF.

- \ No newline at end of file + diff --git a/content/2025-08-haiVELO-V2.md b/content/2025-08-haiVELO-V2.md index c1fd42a..a57abdd 100644 --- a/content/2025-08-haiVELO-V2.md +++ b/content/2025-08-haiVELO-V2.md @@ -1,7 +1,7 @@ --- tags: ["solidity"] title: 2025-08-haiVELO-V2 -description: Electisec haiVELO V2 Report +description: yAudit haiVELO V2 Report ---