A close vote, a governance mandate that isn't yet a live protocol change, and what it means for the users staking on Solana.
KEY TAKEAWAYS
Here's how the network got here, what actually changes, and what we're watching on behalf of our stakers.
Third attempt, first success. Solana has tried to cut emissions twice before, and both times it failed. SIMD-0228, a market-based model that would have let issuance flex with staking participation, was rejected in March 2025 in the largest governance vote crypto had seen to that point, voted down largely by smaller and mid-sized validators. SIMD-0411 tried next and stalled.
SIMD-0550, the proposal behind SGP-0002, drew the lesson from both and went the other way. Instead of a new adaptive mechanism, it changes a single existing parameter, the disinflation rate. That simplicity is a large part of why it succeeded where the others didn't.
The 2025 opposition came from a specific group: the smaller and mid-sized operators most exposed to a shrinking issuance base. That same concern, what a faster taper does to the long tail of the validator set, is a big part of why we landed where we did this time.
What SGP-0002 actually does
Solana's issuance follows a fixed curve: it began at 8% a year and falls by a set fraction of the remaining distance each epoch until it reaches a permanent 1.5% floor. SGP-0002 changes exactly one thing: it doubles the annual rate of that decline, from 15% to 30%, while the 1.5% floor remains untouched. Only the speed of the descent changes: the floor now arrives around 2029 rather than 2032, with roughly 18.9 million fewer SOL issued over six years.
Less new SOL is issued, and staking rewards funded by that issuance step down faster too. The table below shows the issuance-only path.

