Introduction: Fuji Finance; Cross-chain money market aggregator

1

Hello!

I’m on the team with Fuji Finance, and we were recently approved by the Compound Grants team to build the first cross-chain migration tool. I wanted to take the opportunity to introduce ourselves, what we are building for the Compound community, and what our V2 (launching soon) enables.

Fuji is building the first cross-chain money market aggregator, enabling users to deposit, borrow, and repay a position from any chain. The protocol helps to optimize deposit and borrow rates on money markets, and has supported Compound since the initial V1 launch about 2 years ago, where Fuji built the first borrowing aggregator. The team is in the process of launching our V2 (cross-chain money market aggregator), which will be going live soon! We have been in beta testing since March, and things are progressing very well. We are extremely excited to offer this to the community.

unnamed

unnamed (1)

Right now, Compound is currently in the process of going through a variety of new Compound V3 deployments, allowing the protocol to go multi-chain, with the most recent being Polygon and Arbitrum. Other deployments, as discussed in the Compound community calls, are Polygon’s zkEVM, Base, among others! The big difficulty with this, is that it can be incredibly hard to bootstrap liquidity on new chains, or how to incentivize users to migrate liquidity across multiple networks. Liquidity can be quite sticky! However, with this cross-chain migration tool, users will be able to, in one-click, migrate their existing position from Compound V2 or V3 on Chain A to Compound on Chain B, helping liquidity to move liquidity across chains in a seamless manner. There are big advantages to migrating your position to an L2, especially since it will now make maintaining your position significantly cheaper than doing it on Ethereum mainnet. In addition, the on & off ramp process is becoming much more streamlined with various major centralized exchanges supporting them.

unnamed (2)

The biggest difficulty that we are beginning to see, especially in the DeFi ecosystem is, as many of these L2s continue to evolve, this is only going to create more and more liquidity fragmentation. This problem began to arise about 12-18 months ago with the rise of Alt-L1s, and L2s, but this is only going to get worse since it is incredibly easy to spin up a new L2, comparatively speaking. Because of Fuji’s infrastructure, this is a problem we are able to help solve. We are able to tap into liquidity from multiple chains, and multiple money markets on the same network, helping to unify liquidity, to minimize slippage and utilization rates when using DeFi.

Let’s take a look at how things work for Fuji behind the scenes :point_down:

unnamed 3

Fuji uses ERC-4626 for the Vaults, which exist on each individual chain. It’s important to note that the Vaults themselves do not store funds on any bridges, while the router contracts have the capability to move liquidity/messages across chains if the user elects to have this functionality. An interesting fact about ERC-4626 is that it allows you to easily manage yield bearing tokens inside of the vault. Unfortunately, debt-tokens are not compatible with the vault standard. Because of this, the Fuji team ended up building an extension of ERC-4626, making it compatible with money markets (specifically debt tokens), and this new standard will later be introduced as an EIP to the Ethereum community.

These vaults are a layer on top of existing money markets, like Compound! We actually have support for both Compound V2 and V3, and we are planning on supporting all of the new Compound V3 deployments on other chains too. Since not every money market has the same security guarantees, the only money market(s) you will have exposure to are the ones that the vault directly connects with, which is able to be visualized & understood through Fuji’s UI. These isolated vaults are very different from an isolated pool on a money market since we can tap into the liquidity from multiple markets/networks, helping to minimize any potential slippage/impact on utilization ratios on individual money markets.

From a messaging/liquidity perspective, we are working with Connext Network as our official launch partner. The reason why we are working with Connext is their focus on security. They are building a trust-minimized bridge, which leverages the use of canonical bridges, where applicable. This means when passing messages from Chain A → Chain B, it would go through the native bridge of Chain A, back to Ethereum, post the message there, and then ultimately to the destination chain using its native bridge, which would be Chain B in this example. Long term, we want to give additional optionality to users based on Speed, Security, and Cost, so we will support other bridge solutions as well.

As a part of the Cross-chain migration tool that Fuji is building for the Compound community, we will be initially building this with Connext, but also with the mindset that other bridges will be able to be supported as well, depending on how the Compound community sees the tool evolving.

We’re incredibly excited to be building, not only on top of Compound, but alongside the Compound ecosystem, and bringing value to your community. If you want to stay in the loop on Fuji’s progress or become a part of our growing community, you will be able to find out more information below.

Keep climbing!

Website: https://fuji.finance
Twitter: https://twitter.com/fujifinance
Discord: Fuji Finance
Telegram: Telegram: Contact @fujifinancedao

8 Likes
2

Hey!

I wanted to share a brief update regarding the cross-chain migration tool we have been building for Compound as a part of CGP (Compound Grants Program).

