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

# Glossary

> Terms used across the API, contracts, and portal.

### Engine

The non-custodial smart contract Barker deploys per partner per chain. Wraps an underlying ERC-4626 vault and splits accrued yield between Barker and the partner via on-chain fee bps.

### Underlying vault

The yield source the engine deposits into — a curated ERC-4626 vault. Curated by Barker; the partner picks one per engine at deploy time.

### AUM (assets under management)

Total assets currently held by the engine, denominated in the underlying asset (USDC). Equals `engine.totalAssets()` on chain.

### Underlying APY

The yield rate emitted by the underlying vault — what the vault would pay a depositor with no fees. Sourced from on-chain reads + Barker's protocol-specific transforms.

### Net APY (for user)

What the end user actually earns after Barker's and the partner's fee bps are taken out:

```
net_apy = underlying_apy × (1 − barker_fee_bps/10000 − partner_fee_bps/10000)
```

This is what you should display in your UI as "yield".

**Worked example** — same fee split (`barker_fee_bps = 1000`, `partner_fee_bps = 1000`, total 20% of yield) applied across 3 tiers:

| Tier         | Underlying APY | Barker fee     | Partner fee    | **Net APY for user** |
| ------------ | -------------- | -------------- | -------------- | -------------------- |
| Conservative | 5.00%          | 1000 bps (10%) | 1000 bps (10%) | **4.00%**            |
| Balanced     | 8.00%          | 1000 bps (10%) | 1000 bps (10%) | **6.40%**            |
| Aggressive   | 14.00%         | 1000 bps (10%) | 1000 bps (10%) | **11.20%**           |

Fees apply to **yield**, not principal — at 0% APY a depositor pays nothing. Each tier can also run its own fee bps if you want to charge differently per risk profile (see [multi-tier-products](/multi-tier-products#fee-policy)).

### Fee bps (basis points)

`1 bp = 0.01%`. Two configurable parameters set at engine deploy time:

| Field           | Goes to                            |
| --------------- | ---------------------------------- |
| `barkerFeeBps`  | Barker treasury                    |
| `partnerFeeBps` | Your `partnerFeeRecipient` address |

Both are fixed at deploy and configured per partner contract. Changing requires deploying a new engine.

### accrueFee()

The contract method that materializes accumulated yield into engine shares for `barkerFeeRecipient` and `partnerFeeRecipient`. **Auto-invoked before every `deposit` / `mint` / `withdraw` / `redeem`** — so for engines with regular user activity, fees settle naturally with no external trigger. The standalone external `accrueFee()` is permissionless if you ever want to force-settle (e.g. reading on-chain fee balances on a low-activity engine): anyone can call it, gas is paid by the caller.

### Sandbox vs production

A **key-level** distinction, not a host-level one. Same base URL `api.barker.money`, same chains — what differs is access scope and rate limit.

| Key type   | Prefix      | Access                               | Rate limit   |
| ---------- | ----------- | ------------------------------------ | ------------ |
| Sandbox    | `bk_test_*` | Read-only against a demo engine      | 100 req/min  |
| Production | `bk_live_*` | Full access to your deployed engines | 1000 req/min |

Sandbox keys are issued instantly after email verification. Production keys go through manual review (typically a few hours).

### API key prefix

The first 12 chars of an API key (e.g. `bk_live_a3F2`) — the only part of the key we keep in the clear. Used in audit logs, key listings, and `last_used_at` displays. The full key is bcrypt-hashed and unrecoverable once you lose it.

### Outbound vs inbound webhook

* **Outbound**: Barker → you. Notifies you of engine events (deployed, fee accrued, etc.)
* **Inbound**: you → Barker. Notifies us of partner-side events (user KYC change, off-chain reconciliation)

Each direction has its own secret. See [Webhooks](/webhooks).

### Idempotency key

Any string you pick (UUID recommended) attached to an inbound webhook via `X-Idempotency-Key`. Resending the same key returns `200 duplicate` without re-processing — safe to retry on network errors.

### LiFi widget

Third-party cross-chain bridge UI that we embed inside the widget for users whose USDC is on a chain other than the one your engine is deployed on. Barker does not custody bridge flows; the widget hands off to LiFi and waits for the user to return.

### Pending deploy

An engine product can be created in our DB before the contract is deployed on chain. During this window:

* `status` is `pending_deploy`
* `engine_contract_address` is `NULL`
* The product is not listed in public `/products` responses
* Your portal shows it as "Awaiting deploy"

Once Barker deploys the contract and the on-chain event is indexed, status flips to `active` and the address is populated.