Skip to main content
This is a detailed tutorial on how to make a deposit to one of the Morpho’s vaults through the DeFi API. To learn more about the flow in general, refer to the Getting Started section.
As an example of using the DeFi API with the Morpho integration, let us consider making the deposit to the Steakhouse USDC vault on the Base network. The process is the following:
  1. Get the schema with the step list for obtaining approval.
  2. Create the permission request for the permit2 smart contract.
  3. Get the schema with the step list for initiating the deposit.
  4. Create the permission request for the Morpho bundler.
  5. Create the permission request for the P2P.ORG proxy contract.
  6. Prepare the final deposit transaction.
  7. Broadcast the deposit transaction to the Base network.
Before starting, ensure you have met the prerequisites for successful integration. Request examples are provided using cURL
This is an example for the Steakhouse USDC vault. Note that for other vaults, the number of steps may vary.This tutorial covers the most complex flow involving construction of three transactions to make a deposit. For the majority of strategies, one transaction is sufficient.

​
1. Get schema for approval

Before depositing assets into the vault, first grant permissions to the smart contracts involved in the integration to manage tokens. To check the action schema and retrieve a list of steps required for approval, send a GET request to /api/defi/v1/transactions/schema. Example request (for base chain and Steakhouse USDC strategy):
  • action — operation type; in this case approvePermit2.
  • chain — blockchain network, e.g., base.
  • protocol— integration name, e.g., morpho.
  • strategy — vault name, e.g., Steakhouse USDC.
  • x-client-hash — unique identifier of the user or merchant participating in the integration; obtained with the authentication token.
Example response:
  • action — operation type; in this case approvePermit2.
  • steps — schema with the list of steps describing which transactions you have to construct using the Craft Transaction Step endpoint.
    • index — step number in the execution order.
    • name — transaction type corresponding to the stepName request parameter of the Craft Transaction Step endpoint.
    • description — detailed information on the step purpose.
    • inputs — list of request parameters required to construct a transaction, e.g., wallet address, amount of tokens, etc. It may include transactions that require a signature as well.
      • key — parameter name.
      • type — parameter object format.
      • description — detailed information on the parameter.
      • required — boolean flag indicating if this parameter is necessary for the request.
    • outputs — list of fields expected in the transaction response.
      • key — raw transaction payload ready for signing, either encoded or json (optional).
      • type — transaction payload format.
      • description — detailed information on the payload contents.
    • groupID — identifier of the group to which this step belongs.
    • canExecuteInParallel — boolean flag indicating if it is possible to perform this step asynchronously. By executing in parallel, you can initiate the construction of multiple transactions at the same time.
      • true — step can be performed asynchronously.
      • false — step can only be performed synchronously.
    • isUnsignedTransaction — boolean flag indicating if the result of the step is a transaction that must be signed and broadcasted.
  • stepGroups — groups of steps that can be executed in parallel; currently is not operational.
  • meta — API request attributes:
    • time — request execution time in ms.
    • requestId — unique identifier of the request.
Approval action summaryIn this schema, the steps response array includes one step called finalPermit2AllowanceTransaction.It means that to approve token management, you have to prepare only one transaction and then sign and broadcast it.

