Vault curation on Symbiotic

Vault curation on Symbiotic

How much shared security should we allocate to which Networks in Symbiotic? We present a methodology that guides MEV Capital (as Curator) and Nodeinfra (as node Operator) in making this decision.

Our goal is simple: maximizing the risk-adjusted returns from Symbiotic Networks for restakers. The primary risk to minimize is the slashing risk that could lead to the loss of restaker collaterals. The return to maximize is the value of rewards that restakers receive from Symbiotic Networks in exchange for providing economic security.

In this article, we focus on minimizing slashing risks by gauging the risks of Networks. We first examine how slashing works in Symbiotic. We then identify slashing risk factors that increase the probability of a slashing event. We design a methodology to evaluate these risk factors for any Symbiotic network. Using this methodology, we evaluate an example of a network. Finally, we discuss future work, and conclude.

We hope this article contributes to the Symbiotic ecosystem by presenting:

  • An examination of code paths in Symbiotic smart contracts that could lead to slashing

  • Analysis of risk factors arising from Symbiotic’s flexibility and modular nature

  • A multi-dimensional risk approach to evaluate software, governance, and communication

  • A case study on Stubchain, a Symbiotic network based on the Cosmos SDK


 

1. Slashing in Symbiotic

We describe how slashing—which penalizes retsakers and operators for malicious behavior or underperformance—is invoked in Symbiotic. We provide a brief overview of the Symbiotic related parties and examine the code path leading to slashing. We then describe a slashing scenario using StubChain [1], an example of a Symbiotic network.

1.1. Overview of Symbiotic

The Symbiotic ecosystem consists of vaults, curators, operators, networks, and resolvers. Vaults are contracts that receive collaterals from restakers and delegate the collaterals to node operators. Curators perform risk management for restakers and optimize the allocation of collaterals across different vaults. Operators are entities that run nodes to validate networks by provisioning the delegated economic security. Networks are decentralized protocols that utilize Symbiotic to source their security. Resolvers are contracts or entities that veto slashing incidents.

The network middleware contract (Middleware [2]) binds operators, networks, and resolvers. Operators and networks agree on which Middleware implementation to use. Middleware has two key functionalities. First, Middleware provides methods to identify which operators and how much of their stakes are participating to secure the network. Second, Middleware provides methods to initiate slashing, which may involve resolvers to potentially veto slashing.

1.2. The slashing code path in Symbiotic ecosystem

The above diagram depicts a simplified overview of the slashing code path for a Symbiotic network. Distributed nodes managed by operators initiate slashing by invoking the Middleware contract. Slashing is propagated to the Slasher contract, and ultimately to the Vault contract where collaterals reside. In the process, resolvers can veto the slashing request.

Slashing in Symbiotic ultimately happens in the onSlash() function of Vault contract. The function transfers the slashed amount of collateral to the burner address, effectively making the transferred fund not accessible by anyone, resulting in a worst case scenario. We do not want this line to be executed on any collaterals we curate and run nodes for.

The onSlash() of Vault can only be invoked by a Slasher contract. Vault rejects slashing when onSlash() is called by an account or contract other than the configured Slasher. There are currently two types of Slashers: InstantSlasher and VetoSlasher. Slasher calls onSlash() instantly when its slash() method is called.

VetoSlasher provides three methods for slashing: requestSlash(), vetoSlash(), and executeSlash(). requestSlash() keeps slash requests from Middleware. vetoSlash() allows configured resolvers to veto the kept requests. The conditions under which the method gets executed are : 1. the caller should be the configured resolver and 2. the method should be called before the deadline. Ultimately, executeSlash() is called to penalize the vault by slashing it, but only if the veto process has failed to prevent this action.

Using the onlyNetworkMiddleware solidity modifier, both Slasher and VetoSlasher require that only the Middleware can initiate slashing. Middleware can be any contract that the Network and the Operator agree on. Middleware has public entry functions that allow external parties, particularly nodes managed by operators, to interact with it.

