Salty.IO - 0xepley's results

🛠️ Analysis - Salty.IO

An Ethereum-based DEX with zero swap fees, yield-generating Automatic Arbitrage, and a native WBTC/WETH backed stablecoin.

Summary

a) Overview of the Salty Project

The Salty.IO project is a comprehensive ecosystem, focusing on token staking, liquidity provision, and efficient management of digital assets. The project is designed to incentivize users to participate actively in the ecosystem through staking and liquidity provision, while also ensuring secure and efficient management of crucial wallet addresses.

Key Features and Functionalities:

1. Staking Rewards Management:

   • Manages the distribution of rewards for users staking SALT tokens or liquidity shares.
   • Provides mechanisms for users to claim accumulated rewards based on their share in the staking pool.

2. Token Staking System:

   • Allows users to stake SALT tokens and receive xSALT, representing their staked amount.
   • Implements a flexible unstaking process with varying durations, influencing the amount of SALT reclaimed.
   • Includes a feature for expedited unstaking with reduced returns, offering users a choice between speed and efficiency.

3. Secure Wallet Management:

   • Manages critical wallet addresses using a dual-wallet system (main and confirmation wallets).
   • Enables secure and controlled changes to wallet addresses through a proposal and confirmation process.
   • Incorporates a 30-day timelock for implementing confirmed changes, adding an extra layer of security.

b) Technical Architecture

<br/> <br/> <br/>

<br/> <br/>

c) The approach I would follow when reviewing the code

First, by examining the scope of the code, I determined my code review and analysis strategy. https://code4rena.com/audits/2024-01-saltyio

Accordingly, I would analyze and audit the subject in the following steps;

<br/> <br/>

d) Analysis of the code base

The most important summary in analyzing the code base is the stacking of codes to be analyzed. In this way, many predictions can be made, including the difficulty levels of the contracts, which one is more important for the auditor, the features they contain that are important for security (payable functions, uses assembly, etc.), the audit cost of the project, and the time to be allocated to the audit; Uses Consensys Solidity Metrics

• File: This field contains the name or path of the source file being analyzed.

• Logic Contracts: This field indicates the number of Contracts involves

• Interfaces: This field indicated specify the number or details of interfaces defined in the source file.

• Lines: This field represents the total number of lines in the source file, including code lines, comments, and blank lines.

• nLines: nLines typically stands for "normalized lines" and represents the total number of lines in the source file excluding blank lines.

• nSLOC: nSLOC stands for "normalized source lines of code," and it further refines nLines by excluding both blank lines and comments. It gives a more accurate measure of the code's complexity.

• Comment Lines: This field specifies the number of lines in the source file that contain comments.

• Complex. Score: This field may indicate a complexity score or metric for the source file.

Analysis of sloc of Dao contracts

Analysis of sloc of Launch contracts

Analysis of sloc of Pools contracts

Analysis of sloc of price_feed contracts

Analysis of sloc of Rewards contracts

Analysis of sloc of Stable contracts

Analysis of sloc of Staking contracts

Analysis of sloc of src contracts

Comment-to-Source Ratio:

DAO contracts: On average there are 4.69 code lines per comment (lower=better).

Launch contracts: On average there are 4.39 code lines per comment (lower=better).

Pools contracts: On average there are 1.82 code lines per comment (lower=better).

price_feed contracts: On average there are 4.49 code lines per comment (lower=better).

Rewards contracts: On average there are 3.54 code lines per comment (lower=better).

Stable contracts: On average there are 3.26 code lines per comment (lower=better).

Staking contracts: On average there are 2.98 code lines per comment (lower=better).

src contracts: On average there are 3.22 code lines per comment (lower=better).

Call Graph of Important Contracts

Call graph of Launch contract

Call graph of Pools contracts

Call graph of Price_feed contracts

Call graph of Staking contracts

Contract Integration Graph

High Level Domain Model

This domain model provides an overview of the key components and how they are interconnected.

<br/> <br/>

e) Test analysis

