Ledger Enterprise staking goes live with P2P.org for SOL, XTZ, and ADA

<p>If you have ever wondered why some trading teams on Sui and Hyperliquid consistently see on-chain data before others, the answer is usually the same: they are not consuming from a public endpoint. They are consuming from a validator data stream.</p><p>This post explains what a validator data stream is, how it works technically, and what to look for when evaluating providers. Less pitch, more architecture. For teams where data latency is a direct trading-outcome concern, the infrastructure layer is worth understanding clearly.</p><h2 id="what-is-a-validator-data-stream">What is a validator data stream?</h2><p>A validator data stream is a real-time feed of on-chain data sourced directly from a validator node, delivered to subscribers before that data propagates to public infrastructure.</p><p>To understand why this matters, it helps to understand what a validator actually does. Validators are the nodes responsible for processing transactions and producing blocks. They are the first point of contact for new on-chain activity. Before a transaction appears in a public checkpoint, before it reaches a shared RPC endpoint, before any downstream service sees it, the validator has already processed it.</p><p>A validator data stream taps into that processing at the earliest possible point. Rather than waiting for data to travel through the network and become available to public consumers, a subscriber receives it directly from the validator the moment it is processed.</p><p>The result is a structural latency advantage. Not an optimized version of the same architecture. A different position in the data delivery chain.</p><h2 id="how-do-public-rpcs-and-checkpoints-work">How do public RPCs and checkpoints work?</h2><p>To appreciate what a validator data stream delivers, it is worth understanding the alternative clearly.</p><p>When a trading team consumes data through a public RPC endpoint, they are consuming data that has already completed a significant journey. A validator processes a transaction. That transaction propagates through the network via gossip. Other nodes receive and validate it. It is included in a block. The block is finalized and published. A checkpoint is created. The checkpoint becomes available through public RPC infrastructure.</p><p>Each of those steps takes time. On Sui, public checkpoints reflect the network state after finalization, not at certificate processing. On Hyperliquid, the public API delivers order book snapshots at approximately 260 ms* from block creation, rate-limited to 100 requests per minute*.</p><p>Shared RPC infrastructure adds further latency on top of network propagation. Public endpoints serve many clients simultaneously. Under load, queuing and rate limiting compound the delay. A team consuming from a public endpoint during peak activity is not just delayed by network propagation. They are delayed by everyone else using the same pipe simultaneously.</p><p>For most applications, this is acceptable. For execution-critical trading, it is not.</p><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://p2p.org/economy/content/images/2026/06/custodian-defi-vault-infrastructure-stack--2--1.jpg" class="kg-image" alt="Two parallel flowcharts comparing the public RPC data journey and the validator data stream path. The public path shows five hops through network propagation, other nodes, block finalization, and a shared RPC endpoint before reaching the subscriber. The validator data stream path shows one hop from the validator through a dedicated WebSocket directly to the subscriber." loading="lazy" width="1600" height="565" srcset="https://p2p.org/economy/content/images/size/w600/2026/06/custodian-defi-vault-infrastructure-stack--2--1.jpg 600w, https://p2p.org/economy/content/images/size/w1000/2026/06/custodian-defi-vault-infrastructure-stack--2--1.jpg 1000w, https://p2p.org/economy/content/images/2026/06/custodian-defi-vault-infrastructure-stack--2--1.jpg 1600w" sizes="(min-width: 720px) 720px"><figcaption><i><em class="italic" style="white-space: pre-wrap;">The public RPC path adds five hops between the validator and your systems. A validator data stream reduces that to one.</em></i></figcaption></figure><h2 id="how-does-a-validator-data-stream-work-differently">How does a validator data stream work differently?</h2><p>A validator data stream bypasses the propagation and shared infrastructure layers entirely by sourcing data at the point of origin.</p><p>The architecture varies slightly by network, but the core principle is consistent. The data stream runs directly on or adjacent to an active validator node. Data is captured as the validator processes it, before it enters the public propagation path, and delivered to the subscriber over a dedicated WebSocket connection with isolated credentials and IP-based access controls.</p><p>On Sui, this means capturing transaction events at certificate processing. This is the stage at which the validator has processed the transaction, but before it has been confirmed and published to the broader network. Two streaming endpoints are typically available: one covering pending transactions as they are processed, and one covering accepted transactions received from other validators before consensus. The result is the delivery approximately 15* ms ahead of public checkpoints.</p><p>On Hyperliquid, the architecture goes one step further. The data path runs from an active validator to dedicated private sentry infrastructure. The sentry node peers with the validator over a private network, receiving block data before it propagates through public gossip. Critically, the sentry reads data directly from the validator's internal output, before it passes through the node API, rather than consuming it through the node’s internal API. This eliminates an additional latency layer inherent to API-based delivery, where internal call overhead sits between the data being written and the data being sent. The result is delivery of full order flow within 115 to 135* ms of block creation.</p><p>In both cases, each subscriber receives a dedicated connection. There is no shared infrastructure, no queuing behind other clients, and no rate limiting that degrades performance under load.</p><h2 id="what-data-does-a-validator-data-stream-deliver">What data does a validator data stream deliver?</h2><p>The data surface available through a validator data stream is also meaningfully different from what public endpoints provide.</p><p>Public RPCs typically deliver snapshots: the state of the chain at a given point in time, available on request. They are built for read access, not for streaming. They do not deliver continuous event feeds, and they do not provide the granular per-event data that execution-critical strategies require.</p><p>A validator data stream delivers a continuous real-time feed of on-chain events as they occur. On Sui, this means transaction events at the moment of processing, with deduplication handled on-node. On Hyperliquid, this means the full order flow surface: every order across every asset, with order ID, side, price, quantity, status, and user attribution. Block events with height, timestamp, and apply duration. System metrics and heartbeat data on a dedicated channel, separated from the market data path so operational signals do not interfere with trading logic.</p><p>The user attribution component deserves particular attention. Aggregated public feeds do not identify the counterparty behind each order. A validator data stream that delivers user-attributed order flow enables counterparty modelling and signal research that is difficult to achieve on snapshot-based infrastructure. This is not a performance improvement. It is a meaningfully different class of data.</p><h2 id="why-does-the-infrastructure-layer-matter-for-trading-teams">Why does the infrastructure layer matter for trading teams?</h2><p>The trading infrastructure stack is usually discussed at the strategy and execution layer. What signals to act on? How to route orders. How to manage risk. The data layer is assumed to be a solved problem.</p><p>It is not.</p><p>The data layer determines what information is available, when it is available, and how complete it is. A strategy built on public endpoint data is constrained by the latency and completeness of that data. It is limited to acting on what has already surfaced, and to modelling counterparties it can identify. It cannot benchmark its latency because it has no faster feed to compare against.</p><p>A validator data stream changes all three constraints simultaneously. It delivers data earlier, more completely, and with attribution that public feeds do not provide.</p><p>For MEV searchers on Sui, earlier data means seeing opportunities while they are still open rather than after faster teams have closed them. For market makers on Hyperliquid, earlier and more complete data means quoting on the current state rather than the state that is already 200* ms old. For quant funds building signal pipelines, user-attributed order flow means modelling approaches that were previously unavailable.</p><p>None of these teams need to rebuild their strategies. They need to change where the data comes from.</p><h2 id="how-to-evaluate-a-validator-data-stream">How to evaluate a validator data stream?</h2><p>Not all validator data streams are equal. A few things are worth checking before committing to a provider.</p><p>The first is whether the provider actually operates an active validator on the network in question. Some feeds marketed as validator-grade may actually route through third-party nodes. The latency advantage comes specifically from being on the validator itself, not from proximity to one. Confirm the provider operates an active validator on the relevant network before evaluating anything else.</p><p>The second is the delivery architecture. For Hyperliquid specifically, the way data is captured and delivered at the node level has a meaningful impact on latency. Architectures that minimise internal overhead between data being written and data being delivered will have an advantage at the node level. It is worth asking providers specifically how their data is captured and delivered from the validator.</p><p>The third is the operational model. A dedicated endpoint with isolated credentials and IP allowlisting is not just a security feature. It means your latency is not affected by other clients consuming the same stream. A shared endpoint, however fast the validator, reintroduces the queuing problem that public infrastructure creates.</p><p>Finally, the benchmark. Any serious validator data stream provider should offer a free trial specifically designed to let you run their feed alongside your existing setup and measure the gap directly. If the latency advantage is real, the benchmark will show it.</p><h2 id="further-reading">Further reading</h2><p>For a broader look at why on-chain data latency is a business problem rather than a technical one, read <a href="about:blank#">The Hidden Cost of On-Chain Data Latency on Sui and Hyperliquid</a>.</p><p>For a full overview of what Syncro Data Stream delivers and how it is built, read the <a href="about:blank#">launch post</a>.</p><p>Full technical documentation is available at <a href="https://docs.p2p.org/?ref=p2p.org">docs.p2p.org</a>.</p><p>To get started with Syncro Data Stream for Sui, visit the <a href="about:blank#">Syncro Data Stream Sui page</a>.</p><p>To get started with Syncro Data Stream for Hyperliquid, visit the <a href="about:blank#">Syncro Data Stream Hyperliquid page</a>.</p><hr><h2 id="about-p2porg">About P2P.org</h2><p>P2P.org has operated blockchain infrastructure since 2018 across 40+ proof-of-stake networks, serving 190+ institutional partners. Syncro is P2P.org’s crypto trading infrastructure product line, built on active validator nodes across Solana, Sui, and Hyperliquid.</p><hr><h2 id="disclaimer">Disclaimer</h2><p>This material is provided for informational purposes only and does not constitute investment, financial, legal, or tax advice. P2P.org accepts no liability for any actions taken based on it. Latency and performance figures referenced are estimates based on internal benchmarks and may vary depending on network conditions, geography, and client infrastructure. Past performance is not indicative of future results.</p>