In summary, three components are essential in triggering slashing. First, nodes initiate the slashing process by interacting with Middleware. Second, Middleware determines the conditions under which slashing happens and invokes requestSlash() on the configured Slasher. Finally, assuming VetoSlasher(), Resolvers act as the final gatekeeper before the slashing is executed.

1.3. Example: Slashing in Stubchain

We examine a slashing scenario in an example Symbiotic network developed by the Symbiotic team called Stubchain. Stubchain is currently the only available open source Symbiotic network implementation. Stubchain extends the Cosmos SDK such that shared security sourced from Symbiotic secures the chain.

We first examine the Middleware implementation of Stubchain, called SimpleMiddleware.  SimpleMiddleware faithfully provides the two key functionalities of Middleware: identifying the participating operators, and slashing the vaults associated with the operators.

As for the first functionality, SimpleMiddleware provides getValidatorSet() to identify the validator set for a given epoch. The function returns a list of ValidatorData, which specifies the operator key and the amount of stakes of the operator that are accounted for in the epoch. Note that it does not provide any information about the performance or malicious behavior of the validator.

Regarding slashing, SimpleMiddleware provides the slash() method to slash an operator.

The method has the onlyOwner modifier which means that only the account or contract that deployed SimpleMiddleware has the privilege to invoke this method. The function takes as inputs: the epoch, the operator(s), and the collateral amount, specifying how much amount to slash from which operator in an epoch.

Then, the slash() function finds the vaults associated with the operator, and slashes them using _slashVault(). The _slashVault() method is an internal method that invokes slash() from the slasher, configured at the inception of the dedicated SimpleMiddleware. Either InstantSlasher or VetoSlasher can be used by networks.

Stubchain extends the Cosmos SDK to integrate with SimpleMiddleware. Modified Cosmos SDK validators, which participate as the decentralized nodes of Stubchain, periodically issue an RPC call to the Ethereum L1 to invoke getValidatorSet() of the deployed SimpleMiddleware in order to fetch the validator information.Then, they use the information to compute the voting power of the participating nodes. Symbiotic operators are expected to run these nodes.

Although the Stubchain documentation mentions slashing based on the inactivity of the nodes, there is currently no direct integration between the validators and slash(). Nodes do not fetch information about slashing from SimpleMiddleware, and SimpleMiddleware does not maintain any information about the inactivity of the nodes. Instead, it simply provides slash() that can be only invoked by the owner. This means that there is a need for an additional trusted intermediary that has the SimpleMiddleware owner privilege to monitor the activity of the validators and request slash() based on it.

2. Risk Factors

We have observed complexity in slashing code paths, which makes it challenging to identify risk factors. The code paths involve multiple stakeholders spanning restakers, curators, operators, vaults, and resolvers. The paths are also invoked through complex software interactions between contracts on the Ethereum L1, such as network-specific Middleware implementations, and modules in the network node implementations.

To address this challenge, we take a practical approach by identifying three key risk factors that we believe have the most critical impact on slashing: software, governance, and communication. We provide the rationale for each of these factors and describe concrete examples using Stubchain.

2.1. Software

Software is a critical risk factor as slashing ultimately happens on-chain. In addition to the typical smart contract vulnerability risks, we examine risks stemming from the flexibility of Symbiotic. Although the core Symbiotic contracts such as the Vault and Slasher contracts are immutable, Middleware can be any smart contract the network developed. Nodes that connect to the middleware can be any distributed system, including Cosmos SDK and LayerZero DVN.

For example, suppose the Stubchain node implementation had a bug that resulted in incorrectly interpreting the data fetched from invoking getValidatorSet() on SimpleMiddleware. This may lead to slashing larger amounts of collaterals from vaults than what was originally planned, should the validators mistakenly provide wrong information to the Middleware owner that decides how much to slash when invoking slash(). Such software risks cannot be detected just by examining the smart contracts deployed on Ethereum L1.

2.2. Governance

Governance of different software components in Symbiotic is as important as software in determining slashing risk. The network’s governance determines software access privileges and updates to the software. Even with perfectly designed software, bad governance can easily lead to unintended or unfair slashing.

