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

# DeFindex to DeFindex

## `POST /migration/defindex-to-defindex`

Moves a user's **entire** position from one DeFindex vault into another. There is no partial migration: the user's full share balance in the source vault is withdrawn. The target vault must hold the same assets, in the same order, as the source vault; the endpoint verifies this before building anything, because the deposit matches amounts to assets by position.

Works on both networks. The `network` query parameter accepts `mainnet` or `testnet` and defaults to `mainnet`.

```http theme={null}
POST /migration/defindex-to-defindex?network=mainnet
```

```json theme={null}
{
  "from": "G...",
  "fromVault": "C...",
  "toVault": "C...",
  "slippageBps": 10
}
```

| Field         | Type   | Required | Notes                                                                       |
| ------------- | ------ | -------- | --------------------------------------------------------------------------- |
| `from`        | string | yes      | User's Stellar public key. Holds the source vault shares and signs the XDR. |
| `fromVault`   | string | yes      | Source vault. The user's entire share balance here is withdrawn.            |
| `toVault`     | string | yes      | Target vault. Must hold the same assets, in the same order, as `fromVault`. |
| `slippageBps` | number | no       | Buffer applied to the proceeds before depositing. Defaults to `10` (0.1%).  |

Response:

```json theme={null}
{
  "xdr": "AAAAAg...",
  "simulationResponse": [ ],
  "functionName": "exec",
  "operationXDR": "AAAAEA...",
  "isSmartWallet": false
}
```

Sign `xdr` and submit it through your own RPC or `POST /send`. After confirmation the user holds shares in the target vault.

## About `slippageBps`

The transaction deposits a **floor**, not the exact amount withdrawn.

The deposit needs a fixed amount decided when the transaction is built, but the value of a vault share can move slightly between the moment the transaction is simulated and the moment the user submits it. If the deposit demanded the exact simulated amount and the value dipped in between, the whole transaction would revert. So the amount is shrunk by `slippageBps` and that lower number is used for both legs. The trade-off:

* **The migration is resilient**: small share-price movements no longer revert it.
* **A sliver stays behind** in the user's wallet, roughly `slippageBps` of the position. At the default 10 bps that is 0.1%.

Raise it if you see migrations reverting; lower it, down to `0`, if you want zero dust and are willing to retry on failure.

Errors: `400` when an address is invalid, `fromVault` equals `toVault`, the two vaults hold different assets, or the position is so small it rounds to zero once the buffer is applied; `404` when the user holds no shares in `fromVault`.