Proof-of-stake networks have crossed a threshold. With over 30% of Ethereum's total supply now staked — representing more than $100 billion in economic security — institutional participants are no longer early adopters. They are load-bearing infrastructure. That changes the risk calculus entirely. For digital asset custodians, ETF issuers, treasury teams, and crypto-native funds, participation in validator networks is no longer primarily a question of reward optimization. It is a question of operational governance, risk architecture, and institutional accountability. This piece explains why a validator protection layer — a defined set of operational, technical, and governance safeguards — is no longer optional for institutions operating at scale in proof-of-stake environments.
If You Only Have Two Minutes
This article is the first in the Institutional Lens series, which unpacks protocol mechanics and infrastructure decisions for institutional participants in proof-of-stake networks.
What a protection layer actually means operationally
The governance and capital implications of getting it wrong
What to look for in a validator infrastructure partner
Who This Is For
This article is written for professionals operating at the intersection of institutional finance and blockchain infrastructure. Specifically:
Digital asset custodians managing staked positions on behalf of clients
ETF and ETP issuers with staking-enabled products or pending approvals
Crypto-native funds and treasury teams with direct validator exposure
Staking product managers and validator risk committees assessing partner infrastructure
Infrastructure engineers responsible for validator operations and key security
If you are deploying, managing, or overseeing significant staked capital in proof-of-stake networks, the risk dynamics described here are directly relevant to your operational posture.
The Institutional Inflection Point
Institutional participation in proof-of-stake networks has moved from exploratory to structural. Between January and June 2025, the amount of staked ETH rose from 34 million to 35.3 million, reaching approximately 29% of the total supply (CoinLaw). By early 2026, that figure had crossed 30%: a milestone that reflects not just retail participation, but deep institutional commitment.
Institutional funds currently hold approximately 3.3 million ETH, so around 3% of the circulating supply, through exchange-traded funds alone. With staking ratios already above 27%, ETF staking approvals alone could increase total staked ETH by more than 10% (CoinDesk).
This is no longer a niche phenomenon. Banks, asset managers, hedge funds, pension funds, venture capital firms, and centralized exchanges have all entered the sector. Staking solutions designed specifically for professional investors have gained significant momentum, shaping a distinct vertical now known as staking-as-a-service (CoinShares).
The regulatory backdrop has also shifted decisively. In Europe, the MiCA framework provides clear operational and compliance requirements for regulated entities. In the United States, the SEC's August 2025 decision not to classify liquid staking as a security removed one of the main legal obstacles for large allocators. The IRS subsequently issued new guidance providing a clear path for trusts to stake digital assets without jeopardizing their tax status (CoinShares)
All of these points to the same structural reality: institutional capital is now deeply embedded in proof-of-stake infrastructure. And with that comes a risk exposure that did not exist at scale before.
What Risk Actually Looks Like at Institutional Scale
The risks of validator participation are protocol-defined and well-understood. What changes at institutional scale is the magnitude of consequence.
Slashing: Rare, But Asymmetric
Slashing is the protocol-level penalty applied when a validator behaves in ways that threaten network integrity, primarily double-signing or prolonged inactivity. Historical data shows that only 0.03% of all Ethereum validators have ever been slashed since staking launched in December 2020. Of those, the largest realized loss was approximately 3% of staked capital (iShares).
Low frequency does not mean low consequence. In September 2025, 39 validators were slashed in one of the largest correlated slashing events since Ethereum's transition to proof-of-stake. The incident was traced to operator-side infrastructure issues involving third-party staking providers (CoinDesk). What began as an operational failure at the infrastructure layer resulted in compounded penalties — because when multiple validators are slashed simultaneously, Ethereum's protocol enforces additional inactivity leaks that amplify the financial impact.
For an institution managing hundreds of millions in staked capital, a correlated slashing event is not a theoretical scenario. It is a risk that must be engineered around.
Operational and Key Security Risk
Institutions that run their own validators or manage staking operations in-house may face challenges in securely managing private keys, validator operations, rewards tracking, and protocol upgrades. These processes require specialized infrastructure and consistent operational uptime, introducing technical complexity and potential security vulnerabilities if operators lack deep experience (Coinbase).
Validator key compromise, while rare, carries consequences that extend well beyond the immediate staking position. A compromised key is an operational incident, a governance incident, and potentially a regulatory disclosure event, all at once.
Liquidity and Lock-Up Risk
Staked ETH is less liquid than unstaked capital. Withdrawal timelines are variable depending on network conditions, particularly the number of validators attempting to exit simultaneously. Under normal conditions, withdrawals take several days. During periods of elevated activity, delays can extend to weeks or longer (iShares).
For treasury teams and ETF issuers managing redemption obligations alongside staked positions, liquidity risk is not abstract. It is a balance sheet constraint.
What a Protection Layer Actually Means
The term "protection layer" is deliberately structural. It describes a set of architectural, operational, and governance decisions that sit between an institution's capital and the protocol-level risks described above. It is not a product. It is a design posture.
Diagram showing the four layers of a validator protection layer stack: governance and accountability, reporting and auditability, slashing risk controls, and infrastructure architecture, sitting between institutional capital and protocol-defined risk.
A meaningful protection layer has four components:
1. Infrastructure Architecture
The foundation of any protection layer is how the validator infrastructure is built. Institutions should only partner with providers that maintain validators across multiple regions, operating in independent data centers with geographic diversity, multiple client implementations, and dedicated fallback systems (Aetsoft). Single points of failure at the infrastructure layer are unacceptable at institutional scale.
Distributed validator technology (DVT) is increasingly relevant here. By splitting validator key operations across multiple independent operators, DVT reduces the risk of any single infrastructure failure triggering a slashing event — and reduces key compromise risk structurally, not just procedurally. P2P.org's DVT staking infrastructure is built specifically around this architecture for institutional participants.
2. Slashing Risk Mitigation Protocols
Anti-slashing measures must be built into the validator operation itself, not bolted on afterward. This means enforced key signing controls that prevent double-signing under any operational circumstance, automated failover logic that prioritizes safety over liveness, and real-time monitoring of validator status with immediate alerting.
Providers should offer real-time dashboards, alerting tools, and analytics that track validator performance, slashing events, network participation, and reward flow (Aetsoft). Observability is not optional. It is the operational nervous system of a well-governed staking program.
3. Governance and Accountability Structures
For institutions, governance means documented decision rights, audit trails, and clear accountability for validator operations. Who has the authority to initiate an exit? What is the incident response procedure for a slashing event? How are protocol upgrades evaluated and applied?
As institutional capital flows into proof-of-stake networks, concerns about operational governance highlight the importance of resilient infrastructure, transparent risk controls, and adherence to high compliance standards across staking providers (CoinShares). These are not preferences; they are due diligence requirements that institutional risk committees and investor disclosure obligations demand.
4. Reporting and Auditability
Institutional staking programs require reward attribution at the protocol level, disaggregated by validator and by period, in formats compatible with internal risk systems and external audit requirements. This is not a feature. It is an operational necessity for any entity subject to financial reporting obligations.
Beyond operational risk, there is a deeper question that institutional participants in proof-of-stake networks often underestimate: governance rights.
Staking is not passive. In many proof-of-stake protocols, validators and delegators participate in governance decisions — protocol upgrades, parameter changes, treasury allocations. At the scale of institutional participation now entering these networks, staking infrastructure decisions are governance decisions.
Staking enables institutions to actively participate in the networks they hold, contributing to consensus and security. In many proof-of-stake protocols, stakers gain governance rights, enabling them to vote on protocol upgrades, policy changes, and treasury allocations. This influence can be strategically valuable, allowing institutions to help shape network direction (Coinbase).
For institutional participants with fiduciary obligations like ETF issuers, custodians, fund managers, this creates a new category of governance responsibility. The validator infrastructure partner an institution selects is not just an operational vendor. It is a governance representative.
Validator Partner Evaluation: What Institutions Should Be Asking
Selecting a validator infrastructure partner is a risk management decision. The relevant questions are not primarily commercial. They are operational and architectural.
Key areas of evaluation:
Infrastructure design: Is the validator infrastructure geographically distributed? Are multiple client implementations supported? What are the failover protocols?
Slashing risk controls: What technical controls prevent double-signing? How are signing key operations secured and access-controlled?
Incident history: Has the operator experienced slashing events? What was the root cause, and what architectural changes followed?
DVT adoption: Does the operator support or plan to support distributed validator technology for key distribution?
Reporting capabilities: Can the operator provide reward-attribution data at the validator level, in formats compatible with institutional reporting requirements?
Protocol alignment: How does the operator evaluate and respond to protocol upgrades? Is there a documented governance participation policy?
Due Diligence Checklist
For validator risk committees, compliance teams, and digital asset managers assessing staking infrastructure partners:
[ ] Validator infrastructure is geographically distributed across independent data centers
[ ] Multiple consensus client implementations are supported (client diversity)
[ ] Anti-double-signing controls are enforced at the key management level
[ ] Automated failover logic prioritizes safety over liveness
[ ] Real-time monitoring and alerting for validator performance and anomalies
[ ] Documented incident response procedure for slashing events
[ ] Audit trail for all validator key operations and access events
[ ] Reward reporting at validator level, compatible with institutional accounting requirements
[ ] Documented governance participation policy for protocol upgrades
[ ] SLA is framed around operational practices, not performance guarantees, so in line with protocol-defined outcomes
[ ] No custody of client assets (non-custodial architecture confirmed)
FAQ
What is a validator protection layer?
A validator protection layer refers to the combination of infrastructure architecture, operational controls, and governance frameworks that an institution or its validator infrastructure partner deploys to manage the protocol-defined risks of staking participation. It is not a product but a design posture that encompasses distributed infrastructure, anti-slashing controls, key security, incident response protocols, and institutional-grade reporting.
How often does slashing actually occur on Ethereum?
Slashing on Ethereum is rare. Historical data indicates that fewer than 0.03% of all validators have been slashed since the Beacon Chain launched in December 2020. However, correlated slashing events where multiple validators are penalized simultaneously carry amplified penalties due to Ethereum's inactivity leak mechanism. For institutions managing large staked positions, the tail risk of a correlated event is the relevant risk to engineer around, not the average frequency.
Are slashing risks eliminated by using a third-party validator provider?
No. Slashing risks are protocol-defined and client-borne. A validator infrastructure provider can implement robust controls that reduce the likelihood of slashing events through anti-double-signing logic, distributed key management, and high-availability infrastructure, but cannot eliminate protocol-level risk. Institutions should evaluate the quality of a provider's risk controls rather than expecting guarantees.
What is the difference between operational risk and slashing risk in staking?
Slashing is a specific protocol penalty triggered by defined validator misbehaviors, primarily double-signing. Operational risk is broader. It encompasses validator downtime, key management failures, infrastructure outages, and human errors that may result in missed rewards, delayed withdrawals, or, in severe cases, conditions that trigger slashing. A protection layer addresses both categories.
How does validator infrastructure selection affect governance participation?
In many proof-of-stake protocols, validators participate in governance decisions including protocol upgrades and parameter changes. Institutions delegating to a validator provider are, in effect, delegating governance participation. This creates a fiduciary dimension to infrastructure selection that risk committees and compliance teams should account for explicitly.
What should institutions look for in staking reporting capabilities?
Institutional staking programs require reward attribution at the protocol level, disaggregated by validator and period, in formats compatible with internal risk management systems and external audit requirements. Providers should be able to demonstrate reporting capabilities before onboarding, not describe them as a future roadmap item.
Key Takeaway
For digital asset custodians, ETF issuers, treasury teams, and crypto-native funds operating in proof-of-stake networks, the validator infrastructure decision is no longer an operational afterthought. It is a risk management and governance decision with direct capital implications. A protection layer built from distributed infrastructure, enforced anti-slashing controls, non-custodial architecture, and institutional-grade reporting is the baseline expectation for any entity with fiduciary obligations and material staked positions. The question is not whether to implement one. It is whether your current infrastructure partner is actually providing one.
Protocol-generated rewards are determined by network conditions and are variable. P2P does not control or set reward rates. Slashing risks are protocol-defined and client-borne.
Subscribe to P2P-economy
Get the latest posts delivered right to your inbox
<p>A publicly listed Japanese company is now running Ethereum validators through a DVT-based infrastructure stack. For institutional staking, that's a meaningful signal.</p><p>P2P.org has joined a four-party collaboration with BITPOINT Japan, Def consulting, and SSV Labs to support Def consulting's Ethereum treasury strategy — a framework in which ETH is held on the corporate balance sheet and participates in Ethereum network validation and receives protocol-level staking rewards. P2P.org handles validator operations; SSV Labs contributes its Distributed Validator Technology protocol; BITPOINT provides the trading and custody infrastructure that ties the structure together.</p><h2 id="the-setup"><strong>The Setup</strong></h2><p>Def consulting's approach — treating ETH as <strong>an operational treasury asset </strong>rather than a speculative holding — reflects a broader shift in how institutional players think about digital assets. Staking turns a passive balance sheet position into an active revenue line. DVT, layered on top, addresses the operational risk that has historically made institutions hesitant to run validator infrastructure at scale.</p><p>The mechanics are straightforward. Distributed Validator Technology splits validator key management and signing duties across multiple independent nodes. <strong>This design distributes validator responsibilities across multiple nodes, reducing reliance on any single operator. </strong>For a corporate treasury with fiduciary obligations, that resilience matters as much as the rewards. SSV Network's incentive program provides additional network incentives associated with SSV-enabled validator participation without changing the operational model.</p><h2 id="p2porgs-role"><strong>P2P.org's Role</strong></h2><p>P2P.org operates as a certified SSV Network operator — we've been running DVT-based validator infrastructure for institutional clients globally before this collaboration. Bringing that capability to the Japanese market, through BITPOINT's infrastructure and Def consulting's operational framework, is a concrete extension of that work.</p><p>As Konstantin Zaitcev, Co-CEO of P2P.org, noted:</p><p>"Deploying this technology and our operational expertise for corporate clients in Japan marks an important milestone for us. We believe this initiative will serve as a foundation for expanding the adoption of staking in the Japanese market."</p><p>Our mandate here is the same as it is across all institutional deployments:<strong> </strong>operate validator infrastructure with strong operational monitoring and reliability standards<strong>, and build the kind of track record that helps institutional participants evaluate staking infrastructure as part of their digital asset operations.</strong></p><h2 id="a-template-for-regulated-markets"><strong>A Template for Regulated Markets</strong></h2><p>The Japanese market has been deliberate about digital asset adoption — which is precisely why this collaboration carries weight. When a listed company formalizes ETH staking as part of its treasury strategy, backed by DVT infrastructure and a regulated exchange partner, it creates a replicable model that other corporate treasuries in the region can evaluate.</p><p>The four-party structure here — trading infrastructure, validator operations, DVT protocol, and a defined corporate ETH strategy — is a working template for how institutional staking gets built in regulated markets. It won't be the last time we see this model.</p><h2 id="start-staking-with-p2porg"><strong>Start Staking with P2P.org</strong></h2><p>If you're exploring ETH staking for your treasury or institutional portfolio, we'd be happy to walk you through how it works in practice — infrastructure, security model, reporting, and all.</p><p>Get in touch with our institutional team → <a href="https://link.p2p.org/3325c6?ref=p2p.org">https://link.p2p.org/3325c6</a></p><p>Learn more about ETH staking: <u> </u><a href="https://link.p2p.org/e3a57d?ref=p2p.org">https://link.p2p.org/e3a57d</a> </p>
<h2 id="intro">Intro</h2><p>Every Solana transaction sender promises speed. Few explain where that speed actually comes from.</p><p>Solana transaction landing is about speed. But speed is not just how fast a transaction is sent. It depends on how transactions are routed through staked validator paths that give your flow priority bandwidth to the block leader, before competing with everyone else.</p><p>The difference is not small. It determines whether a transaction lands or misses entirely.</p><h2 id="the-hidden-bottleneck-behind-solana-transaction-landing">The Hidden Bottleneck Behind Solana Transaction Landing</h2><p>When a transaction is submitted on Solana, it is sent toward the block leader. But how it gets there determines whether it lands.</p><p>Transactions are forwarded by RPC nodes to the current and upcoming leaders via TPU and QUIC. However, routing conditions such as bandwidth, prioritization, and connection quality define the result.</p><p>Two transactions submitted at the same time can produce very different outcomes depending on how they are routed.</p><p>This is where Solana transaction landing performance is decided.</p><h2 id="why-public-rpc-infrastructure-limits-solana-transaction-landing">Why Public RPC Infrastructure Limits Solana Transaction Landing</h2><p>Public RPC endpoints are designed for accessibility, not execution performance. They introduce structural limitations that affect Solana transaction landing speed.</p><h3 id="1-limited-routing-paths">1. Limited routing paths</h3><p>Public RPC nodes forward transactions to leaders, but through a constrained set of routes. If those paths are congested, transactions arrive later than competing flow.</p><h3 id="2-shared-infrastructure">2. Shared infrastructure</h3><p>Traffic from thousands of users competes for the same resources. There is no prioritization for execution-critical transactions.</p><h3 id="3-unstaked-bandwidth">3. Unstaked bandwidth</h3><p>Public RPC nodes forward transactions through connections without stake backed priority. This limits bandwidth and increases delays during periods of high demand.</p><p>For general usage, this is sufficient. For trading, arbitrage, and liquidations, this becomes a limiting factor.</p><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://p2p.org/economy/content/images/2026/03/solana-transaction-landing-routing-vs-rpc.png" class="kg-image" alt="Solana transaction landing comparison between RPC single path and multi path validator routing" loading="lazy" width="1536" height="1024" srcset="https://p2p.org/economy/content/images/size/w600/2026/03/solana-transaction-landing-routing-vs-rpc.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/03/solana-transaction-landing-routing-vs-rpc.png 1000w, https://p2p.org/economy/content/images/2026/03/solana-transaction-landing-routing-vs-rpc.png 1536w" sizes="(min-width: 720px) 720px"><figcaption><span style="white-space: pre-wrap;">Solana transaction landing comparison between RPC single path and multi path validator routing</span></figcaption></figure><h2 id="solana-transaction-landing-speed-comes-from-routing">Solana Transaction Landing Speed Comes From Routing</h2><p>The key idea is simple.</p><p>Solana transaction landing speed is determined by routing, not just submission latency. Infrastructure must:</p><ul><li>route through high-priority paths</li><li>reduce contention with shared traffic</li><li>reach the leader through optimal connections</li><li>increase delivery probability under congestion</li></ul><p>This is a network design problem. Not an API problem.</p><h2 id="stake-weighted-qos-and-priority-access">Stake Weighted QoS and Priority Access</h2><p>Solana includes <a href="https://solana.com/developers/guides/advanced/stake-weighted-qos?ref=p2p.org">Stake Weighted Quality of Service (SWQoS)</a>, a mechanism that prioritizes traffic based on validator stake.</p><p>In practice:</p><ul><li>staked connections receive priority bandwidth</li><li>transactions routed through them reach validators faster</li><li>during congestion, this advantage becomes decisive</li></ul><p>SWQoS is a critical factor in Solana transaction landing, especially for execution focused teams. Transactions submitted through unstaked public RPCs compete at a structural disadvantage.</p><h2 id="network-proximity-and-transaction-landing">Network Proximity and Transaction Landing</h2><p>Latency still matters, but not only in geographic terms. Network proximity defines performance:</p><ul><li>direct validator connections</li><li>optimized routing paths</li><li>fewer intermediaries</li></ul><p>Even small differences in latency can determine whether a transaction lands in the first slot or misses the opportunity entirely. Learn more about how <a href="https://docs.solanalabs.com/validator/anatomy?ref=p2p.org">Solana's validator architecture</a> affects transaction delivery.</p><h2 id="multi-path-routing-and-execution-reliability">Multi-Path Routing and Execution Reliability</h2><p>Relying on a single route assumes that the path will succeed. In practice, this is not reliable.</p><p>Multi-path routing improves Solana transaction landing by sending transactions through multiple routes simultaneously:</p><ul><li>current leader</li><li>upcoming leader</li><li>validator level paths</li><li>fallback connections</li></ul><p>The first successful path determines the outcome. This improves consistency and landing probability, especially during congestion.</p><h2 id="from-infrastructure-to-execution-results">From Infrastructure to Execution Results</h2><p>Improving Solana transaction landing requires a Solana sender built with the right infrastructure: one that uses Stake Weighted QoS-enabled paths, routes through validator-level connections, minimizes delays and contention, and supports multi-path delivery.</p><p>Without this, execution strategies are limited by infrastructure performance. <a href="https://www.p2p.org/products/syncro-solana-transaction-sender?ref=p2p.org">Syncro Sender</a> is a Solana sender built specifically for execution critical workflows, using validator-level routing and multi-path delivery to reach the block leader first.</p><p>For a deeper look at how it works, see the <a href="https://p2p.org/economy/solana-transaction-landing-syncro-sender/">Syncro Sender overview</a>.</p><h2 id="what-teams-should-measure-instead">What Teams Should Measure Instead</h2><p>For execution focused teams, this changes how infrastructure should be evaluated.</p><p>Instead of asking: How fast is the endpoint?</p><p>The better question is: How are transactions routed, and do they have priority access?</p><h2 id="apply-this-to-your-own-transaction-flow">Apply This to Your Own Transaction Flow</h2><p>If you are running execution critical workflows on Solana, speed is only part of the equation. The real question is how that speed is achieved.</p><p>Test <a href="https://www.p2p.org/products/syncro-solana-transaction-sender?ref=p2p.org">Syncro Sender</a> alongside your current setup and compare Solana transaction landing performance using real transaction flow. You can get started in minutes via the <a href="https://docs.p2p.org/docs/syncro-sender-quick-start?ref=p2p.org">quick start documentation</a>.</p><h2 id="takeaway">Takeaway</h2><p>On Solana, speed defines execution.</p><p>But speed does not come from sending faster.</p><p>It comes from routing smarter.</p><p>That is what defines Solana transaction landing.</p><h1 id="faq-section">FAQ Section</h1><h2 id="what-is-the-solana-transaction-landing">What is the Solana transaction landing?</h2><p>Solana transaction landing refers to whether a submitted transaction successfully reaches the block leader and is included in a block. It is the key metric that determines execution success on Solana.</p><h2 id="why-do-solana-transactions-fail-to-land">Why do Solana transactions fail to land?</h2><p>Solana transactions fail to land when they arrive too late to the block leader or lose priority against competing transactions. This is often caused by congestion, limited routing paths, or insufficient priority bandwidth.</p><h2 id="what-affects-solana-transaction-landing-speed">What affects Solana transaction landing speed?</h2><p>Solana transaction landing speed is affected by routing paths, validator connections, network congestion, and whether the transaction is sent through a Solana sender with Stake Weighted QoS-enabled infrastructure.</p><h2 id="does-public-rpc-affect-transaction-landing-on-solana">Does public RPC affect transaction landing on Solana?</h2><p>Yes. Public RPC infrastructure can limit Solana transaction landing performance due to shared bandwidth, limited routing paths, and a lack of stake-backed priority connections.</p><h2 id="what-is-stake-weighted-qos-in-solana">What is Stake-Weighted QoS in Solana?</h2><p>Stake-weighted Quality of Service is a mechanism that prioritizes traffic based on validator stake. Transactions routed through staked connections receive higher priority and are more likely to reach the block leader faster.</p><h2 id="why-is-routing-important-for-solana-transaction-landing">Why is routing important for Solana transaction landing?</h2><p>Routing determines how quickly and reliably a transaction reaches the block leader. Even if two transactions are submitted simultaneously, the one with the better routing will be processed first.</p><h2 id="what-is-multi-path-routing-in-solana">What is multi-path routing in Solana?</h2><p>Multi-path routing is the practice of sending a transaction through multiple validator routes simultaneously. This increases the probability that at least one path reaches the leader early.</p><h2 id="how-can-i-improve-solana-transaction-landing-performance">How can I improve Solana transaction landing performance?</h2><p>To improve Solana transaction landing, use a Solana sender that provides validator-level routing, stake-weighted QoS access, optimized network proximity, and multi-path delivery, such as <a href="https://www.p2p.org/products/syncro-solana-transaction-sender?ref=p2p.org">Syncro Sender by P2P.org</a>.</p>
ALL
Agoric
Aptos
Auth
Avail
Avalanche
Axelar
Babylon
Bitcoin
BTC
Cardano
Celestia
Chainlink
Cosmos
Crescent
Cyberway
DAOBet
DeFi
DVT
Dymension
Economy
Education
EigenLayer
Elrond
Ethereum
Evmos
Explain Like I'm Five
Guide
HR
infrastructure
Kava
Kusama
Lido
LSP
Manta
Mantle
Marlin
Matic
Moonbeam
MultiversX
Near
News
NuCypher
Oasis
Origin
Partnership
Persistence
playbook
Pocket
Polkadot
Polygon
products
Quicksilver
Regen
Renzo
restaking
RPC Node
Sender
Serum
slashing
Solana
SSV.Network
Staking
Starknet
Sui
symbiotic
Syncro
syncro sender
Terra
Tezos
TheGraph
Threshold
Update
validator
Vara
Vega