Compared to typical PoS chains where only restakers and validators are involved in governance, Symbiotic has a much more complex structure with restakers, vaults, curators, operators, resolvers, and networks due to its modularity.

For example, the slash() method of SimpleMiddleware can be called only by the owner of the contract. What is left unspecified in the current Stubchain implementation is who exactly the owner will be. In an extreme case where the owner is an EOA account sitting on a person’s laptop, that person can slash any vaults that opted into the network at free will.

2.3. Communication

Communication between responsible parties is critical in handling crises, and making sure different stakeholders are aligned and synced. As there are many different stakeholders in Symbiotic, a miscommunication between the parties at different layers (or lack of it) can potentially create flaws that may eventually lead to unintended slashing.

For example, suppose Stubchain uses Aragon [4] as its Resolver and a committee is assigned to vote on a slashing incident triggered by an attacker. If the committee is unresponsive and unable to vote before the veto deadline, the slashing will be executed, rendering the attack successful.

3. Risk Evaluation Methodology

Based on the three elements described above, we present our methodology to evaluate slashing risks of Symbiotic networks. Ultimately we assign a final score to a network based on its slashing risk. To compute the final score, we use a practical checklist that evaluates governance, software, and communication of three key components of the network: nodes, middleware, and resolver.

3.1. Risk scoring formula

Our scoring methodology utilizes a weighted sum approach to evaluate networks across 9 distinct categories, derived from the intersection of three elements and three components. Each category is assigned a weight reflecting its relative importance. Within these categories, we pose specific questions designed to gauge risks. Responses to these questions are quantified on a three-point scale : -1, 0, or +1. The final score for a network is then calculated using a formula that aggregates these weighted scores for each category.

 

3.2. Evaluating Nodes

a. Network nodes – Governance

  • Weight : 2 (important)
  • Weighted score range : Min -8, Max +8
  • Example : Symbiotic operators running nodes for the network

b. Network nodes – Software

  • Weight : 2 (important)
  • Weighted score range : Min -12, Max +6

Network examples : Cosmos SDK validators, Layerzero DVN nodes, oracles, sequencers

c. Network nodes – Communication

  • Weight : 2 (important)
  • Weighted score range : Min -8, Max +4
  • Example : Communication of node operators and network developers

3.3. Evaluating Middleware

a. Middleware – Governance

  • Weight : 3 (very important)
  • Weighted score range : Min -9, Max +6
  • Example : Privileged access to the Middleware

b. Middleware – Software

  • Weight : 3 (very important)
  • Weighted score range : Min -12, Max +9
  • Example : SimpleMiddleware [3] in Stubchain

c. Middleware – Communication

  • Weight : 1 (less important)
  • Weighted score range : Min -3, Max +3
  • Example : Communication of Middleware developers

3.4. Evaluating Resolver

a. Resolver – Governance

  • Weight : 2 (important)
  • Weighted score range : Min -8, Max +8
  • Example : Governance of a resolver committee

b. Resolvers – Software

  • Weight : 1 (less important)
  • Weighted score range : Min -3, Max +3
  • Resolver examples : Aragon, UMA, Kleros, Reality.eth

c. Resolvers – Communication

  • Weight : 2 (important)
  • Weighted score range : Min -8, Max +2
  • Examples : Communication of the member of the resolver committee

Our current checklist is far from complete or final. We plan to actively add, enhance, or remove eligibility criterias as Symbiotic networks go live and we learn more about their design and operation.

 

3.5. Rating and eligibility thresholds

We first compute eligibility thresholds for each component (nodes, middleware, resolvers) and each  element (governance, software, communication) based on our scoring system. A negative score (< 0) for any of the 6 eligibility thresholds automatically results in the impossibility to provide economic security to the network given its current stage, regardless of its final scoring.

As a Symbiotic curator looking to perform risk management for restakers, we use the eligibility threshold of the final score to classify networks into 3 groups: (Tier-1, Tier-2, and Tier-3). This allows us to seek for an optimal allocation to determine the optimal risk-adjusted return amongst networks for restakers.

