JIP-9: Adopt Interceptor Liquidity Defense

Abstract

This JIP will authorize the Jito DAO to adopt a deployed instance of the open-source Interceptor code and assume governance powers over its parameters.

Interceptor is a program designed to help SPL Stake Pool LSTs avoid the impacts of toxic decentralized exchange flow resulting from socialized liquidity. The Jito DAO’s instance of Interceptor will intercept the depositing of stake accounts into the JitoSOL stake pool, adding a time delay with a linear fee curve to receiving the JitoSOL minted through those stake accounts.

The practical effect of this change would be a new fee imposed on users and protocols that require, and therefore claim, their JitoSol immediately after minting. This fee only applies to JitoSOL mints from stake accounts, and native SOL-based minting will have no fee and no time delay. This will act as a deterrence against socialized toxic flow.

The Jito DAO will maintain governance control over both the fee amount and time decay duration. Initial parameters will be set to a 10% fee, linearly decaying over 10 hours or roughly 20% of an epoch.

Motivation

On April 14th, the JitoSOL price deviated materially from its underlying fair value. Moreover, the price moved outside the liquidity range of the Kamino JitoSOL-SOL vault. The Kamino vault is a key source of liquidity for the JitoSOL-SOL pair, and should it fall out of range during a black swan scenario there could be ramifications across the Solana ecosystem as key liquidity suddenly becomes unavailable. As such, the Jito Foundation launched a data analysis of the event.

After investigation, it was found that a major contributing factor to the range failure was a series of transactions originating from the Sanctum Router program that ultimately sapped over $11m in SOL liquidity from the Orca JitoSOL-SOL pool. This liquidity drain included a $2.7m transaction, a $2m transaction, and a $1.8m transaction – all liquidations of non-JitoSOL LST positions.

The Jito Foundation then conducted a study designed to analyze all transactions originating from the Sanctum Router program for the month of September 2024. The findings indicate that the program is the source of significant toxic flow.

The study found that in September, the Sanctum Router program facilitated 28,626 successful transactions, of which 20% utilized JitoSOL liquidity. However, only 3% of transactions facilitated a user directly swapping in or out of JitoSOL.

An example transaction where JitoSOL serves solely as a liquidity intermediary can be seen below, where a user has created a transaction using Jupiter and signals that they wish to swap their apySOL to SOL with a slippage limit of 50bps. Jupiter identifies that the only immediate way to do this is via the Sanctum Router, and the following transaction takes place:

  1. Jupiter takes control of the signer’s apySOL and invokes the Sanctum Router
  2. The Sanctum router burns the apySOL and mints the equivalent JitoSOL
  3. With the newly minted JitoSOL,the router finds instant liquidity via the Orca JitoSOL-SOL pool, swapping in the JitoSOL and siphoning SOL liquidity from the pool

This is a prime instance of socialized liquidity, where the Orca JitoSOL-SOL pool – which is incentivized with Jito DAO funds via a Kamino vault – is the target of a trade that saps liquidity from the JitoSOL pool while providing no tangible value to either JitoSOL users or the Jito DAO.

This toxic flow is currently and continually taking place, and at a significant scale. When looking at net liquidity outflows for the month of September, the Sanctum router is responsible for approximately $26,000,000 USD net liquidity siphoned from JitoSOL pools:

Overwhelmingly this toxic flow benefitted other LSTs to the detriment of JitoSOL users:

Toxic flow resulting from socialized liquidity has a number of negative externalities, which we classify as Depeg Risk, Downward Range Pressure, Incentive Misalignment, Yield Drag, and Integration Risk.

  1. Depeg Risk

Socialized liquidity creates correlations which render JitoSOL more vulnerable to depeg events. JitoSOL-SOL delta stability is a key pillar of its utility. Holders have more confidence in the token if they know liquidity at fair value is available even during market stress. Furthermore, delta stability is critical for DeFi integrations with margin protocols, which rely on the liquidity for liquidations in volatile markets.

If we assume that X = total JitoSOL liquidity which can be used to prevent depegs, then there are two possible scenarios.

Scenario 1, with socialized liquidity:

Depeg occurs if X < (JitoSOL unstakes + market LST unstakes originating from Sanctum Router)

Scenario 2, with individual liquidity:

Depeg occurs if X < (JitoSOL unstakes)

One prime historical example of socialized liquidity is is the Curve 3pool, where the collapse of UST led to the depegging of USDT.

  1. Downward Delta Range Pressure

To date, we’ve observed that socialized liquidity widens the JitoSOL-SOL delta. This is because toxic flow is constantly swapping JitoSOL for SOL, and relying on arb bots to rebalance the pools afterwards.

This constant delta-widening disadvantages JitoSOL users who wish to swap out. Additionally, socialized liquidity means there is a thinner liquidity buffer in the event of black swan scenarios.

  1. Incentive Misalignment

Multiple JitoSOL-SOL pools are incentivized via Kamino vaults. These incentives are meant to deepen liquidity in order to strengthen JitoSOL’s position in DeFi.

