Capital Efficiency: The True Measure of a Bridge
How we’re turning Hyphen into the most capital efficient bridge on the market.
Introduction
It’s commonly assumed that volume and TVL are the top metrics when looking at bridge usage, where higher TVL is thought to be indicative of growth.
However, it’s now understood that in addition to volume, a more accurate measure of bridge usage and asset utilization is capital efficiency, rather than TVL.
In this post, we’ll explore ways in which we are building Hyphen to become the most capital efficient bridge in the market as we continue to scale in volume.
Why Capital Efficiency?
More Chains and Tokens added to Hyphen
Shifting to a capital efficient model means liquidity can be used optimally where it’s needed, thus, by moving liquidity just in time across various chains to meet any bridging demand, we can quickly support a lot more chains & tokens. Doing so improves Hyphen interoperability, which is a key component for increasing usage from both mainstream users and crypto-natives.
Higher LP Yields
Volume is usually the driving factor behind the net revenue of a bridge, so that being constant, a more capital efficient bridge gives the LPs more lucrative rewards compared to one with a higher TVL.
In other words…more rewards distributed amongst fewer people=higher APY.
For example: A bridge with 50% of it’s TVL utilised daily has a ~20% APY (at 0.1% LP fees) while one with 15% utilisation has an APY less than 6%.
Reduced Risk
There is always associated risk when dealing with smart contracts. Reducing TVL via increased efficiency, is a proven method in reducing said risk by having a smaller amount of locked value stored within a contract. A more capital efficient bridge is thus able to do the same volume at a lower risk than one with less capital efficiency.
The Challenge: Liquidity Pool Imbalances
Most bridges to date are currently optimized for speed and security, where TVL is assumed to be the primary indicator of success in addition to volume. Much of the focus here is born from bridge developers solving for speed where again, TVL has been the focus, not efficiency with respect to liquidity management.
We won’t get into the technical aspects of liquidity pool rebalancing and node infrastructure, you can learn more about that from our CTO here.
What we will say however, is that it’s a fairly manual process, due to pool imbalances from one-sided demand, with low liquidity in highly demanded destination pools and high liquidity in popular source pools. In these cases, bridge transfers will fail unless the liquidity is rebalanced.
Typically, node infrastructure carries out this rebalancing, bearing the burden of increased overhead without proper compensation. As a result, imbalanced pools and worse, failed transfers, greatly reduce the capacity and speed at which we’re able to integrate with new chains to Hyphen.
Late last year however, we began asking ourselves, what if it didn’t have to be this way?
Solution: Hyphen Dynamic Fees
Achieving capital efficiency begins with ensuring liquidity pools are mirrored effectively between source and destination chains under a decentralized model. Our solution is to introduce a dynamic fee model, where liquidity pools are balanced through incentivizing transfers in favour of source chains with higher liquidity to those with less, resulting in a fee determined by the available liquidity in both the source and destination chain.
More of a visual learner?
Here’s the formula:
$$ F(L(e), L(r)) = \frac {F(max) * F(e) *L(e)^d} {F(e)*L(e)^d + (F(max) — F(e))*L(r)^d} $$
where,
$L(e)$ ⇒ Liquidity at equilibrium state. L(e) == SL
$L(r)$ ⇒ Resulting liquidity after the transfer is done. $L(r) = (L — transfer Amount)$
$F(max)$ ⇒ Max percentage fee to be deducted. F(max) = 10% (Constant value)
$F(e)$ ⇒ Fee to be deducted at equilibrium state. F(e) = 0.1% (Constant value)
$d$ ⇒ Deep Factor. Value that decides how much deeper the curve looks
More simply:
Transfer A) High liquidity pool >>> Low liquidity pool = high fees (moving pools further from equilibrium, being 0)
Transfer B) Low liquidity pool >>> high liquidity pool = low fees (moving pools closer to equilibrium by adding to lower pool)
For Example:
Say you are conducting a transfer between two bank accounts under a dynamic fee model. Your main account (source chain) has a USD balance (liquidity pool) of $10,000 and you deposit $8,000 to transfer to another account (destination chain) with a balance (pool) of $5,000 (lower liquidity than the source). In doing so, you are charged a $10 fee, because you are depositing into the high liquidity pool ($10k), thus increasing the imbalance between the source vs. destination pool and moving further away from equilibrium (difference = 0).
The opposite is also true, where if you were to deposit $8,000 into an account containing $5,000, rather than the higher one with $10,000, your fee might only be $3 because you are increasing the liquidity of the source pool (account), which is the lower of the two, thus bringing them closer to equilibrium or balancing. And therein lies the incentive and mechanism in which Hyphen can rebalance pools under the dynamic fee model.
Arbitrage Opportunities
In the new model, we’ll publish open source bots capable of rebalancing Hyphen pools and collecting rewards for doing so. A bot can be executed by anyone and only requires providing the appropriate pool assets for rebalancing.
In the absence of a bot, Hyphen users will be able to play the role of arbitragers and earn rewards simply by moving their funds from one chain to another.
Example:
To illustrate an arbitrage opportunity in a liquidity bridge, let’s assume chain A has a 100 ETH pool while, at the same time chain B has 100 ETH pool.
In this scenario, a cross-chain transfer should cost a flat-fee of .1%. This fee is the equilibrium cost of capital and goes entirely to the LP. Overtime, user preferences or imbalanced asset demand across chains may change the parity of the ETH pools in our example.
Let’s say a popular yield farm on chain B has caused a spike in demand for ETH withdrawals on chain B. As user transfers from chain A to B are fulfilled, exit liquidity on chain B is becoming scarce. Scarce resources cost more, and users will experience an increase in transfer fees above .1% to withdraw ETH from chain B. The increase in transfer fees above .1% are set aside as a bounty. The larger the imbalance across ETH pools, the larger the bounty grows, the more incentive for arbitrage.
By placing ETH in the depleted pool and withdrawing from a surplus pool, the arbitrageur has captured the user transfer fees above equilibrium (i.e., .1%).
Conclusion
Building more efficient dApps and protocols is imperative for onboarding mainstream users to Web3. If we want to evolve and scale far beyond Web2, we have to catch-up with it first and improving capital efficiency to create an extremely well-rounded bridge for our users is a big step in the right direction.