4. Case Study: Stubchain

Using our methodology, we evaluate a Symbiotic network developed by the Symbiotic team, called Stubchain. Stubchain extends the Cosmos SDK such that shared economic security provided by Symbiotic secures the chain.

4.1. Assumptions

We make the following assumptions for the missing parts in Stubchain’s current state.

  • Slashing mechanism: VetoSlasher with a 1-week veto window

  • Resolver: A resolver committee with a moderate level of governance

  • Operators: 10 operators from the Symbiotic cohort 1 with balanced shared security

  • Owner of Middleware: A multisig account constituted of well-known node operators

4.2. Stubchain scoring

Stubchain scores well on governance (83%), but less so on software (67%) and communication (75%). The positive governance score stems from our assumption of moderate to decentralized governance of Stubchain. The lower software score is mainly due to the ongoing development of the network, with code audits in progress but not yet completed. Communication overall is scored rather low since the network is still in testnet and currently undergoing rapid changes.

Stubchain scores moderately on resolver (75%), rather well on nodes (82%), and moderate on Middleware (71%). The resolver score stems from our assumption of a resolver committee with moderate governance. Although nodes are still being actively developed and tested, extending the battle-tested Cosmos SDK helped with getting higher scoring. Relatively speaking, middleware requires more testing and audits.

We rate Stubchain as a tier-2 network given its final score (+27) and its eligibility threshold (76%). Overall, we find the slashing risk on Stubchain to be moderate, should we factor in our assumptions stated in Section 4.1. We do not identify any design factors intended to be overly aggressive towards slashing. We anticipate the scores for nodes and middleware dedicated to Stubchain to improve as the network’s implementation solidifies, audits finalized, and nodes running in production. For mainnet, we expect more structured and planned communication, which should also  increase the scores for communication.

4.5. Evaluation notes

Our main concern is in the governance and implementation of the admin account that has privileges in the Middleware. In the extreme case where the admin account is an EOA owned by a sole owner, unjustified slashing events can occur anytime to the dedicated vault. When evaluating Networks built with Stubchain, we will closely examine and monitor how the admin account is designed, implemented, and governed.

Stubchain mentions the potential slashing triggered by inactivity of nodes. This is also a concern, but to a lesser extent. This risk can be mitigated by working with operators that have a proven record of reliability. Additionally, we may require the use of replicated remote signing technologies for Cosmos SDK such as Horcrux [5], which enables a validator to remain active despite failures of some of the replicas.

5. Discussion

We discuss several directions in which our methodology can evolve, gathering feedback from Networks projects, protocols, operators, restakers, and ongoing deployment on the Holesky [6] environment. We discuss a risk methodology for evaluating & selecting  Networks, optimizing collateral diversification across LRTs taking into account the reliability of each participant.

5.1. Applying the methodology in production

Applying the methodology in production requires coordination between curators, operators, and Networks. First, we will apply our methodology, starting with the LRTs distributed by Mellow Finance [7] and Amphor applications [8].  Second, we plan to increase the number of collaborations with node operators with effective communication and interest in Symbiotic restaking. 

Third, we will work closely with network developers from Cohort 1 to collect information required for evaluating its middleware, slashing mechanism, delegators, and shared security needs. 

Ultimately, we will curate Symbiotic LRT vaults using the FullRestakeDelegator parameter to opt-in across node operators and whitelisted Networks and will ensure the maintenance of collateral allocation, following a strict diversification methodology.

Network Explorer (testnet) – Vault curation dashboard

5.2. Optimizing allocation across Networks

Although our current methodology enables us to score and rate Symbiotic Networks from the perspective of slashing risk, it falls short in optimizing the exact allocation of collaterals across multiple Networks. To address this problem, we plan to introduce a rebalancing methodology to optimize risk-adjusted returns through eligibility thresholds, coupled with an analytical approach to quantify potential yield generation from whitelisted Networks. 

