⚙️Protocol Architecture

A unique hub & spoke money market architecture.

Protocol Design

Hub & Spoke Model

Synonym is built on a hub and spoke architecture that allows the money market to scale effectively across n chains. To fully appreciate the merits of this model we must understand an alternative, the point-to-point model. A point-to-point model of cross-chain borrow and lending could keep every chain identical in function and allow accounting between any pair of chains. Assets would be kept on native chains, without any wrapping, and Wormhole messages would be used to facilitate only accounting between chains. A schematic for this type of design can be seen below.

Meanwhile, a hub-and-spoke model features a single hub chain that functions as either a centralized accounting or liquidity layer, with different spoke chains sending either accounting messages (centralized accounting) or wrapped token transfers (centralized liquidity) upon token movements to the hub. The hub then serves as the authoritative source of state information, and any state stored on spokes is meant to be a copy of the ground truth state stored on the hub. Below, we motivate the hub-and-spoke model by examining some challenges with other models.

Hub & Spoke Architecture.

Process flow.

The point-to-point model is relatively simple in schema, but interest rate calculation dependencies actually make the pattern a lot more complicated to handle in practice. The interest rate the protocol charges for a loan or pays out for collateral deposits is continually changing as users make deposits and withdrawals. The protocol needs to maintain a state of truth that must reflect the continually updating user behavior.

There are 2 relevant interest indices: one for each asset, the borrowed asset on Ethereum and the collateral asset on Solana. The main challenge with this federated cross-chain borrow-lend model is that both elements of state need to be tracked on both chains. In the model with more than 2 chains, state needs to be tracked and synchronized on all chains. This is because when an initializeBorrow is successfully called from Solana, that instruction must issue a Wormhole message indicating how much of the borrow asset on Ethereum the user can withdraw. If the user calls completeBorrow on Ethereum with that Verified Action Approval, they must be able to withdraw that much of the asset. Similarly, when a user pays back debt on Ethereum (either by repaying their own loan or liquidating someone else’s vault), they must get back a VAA indicating how much of the collateral of the vault on Solana they can withdraw. They must then complete the repay or liquidate by taking that action on the source chain Solana. Throughout this time, Solana holds the “official” interest index for the collateral asset and its perception of the interest index for the debt asset, while Ethereum holds its perception of the collateral asset interest index and the “official” debt asset interest index.

The fundamental issue is that in a single blockchain, state can be atomically updated; in a lending protocol context, both indices are tracked in the same program on the same chain, so they can be updated atomically without any other transactions coming in between. In the case of cross-chain borrow-lend where state is being tracked across multiple chains, synchronization cannot happen atomically, so either there is room for missequencing and error or enforcement of sequential processing of VAAs must be respected.

An alternative to this is to have borrow-lend operations take place on one designated hub chain that serves as the central accounting layer for the whole cross-chain ecosystem. Suppose that layer is on Arbitrum. Consider a user who wants to deposit ETH on an Ethereum spoke and take out a loan of SOL on a Solana spoke. Then, the schematic looks as follows:

Borrowing & lending flow.

This is better than the previous approach of deposits and withdrawals done directly on different chains, because now there is no state asynchronicity problem. The user does need to wrap assets and then deposit those wrapped assets on chain X to make deposits, and a withdrawer needs to take an action on chain X and then unwrap their assets, but all of this is configurable on the frontend. Because all accounting is done on a single blockchain, state is atomically updated, and there is no potential for asynchronicity. In essence, the ability to atomically execute and update makes it far easier to maintain this design of the protocol than a version where borrowing and lending happens on different chains.