We are well underway in development.

  • We have decided on a baseline architecture on which we have agreed to build the compound cross-chain migration tool. The various interfaces and corresponding contracts are ~50% complete.
  • The architecture is attempting to minimize the role of an admin; however, we want to anticipate the creation of new CompoundV3 markets. With that in mind, we are thinking on giving admin-role to the timelock: Compound v2 Docs | Governance
  • We are currently testing a cross chain migration of just a lending position, similar to the image shown above in the original post.
    • This is 70% done.

We will continue to keep you updated on our progress as we bring this tool into production!

If you have any thoughts or comments/questions please feel free to let us know either here or in our Discord.

1 Like
3

Hey @ansteadm, very exciting to see progress made in a cross-chain migration tool and thanks for providing some updates!

In general, making the Timelock the admin is the right approach because it means the community will be deciding on any changes going forward.

To clarify, what do you mean by “add new markets”? Does the admin have to do something for a new Comet market to be supported by the cross-chain migrator? I think it may be helpful to provide a system diagram of all the contracts that exist and how they are related to one another.

1 Like
4

Relaying some of the discussions that occurred during the community call, the Timelock might not actually be the best candidate for the admin role. As conveyed by @adam, the Timelock manages all core protocol contracts. The Fuji Finance cross-chain migrator is a third-party system, so it might not make sense philosophically and practically for the community to govern it.

2 Likes
5

Hi Kevin, thanks for sharing and relaying the message of our discussion during the Compound community call here.

We will proceed as recommended, with Fuji having authority about future changes on the system.

Though, one point I would like to clarify is that the cross-chain migration tool that we are building as a part of this Compound grant is not a “core” element of the FujiV2 protocol, rather an auxiliary set of contracts that can be used by the Compound community to migrate positions cross-chain.

Therefore, that means that these set of contracts are not needed for the core Fuji V2 protocol to function, as it was questioned or indirectly inferred during the call, but can stand alone.

We can see them as a public good, on which Fuji intends to build further in the future.

Regarding the drafts for the system architecture:

We have created these first diagram drafts:

Inheritance Diagram

Fuji_himalaya_cross_chain_migrator_inheritance
Fuji_himalaya_cross_chain_migrator_inheritance1115×532 29.1 KB

INTERFACES
IXReceiver: interface defined by Connext. Every contract that will serve as a target on the destination chain of any connext bridge operation has to implement this interface. It has one function xReceive which will be the function called on the destination chain by connext.

IHimalayaConnext Defines the functions to be available to be called to interact with Connext bridge. It inherits IXReceiver.

IHimalayaMigrator: generalized interface that every protocol who wants to use this migration tool will need to implement. It contains 2 functions (beginXMigration and receiveXMigration). It also contains the Migration struct which is a data structure defining all the necessary data to a migration. It contains the following:

struct Migration {
  address owner; // user who wants to migrate or owner of the position to be migrated
  uint48 fromChainId; // chain from which position will be migrated
  uint48 toChainId; // chain to which migration will be sent to
  address fromMarket; // market on origin chain which owner's position is in
  address toMarket; // market on destination chain which owner's position will be migrated to
  IERC20 assetOrigin; // ERC20 token that is deposited on origin chain
  IERC20 assetDest; // adopted ERC20 token that represents origin asset at destination chain
  uint256 amount; // amount of ERC20 deposit to be migrated
  IERC20 debtAssetOrigin; // ERC20 token that is borrowed on origin chain
  IERC20 debtAssetDest; // adopted ERC20 token that represent origin debt asset at destination chain
  uint256 debtAmount; // amount of debt being migrated
  address himalaya; //address of IHimalayaMigrator on destination chain
  uint256 deadline; //period to execute this migration
}

Function call diagram

Fuji_himalaya_cross_chain_migrator_function_call
Fuji_himalaya_cross_chain_migrator_function_call1100×796 73.8 KB

Feel free to follow progress at the following repository, we will develop the tool in a open source fashion.

PLEASE NOTE: that these diagrams do not include yet the flow on which a third party facilitates the transfer of a debt position, but rather assuming the user has the debt balance to free up their collateral at the origin chain. The “cross-chain flashloan” (lack of a better name) is a functionality that will be added on top at a later stage; though, that it is not in the defined scope of the grant application.

kudos to @pedrovalido on preparing most of this info.

2 Likes
6

Thanks @dcota and @pedrovalido for preparing these diagrams! This definitely helps paint a clearer picture of the different components involved in facilitating a cross-chain migration.

If you don’t mind, I have a few questions:

  1. Which chains does Fuji Finance plan to support as source and destination chains?
  2. What happens if the deadline is exceeded? Do the user’s funds end up back where they started on the source chain? Does the user incur any fees in this case?
  3. Are there any fees for the migration? If so, how much and which parties are collecting the fees?
  4. Who pays for the gas on the destination chain? Will the user be required to hold the native gas token on the destination chain?
  5. How does the admin support a new market? Is this list of supported markets set in the HimalayaCompound contract?