We will consider the network’s utilization rate from an activity/security ratio perspective, the network’s potential scalability, the Networks’ yield distribution mechanism, its reward types, the underlying yield-bearing assets used, and more. An exciting future work would be an automated rebalancing of shared security supported by a real-time monitoring system.

5.3. Software libraries for building Networks

We anticipate that a large number of Symbiotic network developers will use a software library for building Symbiotic Networks. Without a software library, developers would need to develop a new distributed system from scratch, which is significantly time-consuming, costly, and risky. Libraries such as Stubchain (Cosmos SDK), Layer Zero DVN (bridges), and Othentic [9] could be seen as robust candidates for this matter. In terms of data availability needs, HyveDA tends to develop a validation service specifically for the Symbiotic environment.

In applying our evaluation, we can take a two-level approach where we first evaluate the software library, and then evaluate specific Networks that are built on top of the software library. This would allow us to scale the evaluation over different Symbiotic Networks using the same standards and facilitate onboarding by node delegators and vault curators.

6. Conclusion

We have presented our methodology to evaluate slashing risks of Symbiotic Networks. Our approach is opinionated and wants to be practical for the Symbiotic ecosystem. We attempt to analyze risk vectors on networks from the software, communication, and governance perspective among the different entities responsible for a Network’s viability. We are making our research public in the hope of contributing to a decentralized, transparent and secured restaking environment on Symbiotic.

7. Acknowledgments 

We thank MEV Capital and NodeInfra teams for their time on this article. Felix L. [10] from Symbiotic and Nick S. [11] from Mellow for reviewing drafts and providing insightful feedback. We also thank network projects, such as HyveDA, Primev, Stubchain, Ojo, Marlin, and others, for their valuable information on Validation services.

8. About MEV Capital and Nodeinfra

MEV Capital [12] is an EU-based investment management firm exclusively focused on DeFi, assessing risks on assets and applications deployed across EVM chains since 2021. MEV Capital is part of the first Symbiotic curator cohort, and has been one of the main economic security providers for validation services.

Nodeinfra [13] is a Korea-based node operator and part of the first Symbiotic operator cohort. The founder of Nodeinfra discovered two consensus bugs in Geth. One of these bugs led to the Ethereum hard fork on November 11, 2020. At the time, it was considered Ethereum’s most significant challenge since the DAO fork in 2016.

9. References

[1] Stubchain – github.com/symbioticfi/cosmos-sdk

[2] Middleware – github.com/symbioticfi/cosmos-sdk/tree/main/middleware

[3] SimpleMiddleware – github.com/symbioticfi/cosmos-sdk/blob/main/middleware/src/SimpleMiddleware.sol

[4] Aragon – aragon.org

[5] Horcrux – github.com/strangelove-ventures/horcrux

[6] Holesky – core/src/contracts/slasher/VetoSlasher.sol at tests · symbioticfi/core · GitHub

[7] Mellow – app.mellow.finance/vaults

[8] Amphor – app.amphor.io/earn

[9] Othentic – othentic.gitbook.io/main/introduction/use-cases

[10] Felix L. – x.com/FelixLts

[11] Nick S. – x.com/s0xn1ck

[12] MEV Capital – x.com/MEVCapital

[13] Node Infra – x.com/nodeinfra

10. Entities cluster (testnet October  – November 2024)


Institutional Investors Are Farming LRT points For Yield

Institutional Investors Are Farming LRT points For Yield

MEV Capital says liquid restaking offers market-neutral ETH yields and additional point incentives.

Find the original article on Defiant.io

Liquid restaking is not just for degens. Institutional investors are also getting in on the trade.

Gytis Trilikauskis, COO of MEV Capital, said his fund initially focused on liquidity provision, arbitrage, and MEV-based strategies, but has recently pivoted to capitalize on the booming liquid restaking token (LRT) sector.

Trilikauskis noted that MEV Capital wasn’t interested in restaking until Liquid Restaking Tokens (LRTs) gave rise to new opportunities for yield generation through DeFi composability, noting that his clients expect “at least a double-digit yield.”

