# Fees and incentives

**Proposal for review · 2026-09-16.** No partner fee rate, wrapper deployment,
revenue split or AMM reward budget is approved by this document.

## Keep four amounts separate

- **Vault income:** LP fees and any lending interest attributable to vault holders.
- **Protocol fees:** Charges set by the deployed protocol and its governance.
- **Partner fee:** An optional, disclosed surcharge for using a fork's execution path.
- **Campaign rewards:** A separately funded promotion with published rules.

A referral record is not a fifth source of income. The AMM deposit router
records attribution; it does not itself pay the referrer. Rebranding an existing
market does not give a fork ownership of its fees or a right to change them.

## Proposed partner choices

| Choice | Proposed responsibility | Readiness |
| --- | --- | --- |
| No extra fee | Use the existing execution path. Agree any protocol revenue share separately. | Existing no-surcharge path; revenue-sharing terms still need approval. |
| Thetanuts-maintained AMM adapter | Partner chooses from approved fee/payout settings; Thetanuts maintains the reviewed implementation. | To design, test and release for AMM. |
| Your own AMM adapter | Partner owns implementation, review, UI disclosure and support. | Possible integration path, not an automatically accepted contract. |

The Thetanuts OptionBook partner broker is a design reference, **not** an AMM
Markets adapter. AMM buyer ownership, exercise rights, refunds and deposit
attribution must survive the added contract call. Merely replacing a router
address with a wrapper address is not sufficient.

Recommended first wrapper scope: buyer fills only, with a clear fee base and
an all-in spend limit. Preserve the passive seller's requested payment. Leave
vault deposits, withdrawals and option exercise on existing paths until any
extra fee on those actions is separately designed and approved.

Quote the fee amount and its basis before approval. Do not charge against an
unused top-up allowance, refundable surplus or another user's funds. Protocol
fees and partner fees must not be counted twice. Routing directly to a public
contract may bypass an optional frontend wrapper; do not promise revenue from
all users of the underlying market.

## Protocol revenue sharing

Agree who receives which portion of fees actually collected, in which token,
from which actions, on which schedule. This is distinct from an extra buyer fee.
Keep partner identity separate from a user's first-touch referrer. Do not
overwrite referrals to make a partner fee ledger easier to implement.

The current shared referral leaderboard is not a fee-settlement ledger. A new
programme needs verifiable attribution, reconciliation, payout evidence and
rules for refunds, duplicates and unavailable data before balances are payable.

## Funded incentives

[Odette advertises a weekly 1,150 USDC competition](https://odette.fi/):
500 / 200 / 100 USDC for the top three, then 50 USDC each for places 4–10.
That is a reference for campaign design, not a budget promised to AMM forks or
evidence that a new campaign has funds reserved.

A fork can propose a partner-funded, Thetanuts-funded or co-funded campaign.
Publish the sponsor, funded cap, dates, eligibility, scoring, verification and
payout process before launch. Separate pending rewards from paid rewards and
from trading returns. Rewards stop when their stated budget ends.

Prefer a bounded pilot that rewards verified useful activity. Review self-referral,
Sybil, circular trading and deposit-withdrawal farming before paying. Do not
reward raw volume alone or make a missing index record look eligible.

## Decisions before implementation

1. Wrapper fee payer, action scope, basis, cap, recipient and change policy.
2. How user ownership and first-touch attribution survive each execution path.
3. Protocol revenue-sharing source, beneficiaries and settlement process.
4. Campaign sponsor, budget, period, scoring and payout authority.

The detailed engineering review and estimates remain with the launch team.