Foundry Testing:

Foundry, a modern smart contract testing framework, was utilized to test the Salty contracts. This involved several key steps:

a. Installation and Setup: - Foundry was installed using the command curl -L https://foundry.paradigm.xyz | bash, followed by foundryup to ensure the latest version was in use. - Dependencies were installed using forge install, ensuring all necessary components were available for the testing process. - Then to run the tests, I simply added the relevant files to the .env, referencing .env.example.

b. Execution of Tests: - Tests were run using fCOVERAGE="yes" NETWORK="sep" forge test -vv --rpc-url https://rpc.sepolia.org, executing a suite of predefined test cases that covered various functionalities and scenarios.

c. Test Coverage and Documentation: - The overview of the testing suite, as referred to in the provided documentation, likely details the scope, scenarios, and objectives of each test, ensuring a comprehensive assessment of the contracts.

What did the project do differently? ;

• 1. It can be said that the developers of the project did a quality job, there is a test structure consisting of tests with quality content. In particular, tests have been written successfully.
• 2. Overall line coverage percentage provided by your tests : 99

What could they have done better?

• 1. If we look at the test scope and content of the project with a systematic checklist, we can see which parts are good and which areas have room for improvement As a result of my analysis, those marked in green are the ones that the project has fully achieved. The remaining areas are the development areas of the project in terms of testing ;

Ref:https://xin-xia.github.io/publication/icse194.pdf

<br/> <br/>

Imp Test cases coverage with gas report

ExchangeConfig.sol

ManagedWallet.sol

Salt.sol

DAO.sol:

DAOConfig.sol

Proposals.sol

Deployment.sol

InitialDistribution.sol

Pools.sol

PoolsConfig.sol

CoreSaltyFeed.sol

PriceAggregator.sol

ForcedPriceFeed.sol

TestChainlinkAggregator.sol

RewardsConfig.sol:RewardsConfig contract

SaltRewards.sol:SaltRewards contract

TestSaltRewards.sol

f) Security Approach of the Project

Successful current security understanding of the project;

1- The project hasn't underwent any audits(nothing stated in the docs), this innovative assessments on Code4rena is the first, where multiple auditors are scrutinizing the code.

What the project should add in the understanding of Security;

1- By distributing the project to testnets, ensuring that the audits are carried out in onchain audit. (This will increase coverage)

2- Add On-Chain Monitoring System; If On-Chain Monitoring systems such as Forta are added to the project, its security will increase.

For example ; This bot tracks any DEFI transactions in which wrapping, unwrapping, swapping, depositing, or withdrawals occur over a threshold amount. If transactions occur with unusually high token amounts, the bot sends out an alert. https://app.forta.network/bot/0x7f9afc392329ed5a473bcf304565adf9c2588ba4bc060f7d215519005b8303e3

3- After the Code4rena audit is completed and the project is live, I recommend the audit process to continue, projects like immunefi do this. https://immunefi.com/

4- Emergency Action Plan In a high-level security approach, there should be a crisis handbook like the one below and the strategic members of the project should be trained on this subject and drills should be carried out. Naturally, this information and road plan will not be available to the public. https://docs.google.com/document/u/0/d/1DaAiuGFkMEMMiIuvqhePL5aDFGHJ9Ya6D04rdaldqC0/mobilebasic#h.27dmpkyp2k1z

5- I also recommend that you have an "Economic Audit" for projects based on such complex mathematics and economic models. An example Economic Audit is provided in the link below; Economic Audit with Three Sigma

6 - As the project team, you can consider applying the multi-stage audit model.

Read more about the MPA model; https://mpa.solodit.xyz/

7 - I recommend having a masterplan applied to project team members (This information is not included in the documents). All authorizations, including NPM passwords and authorizations, should be reserved only for current employees. I also recommend that a definitive security constitution project be found for employees to protect these passwords with rules such as 2FA. The LEDGER hack, which has made a big impact recently, is the best example in this regard;

