Satoshi Finance

Smart Contract Security Assessment

February 26, 2024

SUMMARY​

ABSTRACT​

Dedaub was commissioned to perform a security audit of the Satoshi Finance protocol, which is a fork of Liquity to launch on Binance. The audit was over smart contract code. Both the code and the accompanying artifacts (i.e., test-suite, documentation) adhere to high professional standards.

BACKGROUND​

Satoshi Finance attempts to change how Liquity’s redemption mechanism works by making redemptions “socialized”. During a debt redemption, the protocol does not prioritize the troves with the lowest individual collateralization ratio (ICR) but instead distributes the redeemed debt across all active troves. This change has the additional effect of removing the requirement of maintaining a sorted ordering of all active troves based on their ICR, potentially simplifying the implementation of the protocol.

Additionally, Satoshi Finance introduces the following modifications to the original Liquity codebase:

• The Active Pool now offers an ERC3156-compliant flashloan implementation.

• Protocol stakers can opt for a premium membership that will provide them with improved fee rates within the protocol.

• A new ecosystem party, scavengers, will be responsible for closing down troves whose debt gets lower than the required minimum because of how redemptions are now “socialized”.

• When a trove gets created, no debt is reserved as a “gas compensation” for a potential liquidation of the trove

SETTING & CAVEATS​

This audit report mainly covers the contracts of the public repository https://github.com/Satoshi-Finance/sato-dev of the protocol at commit 787bac5aa5754b78412457791e6280b07150d191. We performed the audit as a “delta” audit, inspecting the differences relative to commit ce7f382e2be3c360c38d6ad838b6ab658b588e4e of the Liquity codebase.

2 auditors worked on the codebase for 5 days on the following contracts:

The audit’s main target is security threats, i.e., what the community understanding would likely call "hacking", rather than the regular use of the protocol. Functional correctness (i.e. issues in "regular use") is a secondary consideration. Typically it can only be covered if we are provided with unambiguous (i.e. full-detail) specifications of what is the expected, correct behavior. In terms of functional correctness, we often trusted the code’s calculations and interactions, in the absence of any other specification. Functional correctness relative to low-level calculations (including units, scaling and quantities returned from external protocols) is generally most effectively done through thorough testing rather than human auditing.

The above is particularly a concern in a delta audit, such as the present one. Auditing only the delta of the functionality compared to the original baseline (the Liquity code) has some threats, especially threats of omission: it is relatively easier to see via auditing that added code is erroneous, but much harder to discover that a certain key update is missing, e.g., for correct accounting or maintaining a consistent protocol state. This burden falls on thorough testing: the validity of the protocol’s accounting can be fully ascertained only by the existence of appropriate test cases. The Satoshi codebase extends the (already extensive) Liquity tests, yet still we remind of the need for vigilance in very high test coverage of possible code conditions.

PROTOCOL-LEVEL CONSIDERATIONS​

Some design decisions have economic consequences that differ from the tradeoffs of the underlying Liquity system. We bring them up for awareness.

function _requireSystemTCR() internal {
  uint price = priceFeed.fetchPrice();
  uint tcr = troveManager.getTCR(price);
  require(tcr > CCR, "StabilityPool: Cannot withdraw while TCR is low");
}

VULNERABILITIES & FUNCTIONAL ISSUES​

This section details issues affecting the functionality of the contract. Dedaub generally categorizes issues according to the following severities, but may also take other considerations into account such as impact or difficulty in exploitation:

Issue resolution includes “dismissed” or “acknowledged” but no action taken, by the client, or “resolved”, per the auditors.

CRITICAL SEVERITY​

[No critical severity issues]

HIGH SEVERITY​

MEDIUM SEVERITY​