SGP-0002 has passed the quorum by a hair – 0.334 percentage points. For most of the final hour, the outcome was genuinely in doubt: the validator set was split, stake moved on both sides late in the window. Clearing the bar this narrowly says the ecosystem is still some way from consensus on this.
We agreed with where this ends up: the 1.5% floor is reached under both schedules, so the open question was how fast to get there. What gave us pause was the effect of halving that schedule on the shape of the network: it squeezes smaller and mid-sized operators soonest and, over the years, concentrates stake toward the largest ones. We'd have preferred a bit more time to preserve that balance, even with the same destination ahead, and the closeness of the vote suggests we weren't the only ones weighing that tradeoff.
Many expected SGP-0002 and SGP-0003 to land together: less issuance on one side, more fee burn on the other. SGP-0003 didn't pass. It finished at 53.9%, with a large share of stake choosing to abstain rather than take a side.
So only one half of that picture activated. SGP-0002 accelerates the reward compression; the offsetting burn mechanism many assumed would accompany it isn't there. The vote was legitimate, and it stands as the mandate now in place. But the disinflation curve is steeper than the paired framing implied, and that's the dynamic we're watching most closely for the stakers we serve.
Where we stand
Faster disinflation was always coming. The ecosystem's monetary conversation has been moving in one direction for two years, and rewards built mainly on predictable, market-independent issuance stopped making narrative sense some time ago.
The change serves something bigger: Solana's push to become the settlement layer for real financial flows. SGP-0002 sits on the same strategic arc as Alpenglow and the accounts-model upgrades, each one advancing that same goal. Read against that trajectory, a faster taper isn't a surprise.
Our No came down to pace. The capital we serve stakes at enterprise grade, and capital like that absorbs structural change on a longer clock: it needs time to model, reprice, and adjust mandates.
We've voted against proposals like this before, consistently, because moving a network's economics this quickly asks a lot of the operators and allocators who have to live with the result. Flagging that discomfort is part of representing the people whose stake sits with us.
None of that puts us on the sidelines of where Solana is going. We keep pace with the ecosystem's ambitions because we're helping build them, and we see real potential in the non-staking side of the network to carry more of the load.
We're investing in the MEV and priority-fee infrastructure that has to mature as issuance steps back, because that side of validator revenue is becoming a core part of the rewards.
Doubling disinflation means we work harder on the parts of the rewards we can still control: transparent reporting across every reward type, and a faster build-out of the fee and MEV side of the business as the issuance base thins. Capital doesn't like to wait, and neither does Solana anymore.
Nothing changes for your stake today. SGP-0002 is a governance mandate rather than a live protocol change yet. The new schedule takes effect only once SIMD-0550 clears implementation and feature-gate activation across Solana's clients, and we'll flag it clearly when that timeline firms up.
When it does land, the issuance-based portion of staking yield steps down over roughly three years, and it won't be felt evenly. How much depends on a validator's mix of issuance versus MEV and priority-fee revenue. If you stake with us and have questions about what this means for your own position, reach out to your account manager, and we'll walk you through it.
Your stake is your voice now; don’t hesitate to speak up.
SGP-0002 is the clearest reminder yet that Solana's economic direction is no longer decided somewhere above you. Under the new framework, every delegator can vote their own stake on each proposal independently, and override their validator if they see it differently. That is real power.
Governance of this kind rewards the people who show up. Close votes get decided in the final hours by whoever is paying attention, and the stakers who engage early shape outcomes that the ones who wait simply inherit.
What these proposals actually affect is exactly the kind of thing we are here to translate. The decision stays yours and we just make sure you are making it with the full picture.
The technical path runs through SIMD-0550, which is already specified, with an Agave implementation merged. What remains is coordination across Solana's other client teams, testing, and feature-gate activation before the new schedule takes effect on-chain. Expect that to take time, and expect it to be the part worth watching, since implementation, not the vote, is where a change like this actually becomes real. The open question we're tracking is how the network's economics behave with a steeper disinflation curve and no burn-side offset in place yet.
Questions about what this means for your stake?
Reach out to your P2P.org account manager. We're glad to walk delegators through what SGP-0002 changes, when it takes effect, and what it means for your position.
Sources & further reading
SGP-0002 · Double Disinflation - proposal page & results: governance.solana.com
SGP-0001 · The Solana Constitution: governance.solana.com
SGP-0003 · Resource & Inclusion Fee: governance.solana.com
Figures reflect P2P.org and proposal-author modelling; issuance-only yields are approximate and move with staking participation and market conditions. Vote figures and dates are epoch-driven. This article is informational, reflects P2P.org's view at the date of publication, and is not investment, legal, or tax advice.
<h2 id="series-validator-playbook-mev-infrastructure"><strong>Series: Validator Playbook | MEV Infrastructure</strong></h2><p>The Validator Playbook is <a href="http://p2p.org/?ref=p2p.org">P2P.org</a>'s infrastructure education series for institutional Ethereum operators. Each article addresses a specific operational, risk, or governance decision that validator infrastructure teams, staking product managers, ETF issuers, custodians, asset managers, and risk committees face when building or evaluating proof-of-stake infrastructure.</p><p>Previously in the series: <a href="https://p2p.org/economy/validator-playbook-ethereum-staking-etf-validator-infrastructure/">How ETF Issuers Should Evaluate Validator Infrastructure: An Operational Guide</a></p><hr><h2 id="learnings-for-busy-readers">Learnings for Busy Readers</h2><ul><li>MEV-Boost revenue typically adds 10 to 30% to staking rewards. On a 2.78% base APR, that translates to roughly 0.28 to 0.83% additional yield per validator. For institutional operators running thousands of validators, that difference is material.</li><li>The MEV-Boost architecture splits the role of producing a block into four functions: searchers identify MEV opportunities, builders aggregate them into blocks, relays connect builders to validators, and validators propose the selected block to the chain. Validators sit at the end of that chain, not the beginning.</li><li>Of the seven major MEV-Boost relays, only three do not censor according to OFAC compliance requirements. For regulated institutions, relay selection is a compliance decision, not just a yield decision.</li><li>Running multiple relays simultaneously is standard practice. MEV-Boost compares bids across all connected relays and selects the highest-paying valid block for each slot.</li><li>Approximately 88% of Ethereum blocks are currently assembled off-chain through MEV-Boost relays. Running without MEV-Boost means building blocks locally and forgoing the yield uplift from the builder marketplace entirely.</li><li>Glamsterdam's EIP-7732 will move the proposer-builder separation mechanism into the Ethereum protocol itself, replacing the trust-based relay layer with in-protocol bids, commitments, and payments. The relay stack as it exists today has a defined end date.</li><li>The MEV decision for institutional operators involves three distinct layers: the yield layer (relay selection and multi-relay configuration), the compliance layer (OFAC screening and transaction filtering), and the forward-planning layer (preparing for Glamsterdam's ePBS transition).</li></ul><h2 id="why-mev-now-matters-at-the-institutional-level">Why MEV Now Matters at the Institutional Level</h2><p>Ethereum staking rewards come from two structurally different sources that carry different risk profiles and require different infrastructure decisions.</p><p>Consensus layer rewards are protocol-issued and relatively predictable. Validators earn them by attesting to the state of the chain, proposing blocks, and participating in sync committees. Execution layer rewards come from user priority fees and MEV at the time of block proposals. They are variable and market-driven. In Q1 2026, consensus layer rewards accounted for approximately 93% of total validator rewards, with execution layer rewards comprising the remaining 7%.</p><p>That 7% is not a rounding error for institutional operators. For institutional operators running thousands of validators, the MEV uplift is the difference between a profitable and marginal operation. The variability also matters: execution layer rewards spike during periods of elevated on-chain activity, including token launches, liquidation cascades, and major market events, and compress during quieter periods. Managing that variability through relay configuration is where institutional MEV strategy begins.</p><p>Before Pectra, an institution staking 2,048 ETH ran 64 separate validators, each with its own block proposal slot. Post-consolidation, that same position sits in a single validator. Each block proposal now represents a larger concentrated opportunity to capture execution layer rewards. Validator consolidation has made MEV-per-proposal more consequential, not less.</p><h2 id="how-the-mev-boost-stack-works">How the MEV-Boost Stack Works</h2><p>Understanding the institutional decision requires understanding the architecture. The MEV-Boost proposer-builder separation architecture splits the role of producing a block into three separate functions: searchers identify MEV opportunities and submit bundles of transactions that capture them; builders aggregate searcher bundles and other transactions into proposed blocks; relays connect builders to proposers and provide the trust layer that allows proposers to commit to blocks they have not directly constructed.</p><p>MEV-Boost is a sidecar for the beacon node, a separate piece of open-source software, which queries and outsources block-building to a network of builders. Block builders prepare full blocks, optimizing for MEV extraction and fair distribution of rewards. They then submit their blocks to relays. Relays aggregate blocks from multiple builders to select the block with the highest fees. One instance of MEV-Boost can be configured by a validator to connect to multiple relays.</p><p>For institutional operators, three properties of this architecture are operationally significant.</p><p>First, the relay is a trusted intermediary. Validators commit to a block header before seeing the full block contents. They are trusting the relay not to manipulate or front-run the payload. The trust assumption sits entirely outside Ethereum's protocol rules, which is precisely what Glamsterdam's ePBS addresses.</p><p>Second, relay selection is the primary lever. Validators do not choose builders directly. They choose relays, and relays determine which builders they aggregate. The relay decision shapes both the yield profile and the compliance posture of the validator's block production.</p><p>Third, multi-relay configuration is the standard operating model. If connected to multiple relays, the validator's MEV-Boost software can compare bids and select the block header that will provide the highest value, increasing the overall staking reward for that block. Running a single relay concentrates both yield and operational risk on that relay's availability and performance.</p><h2 id="the-compliance-dimension-of-relay-selection">The Compliance Dimension of Relay Selection</h2><p>For institutional validators operating under regulatory obligations, relay selection carries a compliance dimension that yield calculations alone do not capture.</p><p>Of the seven major MEV-Boost relays, only three do not censor according to OFAC compliance requirements. The remaining relays apply transaction filtering based on OFAC sanctions lists, meaning they will not include transactions involving sanctioned addresses in the blocks they produce. For regulated institutions, using a non-OFAC-compliant relay can expose the validator to sanctions risk if a block they propose contains a transaction involving a sanctioned counterparty.</p><p>The compliance question involves two distinct considerations that institutions need to evaluate separately.</p><p>The first is sanctions exposure. Regulated institutions operating under US jurisdiction, or serving clients subject to US regulatory oversight, typically need to confirm that their block production infrastructure does not facilitate transactions with sanctioned addresses. OFAC-compliant relays address this by filtering their block payloads against the SDN list before forwarding bids to validators.</p><p>The second is censorship posture. OFAC-compliant relays filter transactions, which means they exclude certain transactions from blocks they produce. For institutions with clients or stakeholders concerned about Ethereum's censorship resistance properties, running OFAC-compliant relays exclusively carries a network-level implication beyond the institution's own compliance posture.</p><p>The practical resolution for most institutional operators is a multi-relay configuration that includes both OFAC-compliant and non-censoring relays, with MEV-Boost selecting the highest bid at the time of each block proposal. This approach maintains compliance coverage on most slots while preserving access to the full builder market when a non-censoring relay wins the bid.</p><p>Source: <a href="https://www.kucoin.com/blog/ethereum-staking-in-2026-yield-trends-validator-queue-dynamics-and-mev-impact-exlained?ref=p2p.org">KuCoin</a></p><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://p2p.org/economy/content/images/2026/09/Diagram-showing-the-MEV-Boost-stack-from-searchers-to-validators-on-the-left--and-the-three-institutional-decision-layers-on-the-right--yield-layer--compliance-layer--and-forward-planning-layer-for-Glamsterdam-ePBS..jpg" class="kg-image" alt="Diagram showing the MEV-Boost stack from searchers to validators on the left, and the three institutional decision layers on the right: yield layer, compliance layer, and forward planning layer for Glamsterdam ePBS." loading="lazy" width="1600" height="900" srcset="https://p2p.org/economy/content/images/size/w600/2026/09/Diagram-showing-the-MEV-Boost-stack-from-searchers-to-validators-on-the-left--and-the-three-institutional-decision-layers-on-the-right--yield-layer--compliance-layer--and-forward-planning-layer-for-Glamsterdam-ePBS..jpg 600w, https://p2p.org/economy/content/images/size/w1000/2026/09/Diagram-showing-the-MEV-Boost-stack-from-searchers-to-validators-on-the-left--and-the-three-institutional-decision-layers-on-the-right--yield-layer--compliance-layer--and-forward-planning-layer-for-Glamsterdam-ePBS..jpg 1000w, https://p2p.org/economy/content/images/2026/09/Diagram-showing-the-MEV-Boost-stack-from-searchers-to-validators-on-the-left--and-the-three-institutional-decision-layers-on-the-right--yield-layer--compliance-layer--and-forward-planning-layer-for-Glamsterdam-ePBS..jpg 1600w" sizes="(min-width: 720px) 720px"><figcaption><i><em class="italic" style="white-space: pre-wrap;">The MEV-Boost architecture mapped against the three institutional decision layers: yield configuration, compliance posture, and Glamsterdam readiness. All three converge at the relay node.</em></i></figcaption></figure><h2 id="what-glamsterdam-changes-for-the-mev-stack">What Glamsterdam Changes for the MEV Stack</h2><p>The MEV-Boost relay architecture is transitional infrastructure. Glamsterdam's enshrined Proposer-Builder Separation, EIP-7732, formally separates the job of the proposer from the builder and enshrines this hand-off directly into the protocol. Building the trustless exchange of a block payload for payment directly into the protocol removes the need for third-party middleware like MEV-Boost.</p><p>Under ePBS, builders cryptographically seal their blocks and commit to a bid. Validators select the highest bid without seeing transaction contents, and the block is only revealed after the commitment is locked in. The trust assumption that currently sits with the relay moves into the protocol itself.</p><p>Glamsterdam has been pushed back from the first half of 2026 to the fourth quarter of 2026. As of September 2026, the upgrade is in active testnet preparation. Glamsterdam is currently in the devnet phase, where client teams test the new rules on small coordinated networks. Public testnets like Sepolia and Hoodi will activate before mainnet.</p><p>For institutional operators, Glamsterdam's ePBS transition has three operational implications worth tracking now rather than at activation.</p><p>The relay dependency changes but does not disappear immediately. Builders and proposers might still choose to use off-protocol relays or middleware for complex features that are not yet part of the core protocol. The current relay infrastructure will likely operate in parallel with the new in-protocol mechanism during a transition period.</p><p>Compliance architecture needs to be reconsidered. Under the current MEV-Boost model, OFAC compliance is implemented at the relay layer. Under ePBS, the filtering logic will need to be remapped to the new in-protocol builder selection mechanism. Institutions that have built compliance programs around relay-level OFAC filtering will need to evaluate how those programs need to adapt.</p><p>Gas limit expansion affects execution layer reward dynamics. Glamsterdam will bring bigger blocks, moving from a gas limit of 60 million per block to a gas limit floor of 200 million per block. Whether that expansion increases execution layer rewards depends on how demand for blockspace responds to the increased supply. Institutions modeling execution layer yield projections for staking programs should treat Glamsterdam-era reward assumptions as uncertain until mainnet data is available.</p><p>Source: <a href="https://ethereum.org/roadmap/glamsterdam/?ref=p2p.org">ethereum.org</a></p><div class="kg-card kg-callout-card kg-callout-card-blue"><div class="kg-callout-emoji">🗞️</div><div class="kg-callout-text"><b><strong style="white-space: pre-wrap;">The institutional digital asset space moves fast.</strong></b><br><br>Our subscribers get structured analysis across staking, DeFi vaults, and regulation through <i><em class="italic" style="white-space: pre-wrap;">DeFi Dispatch</em></i>, <i><em class="italic" style="white-space: pre-wrap;">Institutional Lens</em></i>, <i><em class="italic" style="white-space: pre-wrap;">DeFi Infrastructure for Institutions</em></i>, and <i><em class="italic" style="white-space: pre-wrap;">Legal Layer</em></i>.<br><br>No noise. Just the signals that matter.<br><br><b><strong style="white-space: pre-wrap;">Subscribe to the newsletter at the bottom of this page.</strong></b></div></div><h2 id="the-mev-configuration-checklist-for-institutional-operators">The MEV Configuration Checklist for Institutional Operators</h2><p>The following checklist covers the MEV infrastructure decisions that institutional validators need to have documented and actively managed.</p><h3 id="relay-selection-and-configuration">Relay selection and configuration</h3><p>[ ] MEV-Boost installed and running as a sidecar to the beacon node</p><p>[ ] Minimum bid threshold configured to ensure local block production fallback when no relay bid meets the floor</p><p>[ ] Multiple relays connected to maximize bid competition across slots</p><p>[ ] Relay list reviewed for OFAC compliance posture against the institution's regulatory obligations</p><p>[ ] Relay availability and performance monitored independently of MEV-Boost defaults</p><h3 id="compliance-posture">Compliance posture</h3><p>[ ] OFAC-compliant relays confirmed in the active relay list for all validators operating under US regulatory jurisdiction</p><p>[ ] Transaction filtering policy documented and reviewed by compliance team</p><p>[ ] Censorship posture decision made explicitly and recorded: full OFAC filtering, partial filtering, or multi-relay with non-censoring fallback</p><p>[ ] Relay compliance posture reviewed on a defined schedule, as relay policies change</p><h3 id="operational-resilience">Operational resilience</h3><p>[ ] Local block production fallback confirmed and tested: if all relays fail to return a valid bid, the validator must be able to build locally without downtime</p><p>[ ] Relay response time monitoring in place: slow relay responses can cause missed proposals</p><p>[ ] Client updates for MEV-Boost and beacon node coordinated to avoid version incompatibilities at upgrade boundaries</p><p>[ ] Glamsterdam client readiness on the infrastructure roadmap ahead of testnet activation</p><h3 id="reporting-and-audit-trail">Reporting and audit trail</h3><p>[ ] MEV revenue logged per validator per slot for reward attribution and NAV reconciliation</p><p>[ ] Relay source logged per block proposal for compliance audit trail</p><p>[ ] Execution layer reward variance documented for shareholder reporting and fund-level performance reconciliation</p><h2 id="key-takeaway">Key Takeaway</h2><p>MEV-Boost is now standard infrastructure for institutional Ethereum validators. Approximately 88% of Ethereum blocks are assembled off-chain through MEV-Boost relays. Running without it means forgoing the execution layer yield uplift that the builder marketplace generates on every block proposal.</p><p>For custodians, asset managers, ETF and ETP issuers, exchanges, treasury teams, staking product managers, and risk committees, the MEV decision is not a single infrastructure choice. It is three parallel decisions: relay selection for yield maximization, relay compliance posture for regulatory alignment, and forward infrastructure planning for Glamsterdam's ePBS transition.</p><p>The institutions best positioned across all three have explicitly documented their relay configuration, aligned it with their compliance team's review of OFAC filtering requirements, and placed Glamsterdam client readiness on their infrastructure roadmap before the testnet activation schedule forces the conversation.</p><p>P2P.org's validator infrastructure runs MEV-Boost with OFAC-compliant relay configuration as standard across all client accounts. For institutional operators evaluating their MEV infrastructure, <a href="https://p2p.org/contact?ref=p2p.org">get in touch with our team</a>.</p><h2 id="frequently-asked-questions-faq">Frequently Asked Questions (FAQ)<br></h2><h3 id="what-is-mev-and-why-does-it-matter-for-institutional-ethereum-validators">What is MEV and why does it matter for institutional Ethereum validators?</h3><p>MEV stands for Maximal Extractable Value. It refers to the additional value that can be captured during block production by reordering, inserting, or excluding transactions within a block beyond the standard consensus layer rewards. On Ethereum, MEV flows primarily through the block builder marketplace: searchers identify profitable transaction ordering opportunities, builders incorporate them into blocks, and validators capture the value when they propose those blocks. In Q1 2026, execution layer rewards, including MEV accounted for approximately 7% of total validator rewards, with the consensus layer providing the remaining 93%. For institutional operators managing large validator sets, that 7% is a material component of total staking economics and needs to be actively managed rather than left to default configuration.</p><h3 id="what-is-mev-boost-and-how-does-it-work">What is MEV-Boost and how does it work?</h3><p>MEV-Boost is a sidecar for the beacon node, a separate piece of open source software which queries and outsources block-building to a network of builders. Block builders prepare full blocks optimizing for MEV extraction and fair distribution of rewards. They then submit their blocks to relays. Relays aggregate blocks from multiple builders in order to select the block with the highest fees. One instance of MEV-Boost can be configured by a validator to connect to multiple relays. The consensus layer client of a validator proposes the most profitable block received from MEV-Boost to the Ethereum network for attestation and block inclusion. Running MEV-Boost is effectively standard practice for institutional validators because the yield differential between MEV-Boost-enabled and local block production is consistently positive over time.</p><h3 id="why-is-relay-selection-a-compliance-decision-for-regulated-institutions">Why is relay selection a compliance decision for regulated institutions?</h3><p>Not all relays treat transactions equally. Of the seven major MEV-Boost relays, only three do not censor according to OFAC compliance requirements. Relays that apply OFAC filtering exclude transactions involving sanctioned addresses from the blocks they produce. Regulated institutions operating under US jurisdiction, or serving clients subject to US regulatory oversight, need to confirm that their block production infrastructure does not facilitate transactions with sanctioned counterparties. Running a non-OFAC-compliant relay without explicit compliance team sign-off introduces sanctions exposure that cannot be managed after the fact, since the block is already on-chain by the time a sanctions issue would be detected.</p><h3 id="what-is-the-risk-of-running-only-one-relay">What is the risk of running only one relay?</h3><p>Relay concentration introduces two distinct risks. The first is yield concentration: if a single relay consistently loses bid competition against others, the validator systematically underperforms on execution layer rewards relative to a multi-relay configuration. The second is operational concentration: if the single relay experiences an outage, latency issue, or returns invalid bids, the validator either misses proposals or falls back to local block production without the execution layer uplift. Multi-relay configuration addresses both risks by distributing bid competition across multiple providers and providing operational redundancy if any individual relay fails.</p><h3 id="what-does-glamsterdams-eip-7732-mean-for-the-current-mev-relay-stack">What does Glamsterdam's EIP-7732 mean for the current MEV relay stack?</h3><p>Glamsterdam's EIP-7732 moves the proposer-builder separation mechanism into the Ethereum protocol itself. Under ePBS, builders cryptographically seal their blocks and commit to a bid. Validators select the highest bid without seeing transaction contents, and the block is only revealed after the commitment is locked in. Building this trustless exchange directly into the protocol removes the need for third-party middleware like MEV-Boost. However, builders and proposers might still choose to use off-protocol relays or middleware for complex features not yet part of the core protocol. Glamsterdam has been pushed back to Q4 2026 and is currently in active testnet preparation. Institutions should treat current MEV-Boost relay configurations as operational through at least the first half of the 2026 mainnet transition period, while beginning to assess how their compliance architecture will need to adapt to the new in-protocol builder selection mechanism.</p><h3 id="how-should-etf-issuers-think-about-mev-revenue-in-fund-reporting">How should ETF issuers think about MEV revenue in fund reporting?</h3><p>MEV revenue flows through the execution layer as part of block proposal rewards. For ETF products that distribute protocol-attributed participation rewards to shareholders, execution layer rewards, including MEV need to be included in the reward attribution methodology. The variability of MEV revenue complicates distribution modeling: execution layer rewards spike during high-activity periods and compress during quieter ones. ETF issuers building NAV calculation infrastructure for staking-enabled products should model execution layer reward variability as a range rather than a fixed assumption, and confirm with their fund administrator that the reporting infrastructure captures relay-source revenue per block proposal for audit trail purposes.</p><hr><p><strong>About P2P.org</strong></p><p>Founded in 2018, P2P.org helps institutional capital protect digital asset yield across non-custodial staking infrastructure and curated DeFi strategies. With over $10B in assets secured and operating on 35+ proof-of-stake networks, P2P.org maintains a zero-slashing-incident track record, is trusted by over 190 institutional clients and is SOC 2 Type II attested and ISO/IEC 27001:2022 certified. To explore how P2P.org can support your institution's staking or DeFi infrastructure needs, <a href="https://p2p.org/contact?ref=p2p.org">get in touch with our team</a>.</p><p><strong>Disclaimer</strong></p><p>This material is provided for informational purposes only and does not constitute investment, financial, legal, or tax advice. <a href="http://p2p.org/?ref=p2p.org">P2P.org</a> 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>
from p2p validator
<p>On 25 August, P2P.org hosted Trading Infrastructure On-Chain: What Institutional Firms Actually Need, a practitioner roundtable on the market structure, latency, data, and execution questions shaping institutional trading on-chain. </p><p>One thread ran through nearly every answer: the technology solving data, privacy, and execution problems is moving faster than the operational layer institutions actually need to trade at scale, settlement speed, best-execution reporting, and risk tooling among them.</p><p>Moderated by Max Mironov, General Manager of New Bets at P2P.org, the discussion featured Duncan Moir (President, 21shares), Oleksandr Proskurin (Co-Founder & CPO, Arkis), Genevieve Doo (Senior Account Manager, Talos), and Kyle O'Brien (VP of Capital Markets & Investor Relations, Zama).</p><p><strong>LEARNINGS FOR BUSY READERS</strong></p><ul><li>Institutional capital already trades on-chain, mostly through market makers, authorized participants, and liquidity providers acting on a fund's behalf, not through direct execution.</li><li>Tokenized assets settle in milliseconds. The cash side of a trade is still bound to banking rails and compliance checks that don't move at that speed, and that mismatch, not chain throughput, is what keeps flow on centralized venues.</li><li>Hyperliquid's on-chain order book has closed the gap with centralized exchanges on depth and speed, but on-chain markets still lack a consolidated tape, so proving best execution across venues remains genuinely harder.</li><li>MEV is treated less as a bug to fix and more as a cost every panelist expects to manage indefinitely, with real disagreement over whether privacy tooling changes that.</li><li>Risk management tooling, not regulation, was named as the clearest remaining infrastructure gap for institutional trading on-chain.</li></ul><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/09/1600x900--35-.png" class="kg-image" alt="" loading="lazy" width="2000" height="1125" srcset="https://p2p.org/economy/content/images/size/w600/2026/09/1600x900--35-.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/09/1600x900--35-.png 1000w, https://p2p.org/economy/content/images/size/w1600/2026/09/1600x900--35-.png 1600w, https://p2p.org/economy/content/images/size/w2400/2026/09/1600x900--35-.png 2400w" sizes="(min-width: 720px) 720px"></figure><h2 id="who-is-actually-trading-and-through-what">Who is actually trading, and through what</h2><p>Duncan Moir opened by correcting an assumption in the question itself: institutional capital moving through an ETP still reaches on-chain execution, just through market makers and liquidity providers trading on the fund's behalf, increasingly on decentralized venues where liquidity depth requires it.</p><blockquote><strong>I think it's maybe a misconception that institutional investors don't understand this world. A lot of them just are not restricted from operating in it, and that's why they come to us. Something like half of our assets are hedge funds, prop desks, market makers, so they understand it very well.</strong></blockquote><blockquote><strong><em>Duncan Moir, 21shares</em></strong></blockquote><p>Oleksandr Proskurin pushed the timeline back further, arguing institutions have quietly driven most crypto trading volume for years, Aave and Uniswap included, and that what changed recently is visibility, not underlying participation. Genevieve Doo pointed to the actual constraint: settlement, not sentiment. Institutional interest is accelerating, but flow still defaults to centralized venues and OTC desks because the cash side of a trade hasn't caught up with how fast the assets themselves move.</p><blockquote><strong>Tokenized assets can move in literally milliseconds, but the settlement piece is often the more complicated part of the trade, and it cannot really move with that level of speed due to banking and compliance reasons.</strong></blockquote><blockquote><strong>Genevieve Doo, Talos</strong></blockquote><p>Asked what changed over the last year, the panel agreed on the direction: tokenization and real-world assets accelerated faster than expected, with Hyperliquid repeatedly cited as the venue that forced the pace, and clearer policy signals giving institutions more room to act on interest that already existed.</p><h2 id="where-the-data-and-latency-gap-actually-sits">Where the data and latency gap actually sits</h2><p>Genevieve gave the sharpest read on where on-chain data has closed the gap with centralized venues, and where it hasn't. Hyperliquid's central limit order book now runs at a scale comparable to major centralized exchanges and leads specifically in real-world asset perpetuals. What's still missing is consolidated depth: a centralized venue offers one order book and one tape, and on-chain markets have no real equivalent, which makes proving best execution across venues meaningfully harder.</p><p>Kyle O'Brien framed the structural issue underneath that gap. Public blockchains were built on the idea that verifiability requires public data, workable in crypto's early years, increasingly at odds with what institutions need now.</p><blockquote><strong>Many of us would agree that the original sin of crypto was that public verifiability required public data. As more institutions move on-chain, privacy has become somewhat of a prerequisite.</strong></blockquote><blockquote><strong>Kyle O'Brien, Zama</strong></blockquote><p>Zama's approach, built on fully homomorphic encryption, keeps data encrypted on-chain while remaining publicly verifiable, letting specific parties, an auditor or regulator, decrypt what they need without broadcasting trading activity to the rest of the network. Oleksandr described the mirror-image version of this problem from the operations side: Arkis computes margin off-chain against on-chain oracles while collateral custody and liquidation rules stay enforced by smart contracts, and treats redundant data providers as non-negotiable, since a single RPC node isn't an acceptable point of failure for a prime brokerage. Duncan, only half-joking, argued the opposite case: on-chain data staying hard to clean and extract currently gives an edge to firms willing to do that work themselves.</p><h2 id="mev-a-cost-to-manage-not-a-bug-to-fix">MEV: a cost to manage, not a bug to fix</h2><p>Oleksandr set the tone early, with Arkis's own exposure coming mostly from its own smart contracts rather than cross-venue execution.</p><blockquote><strong>MEV is a curse, or a blessing. It's a blessing for the MEV bots, and the curse for anyone who is building.</strong></blockquote><blockquote><strong>Oleksandr Proskurin, Arkis</strong></blockquote><p>Duncan pushed back on the idea that institutions don't understand MEV, and drew a distinction that shaped the rest of the conversation.</p><blockquote><strong>You probably need to distinguish between predatory MEV and beneficial MEV. It also helps with price discovery, so it keeps spreads tight, which is good for the ETPs as well.</strong></blockquote><blockquote><strong>Duncan Moir, 21shares</strong></blockquote><p>Asked for a five-year outlook, the panel split. Kyle expects MEV in its current form to disappear if privacy tooling works as intended. Oleksandr expects it to persist regardless, noting that competing funds already track each other's on-chain positions closely. Genevieve suggested a middle path: MEV eventually settling into something closer to exchange fees, priced in and rarely discussed. Hyperliquid came up again as the clearest example of mitigation working in practice, through centralized transaction submission and binary node distribution that makes sandwich attacks structurally difficult to run.</p><h2 id="the-gap-that-isnt-regulation">The gap that isn't regulation</h2><p>Duncan moved past regulation quickly, calling it broadly workable across most major jurisdictions today, with pace and cost varying by region rather than any hard blocker. The gap he actually named was risk management tooling: live portfolio analytics, backtesting, and scenario stress-testing at the level institutional equity desks already expect, which firms currently have to build in-house.</p><p>Kyle argued confidentiality and compliance, the two standard objections from a couple of years ago, are largely handled on the technology side now. What's left is distribution, getting confidential token support into the wallets, custodians, and exchanges institutions already use. Genevieve closed the point by noting institutional adoption doesn't move on one curve: some firms are still evaluating the technology, others have broad conviction and are waiting on a specific custody solution, and both groups are ultimately judging on-chain venues against the same two standards traditional finance already runs on, best execution and counterparty risk discipline.</p><h2 id="closing-round">Closing round</h2><p>The sharpest exchange came between Duncan and Oleksandr on vault structures. Duncan raised an idea he says he regularly debates with his own legal team: a curator allocating through a smart contract may not legally be managing a collective investment scheme at all, since investors allocate directly and the contract executes. He noted regulators have already pushed back on that reading. Oleksandr agreed vaults expose real inefficiency in traditional asset management, but flagged the unresolved tension underneath their growth, onboarding a curator running traditional strategies still triggers standard proof-of-funds checks that anonymous on-chain deposit addresses can't easily satisfy. His bet was that vaults, like Bitcoin before them, eventually find a regulatory middle ground.</p><p>Kyle's closing prediction, offered as talking his own book, was that 95% of blockchain traffic gets encrypted through Zama's protocol within four years. Genevieve's was structural: crypto forced fragmented liquidity, 24/7 markets, and custody problems into the open earlier than other asset classes had to face them, and the infrastructure built to solve those problems now is what eventually gets reused as other asset classes move on-chain.</p><p><strong>KEY TAKEAWAY</strong></p><p>Across all four sections, the pattern held: data quality, MEV mitigation, and privacy tooling are improving quickly, Hyperliquid's rise is the clearest evidence of that. Settlement speed, consolidated best-execution reporting, and institutional-grade risk tooling have not kept pace. The firms building that missing operational layer themselves are the ones actually moving faster than the rest of the market right now.</p><p>You can watch the webinar recording <a href="https://www.youtube.com/watch?v=CDdcuC5IgoI&ref=p2p.org" rel="noreferrer">here</a>.</p><p></p><p><strong>WORK WITH P2P.ORG ON TRADING INFRASTRUCTURE</strong></p><div class="kg-card kg-cta-card kg-cta-bg-grey kg-cta-minimal " data-layout="minimal"> <div class="kg-cta-content"> <div class="kg-cta-content-inner"> <div class="kg-cta-text"> <p><span style="white-space: pre-wrap;">If your firm is evaluating what institutional trading on-chain actually requires in practice, the P2P.org team is available for that conversation. We build the infrastructure institutions rely on for data reliability and execution, including Syncro Data Stream and Syncro Sender, and can walk through the specific operational questions your desk or risk committee is navigating. Explore P2P.org's trading infrastructure.</span></p> </div> <a href="https://www.p2p.org/products/syncro?ref=p2p.org" class="kg-cta-button " style="background-color: #000000; color: #ffffff;"> Learn more </a> </div> </div> </div><hr><p><strong>Disclaimer:</strong> The views and opinions shared during this discussion are those of the individual speakers and do not necessarily reflect the views of P2P.org. This recap is intended to summarize the key themes discussed and should not be considered investment, legal, or financial advice. 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><div class="kg-card kg-toggle-card" data-kg-toggle-state="close"> <div class="kg-toggle-heading"> <h4 class="kg-toggle-heading-text"><span style="white-space: pre-wrap;">FAQ</span></h4> <button class="kg-toggle-card-icon" aria-label="Expand toggle to read content"> <svg id="Regular" xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"> <path class="cls-1" d="M23.25,7.311,12.53,18.03a.749.749,0,0,1-1.06,0L.75,7.311"></path> </svg> </button> </div> <div class="kg-toggle-content"><p><b><strong style="white-space: pre-wrap;">What did the P2P.org Trading Infrastructure On-Chain webinar cover?</strong></b></p><p><span style="white-space: pre-wrap;">The 25 August panel featured practitioners from 21Shares, Arkis, Talos, and Zama, covering who is actually trading on-chain today, where on-chain data and latency still fall short of centralized venues, how MEV shows up in practice, and what remains before on-chain venues can fully compete with centralized trading infrastructure.</span></p><p><b><strong style="white-space: pre-wrap;">Why does settlement speed matter more than asset speed for institutional on-chain trading?</strong></b></p><p><span style="white-space: pre-wrap;">Tokenized assets can move in milliseconds, but the cash side of a trade is constrained by banking rails and compliance requirements that cannot move at the same speed. That mismatch, rather than blockchain throughput itself, is what keeps a meaningful share of institutional flow on centralized venues and OTC desks today.</span></p><p><b><strong style="white-space: pre-wrap;">Is MEV something institutions can eventually avoid entirely?</strong></b></p><p><span style="white-space: pre-wrap;">The panel was split. Some see privacy-preserving infrastructure making MEV structurally obsolete over time. Others see it as a permanent feature of any competitive on-chain market, priced in and managed rather than eliminated.</span></p><p><b><strong style="white-space: pre-wrap;">Where can I watch the webinar replay?</strong></b></p><p><span style="white-space: pre-wrap;">The full replay of Trading Infrastructure On-Chain: What Institutional Firms Actually Need is </span><a href="https://www.youtube.com/watch?v=CDdcuC5IgoI&ref=p2p.org" rel="noreferrer"><span style="white-space: pre-wrap;">available on YouTube.</span></a></p><br></div> </div>
from p2p validator