Socialized liquidity means that incentives are inadvertently being spent on making swaps between competing LSTs more effective, ultimately making the JitoSOL user’s experience less favorable and benefitting protocols in direct competition with JitoSOL.

  1. Yield Drag

Deposits of stake accounts creates additional rebalancing pressure on JitoSOL. These deposits may not be consistent with JitoSOL’s delegation strategy, so accounts that are unstaked in the same epoch as deposits temporarily do not receive yield, which has a negative impact on all JitoSOL holders.

  1. Integration Risk

Instances where JitoSOL’s incentivized pools fall out of range can factor into both DeFi and CeFi risk management analyses. When this occurs due to socialized liquidity, JitoSOL’s status as the most liquid LST – and therefore often favored in terms of weights and caps – comes under scrutiny.

Ultimately, as the largest and most liquid LST, JitoSOL sees no benefit from socialized liquidity, and indeed currently and inadvertently benefits its competitors via JTO incentives. JitoSOL should stand as the most resilient LST in black swan scenarios and fully benefit from its liquidity depth, rather than serving as a target for continual, protocolized vampire attacks.

Interceptor ensures that JitoSOL users and the Jito DAO enjoy the full benefits of the protocol’s pole position in DeFi.

Key Terms

Jito DAO: Decentralized Autonomous Organization governing the Jito ecosystem.

JitoSOL: A Solana Liquid Staking Token (LST) representing staked SOL within the Jito ecosystem.

Interceptor: An open-source program designed to protect SPL stake pool LST by introducing fees for immediate stake account claims, specifically targeting actions that contribute to toxic flow.

Socialized Liquidity: A situation where liquidity intended for JitoSOL is instead used to facilitate swaps between competing LSTs, diluting JitoSOL’s utility and stability, creating externalities like Depeg Risk, Downward Price Pressure, and Yield Drag.

Toxic Flow: Liquidity movement that benefits competing assets at JitoSOL’s expense. This flow typically originates from decentralized exchanges or protocols using JitoSOL pools for swaps, diminishing JitoSOL’s utility and liquidity for native users.

Sanctum Router: A decentralized exchange routing program identified as a primary source of toxic flow impacting JitoSOL pools.

Specifications

This proposal would signal approval for Jito Network to adopt an instance of the Interceptor code, which intends to disincentivize toxic flow by charging fees to users and protocols that require JitoSol from stake account deposits immediately.

The Interceptor would act as a stake deposit authority for the JitoSOL pool. When depositing a stake account, the staked account will be immediately converted to JitoSOL and transferred to an intermediate token account owned by the Interceptor program. At a future date, the second instruction can be called to claim the user’s JitoSOL, at which point the fee is levied based on the fee parameters set by the DAO.

Claiming is permissionless for fully vested JitoSOL and can be performed by keeper bots to ensure a good user experience.

Fees collected from the Interceptor would be directed to the Jito DAO treasury.

The Jito DAO will assume control over both fee and fee duration parameters after the successful passing of this proposal and deployment. The initial parameters for Interceptor would be set at a 10% fee decaying linearly over 10 hours.

Benefits/Risks

Benefits:

  • Enhanced liquidity for JitoSOL
  • Incentives flow to intended parties and purposes
  • New fee stream

Risks:

  • Some stake account transfers do not result from toxic flow, and Interceptor would negatively impact the user experience for these users

Outcomes

The passing of this proposal will lead to utilizing the Interceptor code, which will be managed by the DAO in perpetuity going forward. Furthermore, the DAO will set the JitoSOL Stake Pool’s stake_deposit_authority to a program derived address owned by the stake_deposit_authority, which will gate all stake deposits to being run through that program.

Cost Summary

This proposal will incur no direct cost to the DAO.

5 Likes

Hi there, a few questions:

  1. Who are the devs behind the Interceptor code, I haven’t heard of Exo Tech before? Are they known to the proposer and other Jito core contributors and have there been direct discussions about the functionality and use of their program/code?
  2. Has the Interceptor been audited? If not this should be a pre-requisite for adoption as this code will gain access and custody of potentially significant in-flowing stake accounts
  3. This proposal appears to require additional keepers, which creates a further maintenance burden on the Jito Network, who will run these keepers and what will their incentives be?
  4. Will this in any way break existing integrations with web3.js / spl-stake-pool JS bindings that may be used by various bots, dapps or wallets?
3 Likes

Who are the devs behind the Interceptor code, I haven’t heard of Exo Tech before? Are they known to the proposer and other Jito core contributors and have there been direct discussions about the functionality and use of their program/code?

Hey @laine, I’m Taylor, one of the co-founders of Exo. We’re a group of Solana community engineers that have been building smart contracts (among other products) since 2020. After moving on from other projects we founded and/or contributed to, we decided to work with awesome teams like Jito to help accelerate their development timelines through our firm Exo. We’ve been working with the Jito foundation on research and development for the Interceptor program mentioned by OP.