1 Like
7

Good questions :grinning:

Which chains does Fuji Finance plan to support as source and destination chains?

On the scope of this grant, we decided to build on top of Connext (amarok v2). Connext currently supports: Ethereum, Polygon, Optimism, Arbitrum, Gnosis and Binance Smart Chain. Any combination of those as origin or destination chain will currently work.

We are aware of Connext’s intention to keep adding new evm chains in the future.

If the community desires an immediate support for another chain, we could have a discussion with Connext to support it, or decide to expand the scope of work and develop a Himalaya-adaptor for a bridge system that currently supports the desired chain(s).

What happens if the deadline is exceeded? Do the user’s funds end up back where they started on the source chain? Does the user incur any fees in this case?

Quick answer: user’s funds end up in the desination chain and the user’s collateral is substracted the Connext bridging (router) and relayer fee. User will have to execute a tx on the destination chain to get back the funds they attempted to migrate.

Long answer:Now, we should probably explain why there is a deadline. In general, you would want that any signed message (specifically allowing to do on-behalf user actions) expire at some point. You can refer to the pattern where inspiration came from in EIP2612 including a deadline. However, in the “vanilla” eip-2612 case, the asset transfer does not happen partially before execution of the signed permit. In a cross-chain tx this is not the case. Therefore, we have two options:

i) Create logic that handles recovering funds by the user’s with all guards and checks required if a migration is initiated and is unable to be completed before deadline. (This is what core FujiV2 does).

ii) Remove the deadline, but explore if there is any unwanted consequence or possible ways to re-use a migration permit.

Regardless if we choose option ii), we will still require logic that handles recovering funds. This is because a migration can fail for other reasons. For example, wrong migration inputs, or tx failing at the destination Compound market (paused, frozen, capped).

Are there any fees for the migration? If so, how much and which parties are collecting the fees?

To migrate there is two fees:

Bridge fee (also called router fee): This is common of all bridges. Essentially a convenience fee for having fast liquidity and execution of your desired transaction on the destination chain. Connext charges 0.05% fee.

Relayer fee: The usual gas cost of executing your tx on the destination(s) chains. This depends on the current gas cost market condition and obviously the chain to which you are trying to migrate. Connext collects and distributes this fee to their relayers.

An implied question that follows is: When is the fee collected? We will make the extension UI to clearly state the fee costs before a user commits to the migration tx. This will be deducted from their bridging collateral.

You can also refer to Connext description of fees here.

Who pays for the gas on the destination chain? Will the user be required to hold the native gas token on the destination chain?

User does not need gas on the destination chain to make a migration. You can refer also to the previous question. However, if the user would want to manage their Compound position post-migration, they will require native token to transact as they would do with normal Compound operations.

How does the admin support a new market? Is this list of supported markets set in the HimalayaCompound contract?

The migration struct has inputs: address fromMarket, address toMarket. We are thinking as a security measure to validate these addresses inside the _handleOutbound logic. However, in order to validate them, they have to be in storage somewhere by some trusted authority.

2 Likes
8

Quick update on the fly. We will be performing production tests (smart contract mainly) by the end of next week.

Design (UIUX) update coming soon too.

1 Like
9

Hi community!

We wish to provide you with an update regarding the current status of the Fuji Finance team and the cross-chain migration tool that was under development as part of the Compound Grants program, which was accepted in this proposal.

Last week, we announced that we will be shutting down Fuji Finance . Unfortunately, despite our best efforts, we were unable to secure the necessary funding to sustain the development of the core protocol. While we believe that a product like ours, or a similar one, will have a place in the future, our available resources, expertise, and market conditions posed significant challenges to achieving product market fit for our V2. You can check out more details in our public announcement.

With our limited resources, we arrived at the conclusion that we would be unable to maintain the operation of a cross-chain migration tool. The contracts still require an audit, and the ongoing coverage of backend services necessary for the extension’s functionality proved to be unsustainable on a month-to-month basis. Consequently, we made the decision not to deliver an incomplete or “half-baked” extension to the Compound community.

We also want to clarify that our team never received the grant stipend, as we regrettably fell short of delivering the promised extension and deadlines. The code for the cross-chain migration tool we developed will remain open source and accessible at the following Github Repository: himalaya-migrators. If any members of the community are interested in taking on this project or building upon it, our team members are available to provide explanations and support for any of its components.

We would like to express our apologies for not being able to successfully deliver the cross-chain migration tool extension as planned.

Thank you for your continued support on behalf the Fuji team !

3 Likes