DittoEth audit details

Total Prize Pool: $13,600 in USDC
- HM awards: $11000 in USDC*
- Judge awards: $2100 in USDC
- Scout awards: $500 USDC
Join C4 Discord to register
Submit findings using the C4 form
Read our guidelines for more details
Starts July 2, 2024 20:00 UTC
Ends July 8, 2024 20:00 UTC

*❗️Note: This audit has $0 in QA awards. However, if no valid HM findings are found, the HM awards will be$ 0, and the top 3 QA reports will split a QA award of $440 in USDC.

This is a Private audit

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

Code4rena's Certified Contributor Terms and Conditions
Code4rena's Certified Contributor Code of Professional Conduct

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

Automated Findings / Publicly Known Issues

The 4naly3er report can be found here.

Note for C4 wardens: Anything included in this Automated Findings / Publicly Known Issues section is considered a publicly known issue and is ineligible for awards.

Previous audit known issues

Issues related to the start/bootstrap of the protocol
- When there are few ShortRecords or TAPP is low, it's easy to fall into a black swan scenario
- Ditto rewards: first claimer gets 100% of ditto reward, also dittoShorterRate can give more/less ditto than expected (see L-21).
- Empty order book can lead to different kinds of issues. Just as one example, matching self can get ditto rewards/yield. Creating a low bid (see L-16) isn't likely since anyone would want to simply match against it. Creating a high short that eventually matches seems impossible with real orders. Can also prevent creating an order too far away from the oracle.
Don't worry about front-running
Not finished with governance/token setup
Issues related to oracles
- Oracle is very dependent on Chainlink, stale/invalid prices fallback to a Uniswap TWAP. 2 hours staleness means it can be somewhat out of date.
Bridge credit system (for LST arb, since rETH/stETH is mixed)
- If user has LST credit but that bridge is empty, LST credit can be redeemed for the other base collateral at 1-1 ratio
- In NFT transfer, LST credit is transferred up to the amount of the collateral in the ShortRecord, which includes collateral that comes from bidder, might introduce a fee on minting a NFT
- Thus, credits don't prevent arbitrage from either yield profits or trading: credit is only tracked on deposits/withdraw and not at the more granular level of matching trades or how much credit is given for yield from LSTs.
There is an edge case where a Short meets minShortErc requirements because of ercDebtRate application
disburseCollateral in proposeRedemption() can cause user to lose yield if their SR was recently modified and it’s still below 2.0 CR (modified through order fill, or increase collateral) - this is only YIELD_DELAY_SECONDS which is currently 60s
Recovery Mode: currently not checking recoveryCR in secondary liquidation unlike primary, may introduce later.
Incentives should mitigate actions from bad/lazy actors and promote correct behavior, but they do not guarantee perfect behavior:
- That Primary Liquidations happen
- Redemptions in the exact sorted order
Redemptions
- Proposals are intentionally overly conservative in considering an SR to ineligible (with regards to minShortErc) to prevent scenarios of ercDebt under minShortErc
- ~~There is an issue when claimRemainingCollateral() is called on a SR that is included in a proposal and is later correctly disputed.~~ Fixed
- ~~Undecided on how to distribute the redemption fee, maybe to dusd holders rather than just the system.~~ Redemption fee goes to the TAPP
- ~~Currently allowed to redeem at any CR under 2, even under 1 CR.~~ Cannot redeem under 1 CR

Added known issues

In the case of collateral efficient SR, protocol can be overly conservative with checkShortMinErc for partial liquidations in reverting (Not worried bc the liquidator can just supply the asks needed to reach full liquidation)
Is possible to have SR with CR higher than max at small amounts, ie. collateral efficient SR with ethInitial and small partial match
If you don’t dispute before proposing, can get disputed yourself since dispute doesn’t change updatedAt
new: ERC4626 Vault (yDUSD.sol)
- ~~the vault contract is currently immutable, but before deployment will either be a proxy or diamond, or incorporate a way to modify the values~~ (Fixed: added an address mapping to be able to swap vaults and let people migrate over if there is a need to update the contract in the future)
Introduced ercDebtFee to allow the fee itself not to be compounded. Didn't cover every case but looking for feedback (handled in cases where ercDebt changes: redemptions, liquidations, black swan socialization, exit short, combine). ~~Found an issue with modifying the ercDebt/updateErcDebt, regarding discountFees/socializing debt from blackswan.~~ Fixed: tried to account for socialized debt as well.