<hr><h2 id="series-institutional-lens"><strong>Series:</strong> Institutional Lens</h2><p>The Institutional Lens series examines protocol mechanics, infrastructure decisions, and governance considerations for institutions participating in proof-of-stake networks. It is written for professionals operating at the intersection of traditional finance and blockchain infrastructure.</p><p><strong>Previously in the series:</strong> <a href="https://p2p.org/economy/how-to-build-an-institutional-staking-program-across-multiple-networks/">How to Build an Institutional Staking Program Across Multiple Networks</a></p><hr><h2 id="learnings-for-busy-readers">Learnings for Busy Readers</h2><p>Article 3 in this series established the framework for designing a multi-network institutional staking program. This article addresses the governance layer that the program creates.</p><p>Most institutions have a policy for how they vote their equity holdings. Almost none have a policy for how they govern their staked network positions. That gap is closing, and closing fast.</p><p>Here is what this article covers and why it matters now:</p><ul><li>When you stake on a proof-of-stake network, you typically acquire governance rights over that network. Those rights do not disappear because you did not ask for them.</li><li>Governance models differ materially across networks. On Cosmos, delegators vote independently of their validators. On Polkadot, staking and governance are structurally separate. On Ethereum, governance is off-chain and informal. These differences require network-specific policies, not a single blanket approach.</li><li>Governance decisions on PoS networks are consequential. In March 2026, Polkadot token holders voted to cut annual issuance by 53.6% and set a hard supply cap for the first time. Every institutional DOT holder was affected. Governance is not a theoretical concern.</li><li>For custodians managing assets on behalf of clients, ETF issuers with staking-integrated products, and regulated funds with fiduciary obligations, undocumented governance participation is an operational and compliance gap.</li><li>The practical path forward is a documented governance participation policy that covers every network in the program and is calibrated to each network's governance model.</li></ul><h2 id="why-staking-governance-rights-are-an-institutional-issue-now">Why Staking Governance Rights Are an Institutional Issue Now</h2><p>For most of the history of institutional participation in crypto, governance was a secondary concern. Institutions held Bitcoin, which has no formal governance mechanism. When they moved into Ethereum, governance was informal and off-chain, requiring no direct action from holders. The governance question was easy to defer.</p><p>That deferral is no longer sustainable for three reasons.</p><h3 id="first-the-asset-universe-has-expanded">First, the asset universe has expanded.</h3><p>The March 17, 2026, joint interpretive release by the SEC and CFTC classified 16 digital assets as commodities, removing the legal barrier that had restricted most institutional staking programs to Ethereum. Institutions are now building staking programs across Solana, Polkadot, Cosmos, Cardano, and other networks. Every one of those networks has a governance system. In many proof-of-stake protocols, stakers gain governance rights, enabling them to vote on protocol upgrades, policy changes, and treasury allocations. For institutional participants with fiduciary obligations, this creates a new category of governance responsibility.</p><h3 id="second-governance-decisions-are-financially-consequential">Second, governance decisions are financially consequential.</h3><p>This is no longer a theoretical point. In March 2026, via OpenGov referendums, Polkadot cut annual DOT issuance by 53.6%, reducing it from roughly 120 million to 55 million DOT per year. A hard supply cap of 2.1 billion DOT was set for the first time. That decision was made by token holders exercising governance rights. Institutions that held staked DOT were affected whether they participated in the vote or not. Abstaining from governance does not mean being exempt from its outcomes.</p><h3 id="third-fiduciary-standards-are-evolving">Third, fiduciary standards are evolving.</h3><p>In 2026, governance tokens are attracting significant attention from traditional finance. Major asset managers have begun acquiring governance tokens at scale to gain influence over on-chain credit infrastructure. As institutional governance participation becomes normalized, the question of whether a regulated entity has a documented policy for its on-chain governance activity is becoming a standard part of operational due diligence. Custodians managing assets on behalf of clients, and ETF issuers whose products hold staked positions, are the most exposed to this scrutiny.</p><h2 id="how-staking-governance-rights-work-across-networks">How Staking Governance Rights Work Across Networks</h2><p>The first obstacle to building an institutional governance policy is that staking governance rights does not work the same way across networks. The model varies significantly depending on whether the network uses direct token-holder voting, delegation, conviction voting, or representative governance. Understanding the model for each network in your program is a prerequisite to having any coherent policy.</p><h3 id="ethereum">Ethereum</h3><p>Ethereum's base-layer governance is off-chain and informal. Protocol changes are proposed through Ethereum Improvement Proposals, debated in public forums, and implemented by client teams. There is no formal on-chain voting mechanism for base-layer changes. Validators participate in consensus but do not have a formal governance vote on protocol upgrades.</p><p>For institutional operators, this means Ethereum governance participation is primarily a monitoring obligation rather than an active voting requirement. The relevant question is whether protocol upgrade proposals that could affect validator behavior, reward mechanics, or slashing conditions are being tracked and evaluated.</p><p>However, Ethereum's governance picture changes in the context of liquid staking. Protocols built on Ethereum, including liquid staking protocols and DeFi vaults, have their own on-chain governance mechanisms. Institutions holding governance tokens associated with those protocols do have formal voting rights.</p><h3 id="polkadot">Polkadot</h3><p>Polkadot's OpenGov system is one of the most technically sophisticated on-chain governance mechanisms in proof-of-stake. OpenGov features enhanced delegation, allowing users to delegate their votes to trusted experts across specific governance tracks, and simultaneous referendums, enabling multiple proposals to progress at once for faster decision-making.</p><p>A critical structural point for institutional operators: on Polkadot, governance and staking are completely disjoint. Nominating a validator does not assign any governance voting rights to the validator. DOT holders vote directly in governance, separately from their staking activity. This means that delegating to a validator does not delegate governance representation. Institutions holding DOT retain their governance rights regardless of their staking configuration, and must exercise or consciously decline those rights independently.</p><p>OpenGov further allows DOT holders to delegate their voting power based on the track of a proposal, enabling specialized delegation to trusted experts for specific governance domains rather than blanket delegation to a single representative.</p><p>The March 2026 issuance vote illustrates the stakes. A governance decision that reduced annual DOT issuance by more than half and introduced a permanent supply cap was executed entirely through this mechanism. Institutions that were unaware of the vote or had no policy for participation experienced the outcome without any input.</p><h3 id="cosmos">Cosmos</h3><p>Cosmos governance operates through on-chain proposals where token holders vote directly. The key structural difference from Polkadot is the default delegation behavior. In Cosmos, if a delegator abstains from a vote, the validator they delegate to assumes their voting power. </p><p>This has a direct institutional implication. If an institution staking ATOM does not actively vote on a governance proposal, its voting power is automatically cast by its validator. This is governance by default, not by choice. For custodians managing assets on behalf of clients, and for regulated funds with voting policies, this default mechanism requires an explicit decision: either participate actively in every governance vote, or make an informed and documented choice to delegate governance representation to the validator.</p><p>Cosmos governance covers a wide range of decisions including protocol upgrades, community pool spending, parameter changes, and interchain security arrangements. The frequency and breadth of governance activity on Cosmos chains is typically higher than on Ethereum base-layer governance.</p><h3 id="cardano">Cardano</h3><p>Cardano's Voltaire governance framework, activated in 2025, introduced on-chain governance through a delegated representative model. ADA holders can delegate their governance rights to Delegated Representatives, or DReps, who vote on their behalf. Alternatively, holders can vote directly.</p><p>Governance decisions under Voltaire include protocol parameter changes, treasury withdrawals, and constitutional amendments. For institutions holding staked ADA, Voltaire creates an explicit governance participation obligation that did not exist under earlier versions of the protocol.</p><p>The structural difference from Cosmos is that ADA's governance delegation is separate from its staking delegation. Delegating to a stake pool does not automatically assign governance rights to the pool operator. Institutions must separately decide how to handle governance delegation through the DRep mechanism.</p><h3 id="solana">Solana</h3><p>Solana does not currently have a formal on-chain governance mechanism for base-layer protocol decisions. Governance is handled off-chain through validator coordination and community processes. For institutional operators, the governance obligation on Solana is primarily monitoring: tracking validator and foundation proposals that could affect protocol behavior.</p><p>This may change as Solana's governance infrastructure matures. Institutions building multi-network programs should treat Solana governance as a watch item rather than an active obligation for now.</p><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://p2p.org/economy/content/images/2026/06/Staking-Governance-Rights-by-Network.jpg" class="kg-image" alt="Comparison table showing how staking governance rights work across Ethereum, Polkadot, Cosmos, Cardano, and Solana, including default voting behavior and key institutional implications for each network." loading="lazy" width="1600" height="900" srcset="https://p2p.org/economy/content/images/size/w600/2026/06/Staking-Governance-Rights-by-Network.jpg 600w, https://p2p.org/economy/content/images/size/w1000/2026/06/Staking-Governance-Rights-by-Network.jpg 1000w, https://p2p.org/economy/content/images/2026/06/Staking-Governance-Rights-by-Network.jpg 1600w" sizes="(min-width: 720px) 720px"><figcaption><i><em class="italic" style="white-space: pre-wrap;">Staking Governance Rights by Network</em></i></figcaption></figure><h2 id="the-four-governance-participation-decisions-every-institution-must-make">The Four Governance Participation Decisions Every Institution Must Make</h2><p>Building an institutional governance policy for staking positions requires four explicit decisions for each network in the program.</p><h3 id="">,</h3><p>The first decision is whether the institution will vote directly on governance proposals or delegate that authority to a representative.</p><p>Direct participation requires monitoring governance proposals across every network in the program and developing internal views on how to vote. For institutions operating across five or more networks, this is a meaningful operational commitment.</p><p>Delegation to validators or governance representatives is the lower-friction path, but it is not a governance-free path. Delegating governance to a validator is a governance decision that requires documentation. For custodians and regulated funds, "we delegated to our validator, and they voted on our behalf" is an answer that requires written policy to support it, not just an operational default.</p><h3 id="decision-2-which-proposals-require-internal-escalation">Decision 2: Which Proposals Require Internal Escalation</h3><p>Not all governance proposals carry the same weight. Routine parameter adjustments are different from decisions that materially affect issuance rates, reward mechanics, or slashing conditions.</p><p>Institutional governance policies should define a threshold for escalation: which categories of proposal require internal review before the institution's governance position is determined, and which can be handled through standing delegation or default behavior.</p><p>For regulated entities, proposals that could affect the value, liquidity, or risk profile of staked positions held on behalf of clients are typically the category that requires internal escalation. The March 2026 Polkadot issuance vote falls clearly into this category. A routine parameter adjustment may not.</p><h3 id="a">a </h3><p>How governance participation is documented is not a secondary concern. For custodians managing staked assets under fiduciary obligations, governance decisions are part of the record of how the asset was managed. For ETF issuers, governance activity on staked holdings may become a disclosure obligation as regulatory frameworks mature.</p><p>At a minimum, institutional governance documentation should record:</p><ul><li>Which networks does the program participate in governance for?</li><li>The standing policy for each network (direct vote, delegation, or monitored abstention).</li><li>The internal escalation threshold for material proposals.</li><li>A log of governance votes cast or delegation decisions made, by network and proposal.</li></ul><h3 id="decision-4-counterparty-alignment">Decision 4: Counterparty Alignment</h3><p>For institutions that delegate governance to validators or governance representatives, counterparty alignment matters. The institution's governance representative will vote on its behalf. If that representative votes contrary to the institution's interests or values, the institution has no recourse after the fact.</p><p>Validator selection and governance representative selection should be evaluated together, not separately. For Cosmos networks, where the validator default vote assumption is active, this is especially important. For Polkadot, where governance and staking are disjoint, the governance delegation decision is entirely separate from the validator nomination decision and requires its own evaluation.</p><h2 id="the-governance-monitoring-obligation">The Governance Monitoring Obligation</h2><p>Even institutions that choose a passive governance posture, delegating all voting to validators or representatives, carry an ongoing monitoring obligation. Governance decisions on PoS networks can be consequential and fast-moving.</p><p>The practical monitoring framework for a multi-network staking program includes:</p><h3 id="protocol-upgrade-monitoring">Protocol upgrade monitoring</h3><p>Major protocol changes on any network in the program should be reviewed for their potential impact on validator behavior, slashing conditions, reward mechanics, and unbonding parameters. The Polkadot unbonding period reduction in March 2026, covered in the previous Institutional Lens article, originated in a governance process that institutions with staked DOT should have been tracking.</p><h3 id="issuance-and-reward-parameter-monitoring">Issuance and reward parameter monitoring</h3><p>Changes to issuance rates, validator reward curves, and protocol-defined reward mechanics directly affect the economics of staked positions. The March 2026 Polkadot issuance decision is the clearest recent example, but similar decisions occur regularly across Cosmos chains and are emerging on other networks.</p><h3 id="slashing-condition-monitoring">Slashing condition monitoring</h3><p>Protocol governance can introduce or modify slashing conditions. Institutions operating validators or delegating to validators need to know when slashing rules change before those changes take effect.</p><h3 id="governance-calendar-awareness">Governance calendar awareness</h3><p>Active governance networks like Polkadot and Cosmos chains often have multiple concurrent proposals. Institutions with a direct participation policy need a tool or a service arrangement that surfaces relevant proposals before voting windows close.</p><h2 id="building-the-governance-policy-a-practical-framework">Building the Governance Policy: A Practical Framework</h2><p>For staking product managers and validator risk committees drafting or reviewing an institutional governance participation policy, the following structure covers the essential elements.</p><h3 id="scope">Scope</h3><p>The policy should name every network in the staking program and classify each by its governance model: direct token-holder voting (Cosmos), disjoint governance and staking (Polkadot OpenGov), delegated representative model (Cardano Voltaire), informal off-chain governance (Ethereum base layer, Solana).</p><h3 id="default-posture-by-network">Default posture by network</h3><p>For each network, the policy should specify whether the default posture is direct participation, delegation to the validator, delegation to a named governance representative, or monitored abstention.</p><h3 id="proposals">Proposals</h3><p>The policy should define what categories of proposals trigger internal review rather than default handling. At a minimum, issuance changes, slashing condition changes, and any proposal that materially affects the liquidity or economics of staked positions.</p><h3 id="counterparty-governance-alignment">Counterparty governance alignment</h3><p>For networks where governance is delegated, the policy should specify how governance alignment with the chosen validator or representative is evaluated and at what frequency.</p><h3 id="documentation-standard">Documentation standard</h3><p>The policy should specify the record-keeping format for governance participation: which decisions are logged, where, and in what format, so that the record is available for audit or regulatory review.</p><h3 id="review-cadence">Review cadence</h3><p>Governance frameworks on PoS networks evolve. The policy should be reviewed at least annually and updated following any material governance change on the network in the program.</p><hr><blockquote><strong>The institutional digital asset space moves fast.</strong> Our subscribers get structured analysis across staking, DeFi vaults, and regulation through <em>DeFi Dispatch</em>, <em>Institutional Lens</em>, <em>DeFi Infrastructure for Institutions</em>, and <em>Legal Layer</em>. No noise. Just the signals that matter. <strong>Subscribe to the newsletter at the bottom of this page.</strong></blockquote><hr><h2 id="governance-rights-and-the-multi-network-program-infrastructure-question">Governance Rights and the Multi-Network Program Infrastructure Question</h2><p>An institutional staking program spanning five or more networks creates a governance, monitoring, and participation burden that cannot be managed manually at scale. The operational infrastructure supporting the program needs to surface governance proposals, track voting windows, and maintain participation records across every network simultaneously.</p><p>For institutions evaluating multi-network staking infrastructure, P2P.org Hub is designed to support institutional staking program management across multiple PoS networks from a single platform. <a href="https://www.p2p.org/products/p2p-hub?ref=p2p.org">P2P.org Hub</a> provides the operational layer through which custodians, treasury teams, and staking product managers can oversee validator performance, reward tracking, and program management across their full network allocation.</p><p>For the multi-network program design framework that this governance policy sits within, see the previous Institutional Lens article: <a href="https://p2p.org/economy/how-to-build-an-institutional-staking-program-across-multiple-networks/">How to Build an Institutional Staking Program Across Multiple Networks</a>.</p><h2 id="an">an </h2><p>Staking governance rights are not optional. They exist by default when you stake, they vary materially across networks, and they produce consequential outcomes whether you participate or not.</p><p>The March 2026 Polkadot issuance decision affected every DOT holder. Governance decisions on Cosmos chains are cast by validators on behalf of delegators who do not vote. Cardano's Voltaire framework created formal governance obligations that did not exist two years ago.</p><p>Institutions that have designed multi-network staking programs without a corresponding governance participation policy have an open gap. A documented policy covering scope, default posture by network, escalation thresholds, counterparty alignment, and record-keeping is the practical path to closing it.</p><p>Staking governance rights are not a compliance burden to be minimized. They are an instrument of participation in the networks that institutional capital is increasingly supporting at scale. Treating them as such is part of operating a staking program at an institutional standard.</p><h2 id="frequently-asked-questions-faq">Frequently Asked Questions (FAQ)<br></h2><h3 id="what-are-staking-governance-rights-and-why-do-they-matter-for-institutions">What are staking governance rights, and why do they matter for institutions?</h3><p>Staking governance rights are the protocol-level rights that accrue to token holders when they stake on a proof-of-stake network. Depending on the network, these rights may include voting on protocol upgrades, parameter changes, issuance decisions, treasury allocations, and slashing condition modifications. They matter for institutions because governance decisions are consequential and financially relevant. After all, the rights exist whether or not the institution has a policy for exercising them, and because regulated entities with fiduciary obligations are increasingly expected to have documented approaches to governance participation across their asset holdings, including on-chain positions.</p><h3 id="do-staking-governance-rights-differ-across-proof-of-stake-networks">Do staking governance rights differ across proof-of-stake networks?</h3><p>Yes, materially. On Ethereum's base layer, governance is off-chain and informal, with no direct voting mechanism for token holders. On Polkadot, governance and staking are structurally disjoint: nominating a validator does not transfer any governance rights to that validator, and DOT holders vote directly and separately from their staking activity. On Cosmos, if a delegator does not vote on a proposal, the validator they delegate to assumes their voting power by default. On Cardano, the Voltaire framework introduced a delegated representative model where governance delegation is separate from staking delegation. Each model requires a different institutional policy approach.</p><h3 id="what-happened-at-polkadot-in-march-2026-that-is-relevant-to-institutional-governance">What happened at Polkadot in March 2026 that is relevant to institutional governance?</h3><p>In March 2026, Polkadot token holders voted through the OpenGov on-chain governance system to cut annual DOT issuance by 53.6%, reducing it from approximately 120 million to 55 million DOT per year, and set a hard supply cap of 2.1 billion DOT for the first time. This was the most significant economic change to the Polkadot protocol since launch. Every institutional DOT holder was affected by the outcome regardless of whether they participated in the vote. The event illustrates that governance abstention is not a neutral position on networks where governance decisions can materially affect issuance rates, liquidity, and the economics of staked positions.</p><h3 id="what-is-the-default-governance-behavior-on-cosmos-chains-if-an-institution-does-not-vote">What is the default governance behavior on Cosmos chains if an institution does not vote?</h3><p>On Cosmos chains, if a delegator does not actively vote on a governance proposal, the validator they delegate to assumes and casts that voting power on their behalf. This means institutional Cosmos positions that are not actively managed produce governance outcomes by default through the validator's voting behavior. For custodians managing assets on behalf of clients, and for funds with voting policies, this default mechanism requires either active participation in governance or an explicit and documented decision to delegate governance authority to the chosen validator.</p><h3 id="what-does-a-documented-institutional-governance-policy-for-staking-need-to-cover">What does a documented institutional governance policy for staking need to cover?</h3><p>A governance policy for an institutional staking program should cover: the scope of networks included and the governance model of each; the default posture for each network (direct participation, delegation, or monitored abstention); the escalation threshold that triggers internal review for material proposals; how counterparty governance alignment is evaluated for networks where delegation is used; the documentation and record-keeping standard for governance decisions; and the review cadence for updating the policy as governance frameworks evolve.</p><h3 id="is-governance-participation-relevant-for-etf-issuers-with-staking-integrated-products">Is governance participation relevant for ETF issuers with staking-integrated products?</h3><p>Yes. ETF issuers whose products hold staked positions inherit the governance rights associated with those positions. As staking-integrated ETF products become more common following the March 2026 regulatory shift, governance participation by ETF issuers will attract increasing scrutiny from regulators and investors. Issuers should develop documented governance participation policies that address how on-chain governance rights associated with staked holdings are managed, and whether those policies are consistent with the fund's investment mandate and fiduciary obligations.</p><hr><h2 id="about-p2porg">About P2P.org</h2><p>P2P.org builds the protection layer that sits between regulated institutions and DeFi execution environments, independently of the curators who manage allocation strategies. If you are evaluating the infrastructure requirements for a DeFi allocation program, <a href="https://p2p.org/?ref=p2p.org#form" rel="noreferrer">talk to our team</a>.</p><hr><p><strong>Disclaimer</strong></p><p>This article is provided for informational purposes only and does not constitute legal, regulatory, compliance, or investment advice. Regulatory obligations may vary depending on jurisdiction and specific business activities. Readers should consult their own legal and compliance advisors regarding applicable requirements.</p>