Security

Kestrel uses defense in depth. Privileged roles can request specific operations, but the program still verifies the accounts, assets, prices, limits, and result of each operation before state is committed. A valid operator signature does not bypass those checks.

Separated roles and limited authority

Tokens and yielding banks separate the admin, manager, curator, fee-wallet, and circuit-breaker roles. Each role is limited to a defined set of instructions and configuration fields.

The manager can operate strategies, but cannot change fee rates, withdrawal limits, deposit limits, or role assignments.
The curator can collect only its accrued fee bucket to the configured curator fee wallet and can rotate only that fee wallet.
The protocol fee authority can collect only accrued protocol fees, and only to the program's configured protocol and donation destinations.
The admin can update bounded configuration and rotate roles, but does not receive unrestricted authority to transfer token reserves.
Curator creation and rotation are restricted to an on-chain allowlist.
Role replacements must be plain System Program-owned wallets with no account data, preventing a caller from silently installing an arbitrary program-owned account as a role.
Oracle configuration is fixed when a token is created rather than being freely replaceable by an operational key.

An admin role can be assigned to a multisig, but multisig use is an operational deployment choice; the program itself does not claim that every configured admin is a multisig.

Circuit breakers

Tokens and yielding banks each have an independent circuit breaker. A dedicated controller or the admin can activate it, while only the admin can turn it off. Once active, normal activity stops. Defensive deleveraging remains available so debt can be reduced during an incident.

This asymmetry lets a narrowly scoped emergency key stop the system without giving that key the power to restart it or redirect funds.

Redemption and deposit limits

Every burn is charged against the token's rolling redemption-rate limit before collateral can leave reserves. The configuration is constrained on-chain:

The minimum rate-limit window is one hour.
Below $1 million TVL, one window can permit at most 50% of supply.
Between $1 million and $5 million TVL, the maximum is 30% of supply.
At $5 million TVL or above, the maximum is 15% of supply.
Above $1 million TVL, the rate limit cannot be disabled.

Tokens can also have a USD deposit cap. A mint is rejected if the deposit would push total unlent-plus-lent collateral above that cap. An admin cannot lower a positive cap below collateral already backing the token.

These controls bound rapid balance-sheet changes. They do not prevent a holder from redeeming; redemptions that cannot settle from unreserved liquid collateral move to the asynchronous flow.

Rate limits, cooldowns, and timelocks

The program limits how frequently loss-producing operational actions can repeat:

A lending position cannot be rebalanced more than once every 24 hours. This limits repeated swap spread and blocks rapid back-and-forth rebalances.
A yielding bank rebalance is rate-limited to no more than once per minute outside local builds.
In production, an empty yielding-bank allocation must age for five days before it can be removed. This protects allocation cleanup from immediate create-and-delete behavior.

Normal allocation touches currently have a zero-second cooldown. The five-day production timelock applies to cleanup, not to every strategy operation.

Fresh prices and bounded risk

Actions that depend on value require recently refreshed accounting and oracle data. Token and yielding-bank prices expire after one hour, while position-changing flows perform fresh lending position reads and validate the configured oracle, reserve, and protocol account identities.

After a strategy action, the program enforces economic bounds including:

Lending-position utilization must remain within its configured LTV band or close to its target.
Carry increases cannot push utilization above target, and deleveraging cannot use a riskier caller-selected target than the configured one.
Swaps and rebalances must remain within instruction-specific slippage and TVL-loss limits.
Interest cannot be collected unless carry assets cover debt.
Token-price growth can be capped by the configured maximum APY.
Fee rates, fee splits, drip settings, and lending-position parameters have hard upper and lower bounds.

If any post-operation check fails, the Solana transaction fails atomically and its preceding state changes and transfers are rolled back.

Constrained cross-program calls

Strategy operations interact with lending markets and swap venues through cross-program instructions. The manager cannot pass an unrestricted bundle and have the token PDA sign it.

The program classifies allowed calls—such as deposit, withdraw, borrow, repay, or swap—and enforces the expected order, count, platform, and target accounts for each instruction. Prerequisite bundles cannot contain active asset-moving categories. Variable swap bundles are capped in length.

Before and after each call, the program measures actual token-account balances and refreshes the external position. It then reconciles balance changes against reported debt, collateral, share, and TVL changes. Unexpected account consumption, duplicate accounts, excess slippage, or a mismatch between transferred assets and position accounting causes the entire transaction to fail.

Account and custody validation

Program state is held in deterministic program-derived accounts. Instructions recompute and verify the canonical PDA address and stored bump before using a state account as a signer.

Asset accounts are bound to their expected mint, authority, and SPL Token or Token-2022 program. User transfers use the user's associated token account; reserve transfers use the token or yielding bank PDA's associated token account. Lending obligations, reserves, debt oracles, fee destinations, sysvars, async requests, and redemption epochs are compared with the addresses recorded in on-chain state before funds move.

Privileged wallets therefore request PDA-signed actions; they do not directly custody the reserves or receive a generic PDA signing capability.

Asynchronous redemption safety

When liquid, unreserved collateral is insufficient, redemptions use on-chain request and epoch accounts rather than paying from collateral committed elsewhere.

Requests are processed in strict FIFO sequence.
Escrow accounts are tied to the requesting user, token, epoch, mint, and canonical PDA.
The token tracks gross pending liabilities and collateral reserved across active epochs.
Collateral already reserved for redemptions cannot be redeployed as idle capital or used for a synchronous redemption.
Epoch funding, unwind losses, user payouts, and released reservations are reconciled as each request is processed.
A request owner can cancel the FIFO-head request after the cancellation delay while its epoch is still open.

Arithmetic and configuration validation

Accounting uses checked addition, subtraction, multiplication, division, and integer conversion for asset amounts and normalized USD values. Invalid or overflowing calculations return an error instead of wrapping. Basis-point values, fee totals and splits, interest-release settings, LTV bands, epoch identifiers, timestamps, and account-array indices are validated before use.

The program also derives financial outcomes from observed balance changes instead of trusting only caller-supplied amounts. This is important when an external protocol rounds, charges a fee, closes an account, or otherwise returns a result different from the requested amount.

What these controls do not guarantee

Security controls reduce attack surface and constrain privileged actions; they are not a guarantee against loss. Kestrel still depends on its own program code, Solana, configured oracles, supported lending and swap protocols, deployment and upgrade processes, and operational security. Review Risks alongside this page.