Professional investors are seeking to take advantage of the yield that’s generated from liquid restaking, plus the potential airdrops many of these applications are expected to do, said Trilikauskis. It’s a sign institutions are weighing that the yield from one of the fastest growing sectors in crypto is worth the potential risk that comes from taking multiple layers of protocol and smart contracts risks.

MEV Capital, which launched in late 2020, mobilizes $160 million in assets under management on behalf of institutional clients including crypto funds, high-net-worth individuals, DAOs, and other web3 projects commanding sizable treasuries.

“What we focus on is generating more Ethereum for our clients… We just want to preserve the principle that the clients are giving us and then we want to generate them some yield.”

MEV Capital moves into liquid restaking

EigenLayer, the pioneering restaking protocol, allows users to earn additional yields on top Ethereum staking rewards by also securing third-party Actively Validated Services (AVSs) at the same time EigenLayer users can either deposit liquid staking tokens (LSTs) into its capped pools or provide natively staked Ether without limit.

Liquid restaking builds on this by offering users exposure to native restaking, with depositors receiving tokens representing their restaked position. Said LRTs can then be used in DeFi protocols to generate even more yield, or traded to bypass restaking withdrawal delays. Deposits also earn “points” — which are expected to qualify holders for future airdrops from EigenLayer and LRT providers in the future.

Trilikauskis noted that MEV Capital isn’t viewing the tokens earned through points campaigns as a long-term hodl.

“I think that we are going to liquidate significant size for sure,” he said. “We are not taking on market risk with these tokens that we farm or get dropped.”

However, Trilikauskis added that the firm will communicate with its clients to establish a “middle path” should individual clients wish to maintain exposure to native tokens airdropped by either EigenLayer or LRT providers in the future.

Trilikauskis estimates MEV Capital is among the top 10 most-active liquid restakers on the three largest LST protocols  EtherFi, Kelp DAO, and Renzo Finance, in addition to holding some smaller positions on Puffer Finance. He noted that the firm is not interested in using every possible LRT protocol, acknowledging that many DeFi protocols can expose users to significant risk.

“We try to focus on what we think are going to be the industry leaders,” Trilikauskis said.

Trilikauskis said MEV Capital is actively providing liquidity for LRTs on decentralized exchanges in addition to using Pendle, a yield tokenization platform. The team is also exploring yield optimization protocols built on top of both DEXes and Pendle to generate additional returns

“Right now, since there’s a lot of hype, and there’s a lot of narrative forming around [LRTs], protocols are actively pushing integrations that would allow you to put those LRTs in DeFi,” Trilikauskis said. “It’s getting to the point where you can say you can really see DeFi’s composability at its best, and where it can lead.” While Trilikauskis acknowledged the risks associated with restaking, he noted that several projects are working to mitigate the exacerbated slashing risks associated with EigenLayer should third-party AVSs misbehave.

“You’ll be able to preemptively withdraw your stake if these protocols start doing some nasty shit that is not confined within the ruleset,” he said. “Of course, there’s a lot of risk, but you can see how these protocols can stack on one another.”

Looking beyond LRTs

Looking ahead, Trilikauskis said MEV Capital will closely monitor the growth of EigenLayer’s AVS ecosystem for opportunity, but will also be willing to exit the sector should delta-neutral strategies no longer present themselves.

“It might still be interesting to [continue restaking on EigenLayer] and keep our LRT exposure,” he said. “But if there’s going to be more opportunities on liquid staking derivatives or ETH-based assets that are not related to EigenLayer, we will go where the opportunity is… Once EigenLayer launches, once the cat is out of the bag, then we’ll need to see how the cat looks. That’s always the case with asset management, you try to find the best risk-adjusted opportunity and go there. At this moment, it looks like EigenLayer is a clear winner.”

Find the original article on The Defiant.

DeFi points farming reshaping investment landscape

DeFi points farming reshaping investment landscape

Find the original publication at Blockworks.com