Has the Interceptor been audited? If not this should be a pre-requisite for adoption as this code will gain access and custody of potentially significant in-flowing stake accounts

The code has NOT been audited and is still under development and initial review. Code is likely to be complete within the next week. Audit timelines are TBD, but should be planned shortly from what I know.

Will this in any way break existing integrations with web3.js / spl-stake-pool JS bindings that may be used by various bots, dapps or wallets?

Yes, this would be a breaking change for any SDK that is using the DepositStake or DepositStakeWithSlippage instructions from the spl-stake-pool program. The Interceptor program would become the stake_deposit_authority through a PDA and thus becomes the entry point for both of those instructions.

5 Likes

How would this impact the UX of the recent Phantom integration?

From my perspective, if this is the core issue, I feel that there’s alternative solutions that should also be considered, which don’t break existing integrations or change the UX of minting jitoSOL.

Proposed alternatives (not mutually exclusive, can do more than one):

  1. Sanctum agrees to modify their router to include a fee directed towards the Jito DAO. This fee would serve two purposes: (i) disincentivize routing through jitoSOL liquidity (as the route becomes expensive) and (ii) monetize any routes that do, which could then be used to further incentivize deep jitoSOL/SOL liquidity.
  2. Jito and Sanctum co-incentivize liquidity such that the cost of attracting backstop liquidity is socialized across all LSTs on Solana

These are just two ideas that I think could address the core concern of this proposal, but there’s also many other possible solutions. I’d love to see the broader Solana community come together, critique these options, and propose any and all alternatives solutions as well.

3 Likes

I think this change makes sense for Jito and for holders of jitoSOL. It’s a non-trivial exercize to build and maintain a token’s liquidity on chain. The jito foundation / DAO has taken this seriously and has invested significantly in building up jitoSOL liquidity in order to support more growth and more DeFI opportunities for holders.

JitoSOL holders rely on healthy liquidity in order to swap in and out of jitoSOL. Making the liquidity pool less vulnerable due to other non-jito related activities and events, is a positive step and strengthens the value-proposition of holding/using jitoSOL in DeFi

4 Likes

@laine
These are good call-outs and we’ll be sure to add that information to the JIP.

This will break existing integrations, such as the current Phantom stake account conversion quest, but as @taylor-exo mentioned the fix should be trivial.

@andrew
I think we’re aligned in acknowledging that there should be some sort of fee for toxic JitoSOL flow. Deep liquidity protects against de-peg scenarios. $90mm+ in liquidity is extremely valuable, especially as total LST TVL grows significantly vs. the amount of LSTs supplying and incentivizing liquidity.

I think where we disagree is when it comes to who should control the fee, and at what layer of the stack. From our perspective:

  1. The vampire attack is protocolized
  2. Jito Network’s defense should be protocolized
  3. It’s much easier to construct creative ways to share liquidity equitably once the ongoing attack has been mitigated, and Jito DAO is the entity with decision making power.

One solution to better sharing liquidity could potentially be an update to Interceptor that whitelists the Sanctum router in exchange for an alternative fee structure.

However, the status quo has already led to negative impacts on a key source of liquidity and caused daily negative externalities for JitoSOL users. I feel a sense of urgency to both end the attack, and make sure the DAO has programmatic control over future decisions, rather than other protocols controlling JitoSOL’s liquidity.

1 Like

FP from Sanctum here, sharing my two cents.

It’s tempting to portray Sanctum as an “attack” on JitoSOL’s liquidity. In reality there is give and take. Sanctum provides over 400,000 SOL (~$100M+) in the Sanctum Reserve, which is open to all LSTs, including JitoSOL. This helps jitoSOL-SOL maintain its peg. Additionally, instead of being one-way, the router also allows jitoSOL to access the liquidity of other large LSTs like mSOL and bSOL.

I think @Andrew makes a good suggestion here, and I’d be happy to explore the below with the Jito DAO:

  1. Sanctum agrees to modify their router to include a fee directed towards the Jito DAO. This fee would serve two purposes: (i) disincentivize routing through jitoSOL liquidity (as the route becomes expensive) and (ii) monetize any routes that do, which could then be used to further incentivize deep jitoSOL/SOL liquidity.

It’s my deep desire to work with the Jito DAO to build a positive-sum staking ecosystem for Solana, rather than trying to cut each other out.

How might the introduction of fees and delays impact JitoSOL’s competitiveness compared to other Liquid Staking Tokens (LSTs) that do not impose similar restrictions?

How would the Interceptor would negatively impact the user experience for the stake accounts that do not result form toxic flow?

In terms of user experience, I think it would also be important to have something that constantly reminds users that the fee will be applied only to JitoSOL mints from stake accounts, and native SOL-based minting will have no fee and no time delay.

Additionally I would like to +1 @andrewt Solution of having Sanctum modify their router. But I would want to see that in ADDITION to the proposed resolution rather than an alternative.