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

# Aave Yield

> Deposit USDC into Aave, check the position, and withdraw through the REST API

Deposit native USDC into Aave V3 on Ethereum or Base, check the supplied balance, and withdraw to the same Para wallet. Your application chooses the amount; Para prepares and signs the required transactions.

<Note>
  Yield is available by default to eligible partner wallets. You do not need separate enrollment or yield-specific permissions setup. Existing wallet authorization, configured transaction permissions, and REST rate limits apply.
</Note>

## Before you start

Use an API key from the [Developer Portal](https://developer.getpara.com) and an API-created, unclaimed EVM wallet that has completed key generation and share persistence. See [wallet lifecycle](/v3/rest/wallet-lifecycle). The wallet needs USDC and ETH for gas.

Select the market with `chainId`:

| Network          | Chain ID   | USDC                   |
| ---------------- | ---------- | ---------------------- |
| Ethereum mainnet | `1`        | Native USDC            |
| Base mainnet     | `8453`     | Native USDC, not USDbC |
| Sepolia          | `11155111` | Aave test USDC         |

The wallet needs funds on the selected network. Use `https://api.beta.getpara.com` for test access and `https://api.getpara.com` for production access. The chain ID selects the network independently of the API environment; mainnet requests use real funds.

## Deposit, check, withdraw

Set `PARA_API_KEY` and `WALLET_ID` for the environment you use. This example requests a 10 USDC deposit on Sepolia:

```bash deposit.sh theme={null}
curl -X POST "https://api.beta.getpara.com/v1/wallets/$WALLET_ID/yield/deposits" \
  -H "X-API-Key: $PARA_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: aave-deposit-001" \
  -d '{"chainId":11155111,"amount":"10"}'
```

For Ethereum mainnet or Base mainnet, use `chainId: 1` or `chainId: 8453` in deposit and withdrawal requests and position queries.

Send amounts as positive decimal strings with at most six decimal places. The source, token, and recipient are fixed by the integration. Para approves the requested amount if needed, confirms that approval, then submits the deposit.

The response contains an operation `id`, `status`, and `transactions` array. A `202` response means Para accepted the work; it does not mean funds have moved. Set `OPERATION_ID` to the returned `id` and poll:

```bash status.sh theme={null}
curl -H "X-API-Key: $PARA_API_KEY" \
  "https://api.beta.getpara.com/v1/wallets/$WALLET_ID/yield/operations/$OPERATION_ID"
```

Read the supplied balance independently:

```bash position.sh theme={null}
curl -H "X-API-Key: $PARA_API_KEY" \
  "https://api.beta.getpara.com/v1/wallets/$WALLET_ID/yield/position?chainId=11155111"
```

After the deposit operation reaches `confirmed`, withdraw a specific amount (for example, `"amount":"5"`) or use `"all"` to request the full position:

```bash withdraw.sh theme={null}
curl -X POST "https://api.beta.getpara.com/v1/wallets/$WALLET_ID/yield/withdrawals" \
  -H "X-API-Key: $PARA_API_KEY" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: aave-withdraw-001" \
  -d '{"chainId":11155111,"amount":"all"}'
```

Set `OPERATION_ID` to the withdrawal response's `id` and poll the same status endpoint until it reaches `confirmed`. Then read the position again to verify the remaining supplied balance.

## Status and retries

| Status            | What your application should do                                                                                                       |
| ----------------- | ------------------------------------------------------------------------------------------------------------------------------------- |
| `pending`         | Keep polling; Para has accepted the operation.                                                                                        |
| `submitted`       | Keep polling. Signed bytes are stored and Para is tracking the transaction, even if RPC acceptance is uncertain.                      |
| `confirmed`       | The final action succeeded with two confirmations in the canonical chain. This is not finality.                                       |
| `failed`          | A transaction reverted or its nonce was consumed. Check `error`, the position, and transaction history before creating a new request. |
| `requires_action` | Read `error`, correct the issue, then repeat the same POST with the same key and body.                                                |
| `cancelled`       | Unsigned work has stopped.                                                                                                            |

`Idempotency-Key` is required for deposits and withdrawals. Keep it stable for one intended operation, including after a timeout. Keys remain attached to yield operations; they do not use the generic REST 24-hour response cache. Changing the wallet, chain, action, or normalized amount with the same key returns `409`.

Recognized temporary RPC failures before signing and waiting for another yield operation on the same wallet keep the operation `pending`; Para retries automatically. After signing, Para retries uncertain submissions using the stored signed bytes, without increasing fees or creating a replacement transaction. A prepared or signed yield transaction can block other REST broadcasts on the same wallet and chain until it is resolved or safely cancelled.

If the saved nonce has been consumed in a finalized block but Para cannot find a receipt for the original hash, the operation and transaction step become `failed` with `error.code: "NONCE_CONSUMED"` on the operation. The signed bytes can no longer execute, but this does not prove that no funds moved: check the position and transaction history before creating a new request. A dropped transaction whose nonce remains unused stays unresolved.

If `error.code` is `AAVE_SUPPLY_CAP_EXCEEDED`, the operation pauses as `requires_action` before signing the deposit. Retry the same request after Aave market capacity becomes available, or cancel the unsigned work. Any token approval that already confirmed remains in place.

## Permissions and cancellation

Para can temporarily disable new yield execution or pause deposits during an incident. New affected operations return `409` with `code: "YIELD_DISABLED"`. Position reads, operation status, and cancellation of eligible unsigned work remain available.

Existing wallet authorization and V1/V2 transaction permissions apply to each signature, including token approval and the Aave action. Configure those policies through the existing [permissions API](/v3/rest/permissions); yield has no separate policy setup.

A policy review appears as `error.code: "POLICY_REVIEW_REQUIRED"` with `error.reviewId`. After the existing review is approved, retry the same yield request. Para reuses the exact prepared transaction and review ID, including its nonce and fees. Yield does not add a separate aggregate deposit spending limit. For `"all"`, policies evaluate Aave's maximum-uint256 withdrawal sentinel, not a substituted balance estimate.

If another yield operation is active on the same wallet and chain, resuming a paused prepared transaction returns `409` with `code: "YIELD_OPERATION_IN_PROGRESS"`. Wait for the active operation to resolve, then retry the same request.

If unsigned work cannot proceed, cancel it:

```bash cancel.sh theme={null}
curl -X POST -H "X-API-Key: $PARA_API_KEY" \
  "https://api.beta.getpara.com/v1/wallets/$WALLET_ID/yield/operations/$OPERATION_ID/cancel"
```

Cancellation returns `409` for an unresolved signed transaction or a confirmed/failed operation. Cancelling after a confirmed approval stops the remaining deposit work but leaves that allowance in place. A cancelled operation cannot restart; use a new key for a new operation.

## Position and transaction records

`suppliedBalance` includes accrued supply interest; it is not historical earnings. `withdrawal.availableAmount` is advisory and can be `null` when debt or failed simulation prevents an estimate. Liquidity, reserve restrictions, and other wallet activity can change before execution. Use `blockNumber` and `blockTimestamp` to identify the snapshot.

Each signed step has a `transactionId` in [transaction history](/v3/rest/transaction-history), with `intentKind: "yield"`. Existing `rest.transaction.confirmed` and `rest.transaction.failed` webhooks describe individual steps, so an approval confirmation does not mean the deposit is complete. Poll the yield operation for the overall result.