​
2. Create permission request for permit2 contract

  1. To allow Morpho’s Permit2 contract to perform any operations with the specified amount of tokens, send a POST request to /api/defi/v1/transactions/steps/craft. Example request (for base chain and Steakhouse USDC strategy):
    • action — operation type.
    • chain — blockchain network.
    • protocol— integration name.
    • strategy — vault name.
    • userAddress — user wallet address.
    • options.executeMode — DeFi API processing mode. The recommended value for each step can be found in the schema’s canExecuteInParallel field.
      • sync — synchronous; default for some networks so that the blockchain does not reverse the block in which the transaction is included. In this mode, before continuing with other steps, the user has to wait until the API operation is fully completed and the transaction is returned.
      • async — asynchronous. In this mode, after sending the request, the user can continue with other steps according to the schema and periodically check the request status with the Get Step Crafting Status endpoint.
    • stepName — name of the transaction to construct. In this case, it is finalPermit2AllowanceTransaction.
    • payload — transaction data:
      • amount — amount of tokens the permit2 contract is allowed to interact with. You can specify any amount, but not less than the deposit amount.
      • asset — token denomination, e.g., USDC.
    Example response:
    • operationId — unique identifier of the transaction.
    • chain — blockchain network.
    • action — operation type.
    • status — current transaction status: AWAITING_CRAFT, IN_PROGRESS, READY_FOR_SIGN or DONE.
    • protocol— integration name.
    • strategy — vault name.
    • userAddress — user wallet address.
    • stepList — list of fields with the step results obtained according to the schema:
      • index — step number in the execution order.
      • type — object format.
      • name — name of the transaction to construct. In this case, it is finalPermit2AllowanceTransaction.
      • description — detailed information on the step purpose.
      • payload — raw transaction object ready for signing represented in two formats: encoded and json (optional).
      • verifierMeta — data object received from P2P.ORG’s verifier module.
        • signature — signature provided by the verifier module, which confirms that the transaction was crafted and then cryptographically verified by P2P.ORG.
    • payload — final transaction payload represented either in encoded or json (optional) format.
    • verifierMeta — final transaction data object received from the verifier module.
    • createdAt — timestamp of the transaction creation in the ISO 8601 format.
    • updatedAt — timestamp of the transaction update in the ISO 8601 format.
    • meta — API request attributes:
      • time — request execution time in ms.
      • requestId — unique identifier of the request.
  2. Sign the raw json or encoded object in the result.payload field.
  3. Broadcast it to the network by sending a POST request to /api/defi/v1/transactions/steps/broadcast. By broadcasting this transaction, you’re granting permission to the permit2 smart contract to interact with the specified amount of tokens at your wallet address.

​
3. Get schema for deposit

The deposit action may require a various number of steps depending on the target chain and vault. To retrieve a list of steps for the preferred strategy, send a GET request to /api/defi/v1/transactions/schema. Example request (for base chain and Steakhouse USDC strategy):
  • action — operation type; in this case deposit.
  • chain — blockchain network.
  • protocol— integration name.
  • strategy — vault name.
  • x-client-hash — unique identifier of the user or merchant participating in the integration; obtained with the authentication token.
Example response:
  • action — operation type.
  • steps — schema with the list of steps describing which transactions you have to construct using the Craft Transaction Step endpoint.
    • index — step number in the execution order.
    • name — transaction type corresponding to the stepName request parameter of the Craft Transaction Step endpoint.
    • description — detailed information on the step purpose.
    • inputs — list of request parameters required to construct a transaction, e.g., wallet address, amount of tokens, etc. It may include transactions that require a signature as well.
      • key — parameter name.
      • type — parameter object format.
      • description — detailed information on the parameter.
      • required — boolean flag indicating if this parameter is necessary for the request.
      • requiresSignature — boolean flag indicating if the parameter is a transaction itself that must be signed.
      • signatureSource — detailed information on the step at which the transaction requiring a signature was received:
        • stepIndex — step number.
        • stepName — transaction type.
        • outputKey — resulting object format.
    • outputs — list of fields expected in the transaction response for the specific step.
      • key — raw transaction payload ready for signing.
      • type — object format, which is either encoded or json (optional).
      • description — detailed information on the payload contents.
    • groupID — identifier of the group to which this step belongs.
    • canExecuteInParallel — boolean flag indicating if it is possible to perform this step asynchronously. By executing in parallel, you can initiate the construction of multiple transactions at the same time.
      • true — step can be performed asynchronously.
      • false — step can only be performed synchronously.
    • inputReferences — references to key from previous steps, either from the request or response.
      • stepIndex — step number.
      • outputKey — name of the specific key parameter from the step output.
  • stepGroups — groups of steps that can be executed in parallel; currently is not operational.
  • meta — API request attributes:
    • time — request execution time in ms.
    • requestId — unique identifier of the request.
