Security

Access Control

Vault Owner

The vault owner (protocol admin) can:

• Set strategy — migrate funds to a new strategy
• Set performance fee — up to the 20% hard cap
• Set fee recipient — change where fees go
• Rescue tokens — recover accidentally sent tokens

The owner cannot:

• Access user funds directly
• Withdraw on behalf of users
• Set fees above 20%
• Pause user withdrawals (no pause mechanism)

Strategy Owner

The strategy owner can:

• Set allocation weights — how funds are split across protocols
• Trigger rebalance — force a reallocation

Keeper

The keeper bot wallet can:

• Call harvest() — trigger yield claiming and compounding
• Call rebalance() — adjust protocol allocations

Slippage Protection

All reward swaps (Takara COMP tokens, Morpho rewards) are protected against MEV extraction and price manipulation:

How It Works

function harvestWithSlippage(
    uint256 takaraMinOut,   // Min USDC from Takara swaps
    uint256 morphoMinOut    // Min USDC from Morpho swaps
) external;

Before calling harvest, the keeper:

1. Queries fair prices from Sailor DEX for reward tokens → USDC
2. Applies slippage tolerance (1% by default): minOut = quote * 0.99
3. Passes minimum outputs to harvest function
4. If actual output < minOut, transaction reverts

Protection Guarantees

Attack Vector	Mitigation
Sandwich attacks	Transaction reverts if output < expected
Price manipulation	Off-chain price validation prevents bad trades
Front-running	Slippage tolerance makes attack unprofitable
Flash loan attacks	Reversion on manipulated prices

Backward Compatibility

The original harvest() function still exists for backward compatibility but offers no slippage protection (passes 0 for minAmountOut, accepting any output). Production systems should always use harvestWithSlippage().

Example Attack Scenario

1. 🎯 Attacker sees harvest transaction in mempool
2. 💸 Attacker front-runs: buys reward token, manipulates price up
3. 🛡️ Harvest executes: swap output < minAmountOut
4. ❌ Transaction reverts
5. 💸 Attacker back-run fails, attacker loses gas fees

Result: Funds stay safe, attacker loses money.

---

Emergency Functions

rescueToken

If tokens are accidentally sent to the vault (not USDC), the owner can recover them:

function rescueToken(address token) external onlyOwner {
    require(token != asset(), "Cannot rescue vault asset");
    uint256 balance = IERC20(token).balanceOf(address(this));
    IERC20(token).transfer(owner(), balance);
}

This function cannot be used to extract the vault's USDC — it explicitly blocks the vault asset.

Risk Factors

Smart Contract Risk

Risk	Mitigation
Vault contract bugs	ERC-4626 standard, well-tested pattern
Strategy contract bugs	Simple logic, comprehensive tests
Protocol bugs (Yei/Takara/Morpho)	Forked from audited codebases (Aave V3, Compound)

Protocol Risk

Risk	Mitigation
Protocol insolvency	Diversification across 3 protocols
Liquidity crunch	Proportional withdrawal reduces single-protocol drain
Oracle manipulation	Underlying protocols handle their own oracle security

Operational Risk

Risk	Mitigation
Keeper downtime	Funds stay safe in protocols, just unharvested
Keeper key compromise	Keeper can only harvest/rebalance, not steal funds
Owner key compromise	Multi-sig recommended for production

Economic Risk

Risk	Mitigation
Yield drops to 0	No loss of principal — just no returns
Reward token crashes	Immediate swap on harvest reduces exposure
MEV extraction	On-chain slippage limits with transaction reversion, off-chain price validation
Sandwich attacks	minAmountOut protection makes attacks unprofitable

Audit Status

WARNING

Kana is currently in planning phase. Contracts have not been audited. Use at your own risk on testnet. A professional audit will be conducted before mainnet launch.

Recommendations

• Start with YeiOnlyStrategy — simpler, fewer attack surfaces
• Use a multi-sig for owner roles in production
• Monitor keeper operations via Telegram alerts
• Test thoroughly on testnet before mainnet deployment