Skip to main content

​
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.
Response:
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.