As a DeFi-focused hedge fund, MEV Capital has grown comfortable with moving funds around on-chain in pursuit of higher returns, a strategy known as yield farming. 

But in the last few months, the firm has added a new trick to its arsenal: Accruing points, or rewards for interacting with a protocol that may lead to payouts in a future token, on behalf of clients. 

MEV Capital is farming these points especially in order to gain exposure to EigenLayer and a raft of other Ethereum restaking projects offering off-chain points to on-chain users. It’s a testament to renewed animal spirits in crypto and the excitement surrounding restaking that hedge funds like MEV Capital are now acquiring participation tallies for clients.

It all points to restaking

EigenLayer is a restaking protocol that allows the staked ether securing the Ethereum blockchain to be restaked, or used to secure other Ethereum-based blockchains and services. Liquid restaking tokens (LRTs), like ether.fi’s eETH or similar offerings from KelpDAO and Renzo, create a tokenized version of restaked ether that can be used in DeFi applications. 

EigenLayer currently rewards users with points for restaking their ether, and several LRT protocols have points systems for users of the tokens.

Pendle Finance, a DeFi platform that offers tokenized versions of an asset’s APY dubbed yield tokens, has become popular for accruing points. 

Through Pendle and its yield tokens, points farmers can use an LRT to earn EigenLayer points and points from the LRT protocols simultaneously. These yield tokens give investors leveraged exposure to EigenLayer and LRT points, as they’re essentially buying the rights to the points accrual from holders of Pendle’s principal tokens. 

Points have been a very effective tool for bringing assets to the restaking sector. EigenLayer’s total value locked (TVLwas roughly $250 million on Dec. 18, according to DeFiLlama. That figure is over $9 billion today. 

Uncertain returns

Some funds are sitting out the points mania, but there’s still money to be made from the sidelines.

Valentin Mihov, who co-founded the DeFi investment fund Finexify, told Blockworks that the fund has been using Pendle to gain elevated ether yield caused by points speculation. 

Pendle’s fixed-yield products have a higher APY when the implied yield, or the market’s future estimate for yield, goes up. 

Mihov said that while the points-induced higher APY is “quite nice,” his firm finds points farming too risky because the future value of the IOUs is still mostly unclear. 

In some cases, points farming can be quite lucrative. When Solana-based liquid staking protocol Jito executed a points-based airdrop in December, for example, one researcher remarked that moving $40-worth in tokens around on-chain could have netted a user $10,000 in JTO tokens. 

As a result, points are trading in anticipation of future airdrops. Roughly $2.7 million-worth of EigenLayer points have changed hands on the website Whales Market for an average price of around $0.18. A Messari researcher tried his hand at finding an estimate and guessed LRT points to be worth roughly $0.14 apiece.

Points farming is ‘more art than science’

Since points live off-chain, how they’ll convert to token allocations can be opaque — sometimes to the disadvantage of bigger investors. 

A partner at a crypto-native investment firm told Blockworks that points are meant to bootstrap community interest in crypto projects so the tokenomic structure usually favors smaller allocations.

“The way the points typically convert [is] such that larger points farmers are usually rewarded less than smaller people, so it’s not worth putting the capital at risk in a native protocol for a very low payoff,” they said. 

Chase Mayeux, managing partner at investment firm Coral, said figuring out returns on points is more “art than science.” Coral is accumulating points on EigenLayer and a number of other DeFi protocols, Mayeux said. 

“There are secondary markets for points (Whale Market / Pendle), but ultimately, we are trying to accrue either tokens or points on protocols that we think will appreciate in price. Generally, you won’t know until months or years down the line whether you were correct in your theses,” Mayeux said in a Telegram message.

Clients of these investment firms may not understand the ins and outs of points farming, but points’ potential upside still tends to be attractive. MEV Capital general partner 

Laurent Bourquin gave the upshot of a hypothetical conversation with a client about points farming:

“‘Do we make more money? Yes, no?’

‘Yes.’

Boom then it’s good.”

Find the original article on Blockworks.com