Deposit action summaryIn this schema, the steps response array includes three steps ordered from 0 to 2. It means that the process of depositing assets to a vault requires three actions:
  1. Allow transferring funds from the user wallet to the P2P proxy contract address.
  2. Allow transferring funds from the P2P proxy contract address to the vault address.
  3. Combine the two previous transactions to obtain the raw deposit transaction.
For each step, a signature is required. The third and final transaction must have the payloads of the previous two. To complete the deposit action, broadcast the final transaction to the network.Accordingly, these transactions can be constructed only consequently, since the value of the canExecuteInParallel parameter is false.

​
4. Create permission request for the vault

  1. Construct the first intermediate permit2SingleDetailsForMorpho transaction according to the schema. To allow the Morpho bundler to withdraw assets from the P2P proxy address to the vault address, send a POST request to /api/defi/v1/transactions/steps/craft. Example request (for base chain and Steakhouse USDC strategy):
    • chain — blockchain network.
    • action — operation type.
    • protocol— integration name.
    • strategy — vault name.
    • userAddress — user wallet address.
    • options.executeMode — DeFi API processing mode. The recommended value for each step can be found in the schema’s canExecuteInParallel field.
    • stepName — step name corresponding to the name response parameter of the Get Transaction Step Schema endpoint. In this case, it is permit2SingleDetailsForMorpho.
    • payload — transaction data:
      • amount — amount of tokens to deposit.
      • asset — token denomination, e.g., USDC.
    Example response:
    • operationId — unique identifier of the transaction; required for the next steps.
    • chain — blockchain network.
    • action — operation type.
    • status — current transaction status: AWAITING_CRAFT, IN_PROGRESS, READY_FOR_SIGN or DONE.
    • protocol— integration name.
    • strategy — vault name.
    • userAddress — user wallet address.
    • stepList — list of fields with the step results obtained according to the schema.
      For schemes with multiple steps: if a step has not been performed yet, the field will have null. In this example, the response contains data for the step 0 only.
      • index — step number in the execution order.
      • type — object format.
      • name — step name corresponding to the name response field of the Get Transaction Step Schema endpoint.
      • description — detailed information on the step purpose.
      • payload — raw transaction object ready for signing represented in two formats: encoded and json (optional).
      • verifierMeta — data object received from P2P.ORG’s verifier module.
        • signature — signature provided by the verifier module, which confirms that the transaction was crafted and then cryptographically verified by P2P.ORG.
    • payload — final transaction object. null until there are schema steps yet to be performed.
    • verifierMeta — final transaction data object received from the verifier module. null until there are schema steps yet to be performed.
    • createdAt — timestamp of the transaction creation in the ISO 8601 format.
    • updatedAt — timestamp of the transaction update in the ISO 8601 format.
    • meta — API request attributes:
      • time — request execution time in ms.
      • requestId — unique identifier of the request.
  2. Sign the intermediate json or encoded transaction object from the step 0 payload field.

​
5. Create permission request for P2P.ORG smart contract

  1. Construct the second permit2SingleDetailsForP2pProxy intermediate transaction according to the schema. To allow a P2P proxy contract to withdraw assets from your wallet address, send a POST request to /api/defi/v1/transactions/steps/craft. Mind specifying the correct stepName according to the scheme’s step order as well as the operationID of the previous transaction. Example request (for base chain and Steakhouse USDC strategy):
    • chain — blockchain network.
    • action — operation type.
    • protocol— integration name.
    • strategy — vault name.
    • userAddress — user wallet address.
    • options.executeMode — DeFi API request processing mode. The recommended value for each step can be found in the schema’s canExecuteInParallel field.
    • stepName — step name corresponding to the name response parameter of the Get Transaction Step Schema endpoint. In this case, it is permit2SingleDetailsForP2pProxy.
    • payload — transaction data:
      • amount — amount of tokens to deposit.
      • asset — token denomination, e.g., USDC.
      • operationId — unique identifier of the permit2SingleDetailsForMorpho transaction.
    Example response:
    • operationId — unique identifier of the permit2SingleDetailsForMorpho transaction.
    • chain — blockchain network.
    • action — operation type.
    • status — current transaction status: AWAITING_CRAFT, IN_PROGRESS, READY_FOR_SIGN or DONE.
    • protocol— integration name.
    • strategy — vault name.
    • userAddress — user wallet address.
    • stepList — list of fields with the step results obtained according to the schema.
      For schemes with multiple steps: if a step has not been performed yet, the field will have null. In this example, the response contains data for steps 0 and 1.
      • index — step number in the execution order.
      • type — parameter object format.
      • name — step name corresponding to the name response field of the Get Transaction Step Schema endpoint.
      • description — detailed information on the step purpose.
      • payload — raw transaction object ready for signing represented in two formats: encoded and json (optional).
      • verifierMeta — data object received from P2P.ORG’s verifier module.
        • signature — signature provided by the verifier module, which confirms that the transaction was crafted and then cryptographically verified by P2P.ORG.
    • payload — final transaction object. null until there are schema steps yet to be performed.
    • verifierMeta — final transaction data object received from the verifier module. null until there are schema steps yet to be performed.
    • createdAt — timestamp of the transaction creation in the ISO 8601 format.
    • updatedAt — timestamp of the transaction update in the ISO 8601 format.
    • meta — API request attributes:
      • time — request execution time in ms.
      • requestId — request identifier; used as a correlating ID in logs.
  2. Sign the intermediate json or encoded transaction object from the step 1 payload field.

