Security Self-Assessment

The on-chain buyback route points to an unfunded pool (route not in use)

BuybackBurner.buyAndBurn swaps through UniswapV4Adapter, which trades in the KyteHook $KYTE/WETH pool (fee 0.30%, tick spacing 60). At block 109,974,684 that pool holds zero liquidity. Its spot price and its 10-minute TWAP both read 997,000 KYTE per WETH, which is its initialisation price less the LP fee. $KYTE's live market is a different Uniswap v4 pool (0xe25a…229e), where 1 WETH buys about 33.8 million KYTE.

Context. Kyte currently executes $KYTE buybacks manually. Platform volume has not yet justified automated buybacks, and BuybackBurner has never been called: no WETH has been swapped and lastPrice is 0. The rating reflects that this path is inactive. The same issue would be rated Medium if the path were switched on unchanged.

Impact if enabled. With no liquidity, a buyback call simply reverts. If liquidity were later added to the KyteHook pool near its current price, the on-chain slippage floors would accept a fill far above market. That is because the adapter quote is taken from the same pool. The keeper's minTokenOut would then be the only protection.

Recommendation. Before automated buybacks are switched on, point the burner at an adapter for the live pool (setAdapter, through the timelock), or seed the KyteHook pool at market price and let a TWAP history build. Derive minTokenOut from the live market.

Team response. Buybacks remain manual. The route will be corrected before automated buybacks are enabled.

The on-chain buyback price floor follows the last fill (route not in use)

After each swap the burner records lastPrice, the tokens received per WETH. Every later call must satisfy minTokenOut ≥ wethIn × lastPrice × (1 − maxSlippageBps). If $KYTE rises in price by more than maxSlippageBps (5% now, 20% at most) between two buybacks, the next call reverts. lastPrice cannot be reset, and WETH in the burner can only leave through a swap.

Context. Kyte currently executes $KYTE buybacks manually. Platform volume has not yet justified automated buybacks, and BuybackBurner has never been called: no WETH has been swapped and lastPrice is 0. The rating reflects that this path is inactive. The same issue would be rated Medium if the path were switched on unchanged.

Recommendation. Before enabling automated buybacks, bound each fill against the TWAP only, use a floor that decays over time, or add a timelock-only reset. Then deploy the revised burner and point FeeVault.setDestinations at it.

Team response. Acknowledged. Buybacks remain manual and will move to a revised burner before automation is enabled.

The Router can be blocked by sending it 1 wei of WETH (direct market access unaffected)

After every call the Router requires its WETH and ETH balances to be exactly zero. Anyone can transfer WETH to it, and ETH can be forced in with SELFDESTRUCT. The Router has no sweep function and is immutable. A 1-wei transfer would therefore make buyWithETH, exerciseWithETH, buyPutWithETH and createPutOfferWithETH revert.

Impact. This affects availability only. No funds can be taken, and positions are unaffected. The markets remain usable directly with WETH (buy, exercise, exercisePut, createPutOffer). The timelock can install a replacement Router with setRouter on both markets. Both of the Router's balances are 0 at block 109,974,684.

Recommendation. In the next Router, compare against balances recorded at the start of each call, or forward any surplus to the FeeVault.

Team response. Acknowledged. Direct WETH access and a timelock replacement are the fallback; the fix is planned for the next Router.

The timelock delay is 10 minutes on chain; the code comments describe 48 hours

getMinDelay() returns 600 seconds. The NatSpec in Governed.sol describes "the timelock (48 h, behind the admin Safe)". The timelock's powers are listed in section 4; none of them can move escrowed collateral or staked $KYTE. A short delay gives users less time to react to a settings change, such as new FeeVault destinations.

Recommendation. Either raise the delay with updateDelay (called through the timelock), or align the documentation with the value actually in use.

Team response. Acknowledged. The documentation will state the on-chain delay, and the delay will be reviewed as usage grows.

Physical settlement depends on the underlying token staying transferable

Exercise moves the underlying token itself: a call delivers it to the holder, and a put pulls it from the holder. Expiry and cancellation return it to the seller. If a token's issuer paused or restricted transfers, those calls would revert. A pause that overlaps an option's expiry could cost the holder the exercise window. This is inherent to physical settlement and is not a code defect.

Recommendation. Explain this in the interface next to the session warnings. A trading halt is not the same as a token transfer pause.

The guardian Safe needs a single signature

The guardian is a Safe with 3 owners and a threshold of 1. It can only pause and switch listings off, never unpause, enable anything or move funds. A single signer suits a fast circuit breaker.

StakingPool.notifyReward emits no event

The reward amount is recorded by FeeVault.FeesSplit in the same transaction, so indexers can still follow it.

KyteHaltGate reverts instead of answering if the oracle reports a future timestamp

If a row's writtenAt were ever in the future, uint64(block.timestamp) - writtenAt would underflow. That revert happens inside the try success block, so catch does not handle it. The behaviour fails closed. No live contract calls the gate.

Rebasing tokens would break collateral accounting

Fee-on-transfer tokens are rejected on chain. A rebasing token would make locked disagree with the real balance. Every listing goes through the timelock (251 tokens listed), and that curation is the control.

Live contracts were built from different commits

The markets use the newest constants (option ID tags 5 and 6, confirmed on chain). AssetRegistry uses an intermediate set, and Router and StakingPool were built from an earlier commit. Each contract was verified and analysed on its own source. The differences are only in constants those contracts do not use. Tagging one release commit per deployment would make future reviews simpler.