Skip to main content

​
Financial Model

This page separates:
  • what is already modeled in code
  • what is a proposed business model for the product

​
What is already modeled in code

The repository already models:
  • gross APY inputs
  • fees, borrow cost, and slippage as yield reductions
  • risk, liquidity, concentration, and operational haircuts
  • blended expected APY
  • risk budget usage
  • reserve policy
The repository does not yet implement a protocol-agnostic vault fee layer on-chain. So:
  • depositor return logic is modeled
  • business revenue extraction is not yet implemented as a final production mechanism

​
Depositor economics

The user outcome can be approximated as: 
net user return ≈ blended strategy return
                - execution friction
                - any future vault fee
                - cash drag from reserves and unused capacity
In more explicit notation: 
R_user ≈ R_portfolio - F_exec - F_vault - D_cash
Where:
  • R_user is depositor net return
  • R_portfolio is the blended return of allocated sleeves
  • F_exec is execution friction, including slippage and rebalance costs
  • F_vault is any future management or performance fee
  • D_cash is drag from reserve and idle capital
If we expand the portfolio component: 
R_portfolio ≈ sum_i (w_i * R_i)
And the drag term can be approximated as: 
D_cash ≈ w_reserve * OC_reserve + w_idle * OC_idle
Where:
  • OC_reserve is the opportunity cost of holding liquid reserve
  • OC_idle is the opportunity cost of leftover unallocated cash

​
Main positive drivers

  • higher expected net APY in Kamino
  • contribution from Drift
  • selected canary and exotic sleeves when score-positive

​
Main negative drivers

  • reserve requirement
  • protocol caps
  • score penalties
  • non-zero slippage and borrow costs
  • unallocated cash if caps are saturated

​
Business-model layer

The following are good revenue options for the product, but they are still business proposals.

​
1. Management fee

Example framing:
  • 30 bps to 100 bps annualized on TVL
Formalized: 
Revenue_management ≈ TVL * managementFeeRate
Pros:
  • simple to explain
  • aligns with treasury product positioning
Cons:
  • compresses user net yield

​
2. Performance fee

Example framing:
  • fee only on yield above a hurdle or benchmark
Formalized: 
Revenue_performance ≈ max(0, GrossProfit - HurdleProfit) * performanceFeeRate
Pros:
  • better alignment with users
  • easier to justify when solver performance is differentiated
Cons:
  • more complex accounting

​
3. B2B treasury subscription

Instead of monetizing retail TVL first, monetize:
  • treasury automation
  • reporting
  • whitelabel operations
  • compliance-oriented reserve controls
Pros:
  • stronger enterprise angle
  • less pressure to optimize only for TVL

​
4. Hybrid model

The most credible hackathon-to-product path is often:
  • low management fee
  • optional enterprise subscription
  • optional performance fee for advanced deployments
Formalized: 
Revenue_total
  ≈ Revenue_management
  + Revenue_performance
  + Revenue_subscription

​
Simple annualization formulas

For back-of-the-envelope business planning: 
Annual depositor PnL ≈ TVL * R_user

Annual protocol revenue ≈ TVL * feeTakeRate
If the product later charges a management fee plus enterprise subscriptions: 
Annual business revenue
  ≈ TVL * managementFeeRate + enterpriseContracts * averageACV

​
Illustrative unit economics

These numbers are examples, not implemented constants.

​
Example A. Early product

  • TVL: $1M
  • management fee: 50 bps
  • annual recurring revenue: about $5,000
This is too small as a standalone business, but enough to validate product-market fit and treasury workflows.

​
Example B. Small treasury platform

  • TVL: $25M
  • management fee: 50 bps
  • annual recurring revenue: about $125,000
At this stage, enterprise add-ons and B2B distribution matter more than retail scale.

​
Example C. Protocol treasury product

  • TVL: $100M
  • management fee: 35 bps
  • annual recurring revenue: about $350,000
This is where the combination of:
  • stable treasury demand
  • structured risk controls
  • auditability
starts to look commercially defensible.

​
Financial KPIs to track

If this becomes a live business, the most important KPIs are:
  • TVL
  • net depositor APY
  • reserve ratio realized vs target
  • withdrawal completion time
  • rebalance frequency
  • share of capital in cash drag
  • protocol concentration over time
  • number of reserve breaches prevented by the policy layer

​
Relationship between solver quality and business quality

At the product level, solver quality influences business outcomes through a simple chain: 
better allocation quality
  -> higher risk-adjusted depositor return
  -> stronger retention and treasury credibility
  -> more TVL or more enterprise demand
  -> stronger revenue potential
So the solver is not only an engineering component. It is part of the economic moat of the product.

​
Why this is stronger than “highest APY wins”

The business pitch should not be:
  • “we find the highest yield”
It should be:
  • “we manage stablecoin treasury capital with explicit controls and measurable risk-adjusted yield”
That is a much stronger financial story for serious capital.