Overview

Kiln Connect "Portals" API route, enables you to create Portals: a series of transactions that must be executed one after the other in order to achieve a deposited from any initial position.

For example here is a "USDC to Morpho USDT" portal:

A Portal is managed in a few key actions:

1. Create the portal, by telling the api from which position to which product the user wants to go.
2. Get the portal with the current tx to execute
3. Sign and broadcast it
4. Refresh the portal to tell the portal to compute its new state and tx to execute
5. Go back to step 2

More details on the flow going on, with the example of a USDC deposit to Angle USDA vault:

Create a Portal

Create a Portal by specifying the initial position and the destination of the portal.

🩷

POST /v1/portals

(example if you want to create a deposit of 1000 USDC to a DeFi DAI product on Arbitrum)

body.json

{
  "from_chain": 1, 
  "from_asset_or_product": "0x12345"..., // ex: USDC address
  "from_amount": 1000, // ex: 1000 USDC
  "from_address": "0xabcde", // user wallet
  "to_address": "0x123455", // user destination wallet, can be the same as from_address
  "to_chain": 42161,
  "to_product": "0xdea1234" // ex: DAI DeFi vault
}

{
	"id": "uuid-v4"
}

It is recommended you store this id in a local storage so the user can come back to his portal. This is important because some portal made on top of asynchronous flows (like exit on kiln pooling) will require the user to trigger a first action, then come back to execute the second.

This endpoint supports all the transaction crafting flow you need to interface yourself with kiln products:

• Deposit to a product from the correct asset: deposit
• Deposit to a product from a different chain / asset:bridge/swap? -> deposit
• Deposit to a product from an other product: withdraw -> bridge/swap? -> deposit
• Withdraw from a product to the same asset: withdraw
• Withdraw from a product to a different asset: withdraw -> bridge/swap?

Get a portal

This endpoint helps you retrieve the different steps of the portal and the information to display them to the user, but also the current tx the user needs to execute to move forward.

Querying this endpoint multiple time always gives the same result, see "Update a portal" section.

🩷

GET /v1/portals/:id

{
  "id": "uuid-v4",
  "created_at": 123456789013,
  "steps": [
    {
      "title": "Approve Uniswap v3",
      "description": "Approve Uniswap v3 for 1,000 USDC",
      "completed": true,
    },
    {
      "title": "Swap USDC for DAI",
      "description": "Use Uniswap v3, swap 1,000 USDC <> 999.5 DAI",
      "completed": false,
 			"tx_to_broadcast": "0x11212221......."
    },
    {
      "title": "Approve DAI Morpho vault",
      "description": "Approve DAI Morpho vault for 999.5 DAI",
      "completed": false,
    },
    {
      "title": "Deposit DAI on Morpho vault",
      "description": "Deposit 999.5 DAI on Morpho",
      "completed": false,
    },
  ]
}

If all the steps are marked as completed, the portal has been achieved. It is not recommended to store the user portals once they are completed.

Refresh a portal

This will trigger the refresh of the user portal once a step is performed on the client side.

🩷

PUT /v1/portals/:id

With the following body

{
  "broadcasted_tx_hash": "0xaaa",
}

You can then re-do the GET Portal.