Strategies & policy

A strategy is how your capital is allocated — a risk policy plus the engine that enforces it. This doc covers the three templates, every policy dial, the scoring math, and the gates a move must clear. It's the most important doc for understanding what your treasury will actually do.

The three templates

Pick one at deploy. They share the same allocation engine and differ only in their risk posture:

Choosing:

• conservative — capital you might need soon, or a low-risk mandate. Big buffer, tight concentration, only moves for a clear (1%+) gain that pays for itself within 3 days.
• balanced — the default. Reasonable concentration, modest buffer, moves for half-percent gains.
• aggressive — maximize deployed yield. Will concentrate fully into the best venue, runs a thin buffer, chases quarter-percent edges. Aggressive here means "fully deployed and rate-sensitive," not "leveraged" — it's still lend-only, single-asset, custody-bounded.

You can also pass a full custom policy object instead of a template; it's validated (every dial bounds-checked) and rejected if malformed — never silently "fixed up."

Scoring: net risk-adjusted APY

Before allocating, every venue is scored:

net APY = headline APY − venue cost − risk haircut

• headline APY — the venue's live supply rate, read on-chain.
• venue cost (costBps, ~5bps default) — the adapter's estimate of round-trip execution friction (priority fees, etc.). Per-move gas is handled separately by the break-even gate.
• risk haircut (riskBps) — what's wrong with the venue itself:
  • utilization ≥ 90% borrowed → −100bps; ≥ 97% → −400bps. At high utilization, withdrawals queue behind borrower repayments — the headline rate is increasingly theoretical for someone who needs to exit.
  • TVL below $1M → the venue is excluded entirely. A thin pool isn't a venue, it's an exit-liquidity trap.

Venues are then ranked by net APY, best first. This is where a 7%-headline pool at 95% utilization correctly loses to a 6.5% pool at 80%.

The allocation algorithm

Greedy fill, best-net-APY first, within the caps:

1. Target. Reserve the liquidity buffer. Allocate the rest to venues in score order, each up to maxAllocPerVenuePct of total. (At balanced: 70% to the top venue, then 70% of the remainder to the next, etc., until the buffer is all that's left.)
2. Diff. Compare current positions to target → a list of surpluses (too much here) and deficits (too little there).
3. Forced compliance first. A position above its hard cap is a forced surplus — unwinding it bypasses the improvement filter entirely. Risk bounds beat yield: the engine will move capital out of an over-cap venue even at a yield loss, because the policy is a constraint, not a suggestion.
4. Match surpluses to deficits, cheapest-yield capital moved first.

The gates: when a move does not happen

A proposed move must clear all of these or it's dropped (and the rejection is logged):

1. Risk gate (pure function) — won't breach a cap, won't eat the buffer, stays on the allowlist. See Security — risk gate.

2. Minimum improvement — for yield-chasing moves, the APY gain must exceed minImprovementBps. (Forced compliance moves skip this.)

3. Dust floor — the move must be larger than minMoveBps of total. Without this, accrual drift would churn micro-moves forever, each costing gas.

4. Break-even gate — the move's extra yield, over maxBreakEvenDays, must exceed its execution cost:

   horizon gain = amount × improvementBps × days ÷ (10000 × 365)
   move happens only if  horizon gain ≥ MOVE_COST_USDC   (default $0.10)

   This is what makes small treasuries safe to automate. A $100 treasury won't move at all, because a week of a half-percent edge on $100 is less than ten cents of gas. Gas never eats the yield. (MOVE_COST_USDC is tunable per deployment to match real mainnet fees.)

A worked example (live mainnet rates)

With Marginfi at 6.27% net and Kamino at 3.17% net, balanced template:

$10,000 → 7,000 marginfi · 2,000 kamino · 1,000 buffer
$1,000  → 700 marginfi · 200 kamino · 100 buffer   (clears; marginal on kamino leg)
$100    → NO moves                                  (break-even gate: yield < gas)

You can reproduce this yourself with the dry-run planner — no capital, no execution:

npx @olbos/cli plan --aum 10000 --template balanced

Autonomy: the watch loop

A deployed strategy can run unattended. The watch loop re-scores and re-plans on an interval (60s by default with real venues — they move slowly). Because the planner only emits moves that clear every gate, polling is cheap: most cycles are no-ops. Each cycle also runs venue health checks; a violated invariant trips the fail-safe kill. Consecutive failures back off and eventually halt safely.

What's deliberately out of scope (and the roadmap)

v1 is a single-asset, lend-only, spot-rate, greedy allocator — on purpose. It's legible and hard to lose money with. Richer behavior is roadmap, not hidden:

• multi-asset treasuries (and the FX/risk that comes with them);
• forward-rate awareness (act on where rates are going, not just where they are);
• new venue types — LP positions, liquid staking, fixed-term;
• optimization beyond greedy (mean-variance, Sharpe-aware sizing);
• auto-compounding policy and tax-lot awareness.

Each of these slots into the existing seams: a new venue type is a new adapter; a smarter allocator is a change to plan() behind the same gates.

Next: Venues · Payments · Agents.