> ## Documentation Index
> Fetch the complete documentation index at: https://pessoal-86816071.mintlify.site/llms.txt
> Use this file to discover all available pages before exploring further.

# Financial Model

> Financial framing of depositor returns, vault economics, and proposed revenue model for the business layer.

# 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:

```text theme={null}
net user return ≈ blended strategy return
                - execution friction
                - any future vault fee
                - cash drag from reserves and unused capacity
```

In more explicit notation:

```text theme={null}
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:

```text theme={null}
R_portfolio ≈ sum_i (w_i * R_i)
```

And the drag term can be approximated as:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
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:

```text theme={null}
Revenue_total
  ≈ Revenue_management
  + Revenue_performance
  + Revenue_subscription
```

## Simple annualization formulas

For back-of-the-envelope business planning:

```text theme={null}
Annual depositor PnL ≈ TVL * R_user

Annual protocol revenue ≈ TVL * feeTakeRate
```

If the product later charges a management fee plus enterprise subscriptions:

```text theme={null}
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:

```text theme={null}
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.