> For the complete documentation index, see [llms.txt](https://kash-2.gitbook.io/kash-enhanced-yield-protocol/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kash-2.gitbook.io/kash-enhanced-yield-protocol/how-it-works/risks.md). # Risks & Safeguards KASH is a Decentralized Finance protocol on **Arbitrum One** mainnet. Participation involves depositing real assets; the risks involved should be understood before use. > **Important:** KASH should be treated as high risk until contract review and operational security are satisfactory. Only amounts that can be affordably lost should be deposited. *** ## Do not send tokens directly to the contract > **Critical:** Never transfer ETH, wETH, wBTC, or any other token **directly** to a KASH vault contract address (for example from a wallet’s “Send” screen or a raw ERC-20 transfer). Deposits **must** go through the app’s **Mint KASH** flow, which calls `requestMint` on the correct vault. Tokens sent any other way are **not** credited as a deposit and, in most cases, **cannot be returned to you**. The vault contracts only recognize deposits submitted via the **Submit Mint Request** button during the open user window. A plain transfer to the contract address does **not** create a mint request, does **not** mint KASH, and is **not** refundable through the app. | Vault | Accepted asset | Correct method | What goes wrong if you transfer directly | | ----------------------------------------------------------- | -------------- | ------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **KASH-ETH** (`0xC5C8B1Dc1fFF6728869C8BCCe6105Caa6Df9E68d`) | ETH or wETH | Use **Mint KASH** on the ETH tab (calls `requestMint`) | **Native ETH** sent to the contract is accepted by `receive()` but is **not** tied to your wallet — you receive no KASH and have **no way to reclaim it**. **wETH** sent without calling `requestMint` is likewise not credited to you. | | **KASH-BTC** (`0x86B0095f866c05F53363AE31F994E9540033fC2E`) | wBTC only | Use **Mint KASH** on the BTC tab (calls `requestMint`) | **wBTC** sent via a direct ERC-20 transfer is **not** credited and **cannot be recovered** — `rescueERC20` explicitly blocks the vault’s wBTC address, so even the protocol owner cannot pull it back out. | **Use the right vault for the right asset:** * Do **not** send **ETH** or **wETH** to the **KASH-BTC** contract (it has no `receive()` hook; the transaction should revert, but never attempt it). * Do **not** send **wBTC** to the **KASH-ETH** contract — it is the wrong product and will not mint KASH-BTC. * Do **not** send **wBTC** to the **KASH-BTC** contract except through **Mint KASH** — a direct transfer is the most common way to permanently lose funds. The only supported deposit path is the frontend **Mint KASH** section (or an equivalent wallet interaction that explicitly calls `requestMint` on the correct contract). See [Depositing](/kash-enhanced-yield-protocol/using-kash/depositing.md) for the step-by-step flow. *** ## Smart contract risk The protocol is governed entirely by smart contracts. If there is a bug in the code, funds could be lost or locked. Mitigations in place: * All user-facing functions are protected against reentrancy attacks * New exchanges that KASH may interact with require a **24-hour waiting period** before they can be activated (preventing a compromised key from instantly routing funds to a malicious contract) * An emergency pause function exists that can halt all user activity **Verification steps:** The Contract Address link in the app footer leads to the verified contract page on Arbiscan. Contracts are fully source-code verified on Arbiscan, so the complete Solidity source code can be reviewed under the Contract tab. Arbiscan has confirmed that this code compiles byte-for-byte into the exact bytecode deployed on Arbitrum. For maximum transparency, the full source code is also published in the public GitHub repository — it can be cross-checked against the verified code on Arbiscan to confirm it matches the official version the team intended to deploy. *** ## Funding rate risk Yield comes primarily from earning the funding rate on short positions held on the perp DEX. Funding rates are not guaranteed and can go negative — meaning the protocol would **pay** funding instead of earning it. During extended bear markets or periods of low speculative activity, yield could be zero or negative. The protocol does not promise a fixed APY. Yield is variable and reflects current market conditions. *** ## Liquidation risk The protocol's yield strategy involves transactions with perpetual DEX's, spot DEX's, and borrowing & lending protocols. As such, it may be subject to liquidation risk on any of these protocols due to a sharp drop in collateral value. However, this is not a significant risk in practice for two reasons: 1. **The positions are always 100% hedged.** If the protocol holds ETH or wBTC, it will have an equal short position on a perp DEX. If the asset price falls, the short position gains an equivalent amount. Conversely, if the asset price rises, the short position loses value. The two sides of the trade perfectly hedge each other. 2. **The protocol actively monitors and manages collateral.** When needed, the protocol transfers collateral from the various protocols to keep safe from being liquidated on any individual protocol. *** ## Exchange and counterparty risk The yield strategy depends on the lending protocol and perp DEX continuing to function correctly. Risks may include but are not limited to: * Downtime or insolvency of the lending platform or perp DEX * Smart contract vulnerabilities in the above protocols * Regulatory actions *** ## Centralisation risk Protocol operations — batch processing, capital deployment, and NAV updates — are currently performed by a single operator. A compromised or unavailable operator key could delay batch processing or mismanage capital. **Planned improvements:** **Chainlink Automation** is planned so upkeep and batch processing can be invoked on a decentralised schedule, reducing reliance on a single always-online operator key and lowering the risk of missed batches due to downtime. Multi-signature control remains on the roadmap as well. *** ## Hyperliquid custody risk Kash currently interacts with Hyperliquid in **direct deposit mode** — the bot's hot wallet is the master account on Hyperliquid. Protocol funds held on HL are secured by a single private key rather than by the on-chain adapter contract's permissioned guards. In the planned production configuration, the adapter *contract* would be the HL account master and the bot would act as a limited agent. Funds could only leave HL through the adapter → vault path, enforced by on-chain logic. This separation of custody from operations is the same pattern used by institutional custodians. The upgrade to non-direct deposit mode is blocked by the inability to call `approveAgent` for a smart-contract HL account (the adapter contract cannot sign EIP-712 messages). This is expected to be resolved by deploying an EIP-1271-capable adapter, or by integrating **Aster** (an Arbitrum-native perp DEX) as an alternative exchange. Because Aster runs natively on Arbitrum, its adapter contract can directly control positions without any cross-chain custody or agent-approval step — eliminating this risk class entirely. **Mitigations in the interim:** The bot address is distinct from the contract owner address on-chain, limiting what a single-key compromise can do. Continuous monitoring and automated batch operations reduce the need for manual intervention. *** ## Oracle risk The value of a deposit at batch time is calculated using on-chain price feeds. If a price feed provides incorrect or stale data, fewer KASH tokens than expected may be received on deposit, or fewer assets on redemption. Industry-standard oracle providers are used, but no price feed is entirely risk-free. *** ## No insurance Funds deposited in KASH are not insured. There is no protocol-level insurance fund at this stage. Deposits should not exceed amounts participants are willing to lose. *** ## Safeguards KASH is designed with layered protections against **external exploits** (hacks, malicious contracts, reentrancy) and **privileged-key misuse** (rugpulls by owner or operator). No set of safeguards eliminates all risk — see the sections above — but the following are built into the live contracts. ### Protections against hacks and external exploits **Capital deployment is bot-gated.** Moving funds to Aave, Hyperliquid, or spot DEXs — opening or closing shorts, borrowing, repaying, and swapping — can only be called by the configured **bot** or **keeper** addresses. A random attacker who finds a UI bug or phishes users cannot invoke these functions directly; they would need to compromise the bot or keeper key. **Reentrancy guards on high-risk paths.** Batch settlement and all external protocol interactions (Aave, perp DEX, spot swaps) use reentrancy protection. State is updated before outbound calls where it matters, reducing classic reentrancy drain vectors. **Whitelisted integrations only.** Spot swaps can only route through **pre-approved DEX adapter contracts**, and only among **allowed tokens**. The owner cannot point the vault at an arbitrary malicious router in a single transaction. **Timelock before new exchange adapters.** Registering a new perp or spot DEX adapter starts a **24-hour waiting period** on mainnet. A compromised owner key cannot instantly redirect the entire vault to a fake exchange — users and monitors have time to react before the adapter is confirmed and activated. The owner can lengthen this delay if desired. **Swap slippage cap.** On-chain swaps enforce a maximum slippage bound, limiting how much value can be lost to sandwich attacks or misconfigured routes in a single swap. **Safe token handling.** ERC-20 transfers use standard safe-transfer patterns, avoiding non-standard token return-value bugs. **Batch processing limits flash-loan abuse.** Deposits and redemptions queue for the **next daily batch**; there is no same-block deposit-and-redeem loop to farm NAV or funding in one transaction. **Emergency pause.** The owner can pause mints and redemptions. While paused, normal user flows stop — limiting damage while an incident is investigated. **Verified, auditable code.** Contract source is **verified on Arbiscan** and published in the public GitHub repo so anyone can compare deployed bytecode to the intended source. ### Protections against owner misuse **Pending user funds are ring-fenced.** When a deposit is submitted, ETH or wBTC is tracked in an on-chain **reserved** balance. Owner withdrawal functions can only take assets **above** what is reserved for pending mints and estimated redeems across recent unprocessed batches. Any attempt to withdraw reserved funds **reverts automatically**. **Users can cancel before the batch runs.** While the user window is open and the batch has not entered processing, a pending mint or redeem may be **cancelled** and assets or KASH returned — without owner involvement. **Users can self-rescue if the contract is paused.** If the contract is paused, dedicated emergency withdrawal paths allow reclamation of a **still-pending** request directly from the contract. These paths do not go through the owner. They require interacting with the contract directly (e.g. Arbiscan “Write Contract”) rather than the app UI. **Stray tokens only.** Token rescue exists to recover mistakenly sent ERC-20s (not the main deposit asset), sent to a designated recipient. ### Operator and NAV transparency **Separate bot key from owner.** Day-to-day batch ops use a dedicated **bot** address, distinct from the contract **owner**. Compromising one key does not automatically grant the other’s privileges — though either compromise remains serious. **NAV updates are recorded on-chain.** Each batch, the bot submits the new NAV used for mint and redeem pricing. The value is not recomputed inside the smart contract; it reflects off-chain portfolio marking from on-chain balances and perp economics. Each update is emitted on-chain for public audit after the fact. A compromised or buggy bot could still post an unfair NAV — **multi-signature** or additional controls for NAV submission remain on the roadmap. **Planned improvements:** **Chainlink Automation** for decentralised batch triggering, and **multi-sig** owner/operator control — see [Centralisation risk](#centralisation-risk) above. *** --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://kash-2.gitbook.io/kash-enhanced-yield-protocol/how-it-works/risks.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.