> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tradeatlas.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Referral Incentives Evaluation

> Decision package for ticket

This document captures the decision package for issue #125: evaluate referred-user incentives for depositors and choose a rollout path that balances growth, revenue quality, and implementation risk.

## Scope

In scope:

* Quantitative comparison of options A-E.
* Go/no-go recommendation with explicit acceptance gates.
* Implementation-ready direction for follow-up tickets.

Out of scope:

* Mainnet deployment.
* Live token emissions.
* Contract/frontend incentive implementation in this ticket.

## Weighted Scoring Rubric

The weighted scoring model used by `scripts/referrals/evaluate-incentives.ts`:

| Criterion                   | Weight | How it is measured                                 |
| --------------------------- | ------ | -------------------------------------------------- |
| Referral conversion lift    | 35%    | Projected uplift vs baseline referred deposit rate |
| Net protocol revenue impact | 25%    | Incremental fee value minus incentive cost         |
| Engineering complexity/risk | 20%    | Effort + delivery risk normalization               |
| Abuse resistance            | 10%    | Effective risk after controls coverage             |
| Time-to-market              | 10%    | Estimated delivery timeline score                  |

## Baseline Inputs

* Baseline referred deposit rate: `12.00%`
* Average referred deposit size: `$1,800`
* Average referred hold time: `52 days`
* Fee-derived value per referred user (flat regime): computed in script output
* Fee-derived value per referred user (volatile regime): computed in script output
* Staker reward sensitivity: reported per option in scenario CSV (`stakerRewardSensitivityBps`)

## Scenario Design

All options are simulated across:

* Adoption bands: `low`, `base`, `high`
* Market regimes: `flat`, `volatile`

This yields 30 deterministic rows in:

* `scratch/KaironAI/ticket-125-scenarios.csv`

## Simulation outcome summary

Average across all six scenario cells per option:

| Rank | Option                       | Avg weighted score | Avg net revenue impact | Avg conversion lift | Gate pass (conversion / revenue / abuse) |
| ---- | ---------------------------- | ------------------ | ---------------------- | ------------------- | ---------------------------------------- |
| 1    | C (performance fee discount) | 56.78              | +\$1,738.47            | +15.45%             | 3/6, 6/6, 6/6                            |
| 2    | E (points)                   | 48.42              | +\$966.16              | +6.76%              | 0/6, 6/6, 0/6                            |
| 3    | D (fixed USDC bonus)         | 45.20              | +\$109.06              | +12.56%             | 1/6, 3/6, 6/6                            |
| 4    | B (staking boost)            | 41.49              | +\$462.53              | +11.59%             | 1/6, 6/6, 6/6                            |
| 5    | A (vested esATLAS)           | 40.32              | -\$1,454.01            | +18.35%             | 5/6, 0/6, 6/6                            |

Interpretation:

* Option C is the only path that combines top weighted score with positive net revenue and fully passing revenue/abuse gates.
* Option A has strong conversion potential but fails revenue guardrails in this model due emission cost.
* Option E is operationally light but fails conversion and abuse readiness gates for launch economics.

## Abuse and Policy Checks Applied

The simulator includes these controls in the abuse-resistance pass/fail model:

* `featureFlag` gate required for runtime kill-switching
* `treasuryCap` for hard exposure limits
* `minQualifyingDeposit` to reduce dust farming
* `holdPeriodRequired` where relevant
* `freezeCode` administrative freeze control

P1 abuse vectors are counted when hard controls are missing and/or effective risk exceeds threshold.

## Acceptance Gates

A strategy should satisfy:

* Referral conversion uplift `>= +15%`
* Revenue drawdown cap `<= 10%`
* Unresolved P1 abuse vectors `= 0`

## Recommendation

### Phase 1 default

Adopt **Option C (performance fee discount)** behind:

* Feature flag
* Hard treasury drawdown cap
* Minimum qualifying deposit requirement
* Abuse monitoring with freeze controls

Why:

* Strong weighted performance in this evaluation.
* Fastest practical path to tangible depositor value.
* No token emission pressure.
* In the base/high adoption scenarios, it meets conversion gates while preserving revenue and abuse constraints.

### Phase 2 optional campaign

Conditionally run **Option A (capped esATLAS vesting)** only if Phase 1 proves sustained uplift above gate thresholds and budget controls remain intact.

Why:

* Useful as a growth campaign lever.
* Emissions and implementation complexity are higher, so it should remain gated.

### Not primary for initial launch

* **Option B:** viable fallback if fee discount is blocked by fee-path complexity, but staker dilution risk is non-trivial.
* **Option D:** can work as a temporary campaign but scales poorly and requires constant budget operations.
* **Option E:** fast to ship but weak immediate economic pull and higher gaming risk per user value delivered.

## How to reproduce

From repository root:

```bash theme={null}
npx ts-node scripts/referrals/evaluate-incentives.ts
```

This rewrites:

* `scratch/KaironAI/ticket-125-scenarios.csv`

Run twice and compare hashes to confirm determinism.