Integrating a New Market

Add a protocol to IPOR Fusion as a new market, whether it is your own protocol or one you integrate for another team: write and deploy the fuses, open a market id pull request, and IPOR reviews the fuses for the Fuse Whitelist Registry.

This section is for you if you want IPOR Fusion vaults to be able to use a protocol (a lending market, a DEX, a yield vault) that Fusion does not support yet. It may be your own protocol, or one you integrate for another team. You write the fuses in your own repository and deploy them. IPOR does not write or deploy them for you; the IPOR team reviews the deployed fuses and adds them to the Fuse Whitelist Registry.

Why integrate a protocol

  • Every Fusion vault can use the protocol. Once your fuses are deployed, any atomist on that chain can add them to a vault and allocate deposits to the protocol, without waiting for IPOR to build the integration.
  • Vaults using your fuses show on the IPOR frontend without warnings. After the whitelist review, your fuses are listed in the Fuse Whitelist Registry and in Fusion Terminal (opens in new tab). IPOR is adding warnings for vaults that use fuses outside the registry; vaults that use only whitelisted fuses are shown without them.

When an existing fuse is enough

If the protocol exposes an ERC4626 vault, an existing fuse may already cover it. The generic Erc4626SupplyFuse (opens in new tab) is a fuse for ERC4626 vaults whose addresses an atomist grants as substrates of the market. Check that the vault behaves as that fuse expects; for example, at commit 632350d exit does nothing when the vault reports a maxWithdraw of 0 (see Developing a Fuse).

In that case you do not write or deploy a fuse: an atomist grants that vault as a substrate of an ERC4626 market of the vault that uses the deployed Erc4626SupplyFuse, after checking the exceptions above. In that case no market id pull request and no whitelist review are needed, because the whitelist review applies to new fuses.

Use this section when no existing fuse covers the protocol.

What a full market contains

A market integration is more than one action fuse. It is a market id, the action fuses, a balance fuse that values the position, the encoding of the substrates, and the price feeds the valuation needs. Optional parts are instant withdraw, claim fuses and a dependency balance graph. What a Market Integration Contains describes each part. Coding Standard and Security Requirements describe what the deployed code is expected to look like. Whitelist Review describes the pull request, the review request and what happens after them.

The six steps

  1. Develop the fuse family in your own repository. Licensing of your code is your choice. Deployed fuses cannot be changed, so settle the design before you deploy.
  2. Open a pull request to IPOR-Labs/ipor-fusion (opens in new tab) and get the market id confirmed. The pull request adds only the market id constant with a description of the market substrates. Its description links to the repository where the code of your fuses is maintained and, if the documentation is kept outside that repository, to the documentation. Third-party markets use ids from 400_001 to 400_999. Use the next free number in that range (check IporFusionMarkets.sol on main and the open pull requests for constants already taken); the IPOR team confirms it in the pull request. Wait for that confirmation before you deploy: MARKET_ID is immutable, so fuses deployed with a different id must be redeployed.
  3. Deploy on each chain with the confirmed id and verify the sources. Deploy the fuses on the chains you need and verify the source code of every fuse in the block explorer of each chain (for example Etherscan or Basescan). The review needs the verified source. Then add the deployed addresses to the pull request.
  4. Request the whitelist review on Discord. Open a ticket in the IPOR Discord (opens in new tab) and send the IPOR team the link to your pull request and, for every deployed fuse, the link to its verified source in the block explorer of its chain (for example Etherscan or Basescan). The ticket is your request for the whitelist review; the pull request alone does not start it.
  5. Review. The IPOR team reviews the deployed, verified code before adding the fuses to the Fuse Whitelist Registry. The outcome is an entry in the registry or a request for changes in the pull request.
  6. Configure in vaults. After the registry entry the fuses are visible in the registry and in Fusion Terminal (opens in new tab) (the link opens the Ethereum list). Atomists (the administrators of a vault, see What is an Atomist?) then add the fuses to their vaults and configure them.

Deployed fuses cannot be changed: a fix or a new version means a new deployment with new addresses. The market id stays the same, so no new pull request is needed; send the new addresses and their verified sources to the IPOR team in a ticket in the IPOR Discord (opens in new tab) for review. Vaults already using the old address must migrate.

The Fuse Whitelist Registry is a reference list for Fusion Terminal and atomists; it is not enforced on-chain, and a vault can add any fuse address.

Before you request the review

  • The fuses are deployed and their sources verified in the block explorer of each chain you support. See What a Market Integration Contains.
  • The code follows the Coding Standard. Tests and fork-test results at a pinned block are recommended, not required.
  • The risks of the venue and the consequences of the substrate configuration are described in the repository of your fuses. See Security Requirements.
  • The market id was confirmed by the IPOR team in your pull request before you deployed, and the pull request lists the deployed addresses. See Whitelist Review.

Last updated