JIP-9: Adopt Interceptor Liquidity Defense

[andrewt]

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.

2. 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.

3. 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.

4. 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.

5. 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.

[laine]

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?

[taylor-exo]

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.

[Andrew]

@andrewt

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

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

@andrewt

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.

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.

[marky]

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

[andrewt]

@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.

[fplee]

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.

[Chainflow]

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.

[n8tr0n]

This term “toxic flow” that is being repeated (almost as if gaslighting) implies harmful or exploitative behavior, but it’s a misrepresentation of Sanctum’s role in decentralized liquidity markets. Let’s clarify the facts.

Sanctum’s router plays a vital role in maintaining liquidity efficiency and peg stability across various Liquid Staking Tokens (LSTs), including JitoSOL. Far from being toxic, this type of routing is a fundamental function of decentralized finance (DeFi). By enabling seamless interoperability across pools, Sanctum contributes to a healthier and more robust liquidity ecosystem.

The use of “toxic flow” in this context misapplies the term, which typically refers to predatory market behaviors like frontrunning or arbitrage that harm participants without adding value. Sanctum’s routing doesn’t exploit JitoSOL pools; rather, it generates activity and fee opportunities for liquidity providers, benefiting both JitoSOL holders and the broader Solana ecosystem.

Sanctum’s commitment to collaboration over competition is clear. Representatives have expressed openness to aligning incentives with JitoDAO and fostering a positive-sum staking ecosystem, where all participants thrive. As we build forward together, constructive dialogue and shared solutions will ensure the continued growth and innovation of Solana’s DeFi landscape, not demonizing a protocol who’s founder has made his earnest intensions clear and continued to foster a collaborative ecosystem where everyone wins.

JIP-9: Adopt Interceptor Liquidity Defense

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 …

[andrewt]

@Chainflow
Good Q’s. Stake account conversions account for a significantly smaller percentage of JitoSOL mints relative to native SOL mints. Additionally, my personal view is that a stake account conversion user will likely be a longer-term holder, and is thus more forgiving of a time-based lockup. We do not expect a significant negative impact from a competitive standpoint, and can adjust parameters based on user feedback.

@fplee @n8tr0n
Thanks to you both for the thoughtful points about the language and narrative at play here. I agree that the terminology, including “toxic flow” and “vampire attack” could be interpreted as needlessly bellicose, especially given the history of extreme animosity between protocol development teams when it comes to vampire attacks.

With that in mind it’s worth clarifying, to FP’s point, that this is not a matter of Jito vs Sanctum. Jito benefits from Sanctum in many ways and vice versa, and there’s a lot of integration work to be done in the future – it would be interesting to see a VRT Infinity Pool, or find a way to include VRTs in the current LST-only pool. Both projects are here for the long term, and there’s lots of potential to collaborate in positive-sum ways.

That being said, there is inarguably an outstanding negative-sum interaction currently at play between the protocols. This specific interaction is cloistered in how a lone part of the wider Sanctum network (the Router) interacts with a lone part of the Jito Network (the JitoSOL stake pool). Regardless of the terminology used to describe the interaction, JitoSOL holders currently see significant negative outcomes from this integration, which Sanctum currently controls.

FP made one technical argument for why this specific interaction is not a negative outcome for JitoSOL users, specifically that JitoSOL users benefit from other large pool liquidity via the Router.

The data demonstrates that this argument is thoroughly unconvincing. I’d refer again to this chart from the proposal:

For the month of September, there were only 10 swaps where JitoSOL users benefitted from the liquidity of other pools. Meanwhile, there were tens of thousands of swaps where non-JitoSOL users benefitted from incentivized JitoSOL liquidity. The proposal details how this negatively impacts JitoSOL users with some detail.

Interceptor is designed to counteract these negative impacts, and to give the Jito DAO the agency to determine the conditions for how these protocol elements interact in the future.

Ultimately this proposal should not be viewed as an “attack” in either direction, but as a new foundation from which the protocols can work to create more positive-sum interactions, including some potential examples described in this thread.

[benhawkins18]

The real issue here is economic: it’s currently too cheap to mint JitoSOL from stake accounts and extract liquidity at JitoDAO’s and JitoSOL holders’ expense. Instead of adding complexity with time delays and extra claim steps, we should just raise the cost of the problematic behaviors. Some straightforward fixes:

1. Direct Stake Deposit Fee:
Charge a modest fee in basis points when stake accounts convert to JitoSOL. This deters exploitative conversions, generates revenue for the DAO, and keeps things simple and transparent. This capability exists as native functionality within SPL Stake Pool

2. Adjust Liquidity Pool Economics:
If unstaking through incentivized pools is too cheap, consider slightly higher fees there too. Making liquidity extraction costlier aligns incentives with JitoSOL’s long-term health.