function withdrawFromSP(uint _amount) external override {
  if (_amount != 0) {
    _requireSystemTCR();

    // check withdrawal delay
    uint _existReqAmount = withdrawReqAmount[msg.sender];
    require(_existReqAmount > 0,
            "StabilityPool: no valid existing withdrawal request");

    ...
    _amount = _existReqAmount;
  }
  ...
  (uint compoundedDebtDeposit, uint debtToWithdraw) =
     _capWithdrawAmount(msg.sender, _amount);

function _capWithdrawAmount(address _depositor, uint _amount) internal view returns(uint, uint){
    	uint compoundedDebtDeposit = getCompoundedDebtDeposit(_depositor);
    	if (_amount == 0){
        	return (compoundedDebtDeposit, _amount);
    	} else {
        	return (compoundedDebtDeposit,
                    LiquityMath._min(_amount, compoundedDebtDeposit));
    	}
}

LOW SEVERITY​

function _backupIsBroken(ChainlinkResponse memory _response) internal view returns (bool) {
    	// Check for response call reverted
    	if (!_response.success) {return true;}
    	// Check for an invalid timeStamp that is 0, or in the future
    	if (_response.timestamp == 0 ||
          _response.timestamp > block.timestamp) {return true;}
    	// Check for zero price
    	if (_response.answer == 0) {return true;}

    	return false;
}

CENTRALIZATION ISSUES​

The protocol is highly decentralized, following the example set by Liquity. This is an excellent feature, but, as a side effect, raises the bar for correctness, since no administrator can fix, pause, evolve, or rescure the protocol. Liquity clones have been found to have accounting errors, even after years of successful operation. (See, e.g., the recent wrap up of Yeti Finance.) The accounting mathematics is simply quite complex and it is very easy for bugs of omission to creep in. Therefore, we again point out the need for extremely thorough testing, for purposes of functional correctness (not security, except indirectly).

OTHER / ADVISORY ISSUES​

This section details issues that are not thought to directly affect the functionality of the project, but we recommend considering them.

function flashFee(address token, uint256 amount) public view override returns (uint256) {
   require(token == address(collateral), "ActivePool: collateral Only");
   return amount.mul(FLASH_FEE_BPS).div(MAX_BPS);
}

if (_account == collSurplusPoolAddress){
   ICollSurplusPool(collSurplusPoolAddress).receiveCollateral(_amount);
} else if (_account == defaultPoolAddress){
   IDefaultPool(defaultPoolAddress).receiveCollateral(_amount);
} else if (_account == stabilityPoolAddress){
   IStabilityPool(stabilityPoolAddress).receiveCollateral(_amount);
}

if (_account == collSurplusPoolAddress ||
    _account == defaultPoolAddress ||
    _account == stabilityPoolAddress) {
   ICollSurplusPool(collSurplusPoolAddress).receiveCollateral(_amount);
}  // All three pools support the same function signature

function _liquidateRecoveryMode(
    	IActivePool _activePool,
    	IDefaultPool _defaultPool,
    	...
)

function _applyPendingRewards(
    	IActivePool _activePool,
    	IDefaultPool _defaultPool,
    	...
)

    	vars.isCollIncrease = _isCollIncrease;
    	vars.collChange = _collChange;
...
    	vars.newICR =
        _getNewICRFromTroveChange(vars.coll, vars.debt, vars.collChange,
                                  vars.isCollIncrease, vars.netDebtChange,
                                  _isDebtIncrease, vars.price);
    	if (!vars.isCollIncrease){
...

function getSATOYetToIssue() public override view returns (uint256) {
    	uint latestTotalSATOIssued = _getLatestIssuedSATO();
    	return latestTotalSATOIssued >= SATOSupplyCap?
              0 : SATOSupplyCap.sub(latestTotalSATOIssued);
}

function increaseF_LUSD(uint _debtMintFee) external override {
    	_requireCallerIsTroveManagerOrBO();
    	...

function flashLoan(
    	IERC3156FlashBorrower receiver,
    	address token,
    	uint256 amount,
    	bytes calldata data
	) external override returns (bool) {
      ...
    	uint256 amountWithFee = amount.add(fee);
      ...

DISCLAIMER​

The audited contracts have been analyzed using automated techniques and extensive human inspection in accordance with state-of-the-art practices as of the date of this report. The audit makes no statements or warranties on the security of the code. On its own, it cannot be considered a sufficient assessment of the correctness of the contract. While we have conducted an analysis to the best of our ability, it is our recommendation for high-value contracts to commission several independent audits, a public bug bounty program, as well as continuous security auditing and monitoring through Dedaub Security Suite.

ABOUT DEDAUB​

Dedaub offers significant security expertise combined with cutting-edge program analysis technology to secure some of the most prominent protocols in DeFi. The founders, as well as many of Dedaub's auditors, have a strong academic research background together with a real-world hacker mentality to secure code. Protocol blockchain developers hire us for our foundational analysis tools and deep expertise in program analysis, reverse engineering, DeFi exploits, cryptography and financial mathematics.