Overview

About Ditto

The Ditto protocol is a new decentralized stable asset protocol for Ethereum mainnet. It takes in overcollateralized liquid staked ETH (rETH, stETH) to create stablecoins using a gas optimized orderbook (starting with a USD stablecoin, dUSD).

On the orderbook, bidders and shorters bring ETH, askers can sell their dUSD. Bidders get the dUSD, shorters get the bidders collateral and a ShortRecord to manage their debt position (similar to a CDP). Shorters get the collateral of the position (and thus the LST yield), with the bidder getting the stable asset, rather than a CDP where the user also gets the asset.

Scope

Please check the diff to see the changes from the previous audit here

Files in scope

Contract	SLOC	Purpose
tokens/yDUSD.sol	90	the ERC4626 Vault that the DUSD gets minted to
libraries/LibRedemption.sol	58	helper library for Redemptions
libraries/LibPriceDiscount.sol	38	helper library for price discount
libraries/LibOrders.sol	578	helper library for price discount
libraries/LibVault.sol	60
libraries/LibShortRecord.sol	134
libraries/LibSRUtil.sol	100
libraries/LibOracle.sol	122
libraries/LibBytes.sol	51
libraries/LibAsset.sol	63
libraries/DataTypes.sol	273
facets/OwnerFacet.sol	238
facets/BridgeRouterFacet.sol	101
facets/YieldFacet.sol	116
facets/ShortRecordFacet.sol	94
facets/ShortOrdersFacet.sol	56
facets/SecondaryLiquidationFacet.sol	117
facets/PrimaryLiquidationFacet.sol	184
facets/ProposeRedemptionFacet.sol	110
facets/DisputeRedemptionFacet.sol	117
facets/ClaimRedemptionFacet.sol	64
facets/OrdersFacet.sol	117
facets/MarketShutdownFacet.sol	49
facets/ExitShortFacet.sol	136
facets/BidOrdersFacet.sol	227
TOTAL	3293

Files out of scope

All files not listed above are Out Of Scope

Scoping Q & A

General questions

Question	Answer
ERC20 used by the protocol	Protocol tokens: Asset.sol (DUSD, DETH, Ditto), LSTs: stETH/rETH
Test coverage	Lines: 74.33%, Functions: 57.35%
ERC721 used by the protocol	Protocol token: NFT as part of the Diamond, represents a ShortRecord position
ERC777 used by the protocol	None
ERC1155 used by the protocol	None
Chains the protocol will be deployed on	Ethereum

ERC20 token behaviors in scope

Question	Answer
Missing return values	No
Fee on transfer	No
Balance changes outside of transfers	No
Upgradeability	No
Flash minting	No
Pausability	No
Approval race protections	No
Revert on approval to zero address	No
Revert on zero value approvals	No
Revert on zero value transfers	No
Revert on transfer to the zero address	No
Revert on large approvals and/or transfers	No
Doesn't revert on failure	No
Multiple token addresses	No
Low decimals ( < 6)	No
High decimals ( > 18)	No
Blocklists	No

External integrations (e.g., Uniswap) behavior in scope:

Question	Answer
Enabling/disabling fees (e.g. Blur disables/enables fees)	No
Pausability (e.g. Uniswap pool gets paused)	No
Upgradeability (e.g. Uniswap gets upgraded)	No

EIP compliance checklist

None

Additional context

Main invariants

Orderbook

Ditto's orderbook acts similar to central limit orderbook with some changes. In order to make the gas costs low, there is a hint system added to enable a user to place an order in the orderbook mapping. Asks/Shorts are both on the "sell" side of the orderbook. Order structs are reused by implementing the orders as a doubly linked-list in a mapping. HEAD order is used as a starting point to match against.
Ask orders get matched before short orders at the same price.
Bids sorted high to low
Asks/Shorts sorted low to high
Only cancelled/matched orders can be reused (Technically: Left of HEAD (HEAD.prevId) these are the only possible OrderTypes: O.Matched, O.Cancelled, O.Uninitialized).
Since bids/asks/shorts share the same orderId counter, every single orderId should be unique

Short Orders

