Appearance
Security
Access Control
Vault Owner
The vault owner (protocol admin) can:
- Set strategy — migrate funds to a new strategy
- Set keeper — authorize keeper bot to trigger harvests
- Revoke keeper — remove keeper authorization
- Set guardian — authorize guardian for emergency pauses
- Set fee recipient — change where fees go (only if not locked)
- Lock fee recipient — permanently lock the fee recipient address (irreversible)
- Pause/unpause — halt all operations in emergencies
The owner cannot:
- Access user funds directly
- Withdraw on behalf of users
- Change the performance fee (immutable 10%)
Keeper
The keeper bot wallet can:
- Call harvest() — trigger yield claiming and compounding with slippage protection
- Call rebalance() — adjust protocol allocations (subject to cooldown)
The keeper cannot:
- Withdraw funds
- Change allocations
- Access user deposits
Guardian
The guardian can:
- Pause — halt all vault operations in case of emergency
The guardian cannot:
- Withdraw funds
- Change settings
- Unpause (only owner can unpause)
Strategy Owner
The strategy owner can:
- Manage yield sources — add, remove, enable/disable protocols
- Update allocation splits — change how funds are distributed (subject to cooldown)
- Manage DEX routers — add, remove, or switch routers for reward swaps
- Set cooldown periods — configure rebalance and split change cooldowns
- Rescue tokens — recover accidentally sent tokens
- Pause/unpause — halt strategy operations
Security Features
ReentrancyGuard
All state-changing functions in both the vault and strategy are protected by OpenZeppelin's ReentrancyGuard to prevent reentrancy attacks.
Pausable
Both vault and strategy implement OpenZeppelin's Pausable:
- Guardian or owner can pause in emergencies
- Only owner can unpause
- When paused: deposits, withdrawals, harvests, and strategy changes are blocked
Virtual Share Offset
The vault uses a decimalsOffset of 6 (1e6 virtual shares/assets) to protect against inflation attacks where an attacker could donate assets to manipulate share prices and steal from subsequent depositors.
Checks-Effects-Interactions Pattern
The vault and strategy follow the checks-effects-interactions pattern, updating state before making external calls to prevent reentrancy vulnerabilities.
Protocol Rounding Handling
Compound rounding fix: When withdrawing from Compound-based protocols (Takara), the strategy handles cases where the protocol returns slightly less than requested due to rounding. Instead of reverting, it transfers the actual amount received.
Vault withdrawal adjustment: The vault similarly adjusts withdrawal amounts to the actual balance available, preventing reverts from minor rounding discrepancies.
Slippage Protection
All reward swaps are protected against MEV extraction and price manipulation:
How It Works
solidity
function harvest(
uint256[] calldata minAmountsOut // Min USDC from each yield source's reward swaps
) external returns (uint256);Before calling harvest, the keeper:
- Queries fair prices from DEX for reward tokens → USDC
- Applies slippage tolerance (1% by default):
minOut = quote * 0.99 - Passes minimum outputs to harvest function (one per yield source)
- If actual output < minOut for any swap, transaction reverts
On-Chain Slippage Cap
The strategy enforces a maximum slippage cap:
- Default: 5% (500 basis points)
- Ceiling: 10% (
MAX_SLIPPAGE_CEILING) — owner cannot set higher
This provides an absolute upper bound on slippage, preventing keeper misconfiguration or attacks.
Protection Guarantees
| Attack Vector | Mitigation |
|---|---|
| Sandwich attacks | Transaction reverts if output < expected |
| Price manipulation | Off-chain price validation + on-chain slippage cap |
| Front-running | Slippage tolerance makes attack unprofitable |
| Flash loan attacks | Reversion on manipulated prices |
Example Attack Scenario
- 🎯 Attacker sees harvest transaction in mempool
- 💸 Attacker front-runs: buys reward token, manipulates price up
- 🛡️ Harvest executes: swap output < minAmountOut
- ❌ Transaction reverts
- 💸 Attacker back-run fails, attacker loses gas fees
Result: Funds stay safe, attacker loses money.
Cooldown Mechanisms
Rebalance Cooldown
Duration: 1 hour (3600 seconds)
Prevents:
- Excessive rebalancing gas costs
- Manipulation through frequent rebalancing
- Panic rebalancing during temporary APY fluctuations
Splits Cooldown
Duration: 1 hour (3600 seconds)
Prevents:
- Rapid allocation changes
- Gaming the system with frequent splits updates
Both cooldowns are configurable by the strategy owner.
Dynamic Source and Router Limits
Max Yield Sources
Limit: 10 protocols (MAX_YIELD_SOURCES)
Prevents:
- Excessive gas costs from managing too many protocols
- Complexity that could introduce bugs
- Attack vectors from malicious protocol additions
Router Management
The strategy maintains a registry of approved DEX routers:
- Owner controls which routers are enabled
- Can switch active router without redeploying
- Limits exposure to untrusted DEXs
Emergency Functions
rescueToken (Vault)
The vault owner can recover accidentally sent tokens:
solidity
function rescueToken(address token) external onlyOwner;Protection: Cannot be used to extract the vault's underlying asset — it explicitly blocks the vault asset.
rescueToken (Strategy)
The strategy owner can recover stuck tokens:
solidity
function rescueToken(address token, uint256 amount) external onlyOwner;Protection: For the vault's underlying asset, can only recover loose tokens not deployed to protocols (the difference between total balance and strategy-managed balance).
Pause Functions
Both vault and strategy can be paused by guardian or owner:
- Blocks all user operations (deposits, withdrawals)
- Blocks harvests and rebalances
- Blocks strategy changes
- Only owner can unpause
Risk Factors
Smart Contract Risk
| Risk | Mitigation |
|---|---|
| Vault contract bugs | ERC-4626 standard, well-tested OpenZeppelin pattern |
| Strategy contract bugs | Comprehensive security features, ReentrancyGuard |
| Protocol bugs (Yei/Takara/Morpho/Feather) | Forked from audited codebases (Aave V3, Compound, MetaMorpho) |
Protocol Risk
| Risk | Mitigation |
|---|---|
| Protocol insolvency | Diversification across multiple 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 |
| Guardian key compromise | Guardian can only pause, not withdraw or change settings |
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 cap with transaction reversion, off-chain price validation |
| Sandwich attacks | minAmountOut protection makes attacks unprofitable |
Audit Status
WARNING
Kana contracts have not been formally audited. Use at your own risk. A professional audit will be conducted before mainnet launch reaches significant TVL.
Static Analysis
The contracts have been analyzed with Slither (static analysis tool) and all critical issues have been resolved.
Recommendations
- Use a multi-sig for owner roles in production
- Monitor keeper operations via Telegram alerts
- Set appropriate slippage tolerances based on market conditions (default 1%)
- Review yield sources before adding new protocols to the strategy
- Test thoroughly on testnet before deploying new features