https://twitter.com/Ledger/status/1735326240658100414?t=UAuzoir9uliXplerqP-Ing&s=19

g) Codebase Quality

Overall, I consider the quality of the Salty.io protocol codebase to be Good. The code appears to be mature and well-developed, though there are areas for improvement, particularly in code commenting. We have noticed the implementation of various standards adhere to appropriately. Details are explained below:

While the codebase is robust and well-structured, the lack of detailed comments in the code is a notable area for improvement. Enhancing the code commenting would further elevate the overall quality and accessibility of the project.

h) Other Audit Reports and Automated Findings

Automated Findings: https://github.com/code-423n4/2024-01-salty/blob/main/bot-report.md

Previous Audits ABDK Audit Trail of Bits

4naly3er report https://github.com/code-423n4/2024-01-salty/blob/main/4naly3er-report.md

i) Full representation of the project’s risk model

1. Admin Abuse Risks:

• Centralized Control Points: The project's governance is heavily reliant on smart contracts like ManagedWallet.sol, ExchangeConfig.sol, and the DAO. While these contracts ostensibly distribute control, there's a risk of centralization if few actors hold significant control.
• Upgrade and Proposal Approval: The DAO and ManagedWallet.sol contracts have functionalities to approve upgrades and changes. If these mechanisms are compromised or controlled by a small group, they could be used maliciously.

2. Systemic Risks:

• Interconnected Contract Dependencies: The project's DeFi ecosystem comprises various interdependent contracts (like Liquidity.sol, Staking.sol, Emissions.sol). A malfunction or exploitation in one contract could ripple through the entire system.\
• Liquidity Risks: The liquidity pools (Pools.sol) are central to the ecosystem. Any liquidity crunch or imbalance can pose systemic risks.

3. Technical Risks:

• Smart Contract Vulnerabilities: Given the complexity of contracts like Upkeep.sol, Staking.sol, and others, there's a risk of bugs or vulnerabilities that could be exploited, despite thorough auditing.
• Oracle Failures: The system relies on PriceAggregator.sol for market data. Any failure or manipulation in the price feeds can lead to incorrect valuations and system responses.

By continuously monitoring these risk factors and implementing robust mitigation strategies, Salty.IO can aim to ensure a secure and resilient DeFi ecosystem for its users.

j) Packages and Dependencies Analysis 📦

k) New insights and learning of project from this audit:

After thoroughly reviewing the Salty.io project's codebase and documentation, several new insights and learnings have emerged.

1. Use of Uniswap and Chainlink: The project utilizes Uniswap for decentralized trading and Chainlink for secure and reliable external data. This combination indicates an emphasis on robustness and security in obtaining market data and executing trades.

2. Stablecoin Implementation: The USDS.sol contract and related StableConfig.sol suggest the implementation of a stablecoin (USDS), backed by crypto assets like WBTC and WETH. This approach is critical for maintaining stability in a volatile crypto market.

3. Rewards and Incentivization: Contracts like SaltRewards.sol and StakingRewards.sol indicate a mechanism to reward users for participating in the ecosystem, such as through liquidity provision or staking. This is a common practice in DeFi to encourage user participation and liquidity.

4. Governance and DAO: The use of a DAO (Decentralized Autonomous Organization) structure for governance, as seen in DAO.sol and ExchangeConfig.sol, indicates a decentralized governance model. This aligns with the broader ethos of the DeFi sector promoting community-driven decision-making.

5. Risk Management: Contracts like CollateralAndLiquidity.sol and Liquidizer.sol show mechanisms for managing risks associated with collateralized debt positions and liquidity provision. This is essential for maintaining the system's health and user trust.

Overall, your project presents a sophisticated and multifaceted DeFi ecosystem, incorporating key elements like liquidity provision, stablecoin implementation, rewards, governance, and compliance. It shows a strong alignment with DeFi's principles of open finance and community governance, while also considering critical aspects like security and risk management.

Note: I didn't tracked the time, the time I mentioned is just an estimate

Time spent:

5 hours