shortOrders can only be limit orders. startingShort represents the first short order that can be matched. Normally HEAD.nextId would the next short order in the mapping, but it's not guaranteed that it is matchable since users can still create limit shorts under the oracle price (or they move below oracle once the price updates). Oracle updates from chainlink or elsewhere will cause the startingShort to move, which means the system doesn't know when to start matching from without looping through each short, so the system allows a temporary matching backwards.
shortOrder can't match under oraclePrice
startingShort price must be greater than or equal to oraclePrice
shortOrder with a non-zero (ie. positive) shortRecordId means that the referenced SR is status partialFill

ShortRecords

ShortRecords are the Vaults/CDPs/Troves of Ditto. SRs represent a collateral/debt position by a shorter. Each user can have multiple SRs, which are stored under their address as a list.
The only time shortRecord debt can be below minShortErc is when it's partially filled and the connected shortOrder has enough ercDebt to make up the difference to minShortErc (Technically: SR.status == PartialFill && shortOrder.ercAmount + ercDebt >= minShortErc)
Similarly, SR can never be SR.FullyFilled and be under minShortErc
FullyFilled SR can never have 0 collateral
Only SR with status Closed can ever be re-used (Technically, only SR.Closed on the left (prevId) side of HEAD, with the exception of HEAD itself)

Redemptions

Allows dUSD holders to get equivalent amount of ETH back, akin to Liquity. However the system doesn't automatically sort the SR's lowest to highest. Instead, users propose a list of SRs (an immutable slate) to redeem against. There is a dispute period to revert any proposal changes and a corresponding penalty against a proposer if incorrect. Proposers can claim the ETH after the time period, and shorters can also claim any remaining collateral afterwards.
Proposal "slates" are sorted least to highest CR
All CR in proposedData dataTypes should be under 2 CR, above 1 CR
If proposal happens, check to see that there is no issues with SSTORE2 (the way it is saved and read)
Relationship between proposal and SR's current collateral and ercDebt amounts. The sum total should always add up to the original amounts (save those amounts)
SR can be SR.Closed before claim if closed another way (like liquidation)
SR can be partially redeemed in non-last position only if it gets refilled after a full proposal

BridgeRouter/Bridge

Because the Vault mixes rETH/stETH, a credit system is introduced to allow users to withdraw only what they deposit, anything in excess (due to yield) also checks either LSTs price difference using a TWAP via Uniswap.
deposit/withdraw gives/removes an appropriate amount of virtual dETH (ETH equivalent), no matter if someone deposits an LST (rETH, stETH), or ETH and accounts for yield that is gained over time.

Misc

NFT can only be SR.FullyFilled
TAPP SR is never moved to the left of HEAD, even when closed bc of full liquidation
All deleted SR have collateral = 0, unless pointing to shortOrder
User should never be able to force SR under initialCR (excluding oracle price change)
Collateral Efficient SR being redeemed always has enough ETH

Change Log

This changelog section is of what has occured since code-423n4/2024-03-dittoeth. Other than the report this should helpful to get a sense of the changes. It's 2 "features" and otherwise fixes and refactoring.
This encompasses last commit before audit 3/14/24-to now (6/28/24). Diff with previous code and the existing one can be found here. It still might be a bit messy due to version changes and renames.

Features

Apply a fee (increase ercDebt) to ShortRecords when trades are happening at a discount. Basic scenario is that ETH goes up, dUSD holders start to sell at a discount, increased fee or potential fee causes some shorts to exit to buy the discounted usd. Doesn't happen if assetCR < recoveryCR, or if forcedBid. Mints the extra fee/debt to the another vault contract (described below).
Create a vault (erc4626) that allows depositing dUSD for yDUSD which can be withdrawn in the future for more dUSD based on the minted dUSD created from the fees from a discounted price. Different from standard as it doesn't allow withdrawal at any time. Must proposeWithdraw then withdraw, and it must be during a certain time period (after 7 days, before 45 days). Can also cancelWithdrawProposal. Also prevents withdrawal if system is currently in a discount.

Bug Fixes

