> ## Documentation Index
> Fetch the complete documentation index at: https://docs.reap.global/llms.txt
> Use this file to discover all available pages before exploring further.
# Overview
> Unit balances Reap tracks on behalf of your users, contributing to their available balance.
Applies to **Program-Funded** programs using **Managed** [authorization mode](/program-configuration/authorization-mode), the default. See [Funding Model](/program-configuration/funding-models) for where this fits.
**Virtual Assets** are unit balances Reap tracks on behalf of your users. You define the asset (a symbol, a display name, a rate in your program's billing currency), allocate amounts to each account, and Reap turns those allocations into spendable balance the user can use on their card.
You never move real crypto for a virtual asset. The backing is your [master collateral account](/program-configuration/funding-models#program-funded), which covers card spending across the whole program. Virtual Assets are how you tell Reap who gets to spend how much, and in what currency.
## Why they exist
Running a card program usually forces a choice: custody your users' funds with the card issuer, or build your own authorization, clearing, and settlement stack so you can keep custody. Virtual Assets remove that choice.
* You keep the user relationship, the custody model, and the currency denomination you already use.
* Reap authorizes, clears, and settles every card transaction against the master account.
* The user's spending power on Reap is a single number per account per asset, set by you.
## Two primary patterns
Virtual Assets support two patterns that cover almost every program shape we see. They use the same API and the same lifecycle. What differs is what the balance represents on your side.
The virtual balance represents real value you hold for the user off-platform: stablecoins in a custody wallet, crypto on an exchange, fiat in a trust account, gold in vaulted storage. You mirror your internal balances into Reap.
The virtual balance represents value you grant to the user from your own program funds: cashback, sign-up bonuses, salary allowances, credit lines. Nothing to custody, you are the source.
The two patterns can coexist in the same project. A wallet app can allocate **USDC** from custody and **POINTS** as cashback on the same account. The card sees one available balance.
## Use-case vignettes
Users hold USDC, USDT, ETH, or BTC on your platform. Define one virtual asset per token with appropriate rate sources (FIXED for stablecoins, HTTP for volatile assets). Mirror each user's balance into Reap. Their card spends against what they already own.
Define a `POINTS` or `CASHBACK` virtual asset with a FIXED rate (e.g. 1 point = 0.01 USD). Allocate on qualifying transactions. Users spend their rewards through the same card, no separate redemption flow.
Define a `BONUS_USD` virtual asset. Allocate the bonus when onboarding completes. Users see it in their available balance immediately and can spend it on their first transaction.
Define a `CREDIT_USD` virtual asset. Allocate the approved limit to each user who qualifies. The user spends against it. You top up the master account to cover; you handle repayment on your side.
Define a `PAYROLL_USD` virtual asset. Allocate the monthly amount to each employee on payroll day. Optionally deallocate unused balance at period end, or let it roll over.
Allocate **USDC** from real custody for everyday spending, and **CASHBACK\_USD** for rewards earned through the program. Both show up as part of the same available balance on the same card.
## How they feed into available balance
Virtual Asset allocations contribute to the `assets` side of the balance equation on an account:
```
availableBalance = assets - liabilities
```
Each virtual asset is valued in your program's billing currency using its exchange rate. All active allocations on an account are summed. Card debt is subtracted as liabilities.
See [Accounts Overview](/accounts/overview) for the full balance model.
## Lifecycle at a glance
```mermaid theme={null}
flowchart LR
D[Define virtual asset] --> A[Allocate balance to account]
A --> S[User spends on card]
S --> R[Settle card spend]
R --> A
```
1. [Define the virtual asset](/virtual-assets/definitions) once at the project level. Pick a rate source and, for FIXED rates, an initial rate.
2. [Allocate balance](/virtual-assets/postings) to each user's account by posting a `DEPOSIT`. The balance becomes spendable immediately.
3. The user spends. Reap authorizes against the available balance and settles card network debt from the master account. You do not touch this flow.
4. [Settle card spend](/virtual-assets/postings#settling-card-debt) by posting a `SETTLEMENT`. The user's virtual balance drops and the outstanding card debt is cleared in one atomic step.
## What Reap does, what you do
* Authorizes every card swipe against the user's available balance.
* Clears, reverses, and settles card transactions with the card network.
* Custodies the master collateral account.
* Fetches HTTP-source rates on a schedule and stores a snapshot for every update.
* Atomically applies your postings against the user's balance and card debt.
* Decide which virtual assets to offer and their rate sources.
* Post deposits and withdrawals to keep each user's spendable balance in sync with your side.
* Keep the master account topped up to back outstanding spend.
* Post settlements after card spend so the user's virtual balance reflects what they have spent.
## Next
* [Defining virtual assets](/virtual-assets/definitions): rate sources, HTTP endpoint contract, disabling.
* [Virtual Asset postings](/virtual-assets/postings): how to credit, debit, and settle account balances, with patterns per use case.