​
6. Prepare final deposit transaction

Construct the third finalDepositTransaction transaction according to the schema. To prepare the final deposit transaction, send a POST request to /api/defi/v1/transactions/steps/craft. Mind specifying the correct stepName according to the scheme’s step order and the operationID from the step 0. Example request (for base chain and Steakhouse USDC strategy):
  • chain — blockchain network.
  • action — operation type.
  • protocol— integration name.
  • strategy — vault name.
  • userAddress — user wallet address.
  • options.executeMode — DeFi API request processing mode. The recommended value for each step can be found in the schema’s canExecuteInParallel field.
  • stepName — step name corresponding to the name response parameter of the Get Transaction Step Schema endpoint. In this case, it is finalDepositTransaction.
  • payload — transaction data:
    • amount — amount of tokens to deposit.
    • asset — token denomination, e.g., USDC.
    • operationId — unique identifier of the permit2SingleDetailsForMorpho transaction.
    • permit2SignatureForMorpho — signed transaction obtained at step 0.
    • permit2SignatureForP2pProxy — signed transaction obtained at step 1.
Example response:
  • operationId — unique identifier of the permit2SingleDetailsForMorpho transaction.
  • chain — blockchain network.
  • action — operation type.
  • status — current transaction status: AWAITING_CRAFT, IN_PROGRESS, READY_FOR_SIGN or DONE.
  • protocol— integration name.
  • strategy — vault name.
  • userAddress — user wallet address.
  • stepList — list of fields with the step results obtained according to the schema.
    • index — step number in the execution order.
    • type — parameter object format.
    • name — step name corresponding to the name response field of the Get Transaction Step Schema endpoint.
    • description — detailed information on the step purpose.
    • payload — raw transaction object ready for signing represented in two formats: encoded and json (optional).
    • verifierMeta — data object received from P2P.ORG’s verifier module.
      • signature — signature provided by the verifier module, which confirms that the transaction was crafted and then cryptographically verified by P2P.ORG.
  • payload — final deposit transaction payload represented either in encoded an optional json format.
  • verifierMeta — final transaction data object received from the verifier module.
  • createdAt — timestamp of the transaction creation in the ISO 8601 format.
  • updatedAt — timestamp of the transaction update in the ISO 8601 format.
  • meta — API request attributes:
    • time — request execution time in ms.
    • requestId — request identifier; used as a correlating ID in logs.

​
7. Sign and broadcast final deposit transaction

The final deposit transaction now contains all the payload objects from the previous intermediate transactions.
  1. Sign the json or encoded transaction object from the result.payload field.
  2. Broadcast it to the network by sending a POST request to /api/defi/v1/transactions/steps/broadcast. By broadcasting this transaction, you’re making the deposit to the Steakhouse USDC vault on the Base blockchain.

Related topics

WithdrawalSign and Broadcast TransactionDeFi API reference