Allow depositAsset during market shutdown (frozen asset)
Assembly: add should be and
Disputing a Closed SR (exited) gives everything to the TAPP (the proposer already got their collateral, and the shorter already exited, so they would get 1:1 and it's safer to give to the TAPP). If disputing a non Closed SR, it causes the merge helper correctly. Also splits the RedemptionFacet into 3 to get around contract size limits.
Call getSavedOrSpotOraclePrice instead of getPrice in ProposeRedemption.sol to avoid outdated price
When short order is cancelled because of dust, the SR status wasn't set to FullyFilled, made it seem like there was an attached short order when there wasn't (causes an issue when the order is re-used)
Users can dispute multiple times in the same proposal to maximize rewards (as opposed to just finding an incorrect proposal): prevent this by only allowing the lowest CR to be able to be disputable
Various issues with not updating an SR's updatedAt timestamp (example: decrease collateral in a SR to dispute)
shortOrderId wasn't validated correctly for proposeRedemption/liquidateSecondary: create a helper for this check in various places
Incorrect validation: used && instead of ||
Prevent combining SR if resulting SR is undercollateralized (low risk since an issue more around front-running redemption/liquidation)
Lockdown TAPP by preventing sending it an NFT, and also special logic when deleting the TAPP SR after liquidation to prevent re-using ids
Extra validation for transferShortRecord for short.tokenId and input tokenId
Fix issue with partial NFT transfers cancelling orders, by not allowing partial NFT transfers at all
Fix: update the SR's ercDebt before disputing
Issues around user disputing own proposal (could evade a liquidation), introduce a fee that is given to the TAPP to disincentivize this
Fix issues around redemptions that are under 1 CR. A redeemer wouldn't get 1:1 collateral back so prevent both proposing and disputing a SR under 1 CR and ask users to primary liquidate (also they get a fee).
Fix issue with dispute time where it wasn't actually the last valid CR
Make sure tithe doesn't go over 100%
Fix potential out of gas issue with short order hints (find hint from startingShortId vs HEAD)
Fix issue with capital efficient short record creation by forcing user to add extra collateral to the SR to cover minShortErc
Fix issues with NFT ids (multiple NFTs pointing to same SR id), don't re-use ids.
Fix issues with a capital efficient CDP by adding more checks by initial eth when lower collateralization
Add staleness check to non base oracle
Prevent liquidation from matching with own short order
Fix to allow distributing yield when one of a shorter's SR has been fully redeemed already
Fix to send redemptionFee to TAPP

Refactor

Storing the reset of the Redemption parameters (timeProposed, timeToDispute, oraclePrice) in SSTORE2
Solidity 0.8.25 (will update to 0.8.26 on deploy)
Remove NFT of SR feature, make room for something else
Make ercDebtRate u80 from u64
Start using tstore/tload

Attack ideas (where to focus for bugs)

2 new "features": ercDebt increase on price discount (when there's a match under oracle) + the ERC4626 vault that the ercDebt goes to.
fixes from the last audit
In general: redemptions feature, orderbook matching, dust amounts (minShortErc), liquidations at the right time.

All trusted roles in the protocol

Role	Description
onlyDiamond	Asset can mint/burn with onlyDiamond
onlyAdminOrDAO, onlyDAO	for OwnerFacet

Any novel or unique curve logic or mathematical models implemented in the contracts:

None

Running tests

git clone --recurse https://github.com/code-423n4/2024-07-dittoeth.git
cd 2024-07-dittoeth

Use Bun to run TypeScript

curl -fsSL https://bun.sh/install | bash
bun install

Install Foundry for Solidity

curl -L https://foundry.paradigm.xyz | bash
foundryup

Set .env for tests

echo 'ANVIL_9_PRIVATE_KEY=0x2a871d0798f97d79848a013d4936a73bf4cc922c825d33c1cf7073dff6d409c6' >> .env
echo 'MAINNET_RPC_URL=https://eth.drpc.org' >> .env

Create interfaces (should already be committed into interfaces/, but usually in .gitignore)

bun run interfaces-force

Build

bun run build

Unit/fork/invariant tests

bun run test

Gas tests, check /.gas.json

bun run test-gas

To run code coverage

forge coverage

<pre>| File | % Lines | % Statements | % Branches | % Funcs | |---------------------------------------------------------------------|--------------------|--------------------|-------------------|------------------| | contracts/Diamond.sol | 100.00% (24/24) | 100.00% (30/30) | 66.67% (4/6) | 100.00% (2/2) | | contracts/EtherscanDiamondImpl.sol | 0.00% (0/31) | 0.00% (0/31) | 100.00% (0/0) | 0.00% (0/100) | | contracts/bridges/BridgeReth.sol | 100.00% (25/25) | 95.35% (41/43) | 50.00% (2/4) | 100.00% (9/9) | | contracts/bridges/BridgeSteth.sol | 100.00% (17/17) | 92.00% (23/25) | 50.00% (2/4) | 100.00% (8/8) | | contracts/facets/AskOrdersFacet.sol | 100.00% (12/12) | 100.00% (16/16) | 100.00% (4/4) | 100.00% (3/3) | | contracts/facets/BidOrdersFacet.sol | 100.00% (143/143) | 100.00% (182/182) | 91.94% (57/62) | 100.00% (8/8) | | contracts/facets/BridgeRouterFacet.sol | 100.00% (53/53) | 100.00% (74/74) | 95.83% (23/24) | 100.00% (10/10) | | contracts/facets/ClaimRedemptionFacet.sol | 100.00% (30/30) | 100.00% (45/45) | 100.00% (12/12) | 100.00% (3/3) | | contracts/facets/DiamondCutFacet.sol | 100.00% (2/2) | 100.00% (2/2) | 100.00% (0/0) | 100.00% (1/1) | | contracts/facets/DiamondEtherscanFacet.sol | 0.00% (0/3) | 0.00% (0/4) | 100.00% (0/0) | 0.00% (0/2) | | contracts/facets/DiamondLoupeFacet.sol | 47.89% (34/71) | 46.94% (46/98) | 33.33% (6/18) | 50.00% (2/4) | | contracts/facets/DisputeRedemptionFacet.sol | 100.00% (56/56) | 100.00% (75/75) | 100.00% (22/22) | 100.00% (1/1) | | contracts/facets/ExitShortFacet.sol | 100.00% (77/77) | 100.00% (95/95) | 100.00% (22/22) | 100.00% (5/5) | | contracts/facets/MarketShutdownFacet.sol | 100.00% (24/24) | 100.00% (31/31) | 100.00% (8/8) | 100.00% (2/2) | | contracts/facets/OrdersFacet.sol | 100.00% (69/69) | 100.00% (94/94) | 96.43% (27/28) | 100.00% (8/8) | | contracts/facets/OwnerFacet.sol | 98.52% (133/135) | 97.96% (144/147) | 93.94% (62/66) | 97.73% (43/44) | | contracts/facets/PrimaryLiquidationFacet.sol | 100.00% (101/101) | 99.19% (122/123) | 96.15% (25/26) | 100.00% (8/8) | | contracts/facets/ProposeRedemptionFacet.sol | 98.55% (68/69) | 99.00% (99/100) | 94.44% (34/36) | 100.00% (1/1) | | contracts/facets/SecondaryLiquidationFacet.sol | 87.50% (63/72) | 87.36% (76/87) | 78.12% (25/32) | 60.00% (3/5) | | contracts/facets/ShortOrdersFacet.sol | 100.00% (34/34) | 100.00% (50/50) | 100.00% (16/16) | 100.00% (1/1) | | contracts/facets/ShortRecordFacet.sol | 100.00% (55/55) | 100.00% (76/76) | 100.00% (20/20) | 100.00% (4/4) | | contracts/facets/TWAPFacet.sol | 100.00% (1/1) | 100.00% (2/2) | 100.00% (0/0) | 100.00% (1/1) | | contracts/facets/TestFacet.sol | 97.92% (94/96) | 97.46% (115/118) | 77.78% (14/18) | 95.35% (41/43) | | contracts/facets/ThrowAwayFacet.sol | 0.00% (0/1) | 0.00% (0/1) | 100.00% (0/0) | 0.00% (0/1) | | contracts/facets/VaultFacet.sol | 100.00% (9/9) | 100.00% (12/12) | 100.00% (6/6) | 100.00% (3/3) | | contracts/facets/ViewFacet.sol | 95.12% (117/123) | 96.00% (168/175) | 83.33% (30/36) | 94.87% (37/39) | | contracts/facets/ViewRedemptionFacet.sol | 80.00% (4/5) | 77.78% (7/9) | 100.00% (0/0) | 66.67% (2/3) | | contracts/facets/YieldFacet.sol | 97.06% (66/68) | 95.70% (89/93) | 88.89% (16/18) | 87.50% (7/8) | | contracts/governance/DittoGovernor.sol | 0.00% (0/10) | 0.00% (0/19) | 100.00% (0/0) | 0.00% (0/11) | | contracts/governance/DittoTimelockController.sol | 100.00% (0/0) | 100.00% (0/0) | 100.00% (0/0) | 0.00% (0/1) | | contracts/libraries/AppStorage.sol | 100.00% (11/11) | 100.00% (22/22) | 92.86% (13/14) | 100.00% (9/9) | | contracts/libraries/LibAsset.sol | 100.00% (24/24) | 100.00% (47/47) | 75.00% (3/4) | 100.00% (14/14) | | contracts/libraries/LibBridge.sol | 100.00% (2/2) | 100.00% (4/4) | 100.00% (0/0) | 100.00% (1/1) | | contracts/libraries/LibBridgeRouter.sol | 98.41% (62/63) | 98.78% (81/82) | 100.00% (30/30) | 100.00% (4/4) | | contracts/libraries/LibBytes.sol | 100.00% (30/30) | 100.00% (37/37) | 50.00% (1/2) | 100.00% (1/1) | | contracts/libraries/LibDiamond.sol | 86.73% (85/98) | 87.07% (101/116) | 59.26% (32/54) | 100.00% (8/8) | | contracts/libraries/LibDiamondEtherscan.sol | 0.00% (0/3) | 0.00% (0/3) | 100.00% (0/0) | 0.00% (0/2) | | contracts/libraries/LibOracle.sol | 100.00% (36/36) | 94.29% (66/70) | 71.43% (10/14) | 100.00% (9/9) | | contracts/libraries/LibOrders.sol | 99.73% (376/377) | 99.80% (495/496) | 93.92% (139/148) | 100.00% (37/37) | | contracts/libraries/LibPriceDiscount.sol | 100.00% (17/17) | 100.00% (23/23) | 87.50% (7/8) | 100.00% (1/1) | | contracts/libraries/LibRedemption.sol | 100.00% (29/29) | 100.00% (44/44) | 100.00% (12/12) | 100.00% (4/4) | | contracts/libraries/LibSRUtil.sol | 100.00% (55/55) | 97.67% (84/86) | 94.12% (32/34) | 100.00% (9/9) | | contracts/libraries/LibShortRecord.sol | 100.00% (84/84) | 100.00% (98/98) | 100.00% (26/26) | 100.00% (7/7) | | contracts/libraries/LibTStore.sol | 83.33% (5/6) | 85.71% (6/7) | 100.00% (0/0) | 75.00% (3/4) | | contracts/libraries/LibVault.sol | 100.00% (35/35) | 100.00% (51/51) | 100.00% (6/6) | 100.00% (5/5) | | contracts/libraries/PRBMathHelper.sol | 52.50% (42/80) | 45.00% (54/120) | 27.78% (10/36) | 51.22% (21/41) | | contracts/libraries/UniswapOracleLibrary.sol | 81.25% (13/16) | 84.62% (22/26) | 83.33% (5/6) | 100.00% (2/2) | | contracts/libraries/UniswapTickMath.sol | 35.14% (39/111) | 43.66% (62/142) | 78.26% (36/46) | 50.00% (1/2) | | contracts/libraries/console.sol | 11.11% (22/198) | 14.23% (34/239) | 25.00% (2/8) | 18.18% (8/44) | | contracts/mocks/MockAggregatorV3.sol | 75.00% (15/20) | 75.00% (15/20) | 100.00% (4/4) | 44.44% (4/9) | | contracts/mocks/RocketDepositPool.sol | 100.00% (0/0) | 100.00% (0/0) | 100.00% (0/0) | 0.00% (0/1) | | contracts/mocks/RocketStorage.sol | 100.00% (3/3) | 100.00% (3/3) | 100.00% (0/0) | 100.00% (3/3) | | contracts/mocks/RocketTokenRETH.sol | 53.33% (8/15) | 60.00% (12/20) | 12.50% (1/8) | 71.43% (5/7) | | contracts/mocks/STETH.sol | 42.86% (3/7) | 44.44% (4/9) | 50.00% (2/4) | 16.67% (1/6) | | contracts/mocks/UNSTETH.sol | 0.00% (0/27) | 0.00% (0/36) | 0.00% (0/6) | 0.00% (0/4) | | contracts/tokens/Asset.sol | 100.00% (4/4) | 100.00% (5/5) | 100.00% (2/2) | 100.00% (4/4) | | contracts/tokens/Ditto.sol | 100.00% (8/8) | 100.00% (9/9) | 100.00% (2/2) | 100.00% (7/7) | | contracts/tokens/yDUSD.sol | 100.00% (47/47) | 95.29% (81/85) | 83.33% (20/24) | 100.00% (10/10) | | deploy/DeployDiamond.s.sol | 0.00% (0/48) | 0.00% (0/57) | 0.00% (0/4) | 0.00% (0/1) | | deploy/DeployHelper.sol | 89.08% (155/174) | 90.00% (171/190) | 45.45% (10/22) | 50.00% (3/6) | | deploy/ImmutableCreate2Factory.sol | 50.00% (7/14) | 53.33% (8/15) | 30.00% (3/10) | 40.00% (2/5) | | deploy/MultiCall3.sol | 0.00% (0/55) | 0.00% (0/57) | 0.00% (0/10) | 0.00% (0/16) | | deploy/migrations/01_remove_functions/01_remove_functions.s.sol | 0.00% (0/4) | 0.00% (0/5) | 100.00% (0/0) | 0.00% (0/1) | | deploy/migrations/02_upgrade_diamondCut/02_upgrade_diamondCut.s.sol | 5.88% (1/17) | 5.00% (1/20) | 100.00% (0/0) | 50.00% (1/2) | | deploy/migrations/03_deploy_dao/03_deploy_dao.s.sol | 11.36% (10/88) | 12.63% (12/95) | 100.00% (0/0) | 50.00% (1/2) | | deploy/migrations/04_etherscan_diamond/04_etherscan_diamond.s.sol | 34.78% (16/46) | 36.73% (18/49) | 100.00% (0/0) | 50.00% (1/2) | | deploy/migrations/05_disable_deposit/05_disable_deposit.s.sol | 27.27% (6/22) | 27.27% (6/22) | 100.00% (0/0) | 50.00% (1/2) | | deploy/migrations/0X_example_migration/0X_example_migration.s.sol | 21.54% (14/65) | 21.74% (15/69) | 100.00% (0/0) | 33.33% (1/3) | | deploy/migrations/MigrationHelper.sol | 75.00% (3/4) | 60.00% (3/5) | 100.00% (0/0) | 33.33% (1/3) | | test/DiamondCut.t.sol | 100.00% (2/2) | 100.00% (2/2) | 100.00% (0/0) | 100.00% (2/2) | | test/SSTORE2.t.sol | 100.00% (12/12) | 100.00% (12/12) | 50.00% (2/4) | 100.00% (4/4) | | test/fork/ForkHelper.sol | 100.00% (30/30) | 100.00% (32/32) | 100.00% (0/0) | 100.00% (1/1) | | test/fork/MultiAssetFork.t.sol | 100.00% (39/39) | 100.00% (40/40) | 100.00% (0/0) | 100.00% (1/1) | | test/invariants/Handler.sol | 87.72% (457/521) | 89.33% (586/656) | 77.19% (88/114) | 75.44% (43/57) | | test/invariants/InvariantsBase.sol | 3.45% (11/319) | 2.93% (13/444) | 0.00% (0/52) | 4.17% (1/24) | | test/invariants/InvariantsSandBox.sol | 0.00% (0/3) | 0.00% (0/3) | 100.00% (0/0) | 0.00% (0/1) | | test/utils/AddressSet.sol | 69.57% (16/23) | 59.26% (16/27) | 62.50% (5/8) | 50.00% (4/8) | | test/utils/ConstantsTest.sol | 40.00% (4/10) | 29.41% (5/17) | 100.00% (0/0) | 0.00% (0/8) | | test/utils/LiquidationHelper.sol | 100.00% (83/83) | 100.00% (91/91) | 66.67% (8/12) | 12.50% (1/8) | | test/utils/OBFixture.sol | 92.89% (196/211) | 92.80% (232/250) | 83.33% (5/6) | 13.85% (9/65) | | Total | 74.33% (3428/4612) | 75.01% (4437/5915) | 77.61% (953/1228) | 57.35% (468/816) | </pre>

Miscellaneous

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

Ready to secure your project?

Find bugs. Get paid.

DittoETH Invitational