# Security

## Price Oracle

The usage of an oracle is then viewed as providing LP with an additional layer of security. If the oracle detects a severe price divergence, all trades to and from that asset are halted, and withdrawInOtherAsset for that asset is disabled.
Although the Cashmere stablecoin pools design assumes that the peg is maintained, it is possible that one of them becomes unpegged due to unanticipated circumstances.
As a result, Cashmere uses Chainlink to track each token's exchange rate, assisting liquidity providers in protecting their deposits in the event of a 2% unpeg (max price deviation). Please keep in mind that in the event of a bankrun, LP providers may be forced to withdraw from the pool's most covered asset.

## Economic Risk

Solvency Risk and Liquidity Risk are the two most important financial risks. Cashmere protects its financial well-being by monitoring and implementing risk-mitigation techniques.

## Risk of Insolvency

We define liquidity provision as a liability, Li, and the quantity of token I held by the protocol as an asset,
$A_i$
, for the token
$i$
account (both cash and account receivable). The compensation ratio
$c_i$
is defined as
$A_i$
, which is a measure of the token
$i$
account's solvency risk. The lower the solvency risk, the larger the
$L_i$
compensation ratio.
We categorize solvency risk into two categories: account-level and system-level.
• Account-level bankruptcy occurs when a token's assets (
$A_i$
) are less than its liabilities (
$L_i$
) .
• When the sum of assets (Sum of
$A_i$
) exceeds the sum of liabilities, this is referred to as system-level insolvency (Sum of
$L_i$
).
• Permanent insolvency is not the same as temporary insolvency. When users make token swaps from the insolvent token to other tokens, the solvency situation for account-level insolvency may be restored. In the case of system-level insolvency, the solvency situation may be restored if the system's future income is adequate to cover any gaps or if extra equity is infused.

## Liquidity Risk

Cash,
$Q_i$
for token
$i$
account, is the amount of a liquid token
$i$
owned by the protocol. The quick ratio is defined as
$Q_i$
, which is a measure of the token
$i$
account
$L_i$
's liquidity risk.
The lower the liquidity risk, the greater the quick ratio. When
$Q_i$
equals 1, the protocol is totally liquid, and all liabilities can be satisfied with cash in the protocol. To avoid illiquidity (i.e., default) of the protocol, the quick ratio must be kept over a particular threshold.
Insolvency of a token may directly imply the risk of illiquidity of the token if all liabilities are immediately redeemed.

## Impairment Loss

While we do not expect the assets of the stableswap to be smaller than its liabilities, if this occurs, it will cause a trust crisis and maybe a bank run. To account for such a scenario, if the system becomes insolvent, all liquidity suppliers should share the damage.
When a liquidity provider withdraws, an impairment loss IL is charged. It is defined as the difference between the system's equilibrium compensation ratio r and 1. (where the system is insolvent). Mathematically,

The TransparentUpgradeableProxy pattern (OpenZeppelin + Hardhat implementation) is used to construct Cashmere Finance as a collection of upgradeable smart contracts.
Upgradeability is a design option that necessitates confidence in the ProxyAdmin administrator. ProxyAdmin will be owned by Multisig in the early stages of the project.
This allows the protocol to be updated and constructed without affecting the user experience (by reducing manual fund transfers) or the veCSM generated by users.
It also allows the protocol to benefit from the comments of its users and to improve over time.
Governance will eventually hold the ProxyAdmin contract. This means that veCSM holders will vote on whether or not to upgrade. When the protocol is fully mature and battle-tested, governance can opt to "renounce ownership" of the ProxyAdmin contract, thereby rendering the contract logic immutable and making it non-upgradable. The functions of Cashmere Finance Multisig are as follows:
• Control the treasury account at Cashmere Finance.
• Set the Master Cashmere contract's distribution weights.
• Set a new dev address on the pool contract, which will halt all pool operations.
• Assets from pools can be added or updated.
• Pool slippage parameters should be updated.
• Change the pool address on the asset contract, which handles the underlying funds.
• Increase the asset's maximum limit.
• ChainlinkProxyProvider's price feeds are updated.
• On the veCSM contract, update the whitelist and veCSM emissions.
• Control upgrades for Asset, Pool, and AggregateAccount via the proxyAdmin Cashmere finance multisig 2, which is managed by the same signers and retains the monthly liquidity mining incentives to be given to MasterCashmere and other rewarders (REF, etc.).

## Rewards

According to the vulnerability score standard, the severity of disclosed vulnerabilities will be graded. The information below serves as a guide for the reward system.
Severe: 100,000 CSM , High: 50,000 CSM , Medium: 25,000 CSM , Low: 5,000 CSM The actual prize amount will be determined by a number of variables, including the seriousness of the crime, the amount of money at stake, and the chance of being exploited.

## Disclosure

Vulnerability reports from developers and security researchers can be sent here. Please be as specific and clear as possible when reporting a bug. Cashmere will acknowledge receipt of the report as soon as possible.