3. Collaborate with Partners:
Work directly with protocols like Sanctum on fee-sharing models. This way, if their routes rely on JitoSOL liquidity, they help pay for it, balancing the ecosystem rather than breaking it.

By focusing on direct economic solutions—fees that reflect the true cost of liquidity—we can avoid unnecessary complexity, maintain a good user experience, and keep JitoSOL appealing and accessible.

[BlockworksResearch]

From the Blockworks point of view, there is a high chance that toxic flow occurs again, and perhaps under a different protocol. While Sanctum was the protocol highlighted as the source of toxic flow, it’s not unimaginable for this to happen again. Per this instance, is it expected of the DAO to have the capability to blacklist/add a new address to the interceptor under these circumstances. Overall, we’re supportive of this proposal, though we would like to better understand the pipeline for these events moving forward, as it is likely that JitoSOL will be used as proxy-liquidity once more.

Additionally, while we understand the 10% fee to be largely punitive, in traditional finance the instant-withdrawal penalty is typically much smaller, so we ask if the 10% fee is in any way excessive. Also – is there any possibility that this fee could be set a bit more dynamically rather than discretely as it is currently? Perhaps there’s some room for setting volatility thresholds and applying fees based on that scaling.

Bouncing off @Benhawkins18’s point, it’s possible that the cost of minting JitoSOL is currently too low. To address this, we could consider a more dynamic fee model that responds to on-chain indicators—such as liquidity levels, deposit patterns, and shifts in liquidity ratios. There are two potential paths: adopting a straightforward, direct stake deposit fee or implementing a more adaptive, data-driven approach. Perhaps a combination of both would be ideal: start with a modest, direct stake deposit fee, and then layer on a dynamic component that adjusts based on a Liquidity/Volatility metric, factoring in liquidity depletion and price deviations.

[andrewt]

Thanks for the comment Ben

I think the framing around the question of alternative fees is important, so want to make a few points:

JitoSOL is facing a unique attack that no other LST on any other network has to grapple with. Because of socialized liquidity via the Sanctum router, the largest LST on Solana — in this case, JitoSOL — will by default be the target of protocolized liquidity drain.

This put JitoSOL in a position where it effectively serves as the source of liquidity for dozens of other LSTs. This is harmful for JitoSOL users for the reasons described in the proposal, but it’s also arguably harmful for the entire Solana ecosystem: there are massive LSTs, such CEX LSTs, that have no incentive or need to bootstrap liquidity. JitoSOL is load-bearing the liquidity needs of the entire Solana LST ecosystem.

In think in this context, it becomes clear that the problem is not that JitoSOL is selling liquidity too cheaply — indeed, there is no competitive LST on any network that incentivizes pools with higher fees than .01%. Instead, JitoSOL has the unique problem where it is currently being forced to sell liquidity to a particular entity under particular conditions that are harmful. This liquidity suck is bad for JitoSOL and bad for Solana.

Interceptor is a program that allows the Jito Network to behave like every other competitive LST in that it can incentivize low fee pools without subsidizing all other LSTs. Without Interceptor, JitoSOL would be asked to take steps and measures (such as subsidizing deposits into uncompetitive liquidity pools) that no other LST projects have to, simply because of a Solana design quirk that makes it the target of a protocolized vampire attack.

I think through this lens the case for Interceptor, which is a much more targeted fee mechanism that keeps JitoSOL competitive, makes more sense.

[Ian]

I’ll be voting Yes on this proposal.

The Interceptor effectively adds friction to curb exploitative behavior, helping preserve JitoSOL’s liquidity and stability. The initial parameters 10% fee decaying over 10 hours) seem like a reasonable start, and I assume the DAO will remain flexible and ready to adjust based on performance & feedback.

These protective measures stand to ensure JitoSOL remains positioned competitively. JitoSOL serves DeFi better than any other LST with regards to the amount utilized productively, which is beneficial to the overall Solana DeFi ecosystem and network.

I support passing this proposal with the understanding that the DAO will monitor its impact closely, iterate carefully, and remain open to community input as we refine this protective measure.

Thanks to all the delegates and community members for all the thoughtful discussion around this issue.

[Andrew]

After considerable deliberation, I’ve decided to vote ‘No’ on this proposal in its current form.

I can see the need for an added fee to go from an arbitrary stake account to jitoSOL, but I see the enforced time delay as too cumbersome. It will likely break various user journeys and in my opinion, add unnecessary complexity given the stated objective. Instead, I think a simple fee is a much cleaner solution.

I’d be happy to collaborate on a revised proposal (if it comes to that).

Regardless of outcome, I’d really like to hear the latest from the Sanctum team and the Jito Foundation on what a “collaboration” of sorts could look like here vs. this situation ending with barriers up.