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

# Funding via Deposits

> How to fund an account with on-chain token transfers.

To fund an account, send a supported token to the account's deposit address for the relevant chain. Unsupported tokens will not count toward the spending balance. They remain in the account and can be withdrawn.

<Note>
  In [Program-Funded](/program-configuration/funding-models#program-funded) projects, user accounts do not have deposit addresses. Deposits go to the project's [master collateral account](#master-collateral-funding), which has its own addresses and follows the same flow described below. User-level spending power is set by [posting](/virtual-assets/postings) against each account, not by depositing.
</Note>

## Deposit flow

When you send a supported token to a deposit address:

1. The system detects the on-chain transfer and creates a deposit in `PENDING` status.
2. Once the transaction is finalized on-chain, the deposit moves to `CONFIRMED`.
3. The deposit is validated.
4. If validation passes, the deposit is `APPROVED` and the account balance is updated. If validation fails, the deposit is `REJECTED`.

You receive a [CRYPTO\_DEPOSIT\_CREATED](/api-reference/crypto-deposit-created) webhook when the deposit is first detected, and a [CRYPTO\_DEPOSIT\_STATUS\_UPDATED](/api-reference/crypto-deposit-status-updated) webhook at each subsequent status change.

<Warning>
  `CONFIRMED` means only that the transaction is final on-chain - it does **not** mean the funds have been credited to the account. Crediting happens at `APPROVED`, after validation passes. Do not treat `CONFIRMED` as available balance; always rely on the [balance endpoint](/api-reference/accounts/get-account-balance) or wait for `APPROVED`.
</Warning>

### Minimum deposit amount

Deposits below **USD 0.50** are rejected with a `REJECTED` status. This threshold exists to prevent dust deposits. We recommend filtering out rejected deposits before displaying deposit history to your users, as low-value rejections add noise to the UI.

## Master collateral funding

In [Program-Funded](/program-configuration/funding-models#program-funded) projects, the master collateral account is provisioned at project setup. It is the only crypto-holding account in the project, and every authorized card transaction across the program is settled against it. Keep it funded above expected outstanding spend.

To find the master account and its deposit addresses, call [`GET /accounts?ownerType=PROJECT`](/api-reference/accounts/list-accounts). The response includes deposit addresses per enabled chain, the same as for user accounts in User-Funded projects. The deposit flow above applies unchanged: send a supported stablecoin, wait for the [CRYPTO\_DEPOSIT\_STATUS\_UPDATED](/api-reference/crypto-deposit-status-updated) webhook, and the balance is available once approved.

### Per-asset minimum for master deposits

Master deposits enforce a higher floor than user deposits:

| Asset  | Minimum per deposit |
| ------ | ------------------- |
| `USDC` | 2 USD               |

Deposits below the floor are `REJECTED`. The floor is per deposit, not per balance, so a series of smaller deposits is rejected even if their total is above the threshold.

## Checking deposit status

Look up a deposit directly using the [deposit endpoint](/api-reference/crypto-deposits/get-crypto-deposit). Once a deposit is approved, the [balance endpoint](/api-reference/accounts/get-account-balance) will reflect the updated balance.

## Testing in sandbox

Deposit testing requires real on-chain transactions. There is no simulation shortcut for the deposit flow. You send actual tokens on testnet, and the system processes them end to end.

To get sandbox tokens funded to your test wallet, reach out to your Reap contact. See [Supported Assets](/accounts/supported-assets) for the token contract addresses on the supported chains.

### Scenario 1: Successful deposit

1. [Create an account](/api-reference/accounts/create-account) and retrieve its deposit address for all supported chains.
2. Send RUSDC from your funded test wallet to that address.
3. Confirm you receive a [CRYPTO\_DEPOSIT\_CREATED](/api-reference/crypto-deposit-created) webhook.
4. Wait for [CRYPTO\_DEPOSIT\_STATUS\_UPDATED](/api-reference/crypto-deposit-status-updated) webhooks as the deposit progresses. The first will show `status: CONFIRMED` (the transaction has finalized on-chain). The second will show `status: APPROVED` (it has cleared validation and the balance has updated).
5. Check the [balance endpoint](/api-reference/accounts/get-account-balance). It should reflect the deposited amount.

### Scenario 2: Unsupported token

1. Send native ETH or SOL to the same deposit address.
2. Confirm you receive a [CRYPTO\_DEPOSIT\_CREATED](/api-reference/crypto-deposit-created) webhook confirming the transfer was detected.
3. Confirm a [CRYPTO\_DEPOSIT\_STATUS\_UPDATED](/api-reference/crypto-deposit-status-updated) webhook with `status: REJECTED`. Unsupported tokens are rejected immediately on detection, without going through on-chain finalization.
4. Check the [assets endpoint](/api-reference/accounts/get-account-assets) to confirm the token appears there, and check the [balance endpoint](/api-reference/accounts/get-account-balance) to confirm it is unchanged.