<h2 id="series-defi-infrastructure-for-institutions">Series: DeFi Infrastructure for Institutions</h2><p><a href="http://p2p.org/?ref=p2p.org">P2P.org</a>'s content series for regulated institutions evaluating onchain capital allocation. Each article addresses a specific infrastructure, governance, or compliance dimension that determines whether a DeFi allocation can clear institutional approval and operate within mandate.</p><p>This is the third and closing article of the third trilogy of the series, completing the institutional profile sequence. <a href="https://p2p.org/economy/defi-vault-allocation-for-custodians-infrastructure-requirements-and-risk-considerations/">The first article</a> examined the infrastructure requirements for custodians. <a href="https://p2p.org/economy/how-hedge-funds-are-approaching-on-chain-yield-strategies-in-2026/">The second article</a> examined how hedge funds are approaching onchain yield strategies. This article examines stablecoin onchain yield strategies for treasury functions at financial institutions and asset managers.</p><p>The previous trilogy examined how conflict-of-interest frameworks across MiFID II, AIFMD II, and IOSCO's DeFi recommendations are converging on the curator model: <a href="https://p2p.org/economy/conflict-of-interest-defi-vault-regulation-institutional/">How Conflict-of-Interest Regulatory Frameworks Are Catching Up to the Curator Model</a></p><p><em>Previously in this series: </em><a href="https://p2p.org/economy/how-hedge-funds-are-approaching-on-chain-yield-strategies-in-2026/"><em>How Hedge Funds Are Approaching Onchain Yield Strategies in 2026</em></a></p><hr><h2 id="learnings-for-busy-readers">Learnings for Busy Readers</h2><p>Short on time? Here are the key takeaways. For the full analysis and supporting data, continue reading below.</p><ul><li>The stablecoin market has crossed $315 billion in total supply as of mid-2026. Annual stablecoin transaction volumes exceed $45 trillion, surpassing traditional payment networks. Treasury functions at financial institutions and asset managers are holding material stablecoin balances that generate no return, while the onchain yield infrastructure to put those balances to work at 5 to 8% APY is available, auditable, and increasingly regulated.</li><li>The GENIUS Act prohibits payment stablecoin issuers from paying yield directly to holders, creating a structural separation that shapes how all stablecoin yield products work in 2026. Yield generation must happen at the asset deployment layer, not the stablecoin issuer layer. Treasury teams need to understand this distinction before evaluating any stablecoin yield product: the stablecoin is the vehicle, not the return.</li><li>Stablecoin yield in 2026 is a tiered stack, not a single rate. The four primary tiers for institutional treasury mandates are tokenized money market funds at the capital-preservation end, curated DeFi lending vaults in the middle, real-world asset vaults for lower crypto-correlated yield, and yield-bearing stablecoin wrappers for passive deployment. Each tier has a distinct risk profile and governance requirement.</li><li>The governance infrastructure requirement for treasury teams interacting with DeFi vault protocols is the same as for custodians and hedge funds: pre-execution mandate validation, exportable compliance logs, and contractual role separation between the curator and the infrastructure layer.</li><li>The regulatory environment is supportive but evolving. The GENIUS Act provides US regulatory clarity. MiCA governs EU stablecoin operations. Both frameworks create compliance obligations for treasury teams that go beyond simply choosing a yield-bearing product.</li></ul><h2 id="introduction">Introduction</h2><p>Treasury functions at financial institutions, exchanges, asset managers, and neobanks are holding stablecoin balances that have grown materially over the past two years. The stablecoin market has crossed $315 billion in total supply as of mid-2026, with annual transaction volumes exceeding $45 trillion, surpassing traditional payment networks. Public companies, DAOs, fintechs, and crypto-native operating businesses collectively hold over $35 billion in onchain stablecoin reserves as of Q1 2026. Source: <a href="https://www.sygnum.com/blog/2025/05/30/institutional-defi-in-2025-the-disconnect-between-infrastructure-and-allocation/?ref=p2p.org">Sygnum Bank</a></p><p>For most of these treasury teams, those balances are idle. Stablecoins held in custody generate no return. The operational rationale for holding stablecoin balances, settling transactions faster, moving capital across chains without correspondent banking friction, and managing operational floats across multiple jurisdictions is strong. But holding is not the same as deploying. And the gap between a stablecoin balance earning nothing and the same balance deployed into a curated DeFi lending vault earning 5 to 8% APY is now wide enough to attract treasury committee attention across the institutional spectrum.</p><p>According to a June 2025 EY-Parthenon survey, 13% of financial institutions and corporates globally are already using stablecoins, with 54% of non-users expecting to adopt them within 6 to 12 months. The regulatory environment has moved to support that transition. The GENIUS Act, signed into law on July 18, 2025, established the first comprehensive federal framework for payment stablecoins in the US. MiCA governs stablecoin operations across all 27 EU member states. The compliance environment is now defined enough to navigate. Source: <a href="https://www.sygnum.com/blog/2025/05/30/institutional-defi-in-2025-the-disconnect-between-infrastructure-and-allocation/?ref=p2p.org">Sygnum Bank</a></p><p>But regulatory clarity on stablecoins does not automatically produce operational clarity on stablecoin yield. The infrastructure requirements for holding stablecoins and deploying them into onchain yield strategies within a treasury mandate are related but not equivalent. This article examines what those requirements look like in practice, what the stablecoin yield stack looks like for institutional treasury mandates in 2026, and what the governance infrastructure requirement is for treasury teams interacting with DeFi vault protocols.</p><h2 id="the-genius-act-and-the-yield-separation-problem">The GENIUS Act and the Yield Separation Problem</h2><p>Before examining stablecoin yield strategies, treasury teams need to understand a structural feature of the regulatory environment that shapes how those strategies work.</p><p>The GENIUS Act, passed in July 2025, prohibits payment stablecoin issuers from paying interest or yield to stablecoin holders. This prohibition is significant. It means that USDC, USDT, and other payment stablecoins issued under the GENIUS Act framework cannot themselves generate yield for holders. The stablecoin is a transfer and settlement instrument. Yield generation must happen separately, at the asset deployment layer. Source: <a href="https://defiprime.com/defi-vaults-guide?ref=p2p.org">DeFi Prime</a></p><p>This creates a structural separation that treasury teams need to internalize before evaluating any stablecoin yield product. The stablecoin is the vehicle. The yield-generating instrument is a separate product that the treasury team deploys stablecoins into: a tokenized money market fund, a DeFi lending vault, a yield-bearing stablecoin wrapper issued by a separate entity, or a real-world asset vault. Each of these products has its own risk profile, its own regulatory classification, and its own governance requirement. The yield does not come from the stablecoin. It comes from what the stablecoin is deployed into.</p><p>Under the GENIUS Act and similar regulations, stablecoins must be backed one-to-one by high-quality reserves including US dollars, insured bank deposits, and short-term US Treasuries, with monthly public disclosures and management certifications. These reserve requirements apply to the issuer, not to the treasury team deploying the stablecoin. But they matter for treasury evaluation: the quality of the reserve backing determines the stability of the stablecoin itself, which is the entry point for any yield strategy built on top of it.</p><h2 id="the-stablecoin-yield-stack-for-institutional-treasury">The Stablecoin Yield Stack for Institutional Treasury</h2><p>Stablecoin yield in 2026 is no longer a single number. The onchain dollar market has stratified along the same yield curve treasurers already know offchain: cash management at the short end, savings rates in the middle, basis trades and structured strategies at the long end. For institutional treasury mandates, four tiers within that stack are relevant, each mapped to a specific mandate type and risk tolerance. Source: <a href="https://arxiv.org/html/2512.11976v1?ref=p2p.org">arXiv</a></p><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://p2p.org/economy/content/images/2026/07/stablecoin-yield-stack-institutional-treasury.jpg.png" class="kg-image" alt="A horizontal four-tier risk spectrum diagram showing the stablecoin yield stack for institutional treasury mandates. From left to right: tokenized money market funds at the capital preservation end with T-bill rate minus fee yield, curated DeFi lending vaults at 4 to 9% APY with smart contract and curator risk, real-world asset vaults with offchain-backed yield and lower crypto correlation, and yield-bearing stablecoin wrappers at the right with passive deployment and wrapper smart contract risk." loading="lazy" width="1600" height="849" srcset="https://p2p.org/economy/content/images/size/w600/2026/07/stablecoin-yield-stack-institutional-treasury.jpg.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/07/stablecoin-yield-stack-institutional-treasury.jpg.png 1000w, https://p2p.org/economy/content/images/2026/07/stablecoin-yield-stack-institutional-treasury.jpg.png 1600w" sizes="(min-width: 720px) 720px"><figcaption><span style="white-space: pre-wrap;">The stablecoin yield stack for institutional treasury mandates, from lowest to highest risk across four strategy tiers.</span></figcaption></figure><p></p><h3 id="tier-1-tokenized-money-market-funds">Tier 1: Tokenized money market funds</h3><p>The lowest-risk entry point for institutional treasury stablecoin yield. Funds like BlackRock's BUIDL with $2.4 billion AUM as of March 2026, Ondo's USDY, Franklin Templeton's BENJI, and Superstate's USTB hold real US Treasury bills and pass the yield through onchain. The yield is the T-bill rate minus a 15 to 50 basis point management fee. These products are appropriate for treasury mandates with capital preservation as the primary objective, where the governance question is essentially the same as for a traditional money market fund: issuer quality, reserve transparency, and redemption mechanics. The onchain layer adds transparency, 24/7 accessibility, and composability. The risk profile is comparable to a regulated money market fund. Source: <a href="https://www.zircuit.com/en/blog/vault-infrastructure-the-institutional-upgrade-traditional-asset-management-has-been-waiting-for?ref=p2p.org">Zircuit</a></p><h3 id="tier-2-curated-defi-lending-vaults">Tier 2: Curated DeFi lending vaults</h3><p><strong>.</strong> The primary yield generation tier for institutional treasury teams willing to accept smart contract risk in exchange for materially higher returns. Deposits held in onchain lending markets have grown by over 60% year-on-year. Across leading collateralised lending platforms, 30-day lending yields on USDC ranged from 4% to 9% as of June 2025. Curated vaults on Morpho, Aave, and Euler allocate depositor stablecoins across lending markets according to the curator's strategy, generating yield from borrower interest. The governance requirement for this tier is material: pre-execution mandate validation, exportable compliance logs, and contractual role separation between the curator and the infrastructure layer. Without this governance infrastructure, the treasury team cannot demonstrate mandate alignment to its board, auditors, or regulators.</p><h3 id="tier-3-real-world-asset-vaults">Tier 3: Real-world asset vaults</h3><p>For treasury mandates requiring yield with lower correlation to crypto market conditions, RWA vaults offer returns derived from offchain economic activity, including government debt, private credit, and money market instruments. The value of tokenized real-world assets surpassed $7 billion, with tokenized T-bill products adopted and integrated into the DeFi ecosystem. These products sit between Tier 1 and Tier 2 in risk profile: they carry smart contract risk from the onchain layer and credit or duration risk from the underlying assets, but they are less exposed to crypto-native market volatility. The governance requirement includes verifying that the offchain asset backing is accurately and continuously represented onchain, which adds a due diligence dimension beyond standard vault evaluation.</p><h3 id="tier-4-yield-bearing-stablecoin-wrappers">Tier 4: Yield-bearing stablecoin wrappers</h3><p>The most passive deployment option for treasury teams that want yield without active position management. Yield-bearing wrappers like sUSDS, sDAI, and USDY are plain ERC-20 tokens that can be used as collateral elsewhere, allowing treasury teams to stack passive yield underneath whatever deployment they do next, instead of parking capital in an isolated account where the yield stops the moment capital needs to move. The risk profile is the underlying yield source plus wrapper smart contract risk. For treasury mandates with high liquidity requirements, the composability of yield-bearing wrappers makes them a useful base layer. Source: <a href="https://www.thetokendispatch.com/p/defis-risk-layer?ref=p2p.org">Thetokendispatch</a></p><h2 id="the-governance-infrastructure-requirement-for-treasury-teams">The Governance Infrastructure Requirement for Treasury Teams</h2><p>The governance infrastructure requirement for treasury functions interacting with DeFi vault protocols is structurally the same as for custodians and hedge funds, with one additional dimension specific to treasury operations: board and audit committee reporting.</p><h3 id="1-pre-execution-mandate-validation">1. Pre-execution mandate validation</h3><p>A treasury function operating under a documented investment policy statement needs to demonstrate at every execution point that its stablecoin deployments are within mandate parameters. Concentration limits across protocols, approved counterparty lists, maximum smart contract risk exposure, and liquidity requirements are all parameters that must be validated before any vault interaction executes. The curator managing the vault has no visibility into any individual treasury team's mandate. The validation layer is the treasury team's responsibility, not the vault's.</p><h3 id="2-exportable-compliance-logs">2. Exportable compliance logs</h3><p>Treasury functions at regulated financial institutions face audit requirements from internal audit, external auditors, and regulatory examiners. Each of these functions needs to be able to verify that stablecoin deployments were within mandate parameters at every historical point. A vault dashboard is not an audit trail. The compliance log must be sequential, timestamped, and exportable in a format that satisfies the institution's audit infrastructure.</p><h3 id="3-conflict-of-interest-documentation">3. Conflict of interest documentation</h3><p>As the second trilogy of this series established, the curator model creates a structural conflict of interest that MiFID II, AIFMD II, and MiCA all require to be identified, documented, and managed. Treasury functions at regulated institutions face the same requirement through their compliance frameworks. The independent validation layer is the primary control. Its existence and operation need to be documented in the institution's risk and governance framework.</p><h3 id="4-board-and-audit-committee-reporting">4. Board and audit committee reporting</h3><p>Beyond the regulatory compliance requirements that custodians and hedge funds share, treasury functions face specific governance obligations to their board and audit committees. Stablecoin yield positions need to be reported at fair value, with appropriate disclosure of the smart contract, curator concentration, and liquidity risks specific to each strategy tier. Board members and audit committee chairs evaluating stablecoin yield exposure for the first time will ask questions that require the same structural answers as LP due diligence: what is the mandate alignment mechanism, what does the audit trail look like, and what happens in a stress scenario?</p><hr><blockquote><strong>The institutional digital asset space moves fast.</strong><br><br>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>.<br><br>No noise. Just the signals that matter.<br><br><strong>Subscribe to the newsletter at the bottom of this page.</strong></blockquote><hr><h2 id="the-regulatory-environment-for-institutional-stablecoin-treasury">The Regulatory Environment for Institutional Stablecoin Treasury</h2><p>Treasury functions at financial institutions operating across multiple jurisdictions face a regulatory environment that has clarified materially in 2025 and 2026 but remains complex in its cross-border dimensions.</p><p>In the US, the GENIUS Act established the first comprehensive federal framework for payment stablecoins. On April 8, 2026, FinCEN and OFAC issued a joint Notice of Proposed Rulemaking to implement AML and sanctions compliance provisions of the GENIUS Act for permitted payment stablecoin issuers, treating them as financial institutions under the Bank Secrecy Act and requiring AML/CFT programs and sanctions compliance. For treasury teams at US financial institutions, this means their stablecoin operations are subject to the same BSA and OFAC compliance framework as their traditional financial activities. The compliance infrastructure for stablecoin treasury management is not separate from the institution's existing AML and sanctions framework. It is an extension of it. Source: <a href="https://www.rapidinnovation.io/post/top-defi-protocols-to-look-for-in-2024?ref=p2p.org">Rapid Innovation</a></p><p>In the EU, MiCA governs stablecoin operations through its e-money token and asset-referenced token frameworks, with full authorisation required for all issuers operating in the EU. The MiCA framework requires reserve backing, redemption at par, and compliance with the same conflict of interest, audit trail, and client asset safeguarding requirements that MiCA imposes on CASPs more broadly.</p><p>For multinational institutions, navigating this patchwork requires careful attention to jurisdictional requirements and the selection of stablecoin issuers with appropriate licences in target markets. The practical implication for treasury teams is that stablecoin selection is not just a yield and risk question. It is a regulatory compliance question that needs to be evaluated on a jurisdiction-by-jurisdiction basis before any deployment. Source: <a href="https://www.calibraint.com/blog/defi-regulatory-compliance-sec-cftc-2025?ref=p2p.org">Calibraint</a></p><h2 id="what-this-means-for-treasury-functions-evaluating-onchain-yield">What This Means for Treasury Functions Evaluating Onchain Yield</h2><p>The treasury functions at financial institutions that are building durable stablecoin yield programs in 2026 are not the ones evaluating headline APY rates across DeFi protocols. They are the ones that have mapped the yield stack against their mandate parameters, built or sourced the governance infrastructure to validate every deployment, and structured their onchain positions within a framework that their boards, auditors, and regulators can examine.</p><p>Yield-bearing stablecoins have grown from $9.5 billion at the start of 2025 to more than $20 billion, with average yields around 5%, slightly above traditional money market rates. The yield opportunity is documented, growing, and in many cases accessible within conservative treasury mandates through Tier 1 and Tier 2 strategies. The question for treasury teams is not whether stablecoin yield is available. The question is whether the governance infrastructure governing the deployment can demonstrate mandate alignment at every execution point to every stakeholder that needs to see it. Source: <a href="https://www.sygnum.com/blog/2025/05/30/institutional-defi-in-2025-the-disconnect-between-infrastructure-and-allocation/?ref=p2p.org">Sygnum Bank</a></p><p><a href="https://p2p.org/?ref=p2p.org#form">Talk to our team</a> if you are evaluating how <a href="http://p2p.org/?ref=p2p.org">P2P.org</a>'s protection layer integrates with treasury infrastructure for institutional stablecoin yield strategies.</p><h2 id="key-takeaway">Key Takeaway</h2><p>Stablecoin yield for institutional treasury mandates is no longer a frontier question. The protocols exist, the regulatory frameworks are defined, and the yield spreads over traditional money market rates are wide enough to attract treasury committee attention across the institutional spectrum. What remains is the governance question.</p><p>The GENIUS Act's yield separation structure means treasury teams must evaluate stablecoin yield at the asset deployment layer, not the issuer layer. The stablecoin yield stack in 2026 spans four tiers from tokenized money market funds to yield-bearing wrappers, each with a distinct risk profile and mandate fit. And the governance infrastructure that makes deployment within mandate demonstrable, pre-execution validation, exportable compliance logs, and board-level reporting, is the same infrastructure that the first trilogy of this series identified as the missing layer in DeFi vault architecture.</p><p>The treasury functions that build or source that governance infrastructure now will capture the yield spread that idle stablecoin balances are currently leaving on the table. The ones who defer it will find the question increasingly difficult to answer when their boards ask why their stablecoin balances are generating nothing.</p><p><em>The DeFi Infrastructure for Institutions series continues. The next sequence examines how the protection layer operates in practice for specific products and integration use cases.</em></p><h2 id="frequently-asked-questions-faq">Frequently Asked Questions (FAQ)</h2><h3 id="why-cant-payment-stablecoins-like-usdc-pay-yield-directly-to-holders">Why can't payment stablecoins like USDC pay yield directly to holders?</h3><p>The GENIUS Act, signed into law on July 18, 2025, explicitly prohibits permitted payment stablecoin issuers from paying interest or yield to stablecoin holders. This prohibition reflects a policy decision to treat payment stablecoins as settlement instruments rather than investment products, avoiding the regulatory classification questions that yield-paying tokens would raise under securities and banking law. Yield generation must therefore happen at the asset deployment layer: treasury teams deploy stablecoins into yield-generating instruments such as tokenized money market funds, DeFi lending vaults, or RWA vaults, and earn yield from those instruments rather than from the stablecoin itself.</p><h3 id="what-is-the-difference-between-a-tokenized-money-market-fund-and-a-curated-defi-lending-vault-for-treasury-purposes">What is the difference between a tokenized money market fund and a curated DeFi lending vault for treasury purposes?</h3><p>A tokenized money market fund wraps short-duration government debt into an onchain token and passes the yield through to holders. The yield source is sovereign debt or government money market instruments, and the risk profile is comparable to a traditional money market fund with the addition of smart contract risk from the token wrapper. A curated DeFi lending vault deploys depositor stablecoins into DeFi lending markets and generates yield from borrower interest. The yield is higher, but the risk profile is materially different: smart contract risk from the vault and the underlying protocols, curator incentive misalignment, and liquidity risk from the underlying lending markets. For treasury mandates with capital preservation as the primary objective, Tier 1 is the appropriate starting point. For mandates with room for managed risk in exchange for yield above money market rates, Tier 2 becomes relevant.</p><h3 id="what-reserve-requirements-apply-to-stablecoins-under-the-genius-act">What reserve requirements apply to stablecoins under the GENIUS Act?</h3><p>The GENIUS Act requires permitted payment stablecoin issuers to maintain one-to-one backing with high-quality liquid assets, including US dollars, insured bank deposits, and short-term US Treasuries with a maximum 93-day maturity. Reserves cannot be rehypothecated or commingled with the issuer's own funds. Monthly public disclosures of reserve composition and outstanding stablecoins are required, along with monthly management certifications and annual audited financial statements for large issuers. These requirements apply to the issuer, not to the treasury team deploying the stablecoin, but they are material to stablecoin selection for treasury operations because reserve quality determines the stability of the instrument at the base of any yield strategy.</p><h3 id="how-does-the-governance-infrastructure-requirement-for-treasury-differ-from-that-for-hedge-funds">How does the governance infrastructure requirement for treasury differ from that for hedge funds?</h3><p>The core infrastructure requirements are similar: pre-execution mandate validation, exportable compliance logs, and contractual role separation between the curator and the infrastructure layer. The primary additional requirement for treasury functions at regulated financial institutions is board and audit committee reporting: stablecoin yield positions need to be reported at fair value, with appropriate disclosure of smart contract, curator concentration, and liquidity risks specific to each strategy tier. Board members and audit committee chairs evaluating stablecoin yield exposure for the first time will ask the same structural questions as regulatory examiners. The governance infrastructure needs to produce answers that satisfy both audiences.</p><h3 id="what-does-multi-jurisdictional-regulatory-compliance-mean-for-treasury-teams-deploying-stablecoins-across-borders">What does multi-jurisdictional regulatory compliance mean for treasury teams deploying stablecoins across borders?</h3><p>Treasury functions at financial institutions operating across multiple jurisdictions face different regulatory requirements for stablecoin operations in each market. In the US, stablecoin operations are subject to the GENIUS Act framework and BSA/OFAC compliance obligations through FinCEN and OFAC's April 2026 joint Notice of Proposed Rulemaking. In the EU, MiCA governs stablecoin operations through its e-money token framework, requiring issuer authorisation, reserve backing, and compliance with MiCA's conflict of interest and client asset safeguarding requirements. Other jurisdictions, including Hong Kong, Singapore, and the UAE have their own frameworks. The practical implication is that stablecoin selection needs to account for the regulatory status of the issuer in each jurisdiction where the treasury operates, not just in the home jurisdiction.</p><hr><p><strong>About </strong><a href="http://p2p.org/?ref=p2p.org"><strong>P2P.org</strong></a></p><p><a href="http://p2p.org/?ref=p2p.org">P2P.org</a> 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">reach out to our team of experts</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>
from p2p validator
<h2 id="series-validator-playbook"><strong>Series: Validator Playbook</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-validator-consolidation-pectra/">Ethereum Validator Consolidation After Pectra: What Institutional Operators Need to Decide</a></p><hr><h2 id="learnings-for-busy-readers">Learnings for Busy Readers</h2><ul><li>The SEC and CFTC joint interpretive release on March 17, 2026 classified staking rewards from 16 named digital commodities, including ETH as non-securities, removing the primary legal barrier that had delayed staking-enabled ETF structures in the United States.</li><li>Staking ETFs turn validator infrastructure into the backend of a regulated product. The infrastructure provider is now a counterparty in a regulated financial product, not a commodity service.</li><li>Validator selection for ETF issuers has shifted from rate optimisation to operational commitments: uptime service-level agreements, slashing-prevention architecture, key custody design, and compliance attestations.</li><li>SOC 2 Type II is now a baseline diligence requirement for ETF-grade validator infrastructure. It is not a differentiator. Providers without it can create a compliance gap in the issuer's own vendor risk program.</li><li>For ETF staking structures where fiduciary control of underlying assets must remain with the issuer, non-custodial architecture is the preferred model, keeping private keys and withdrawal credentials out of the validator provider's hands.</li><li>Correlated failure risk is a portfolio-level concern for ETF issuers, not just an infrastructure one. Provider concentration across the issuer's validator set introduces systemic exposure that commission rate comparisons will not surface.</li><li>The operational framework for selecting a validator provider maps directly onto how ETF issuers already evaluate prime brokers and custodians: counterparty risk, documented controls, and compliance standing first.</li></ul><h2 id="what-changed-on-march-17-2026">What Changed on March 17, 2026</h2><p>For over a year, the primary obstacle to staking-enabled ETF structures in the United States was legal uncertainty about whether staking rewards constituted securities. That uncertainty was resolved in a single regulatory event.</p><p>The SEC and CFTC issued a joint interpretive release on March 17, 2026, that classified staking rewards from 16 named digital commodities, including ETH, as non-securities, confirming that protocol staking is not a securities transaction and that staking rewards do not create a securities-type relationship. The interpretive release explicitly covers solo, self-custodial, custodial, and liquid staking models. None of these structures triggers securities law obligations. Source: <a href="https://www.jenner.com/en/news-insights/client-alerts/sec-and-cftc-issue-landmark-joint-interpretation-on-crypto-asset-classification?ref=p2p.org">Jenner & Block LLP</a></p><p>The regulatory shift formalized what the market had already begun pricing in. BlackRock debuted the iShares Staked Ethereum Trust on Nasdaq on March 12, 2026, with $107 million in seed assets, staking 70 to 95% of its holdings and distributing monthly protocol-attributed participation rewards. The March 17 ruling then removed the remaining legal uncertainty that had kept other issuers on the sidelines. US spot ETH ETFs now hold approximately $12 billion in combined assets with roughly $11.6 billion in cumulative net inflows since launch. Source: <a href="https://www.coindesk.com/markets/2026/03/12/blackrock-debuts-staked-ether-etf-as-demand-grows-for-yield-in-crypto-funds?ref=p2p.org">CoinDesk</a></p><p>The ruling also expanded the addressable market for institutional staking infrastructure well beyond Ethereum. The commodity classification means compliance departments no longer have such grounds to restrict exposure based on securities risk, applying to proof-of-stake assets across the named 16 and validating existing staking products, including ETFs and exchange-based products. The addressable market for institutional staking infrastructure expanded materially on March 17. Source: <a href="https://bitcoinfoundation.org/news/ethereum/major-ethereum-updates-2026/?ref=p2p.org">Bitcoin Foundation</a></p><p>For ETF issuers that have not yet built a staking-enabled structure, one major legal barrier has been removed. What remains is an operational and procurement decision: which validator infrastructure supports a regulated product at the scale, compliance posture, and risk profile an ETF sponsor requires.</p><h2 id="why-validator-infrastructure-is-now-a-regulated-products-backend">Why Validator Infrastructure Is Now a Regulated Product's Backend</h2><p>The framing that most ETF issuers still apply to validator infrastructure is wrong. They treat it as a utility service purchased at a rate. It is not.</p><p>Staking-enabled spot ETFs do not just give institutions exposure to ETH or SOL. They create a structural, recurring source of validator demand that flows to compliant, non-custodial infrastructure underneath the product wrapper. ETF issuers and their custodians source validator infrastructure the way they source prime brokerage: on counterparty risk. Source: <a href="https://p2p.org/economy/institutional-crypto-investment-in-2026-what-q1-capital-flows-mean-for-validator-demand/">P2P.org Blog</a></p><p>That framing has direct operational implications. When a validator provider goes offline, misses attestations, or suffers a configuration error, the protocol responds with penalties. Those penalties reduce the participation rewards that the ETF distributes to shareholders. A validator infrastructure failure is not an internal IT incident. It is a fund-level performance event with a direct impact on the product the issuer has marketed to regulated investors.</p><p>For regulated financial institutions and custodians, third-party infrastructure providers sit inside the same vendor due diligence process as any cloud provider or payment processor. Before a contract clears internal security review, the provider typically needs to demonstrate recognized certifications, with SOC 2 Type II and ISO 27001 coming up most consistently because they map directly onto the control categories these institutions already audit internally across access management, incident response, availability, and data integrity. Source: <a href="https://chainstack.com/soc-2-type-ii-iso-27001-blockchain-node-infrastructure/?ref=p2p.org">Chainstack</a></p><p>The procurement workflow is the one ETF issuers already know. The evaluation framework is not new. What is new is that validator infrastructure now belongs inside it.</p><h2 id="the-four-dimensions-of-etf-grade-validator-infrastructure-evaluation">The Four Dimensions of ETF-Grade Validator Infrastructure Evaluation</h2><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://p2p.org/economy/content/images/2026/07/etf-validator-infrastructure-evaluation-framework.jpg" class="kg-image" alt="" loading="lazy" width="1600" height="900" srcset="https://p2p.org/economy/content/images/size/w600/2026/07/etf-validator-infrastructure-evaluation-framework.jpg 600w, https://p2p.org/economy/content/images/size/w1000/2026/07/etf-validator-infrastructure-evaluation-framework.jpg 1000w, https://p2p.org/economy/content/images/2026/07/etf-validator-infrastructure-evaluation-framework.jpg 1600w" sizes="(min-width: 720px) 720px"><figcaption><span style="white-space: pre-wrap;">The four dimensions ETF issuers should run against any validator provider before delegating staking exposure inside a regulated product structure.</span></figcaption></figure><h3 id="1-uptime-and-attestation-performance">1. Uptime and Attestation Performance</h3><p>Validator infrastructure for an ETF product requires 24/7 operational continuity without exception. When a validator goes offline, it misses block proposals and attestations. Those missed events reduce protocol-attributed participation rewards directly.</p><p>The evaluation question is not whether a provider advertises high uptime. It is whether the provider can evidence it across an independently verifiable observation period. Commission rates are the most visible differentiator between providers and the least informative. A provider with a higher commission rate, strong uptime history, and documented slashing protection will consistently produce better outcomes for an ETF product than a provider with a lower rate on shared cloud infrastructure with no operational redundancy.</p><p>For ETF issuers, the specific questions to put to any validator provider are:</p><p>What is the documented uptime rate across the past 12 months, and is it independently verifiable?</p><p>Is infrastructure distributed across multiple geographic regions and cloud providers, or concentrated in a single data center?</p><p>What is the failover architecture, and has automated failover been tested under production conditions?</p><p>What does the monitoring stack look like, and how are anomalies escalated?</p><h3 id="2-slashing-protection-architecture">2. Slashing Protection Architecture</h3><p>Slashing is the protocol-level penalty applied to validators that behave maliciously or experience specific configuration failures. For an ETF product, a slashing event is a capital loss event that the issuer must disclose and that directly reduces net asset value.</p><p>How a provider manages validator signing keys is one of the most critical security considerations most critical security consideration. Leading providers use hardware security modules for key storage and multi-party computation for key operations, ensuring that no single individual or process can unilaterally sign a transaction.</p><p>The slashing risk that ETF issuers need to understand is not just individual validator failure. It is a correlated failure. If a provider operates a large concentration of an issuer's validator set on a shared infrastructure stack, a single software bug, cloud region outage, or configuration error can affect multiple validators simultaneously. The correlation penalty on Ethereum scales with the total ETH slashed across the network in the surrounding period, meaning correlated failures produce penalties that are materially larger than the sum of individual events.</p><p>Questions for provider evaluation:</p><p>Does the provider use hardware security modules and multi-party computation for key operations?</p><p>What is the slashing incident history across the provider's full validator set?</p><p>What is the provider's approach to client diversity across consensus implementations?</p><p>How are signing keys isolated across different client accounts?</p><p><a href="http://p2p.org/?ref=p2p.org">P2P.org</a> has maintained a zero-slashing-incident track record since 2018 across 40+ proof-of-stake networks, with dedicated hardware, geographic distribution, and client diversity across consensus implementations as standard infrastructure architecture.</p><h3 id="3-non-custodial-architecture-and-key-control">3. Non-Custodial Architecture and Key Control</h3><p>For ETF staking structures, non-custodial architecture is not a preference. It is a structural requirement.</p><p>Non-custodial staking infrastructure is suitable for ETF staking because it gives the issuer, not the infrastructure provider, control of client assets. The institution retains control of private keys and withdrawal credentials at all times. This model reduces counterparty risk and aligns with most institutional custody mandates.</p><p>The custody question is the most consequential due diligence item for an ETF sponsor's legal team. In a custodial staking arrangement, the provider holds private keys and withdrawal credentials. In the event of provider insolvency, regulatory enforcement, or operational failure, the assets may be inaccessible or treated as part of the provider's estate. That custody risk is not acceptable inside a regulated ETF structure.</p><p>Issuers should confirm explicitly:</p><p>Does the provider take custody of private keys or withdrawal credentials at any point?</p><p>Who holds withdrawal address control throughout the staking lifecycle?</p><p>What is the technical mechanism through which the issuer retains key custody while the provider operates validation?</p><p>How does the provider's custodian integration work, and which custodians have native integrations?</p><h3 id="4-compliance-attestations-and-vendor-risk-program-fit">4. Compliance Attestations and Vendor Risk Program Fit</h3><p>SOC 2 Type II provides audited evidence that security controls actually work, measured continuously over a three to twelve-month observation period rather than a single point-in-time assessment. Together with ISO 27001, these certifications answer the due diligence requirements of institutional clients who need institutional-grade security assurances before routing assets through validator infrastructure.</p><p>For ETF issuers operating under fiduciary obligations, a validator provider without SOC 2 Type II attestation creates a gap in the issuer's own vendor risk program. The compliance team cannot map an unattested provider's controls onto the institution's internal security framework. The deal stalls or the provider is excluded from consideration.</p><p>The compliance evaluation should include:</p><p>Current SOC 2 Type II report: scope, observation period, and any exceptions noted</p><p>ISO 27001 certification status and Statement of Applicability</p><p>Jurisdictional compliance posture for the markets the ETF will serve</p><p>Business continuity and disaster recovery documentation</p><p>Incident notification and reporting commitments under contract</p><hr><blockquote><strong>The institutional digital asset space moves fast.</strong><br><br>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>.<br><br>No noise. Just the signals that matter.<br><br><strong>Subscribe to the newsletter at the bottom of this page.</strong></blockquote><hr><h2 id="the-etf-validator-infrastructure-evaluation-checklist">The ETF Validator Infrastructure Evaluation Checklist</h2><p>The checklist below is structured for the procurement motion ETF issuers already run for other regulated infrastructure counterparties. It is organized by evaluation category, not by provider marketing claims.</p><h3 id="operational-performance">Operational performance</h3><p>[ ] Documented uptime rate across a minimum 12-month independently verifiable observation period</p><p>[ ] Multi-region, multi-cloud or bare-metal infrastructure with no single geographic concentration</p><p>[ ] Automated failover with documented recovery time objective</p><p>[ ] 24/7 monitoring with defined escalation protocols and incident notification timelines</p><h3 id="slashing-protection">Slashing protection</h3><p>[ ] Zero or documented-near-zero slashing history across the full validator set, not just client-specific validators</p><p>[ ] Hardware security module used for key storage with multi-party computation for key operations</p><p>[ ] Client diversity across consensus implementations (minimum two consensus clients in production)</p><p>[ ] Documented approach to isolating signing keys across client accounts</p><h3 id="custody-and-key-control">Custody and key control</h3><p>[ ] Explicit contractual confirmation that the provider does not take custody of private keys or withdrawal credentials</p><p>[ ] Withdrawal address control retained by the issuer or designated custodian throughout</p><p>[ ] Native integrations with the issuer's existing custodian(s)</p><p>[ ] Clear technical documentation of the key custody architecture</p><h3 id="compliance-attestations">Compliance attestations</h3><p>[ ] Current SOC 2 Type II report: read the report’s scope and exceptions rather than filing it without review</p><p>[ ] ISO 27001 certification with current Statement of Applicability</p><p>[ ] Jurisdictional compliance documentation for relevant markets</p><p>[ ] Business continuity and disaster recovery plans reviewed and tested</p><p>[ ] Contractual incident notification obligations confirmed</p><h3 id="counterparty-risk">Counterparty risk</h3><p>[ ] Provider concentration across the issuer's validator set assessed and within acceptable limits</p><p>[ ] Fourth-party dependencies (cloud providers, infrastructure subcontractors) documented</p><p>[ ] Provider financial standing reviewed</p><p>[ ] Governance and key personnel stability assessed</p><h3 id="reporting-and-integration">Reporting and integration</h3><p>[ ] Validator-level reporting available for NAV calculation and shareholder distribution workflows</p><p>[ ] Audit trail documentation compatible with internal compliance reporting requirements</p><p>[ ] API or custodian integration confirmed for reward attribution and reconciliation</p><h2 id="what-correlated-failure-risk-means-for-etf-products">What Correlated Failure Risk Means for ETF Products</h2><p>One risk category that most ETF issuers underweight is provider concentration. A large staking position delegated entirely to a single validator provider on a shared infrastructure stack introduces correlated failure exposure that individual uptime statistics do not capture.</p><p>As institutions deploy into staking, the infrastructure requirements extend beyond standard validator operations to include actively validated service participation, slashing risk management across multiple protocols, and more complex reporting requirements. Source: <a href="https://bitcoinfoundation.org/news/ethereum/major-ethereum-updates-2026/?ref=p2p.org">Bitcoin Foundation</a></p><p>For an ETF product, correlated failure has three forms that the issuer's risk committee needs to evaluate:</p><h3 id="1-infrastructure-concentration">1. Infrastructure concentration</h3><p>If the provider runs all of an issuer's validators on the same cloud region or software stack, a single outage affects the full position simultaneously.</p><h3 id="2-network-level-concentration">2. Network-level concentration</h3><p>If the issuer's provider controls a large share of total staked ETH on the network, a provider-wide failure triggers network-level events including delayed finality and emergency protocol responses that affect every participant.</p><h3 id="3-client-concentration">3. Client concentration</h3><p>If the provider runs a single consensus client implementation across its full validator set, a client-specific bug affects all validators simultaneously. Client diversity across implementations is the mitigation, not a preference.</p><p>Risk committees evaluating validator providers should request explicit documentation of the provider's infrastructure architecture, client diversity posture, and concentration limits per client account.</p><h2 id="key-takeaway">Key Takeaway</h2><p>The March 2026 regulatory shift transformed staking-enabled ETFs from a compliance question into an operational one. For custodians, asset managers, ETF and ETP issuers, treasury teams, staking product managers, and risk committees, the validator infrastructure decision is now a counterparty risk decision that belongs inside the same procurement framework applied to prime brokers and custodians.</p><p>The evaluation framework is built on four dimensions: uptime and attestation performance evidenced over a verifiable observation period; slashing protection architecture grounded in hardware security modules and client diversity; non-custodial key control that keeps withdrawal credentials with the issuer throughout; and compliance attestations, including SOC 2 Type II, that fit into the institution's vendor risk program. Rate optimization is the last consideration, not the first.</p><p>Institutions that build validator infrastructure evaluation on operational commitments rather than headline rates are better positioned to protect the regulated product their investors hold.</p><p>To explore how <a href="http://p2p.org/?ref=p2p.org">P2P.org</a> supports ETF issuers and institutional staking programs with non-custodial validator infrastructure, visit <a href="https://p2p.org/networks?ref=p2p.org">p2p.org/networks</a>.</p><h2 id="frequently-asked-questions-faq">Frequently Asked Questions (FAQ)</h2><h3 id="what-did-the-march-2026-sec-and-cftc-ruling-change-for-etf-issuers-evaluating-staking-infrastructure">What did the March 2026 SEC and CFTC ruling change for ETF issuers evaluating staking infrastructure?</h3><p>The joint interpretive release issued on March 17, 2026, classified staking rewards from 16 named digital commodities, including ETH as non-securities. The ruling explicitly confirmed that protocol staking is not a securities transaction and that staking rewards do not create a securities-type relationship between validators and token holders. For ETF issuers, this removed the primary legal basis on which institutional compliance departments had restricted staking-enabled product structures. Compliance officers who had blocked staking ETF development on securities grounds can no longer cite that uncertainty. The ruling validated existing staking ETF products and cleared the approval path for new ones across the 16 named assets. The operational and procurement question is all that remains.</p><h3 id="why-does-non-custodial-architecture-matter-specifically-for-etf-staking-products">Why does non-custodial architecture matter specifically for ETF staking products?</h3><p>In a custodial staking arrangement, the validator provider holds private keys and withdrawal credentials on behalf of the client. In the event of provider insolvency, regulatory enforcement action, or operational failure, the staked assets may be inaccessible or treated as part of the provider's estate. For an ETF product operating under fiduciary obligations, that counterparty exposure is not acceptable. Non-custodial architecture means the issuer or its designated custodian retains control of private keys and withdrawal credentials throughout the staking lifecycle. The validator provider operates the consensus infrastructure but cannot access or move the underlying assets. This model aligns with most institutional custody mandates and is the structure that regulated ETF products require.</p><h3 id="what-compliance-attestations-should-etf-issuers-require-from-a-validator-provider">What compliance attestations should ETF issuers require from a validator provider?</h3><p>SOC 2 Type II is the baseline. It provides independently audited evidence that a provider's security and operational controls function as designed, measured over a continuous observation period rather than a single point-in-time assessment. Issuers should read the report for scope and any noted exceptions rather than filing it as received. ISO 27001 certification adds a governance layer, covering the policies and risk management processes that define how the provider protects its information assets. Issuers operating across European markets should also assess provider compliance posture against DORA and MiCA requirements. Providers that cannot produce current attestations create a gap in the issuer's own vendor risk program that the compliance team will flag during internal review.</p><h3 id="how-should-etf-issuers-think-about-provider-concentration-risk">How should ETF issuers think about provider concentration risk?</h3><p>Delegating a large staking position entirely to a single validator provider on a shared infrastructure stack introduces correlated failure exposure that individual uptime statistics do not surface. If a provider's infrastructure fails across a cloud region, all validators in that region fail simultaneously. If a provider uses a single consensus client across its full validator set, a client-specific bug affects all validators at once. At the network level, a provider controlling a large share of total staked ETH introduces systemic exposure that affects all participants in a network-level event. Risk committees should request explicit documentation of a provider's infrastructure architecture, client diversity posture across consensus implementations, and concentration limits per client account. These are not secondary considerations. They belong in the same risk model as individual validator uptime.</p><h3 id="what-is-the-difference-between-how-etf-issuers-should-evaluate-validator-infrastructure-versus-how-other-institutional-stakers-do">What is the difference between how ETF issuers should evaluate validator infrastructure versus how other institutional stakers do?</h3><p>The evaluation framework is similar in structure but different in stakes. Any institutional staker should assess uptime history, slashing protection, key custody architecture, and compliance attestations. For ETF issuers specifically, the consequences of infrastructure underperformance are fund-level events: reduced participation rewards that flow directly to shareholder distributions, potential NAV impacts that require disclosure, and vendor risk program requirements that apply to all regulated counterparties. The validator provider sits inside the ETF's operational stack in the same category as a prime broker or custodian. The procurement standards that apply to those relationships apply here. Rate optimization is relevant but secondary. Operational commitments, compliance standing, and counterparty risk documentation are the primary evaluation criteria.</p><h3 id="how-does-ethereum-validator-infrastructure-differ-from-solana-validator-infrastructure-for-etf-staking-products">How does Ethereum validator infrastructure differ from Solana validator infrastructure for ETF staking products?</h3><p>The two networks have structurally different validator economics and operational profiles that shape how an issuer provisions infrastructure for each. Ethereum validators operate in fixed stake units with an activation and exit queue, while Solana validators stake across variable delegation amounts with different unbonding mechanics. Protocol-attributed participation reward rates also differ: Solana runs at approximately 6% to 7% gross versus Ethereum's approximately 3.1% to 3.3% at current network conditions. For multi-asset staking ETF products, these differences are structural inputs to infrastructure provisioning and reward distribution design, not comparable rates on a single scale. Issuers building multi-network staking products need provider infrastructure and reporting capability that handles both networks independently, with validator-level reward attribution for each.</p><hr><p><strong>About </strong><a href="http://p2p.org/?ref=p2p.org"><strong>P2P.org</strong></a></p><p>Founded in 2018, <a href="http://p2p.org/?ref=p2p.org">P2P.org</a> 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 40+ proof-of-stake networks, <a href="http://p2p.org/?ref=p2p.org">P2P.org</a> maintains a zero-slashing-incident track record, is trusted by over 190 institutional clients and is SOC 2 Type II attested. To explore how <a href="http://p2p.org/?ref=p2p.org">P2P.org</a> 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><hr><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
<h2 id="learnings-for-busy-readers"><strong>Learnings for Busy Readers</strong></h2><p>- The Vault has integrated P2P.org non-custodial validator infrastructure directly into its institutional custody platform.</p><p>- Clients can access protocol staking rewards on supported assets without moving those assets outside the custody environment.</p><p>- The integration launches with Ethereum (ETH) and TRON (TRX), with additional networks planned over time.</p><p>- Assets remain segregated and under client custody throughout. Delegation is non-custodial, so P2P.org never takes possession of client funds.</p><p>- The design removes a common tradeoff for regulated institutions: reaching staking infrastructure without stepping outside the controls they already operate.</p><h2 id="the-problem-staking-access-usually-means-leaving-custody"><strong>The Problem: Staking Access Usually Means Leaving Custody</strong></h2><p>For most institutions, putting on-chain assets to work has meant accepting operational complexity and additional counterparty exposure. Reaching staking infrastructure typically requires transferring assets from the custody environment, introducing friction that regulated entities often find operationally unacceptable.</p><p>That friction is not a matter of preference. It is a function of how these institutions are governed. Segregation of assets, defined approval workflows, and auditable movement of funds are baseline requirements, not optional controls. Any process that requires an institution to move assets outside its custody perimeter to access protocol rewards runs directly counter to those requirements.</p><p>The result is a familiar standoff. Demand for on-chain participation is real, but the operational path to it has carried tradeoffs that many institutions were not willing to make.</p><h2 id="who-the-vault-is"><strong>Who The Vault Is</strong></h2><p>The Vault is a Swiss and EU-regulated institutional infrastructure platform for digital assets. It covers the full lifecycle, from secure custody and treasury operations to back-office management and wallet infrastructure, and is built on proprietary threshold MPC cryptography developed by an in-house research team. It is available in three deployment models — SaaS, Hybrid, and On-Premise — with a bespoke modular architecture that can be customised to each company's needs and frameworks.</p><p>The platform serves institutional clients across several segments, including corporate treasuries, financial institutions, professional asset managers, family offices, and payment providers. It is available in three deployment models, SaaS, Hybrid, and On-Premise, with a modular architecture that can be configured to each institution's operating and compliance frameworks.</p><p>The P2P.org integration fits a broader roadmap: consolidating custody, treasury operations, and asset utilization within a single regulated framework, so institutions manage more of their on-chain activity in one controlled environment rather than across disconnected systems.</p><h2 id="the-integration-validator-infrastructure-inside-the-custody-perimeter"><strong>The Integration: Validator Infrastructure Inside the Custody Perimeter</strong></h2><p>The Vault embeds P2P.org institutional-grade validator infrastructure natively into its platform. Clients retain full custody of their assets while accessing protocol staking rewards through the same interface and workflows they already use.</p><p>The mechanism matters. P2P.org operates non-custodial validator infrastructure, which means delegation happens without transferring ownership of the underlying assets. Clients delegate to validators operated by P2P.org, and the assets remain segregated within The Vault's custody environment throughout. Rewards are generated by the network protocol, not by P2P.org, and accrue according to each network's reward schedule.</p><p>For the institution, the practical change is that staking stops being a separate operational track. It becomes a function inside the environment where custody, treasury operations, and reporting already live.</p><h2 id="operational-depth-how-delegation-works-in-practice"><strong>Operational Depth: How Delegation Works in Practice</strong></h2><p>Within The Vault's platform, delegation runs through the same authorization and approval controls that govern other asset movements. Institutions do not adopt a parallel workflow to stake.</p><p>Assets stay segregated and auditable. Because delegation is non-custodial, the custody relationship between the institution and The Vault is not altered by the act of staking. Real-time monitoring of validator performance sits with P2P.org, whose operations are SOC 2 Type II certified, audited by KirkpatrickPrice. Reporting on delegated positions and accrued protocol rewards is available within the platform, which keeps position data and treasury data in one place rather than split across systems.</p><p>The launch scope of Ethereum and TRON reflects two networks with distinct staking mechanics, and the roadmap adds further networks over time. Each additional network carries its own delegation parameters, reward schedule, and risk profile, which are evaluated before support is added.</p><h2 id="governance-and-capital-implications"><strong>Governance and Capital Implications</strong></h2><p>The governance point is the one that regulated institutions tend to weigh most heavily. Staking inside custody means the institution does not surrender control to participate.</p><p>Approval hierarchies, segregation of duties, and audit trails remain intact because the assets never leave the custody perimeter. The institution directs its own delegation. P2P.org provides the validator infrastructure and operates it, but does not take custody, does not exercise discretion over client assets, and does not act as an intermediary that holds funds. This distinction, between operating infrastructure and taking possession, is central to how the arrangement fits within institutional governance frameworks.</p><p>For treasuries and asset managers, the capital implication is straightforward. Assets that were previously idle in custody can access protocol rewards without a separate custody arrangement, a new counterparty relationship, or a break in the audit trail. The decision to stake becomes an operational choice inside existing controls rather than a structural exception to them.</p><h2 id="evaluating-the-validator-layer"><strong>Evaluating the Validator Layer</strong></h2><p>For institutions assessing this kind of integration, the validator operator is a core part of the diligence, not a detail. </p><p>A short checklist:</p><p>- Track record: length of operation and slashing history across networks. P2P.org has operated since 2018 with no slashing incidents across seven years.</p><p>- Certification: independent audit of operational controls. P2P.org is SOC 2 Type II certified, audited by KirkpatrickPrice, and holds an AAA Verified Staking Provider rating.</p><p>- Scale: delegated assets and network coverage as a signal of operational maturity. P2P.org secures over $10 billion in delegated assets across 40+ networks.</p><p>- Custody model: confirmation that delegation is non-custodial and that assets remain segregated.</p><p>- Monitoring: validator performance monitoring and transparent reporting.</p><p>The point of the checklist is that the operational quality of the validator layer is inseparable from the security of the position. Embedding infrastructure inside custody raises the bar on operator diligence rather than lowering it.</p><h2 id="key-takeaway-for-institutional-teams"><strong>Key Takeaway for Institutional Teams</strong></h2><p>For custodians, treasuries, and asset managers, the integration reframes staking as a function inside custody rather than a reason to leave it. Institutions access protocol staking rewards on ETH and TRX without moving assets outside their custody environment, while segregation, approval controls, and audit trails stay intact. The protocol-level risks of proof-of-stake remain and should be underwritten directly. What changes is the operational path to access, which becomes materially cleaner for organisations that cannot compromise on control.</p><h2 id="faq"><strong>FAQ</strong></h2><p><strong>Does staking through this integration move my assets out of custody?</strong> No. Delegation is non-custodial and assets remain segregated within The Vault's custody environment. P2P.org operates the validator infrastructure but does not take possession of client assets.</p><p><strong>Which networks are supported at launch?</strong> Ethereum (ETH) and TRON (TRX), with additional networks planned over time. Each new network is evaluated for its delegation parameters and risk profile before support is added.</p><p><strong>Who generates the staking rewards?</strong> Rewards are generated by each network protocol according to its reward schedule. Reward rates are variable and set by the network, not fixed or promised by The Vault or P2P.org.</p><p><strong>What happens to my custody controls when I stake?</strong> They remain in place. Delegation runs through the same authorization and approval workflows that govern other asset movements, and audit trails are preserved because assets do not leave the custody perimeter.</p><p><strong>How is validator risk managed?</strong> P2P.org operates with slashing protection controls, provides real-time monitoring, and is SOC 2 Type II certified. Slashing risk is inherent to proof-of-stake networks that impose it and should be evaluated as part of institutional diligence.</p><h2 id="explore-the-integration"><strong>Explore the Integration</strong></h2><p>Custodians, treasuries, and asset managers interested in accessing staking inside their custody environment can contact P2P.org to discuss network coverage, delegation parameters, and onboarding.</p>
from p2p validator
<p>Institutional capital on Solana has a visible layer and a working layer. The visible layer is the announcement flow: new treasury deployments, new stablecoin pilots, new settlement rails. The working layer is what practitioners inside regulated institutions deal with before any of that goes live, and those questions rarely surface in launch coverage.</p><p>On June 30, P2P.org hosted Institutional Capital on Solana: From Allocators to Whales, an institutional roundtable exploring how professional investors are evaluating the Solana ecosystem today.</p><p>Moderated by Liza Balandina, Solana Ecosystem Lead at P2P.org, the discussion featured Catherine Gu (Head of Product, Digital Assets, Solana Foundation), Thibault Dubuis (Head of Staking & DeFi, Sygnum Bank), Aleksandar Bukovski (Research Lead, The Big Whale), and Ben Harvey (Digital Asset Researcher, Keyrock). Together, they explored institutional adoption, staking, data transparency, and what it will take to unlock the next wave of capital entering the network.</p><p>This recap highlights the four themes that emerged most consistently throughout the discussion: regulatory and compliance considerations, the need for reliable on-chain data, how institutions evaluate validators, and the emerging native staking vaults category sitting between native staking and DeFi.</p><p><strong>LEARNINGS FOR BUSY READERS</strong></p><ul><li>Compliance sign-off is what stalls institutional allocation to Solana. The technology itself has moved past the question.</li><li>The public chain vs regulated finance dichotomy is closing: JPMorgan, Visa, Mastercard, and Franklin Templeton are already live on Solana.</li><li>Data reliability is a compliance question. The same metric can differ by billions across providers, and the Solana Foundation's new aggregation layer is the first attempt to fix it.</li><li>Institutional validator evaluation comes down to reporting depth: reward attribution, key recovery, SOC 2.</li><li>A middle category is emerging where staked SOL is used as collateral while remaining delegated to the validator, giving institutions access to lending without holding a wrapped derivative. </li></ul><h2 id="compliance-surface-where-allocation-actually-stalls"><strong>Compliance surface: where allocation actually stalls</strong></h2><p>Aleksandar Bukovski opened with the answer most of the ecosystem prefers to avoid. Across the large banks in his research audience, compliance sign-off is the number one prohibitor of Solana allocation. The hesitation is rarely about the chain itself and rarely about volatility in isolation. It is about what a risk committee has to approve.</p><p>The friction shows up at the committee level. An analyst who wants to allocate has to walk the risk committee through what the exposure actually is, how it maps to the institution's existing custody policy, and what happens under stress. That work is heavy for any new asset. It gets heavier when the asset requires the institution to hold something its custody policy never anticipated.</p><p>Catherine Gu named the misconception sitting underneath this. Many institutions still assume that public-chain participation and regulated financial infrastructure exclude each other: that a public chain means the wild west, and that regulated work requires a permissioned setting where liquidity is sacrificed. On Solana, where JPMorgan, Visa, Mastercard, and Franklin Templeton are already running live products, the two coexist. The gap she identified is awareness. Institutions have not yet fully absorbed what the technology already delivers.</p><p>Thibault Dubuis reinforced the point from the field. Describing the discourse at institutional events such as Point Zero in Zurich, he noted that the conversation has moved from building proprietary chains to a more practical question:</p><blockquote><em>Very few people were saying we are going to build our own chain. Super senior people from very big financial institutions were now asking: how am I going to use this public chain?</em><br><br>Thibault Dubuis, Sygnum Bank</blockquote><h2 id="the-data-question-what-allocators-need-before-trusting-on-chain-metrics"><strong>The data question: what allocators need before trusting on-chain metrics</strong></h2><p>The data thread produced the sharpest exchange of the panel. Catherine described what surprised her when the Foundation's data work began: the same metric, calculated by different providers, can differ by billions of dollars. For an allocator building a portfolio thesis, that discrepancy is fatal.</p><p>The Foundation's response is the recently launched aggregation layer at solana.com/data, which benchmarks eight to nine data providers side by side across stablecoin supply, DEX volume, fees, active addresses, and transactions. Catherine positioned the effort as neutral infrastructure. The Foundation does not want to set the standard. It wants to give data providers a coordinated venue to reconcile with one another:</p><blockquote><em>The truth is out there. I do not think it is a single provider who should be setting the standard. We want to be neutral and include all the top players collecting data right now, so it gives them a chance to coordinate and reconcile between one another.</em><br><br>Catherine Gu, Solana Foundation</blockquote><p>Aleksandar pushed for a further step. His reference frame came from traditional finance: the big four auditor structure, and the distinction between a 10-K and a 10-Q. The audited annual filing carries a different weight of trust than the quarterly self-report. In his view, Solana's data layer needs a similar independent-auditor structure, so a risk committee can underwrite the numbers rather than trust a single provider.</p><p>Thibault illustrated how a regulated institution handles the problem today. Sygnum runs full nodes, performs its own indexing every two epochs, and cross-checks every reward calculation against a third-party shadow instance. The reason is regulatory rather than technical: reward bookings in a core banking system must be defensible under audit. The Swiss tax authority treats MEV rewards as VAT-taxable service revenue, while consensus rewards receive different treatment. Which means validator reporting has to distinguish the two at a granularity a bank's operations department can defend to a regulator.</p><h2 id="what-institutional-grade-validator-infrastructure-looks-like-in-practice"><strong>What institutional-grade validator infrastructure looks like in practice</strong></h2><p>Asked what Sygnum actually evaluates when selecting a validator, Thibault's answer was, in his own framing, less technical than the industry usually expects.</p><p>The list: withdrawal-key configuration and the fund-recovery process, SOC 2 credentials and operational certifications, track record on chain, whether the operator can run test-network operations for pre-flight validation, and the granularity of downstream reporting. The emphasis sits on that last point. If a validator cannot cleanly report which portion of rewards came from consensus and which came from MEV, the client bank cannot cleanly book those rewards for tax and audit purposes. If the reporting is not clean, the operator does not clear evaluation.</p><p>OFAC-compliance capability also came up, less as a current requirement than as optionality the institution wants to know exists in case regulators require it later.</p><p>The picture Thibault drew is that institutional-grade, inside a treasury risk committee, means operational depth behind the reporting rather than peak performance numbers. This maps to how P2P.org approaches its own validator profile on Solana: non-custodial architecture across 40+ networks, SOC 2 controls, an explicit regulatory posture, and a dedicated test environment where new client builds, MEV behavior, and edge cases run before reaching a delegated mainnet position.</p><h2 id="the-vault-middle-category-between-native-staking-and-defi"><strong>The vault middle category between native staking and DeFi</strong></h2><p>The most concrete design question of the panel came in the DeFi section. Liza framed it directly: native staking is the safest way to optimize an institutional portfolio, DeFi is where the compliance friction lives, and a middle category has emerged where native stake is used as collateral without a full DeFi posture. The question was whether this is a structural bridge or a relabeling.</p><blockquote><em>If you are looking at it in terms of underwriting, it is definitely just relabeling the same risk. You have to underwrite the same risk, but it is packaged in a way that makes it slightly more attractive for different players. </em><br><br>Ben Harvey, Keyrock</blockquote><p>Aleksandar added the compliance side of the same picture. Institutional compliance teams find LSTs particularly hard to underwrite because the wrapper introduces a systemic layer on top of the underlying stake. His example was blunt: what happens if the issuer goes down? Native protocol rewards are already something risk committees are learning to model. A wrapped derivative multiplies the questions.</p><p>From P2P.org's perspective, the key distinction lies in what happens to the underlying staking position. In an LST-mediated setup, the treasury holds a wrapped derivative on its balance sheet. In a native staking vault design, the treasury continues to hold natively delegated SOL while the position is represented within the lending protocol through a protocol-specific token rather than a treasury-held wrapper.</p><p>While the overall economic risk is not necessarily reduced, the underwriting requirements change. LST-mediated positions require institutions to assess the wrapper, its issuer, governance model, and custody treatment alongside the underlying stake. Native staking vaults simplify that diligence by focusing on the underlying delegated position and the lending protocol itself. Whether this becomes the preferred institutional model will ultimately depend on how these designs evolve and how regulators and risk committees assess them.</p><h2 id="what-is-ahead"><strong>What is ahead</strong></h2><p>Catherine's read on the next 12 months centered on tokenization and stablecoins as two sides of the same coin. Solana already leads on stablecoin volume and liquidity by most metrics, and the natural sequencing brings more real-world asset issuance onto that liquidity base. Confidential transfers via the Token 22 program relaunched on mainnet in late June, giving stablecoin issuers a live privacy feature on regulated tokens, with further privacy solutions approaching mainnet.</p><p>Thibault's push was toward genuine on-chain issuance rather than tokenization of off-chain instruments:</p><blockquote><em>This stuff needs to be issued directly on chain, and this needs to be the source of truth. Until a judge says that if it did not happen on chain, it did not happen, a lot of the stuff we build on these blockchains is a bit pointless.</em><br><br>Thibault Dubuis, Sygnum Bank</blockquote><p>The closing round produced three takes worth keeping. Ben argued that ETFs, counterintuitively, have functioned as a partial blocker for on-chain capital: investment committees can point to the ETF allocation, claim the asset class is covered, and remove the internal pressure to push further on chain. Aleksandar's take was on layer one fragmentation:</p><blockquote><em>The layer one ecosystem right now is too fragmented. The industry is not big enough for 10,000 layer ones. Great consolidation needs to happen, and that fragmentation is sucking out liquidity and redirecting capital from the clear and obvious winners. </em><br><br>Aleksandar Bukovski, The Big Whale</blockquote><p>Thibault closed on market depth: much of the announcement flow is still marketing theater, and until DeFi pools on Solana can absorb an institutional-size liquidation without moving the whole market, institutional size remains an aspiration.</p><p><strong>KEY TAKEAWAY</strong></p><p>The institutional capital thesis on Solana is resolving at the infrastructure layer and stalling at the compliance layer. The bottleneck is the operational surface a risk committee has to sign off on for each new position. </p><p>Throughout the discussion, the panel highlighted how institutions are addressing these challenges in practice, including demonstrating asset segregation and liquidity to regulators, validating reward calculations through independent verification, distinguishing MEV from consensus rewards for accounting and tax purposes, and assessing vault-based staking products without introducing unnecessary layers of complexity.</p><p>Ultimately, the design distinctions that resolve these operational questions - reward attribution, position structure, audit trail - are what will determine which institutional segments deploy on Solana next.</p><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.</p><p><strong>FAQ</strong></p><p><strong>What did the P2P.org Institutional Capital on Solana webinar cover?</strong></p><p>The June 30 panel featured practitioners from Solana Foundation, Sygnum Bank, Keyrock, and The Big Whale, covering compliance friction on institutional allocation, data reliability as a compliance question, validator evaluation criteria, and the vault category between native staking and DeFi.</p><p><strong>What is the main compliance friction blocking institutional DeFi participation on Solana?</strong></p><p>Two overlapping constraints. Institutional treasuries need to prove to regulators that assets are segregated and available at all times, which conflicts with lending pools that can reach full utilization. And LST wrappers introduce additional diligence categories, including issuer risk and accounting classification, that compound across positions.</p><p><strong>How do institutions evaluate validator infrastructure on Solana?</strong></p><p>Sygnum's framework weighs withdrawal-key recovery, SOC 2 credentials, on-chain track record, testnet operations, and the granularity of reward reporting. Reporting carries the most weight because banks must distinguish consensus rewards from MEV rewards for tax and audit purposes.</p><p><strong>What is the difference between native staking, LSTs, and native staking vaults on Solana?</strong></p><p>Native staking delegates SOL to a validator, with protocol rewards accruing directly to the delegation. LSTs wrap the staked position into a derivative the treasury holds on its books, adding wrapper-related diligence. Native staking vaults keep the position delegated to the validator and represent it inside a lending protocol through a protocol-scoped token, without a treasury-held wrapper.</p><p><strong>Where can I watch the webinar replay?</strong></p><p>The full replay of Institutional Capital on Solana: From Allocators to Whales is available on <a href="https://www.youtube.com/watch?v=3izfwGyn2Ak&t=672s&ref=p2p.org" rel="noreferrer">Youtube</a> alongside this written recap.</p><p><strong>WORK WITH P2P.ORG ON SOLANA</strong></p><p>If your institution is evaluating what participation on Solana looks like in practice, the P2P.org team is available for that conversation. We work with institutional allocators across custody profiles. We can walk through the specific operational questions your treasury or risk committee is navigating, from validator evaluation criteria to reward reporting granularity. Explore P2P.org Solana staking infrastructure at p2p.org or reach the team on Telegram at @P2P_staking_support_bot</p>
from p2p validator
<p><strong>At a glance: </strong></p><ul><li>P2P.org is now live with Fireblocks </li><li>Fireblocks institutional clients can stake ETH natively within the platform - same custody model, same key management framework </li><li>P2P.org handles the creation and sunsetting of ETH validators.</li></ul><p>Institutional ETH staking has always involved a tradeoff. To stake, you either built your own validator infrastructure - operationally heavy, compliance-intensive, not what most institutions want to own - or you routed through a third-party provider in a way that introduced custody complexity and additional counterparty risk. Neither path fits cleanly inside the operational model of a custody-first institution.</p><p>The ETH-Link integration changes that. P2P.org now manages and operates ETH validators within the Fireblocks platform via the ETH-Link API. Fireblocks institutional clients can now access P2P.org's validator infrastructure directly within the Fireblocks platform - same custody model, same key management framework - with the full staking lifecycle managed by Fireblocks from end to end.</p><h2 id="p2porgs-role-in-the-stack"><strong>P2P.org's Role in the Stack</strong></h2><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/06/Infrographics.png" class="kg-image" alt="" loading="lazy" width="2000" height="430" srcset="https://p2p.org/economy/content/images/size/w600/2026/06/Infrographics.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/06/Infrographics.png 1000w, https://p2p.org/economy/content/images/size/w1600/2026/06/Infrographics.png 1600w, https://p2p.org/economy/content/images/size/w2400/2026/06/Infrographics.png 2400w" sizes="(min-width: 720px) 720px"></figure><p>Within the ETH-Link architecture, P2P.org's role is focused: we manage and operate ETH validators under Fireblocks' direction. That is the extent of our surface.</p><p>Deposits and validator lifecycle management are handled entirely by Fireblocks through their ETH-Link architecture. P2P.org does not touch any of it. Our validator infrastructure runs in the background - a blind guardian that never intervenes in custodied assets.</p><p>What qualifies P2P.org for this role goes beyond uptime numbers. We built a purpose-built key management system from the ground up - validator keys are stored in an air-gapped private vault with no public access, anchored by Hardware Security Modules (HSMs) and protected through Trusted Execution Environments (TEEs) for real-time encryption of all private key operations. No single person holds access. Our key operations have been fully audited by PwC.</p><p>For ETH specifically, validators run on threshold signature clusters (2 of 3 via Dirk) with strict access controls and no overlap between signers - meaning no single point of failure and no single point of compromise. A built-in slashing database actively protects staked assets from penalties. Our infrastructure spans geographically distinct regions across bare metal and cloud, with diversified consensus and execution clients to ensure resilience against any single point of failure in the broader ecosystem. All MEV extraction runs through OFAC-compliant relays.</p><p>Eight years. Zero slashing events. $10B+ staked. 99.9%+ uptime. SOC 2 Type II certified. This is the infrastructure Fireblocks chose as one of its first integrations within the ETH-Link architecture, enabling even more ETH staking options for its institutional clients.</p><h2 id="what-this-enables-for-fireblocks-clients"><strong>What This Enables for Fireblocks Clients</strong></h2><p>For institutional clients already on Fireblocks, the practical picture is straightforward:</p><p><strong>No new custody setup: </strong>ETH staking is available within the existing Fireblocks platform. There is no new provider relationship to establish at the custody level, no asset migration, no change to the key management model.</p><p><strong>No third-party routing:</strong> Assets do not leave the Fireblocks environment. Staking execution occurs within the platform's validator infrastructure, with P2P.org operating as a provider within that infrastructure rather than outside it.</p><p><strong>Enterprise SLAs and operational continuity: </strong> P2P.org's track record on uptime and slashing prevention applies within the integration. Clients get the execution quality of a purpose-built institutional staking provider without taking on the operational surface area of running that provider relationship separately.</p><p><strong>Institutional-grade validator security:</strong> P2P.org's validator infrastructure runs on air-gapped key vaults, HSM-anchored encryption, threshold signatures, and geographically distributed clusters - PwC-audited. Clients inherit that security posture without building or managing any of it.</p><p><strong>Expanded staking optionality:</strong> Rather than evaluating and onboarding a staking provider independently, clients can access institutional-grade validator infrastructure directly through the Fireblocks platform, with no new custody surface and no change to their existing operational model. </p><h2 id="the-broader-signal"><strong>The Broader Signal</strong></h2><p>ETH-Link is Fireblocks' approach to solving that design problem: a provider-agnostic interface that is minimal enough to be safe, standardized enough to work across multiple providers, and scoped narrowly enough that it does not require custody compromise on either side.</p><p>P2P.org's integration demonstrates that the interface works in production - that a staking provider with the operational depth to operate inside institutional-grade custody infrastructure can implement it cleanly and deliver the execution quality institutions need.</p><p>That combination - a well-designed custody-layer interface and a staking execution provider capable of operating within it - is what institutional-grade staking infrastructure actually looks like. The ETH-Link integration is a live example of it.</p><div class="kg-card kg-cta-card kg-cta-bg-grey kg-cta-minimal " data-layout="minimal"> <div class="kg-cta-sponsor-label-wrapper"> <div class="kg-cta-sponsor-label"> <a href="http://p2p.org/?ref=p2p.org" class="cta-link-color"><u><i><em class="italic underline" style="white-space: pre-wrap;">P2P.org</em></i></u></a><i><em class="italic" style="white-space: pre-wrap;"> provides validator infrastructure for institutional platforms. </em></i> </div> </div> <div class="kg-cta-content"> <div class="kg-cta-content-inner"> <div class="kg-cta-text"> <p><i><em class="italic" style="white-space: pre-wrap;">Talk to our team by filling out the contact form on our website.</em></i></p> </div> <a href="https://p2p.org/?ref=p2p.org" class="kg-cta-button " style="background-color: #000000; color: #ffffff;"> Learn more </a> </div> </div> </div>
from p2p validator
<h2 id="learnings-for-busy-readers"><br><strong>Learnings for Busy Readers</strong></h2><p>- TON is in active multi-front development under the MTONGA roadmap, driven by Pavel Durov. Recently shipped or in-flight items include the Catchain 2.0 consensus upgrade, network fee cuts, Telegram's renewed direct involvement in TON development, and the TON-to-GRAM token rebrand. Staking economics shifted as a downstream effect.</p><p>- TonWhales is P2P.org's TON staking infrastructure, trusted by Ledger, Copper, and BitGo. Institutions stake from as little as 10 TON, integrate directly into their platforms, and let users stake or unstake without limits or operational friction.</p><p><strong>TON is shipping</strong></p><p>TON is in active development across multiple fronts. </p><p>The broader effort, the MTONGA roadmap driven by Pavel Durov, sequences a series of network and ecosystem upgrades intended to scale the protocol's throughput, economics, and market position.</p><p>The most visible recent shipment is the Catchain 2.0 consensus upgrade, which moved block production to 400-millisecond intervals, dropped transaction finality to approximately one second from roughly ten seconds before, and added a streaming layer that pushes state updates directly to applications.</p><p>Main aspects of the upgrade: </p><ul><li>The TON Foundation has called the network up to 6x faster than the pre-upgrade baseline.</li><li>Catchain 2.0 was one part of a broader sequence. </li><li>Network fees have been cut. </li></ul><p>Telegram has resumed an active development posture on TON after a period of stepping back, reinforcing the deepest distribution channel in the ecosystem. The TON-to-GRAM token rebrand is in motion, reframing the asset for broader market adoption.</p><p>For institutions evaluating TON exposure, the most consequential downstream effect of all this activity sits in the staking economics.</p><h2 id="what-it-means-for-staking"><strong>What it means for staking</strong></h2><p>According to the TON Foundation, the consensus upgrade increased the rate at which validator rewards accrue. More blocks per unit of time means more reward-bearing events. </p><p>As a downstream effect, annual network inflation rose from around 0.6% to around 3.6%. The Foundation has explicitly stated that rewards will settle at a new equilibrium as staking participation grows.</p><p>Protocol-level staking reward rates on TON are presently elevated relative to the pre-upgrade baseline, and they vary with network-wide staking participation. </p><p>A lower participation ratio implies a higher reward share per staked unit. As more TON enters the staking set, the rate compresses toward equilibrium. **Both directions of that equation are decisions the protocol makes, not P2P.org.</p><p>TON's economic foundations changed in a way that materially affects the staking math, and the rate is likely to compress over time. The present window is structurally distinct from what comes after.</p><h2 id="tonwhales-as-the-access-layer"><strong>TonWhales as the access layer</strong></h2><p>TON's native staking primitives have institutional friction built in by default. </p><p>The Nominator Pool contract caps delegations at 40 addresses and imposes high minimums. The Single Nominator contract requires approximately 925,000 TON to participate and serves one delegator at a time. Both share a scalability problem: once a pool fills to the maximum stake per validator, a new pool deployment is required to keep accepting stake. </p><p>For institutions managing client mandates, distributed positions, or simply requiring programmatic access at scale, those primitives are not adequate on their own.</p><p>TonWhales sits above the native primitives as P2P.org's TON staking infrastructure. </p><p>The contract architecture splits responsibilities across specialized components: a Pool that aggregates client stakes, a Pool Proxy that handles the gas-expensive Masterchain interactions, a Controller that manages stake distribution across validators, and the validator itself, which never holds user funds. </p><p>The modular design reduces gas costs versus the Single Nominator contract and removes both the structural caps and the re-deployment friction.</p><p>For institutions and integrators, the practical result is that TonWhales removes the upper cap on aggregate stake, with new validators added automatically as the pool grows and no action required from delegators. </p><p>It removes the 40-delegator ceiling. It lowers the minimum stake to 10 TON. It supports partial withdrawals rather than all-or-nothing exits. </p><p>And it operates non-custodially throughout: the Pool contract holds the delegation programmatically, while the validator borrows pool funds to secure a seat in the validation set but never takes ownership. </p><p>Smart contracts have been independently audited by Quantstamp and Trail of Bits.</p><h2 id="p2porg-on-ton"><strong>P2P.org on TON</strong></h2><p>P2P.org has operated validator infrastructure since 2018 across more than 40 networks, and TonWhales runs on the same operational stack: redundant nodes, geographic distribution, automated failover, key management procedures, and 24/7 monitoring and incident response. </p><p>Operations are SOC 2 Type II certified by KirkpatrickPrice. AAA Verified Staking Provider rating.</p><p>On TON specifically, TonWhales is trusted by Ledger, Copper, and BitGo.</p><p>Eight years of validator operations, no slashing events on record. </p><p>That is the operational baseline institutional reviews price into TON delegation decisions.</p><h2 id="access-points"><strong>Access points</strong></h2><p>TonWhales is accessible across the full distribution surface, with vesting contract support across every integration path.</p><p>→ <strong>Public staking widget at</strong><a href="https://ton.p2p.org/deposit?ref=p2p.org"><strong> </strong></a><a href="http://ton.p2p.org/deposit?ref=p2p.org"><strong><u>ton.p2p.org/deposit</u></strong></a>: The widget is both an end-user interface for direct delegation and an embeddable component partners can drop into wallets, exchanges, or custody platforms. Deploys in under a week with no backend complexity required from the integrating partner, and includes a revenue-sharing model. </p><p>→ <strong>Native Ledger Live integration:</strong> TON staking through TonWhales is accessible inside the Ledger application for users managing TON through Ledger devices. P2P.org was one of the first validators to embed native TON staking into Ledger Live.</p><p>→ <strong>Unified API: </strong>Programmatic delegation and operational integration across the broader P2P.org staking footprint, including TON.</p><p>→ <strong>Custody platform integrations:</strong> Institutions running TON balances on either platform can stake into TonWhales without removing assets from their custody arrangement.</p><h2 id="key-takeaway"><strong>Key Takeaway</strong></h2><p>TON is shipping across multiple fronts, and protocol-level staking reward rates rose meaningfully from the pre-upgrade baseline as a downstream effect. </p><p>The rate will compress toward equilibrium as more TON enters the staking set, which makes the present window structurally distinct from what comes after. </p><p>TonWhales is the access infrastructure that lets institutions and individuals participate at scale: 10 TON minimum, unlimited delegators, and audited non-custodial smart contracts. </p><p>Trusted by Ledger, Copper, and BitGo.</p><h2 id="faq"><strong>FAQ</strong></h2><p><strong>What does the TON-to-GRAM token rebrand mean for staking?</strong></p><p>The TON-to-GRAM token rebrand is days from going official as of writing. The rebrand applies to the token ticker and asset identity only. The TON network, the TonWhales staking infrastructure, and the staking mechanics described in this article are unaffected: holders of TON will hold GRAM after the transition with no action required, and institutional treasury operations, position reporting, and integration paths require no changes. We use TON throughout this piece because that is the asset's current designation. Readers researching staking infrastructure for GRAM will find the same product, the same audited contracts, and the same access points described here.</p><p><strong>What is the current TON staking reward rate?</strong></p><p>The effective rate depends on network-wide staking participation. Following the Catchain 2.0 upgrade, TON's annual inflation rose from approximately 0.6% to approximately 3.6%. The effective staking reward rate is the inflation rate divided by the staking participation ratio, so a lower participation share results in a higher rate per staked unit. As more TON enters the staking set, the rate compresses toward equilibrium. All rates are protocol-determined and variable.</p><p><strong>Is TonWhales custodial?</strong></p><p>No. The Pool smart contract holds the delegation programmatically. The validator never takes ownership of user funds. The user signs from their own wallet for all deposits, withdrawals, and movements. Contracts have been audited by Quantstamp and Trail of Bits.</p><p><strong>What is the minimum stake?</strong></p><p>10 TON. The TonWhales contract removes the approximately 925,000 TON requirement of native single nominator contracts and the 40-delegator cap of standard nominator pools.</p><p><strong>Can institutions stake TON via custody platforms?</strong></p><p>Yes. TonWhales is integrated with BitGo and Copper. Institutions can stake TON to TonWhales without moving assets out of their custody arrangement. Reporting and position monitoring is available through P2P.org's Data API. Vesting contract staking is supported across all integration paths.</p><p><strong>Can partners embed the staking widget directly into their own platforms?</strong></p><p>Yes. The widget is built as a drop-in component for wallets, exchanges, and custody platforms. Integrations deploy in under a week with no backend complexity required from the partner, and operate under a revenue-sharing model.</p><h2 id="get-in-touch"><strong>Get in touch</strong></h2><p>Stake directly via the public widget:<a href="https://ton.p2p.org/deposit?ref=p2p.org"> <u>ton.p2p.org/deposit</u></a>.</p><p>For institutional integrations or operational support, contact P2P.org's institutional team.</p><p>For more on the broader TON development roadmap, see<a href="https://t.me/toncoin?ref=p2p.org"> <u>t.me/toncoin</u></a> and<a href="https://www.mtonga.com/?ref=p2p.org"> <u>mtonga.com</u></a>.</p>
from p2p validator
<p>P2P.org is now integrated with Taurus. </p><p>Our non-custodial validator infrastructure is available inside Taurus-PROTECT, the digital asset custody platform built for banks and financial institutions.</p><p>The integration starts with Ethereum, built using P2P.org's Staking API and the Beacon Chain deposit contract, and extends to other Proof-of-Stake networks where P2P.org is available as a validator through the Taurus interface.</p><h3 id="tldr"><strong>TL;DR</strong></h3><ul><li>P2P.org is now available inside Taurus-PROTECT, starting with Ethereum and extending to more networks through the Taurus interface. </li><li>Assets stay in Taurus custody. Clients delegate to P2P.org validator operations. Each protocol sets the rewards. </li><li>Banks can stake inside the platform they already use, without rebuilding their controls around a new provider.</li></ul><p>For Ethereum, P2P.org built a direct integration using its Staking API and the Beacon Chain deposit contract.</p><p>On the other networks, clients select P2P.org as a validator inside the Taurus interface, where P2P.org has been added as an approved provider. </p><p>In both cases, clients keep control of their assets inside Taurus custody while delegating to P2P.org validator operations, and staking rewards come from each protocol's network reward rate.</p><h3 id="what-taurus-protect-is"><strong>What Taurus-PROTECT is</strong></h3><p>Taurus is a Swiss digital asset infrastructure firm, founded in 2018 and regulated by FINMA. Taurus-PROTECT is its custody platform: the system a bank uses to hold and move digital assets. </p><p>What matters for staking is what the platform already does. </p><p>When banks adopt Taurus-PROTECT, Taurus integrates into the bank's existing risk management, compliance, and operational frameworks, and the bank keeps full oversight and control of its assets. </p><p>The controls a bank needs are already in the platform.</p><h3 id="staking-used-to-mean-leaving-that-environment"><strong>Staking used to mean leaving that environment</strong></h3><p>A bank that wanted to stake client assets usually had to move them to a separate provider. </p><p>That meant taking on a different security model and running a second set of operational processes next to the controls compliance and risk had already approved. </p><p>For a regulated financial institution, all of it has to clear internal review before anything goes live.</p><p>Most institutions found that hard to justify. The validator and the network were rarely the problem. The work was in rebuilding governance around a new provider, and it was heavy enough that many banks decided staking was not worth offering.</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/06/data-src-image-ec2b693a-cf75-41fb-8f9b-91cf61c99315.png" class="kg-image" alt="" loading="lazy" width="1600" height="900" srcset="https://p2p.org/economy/content/images/size/w600/2026/06/data-src-image-ec2b693a-cf75-41fb-8f9b-91cf61c99315.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/06/data-src-image-ec2b693a-cf75-41fb-8f9b-91cf61c99315.png 1000w, https://p2p.org/economy/content/images/2026/06/data-src-image-ec2b693a-cf75-41fb-8f9b-91cf61c99315.png 1600w" sizes="(min-width: 720px) 720px"></figure><h3 id="running-the-validator-inside-taurus-protect-removes-that-work"><strong>Running the validator inside Taurus-PROTECT removes that work</strong></h3><p>Assets stay where the bank already holds them.</p><p>The security model does not change. The same controls that cover custody, the approval flows, the access policies, the audit trails, also cover staking. </p><p>A bank already on Taurus-PROTECT can enable P2P.org validator operations inside its current setup instead of standing up a new one.</p><p>That is what moves staking from a project to a feature. The bank is not taking on new infrastructure; it is enabling something inside infrastructure it already trusts.</p><h3 id="swiss-and-european-private-banks-are-moving-first"><strong>Swiss and European private banks are moving first</strong></h3><p>Swiss and European private banks are likely to move first, and the reason is their approval process. </p><p>Anything that touches client assets has to clear internal risk and compliance review, and that review turns on a single question: does this fit the controls the bank already runs? </p><p>Because P2P.org operates inside Taurus-PROTECT, which these banks have already vetted, staking doesn't trigger a new review. It runs inside one they have already passed.</p><h3 id="taurus-is-the-first-integration-and-the-template-for-the-rest"><strong>Taurus is the first integration, and the template for the rest</strong></h3><p>For most regulated institutions, the limit on staking has been governance fit, not validator quality. </p><p>Integrating a provider bank by bank is slow, because every institution runs the same review on its own. </p><p>Putting the validator inside a custody platform the bank already uses reaches every institution on that platform through a path they have already approved.</p><p>P2P.org operates validator infrastructure across +50 networks. </p><p>The work now is making it available inside the systems institutions already trust. Taurus is where that starts.</p><h3 id="get-started"><strong>Get started</strong></h3><p><strong>Building a platform?</strong> Integrate P2P.org validator infrastructure into your custody or digital asset platform, the way Taurus did. Talk to <a href="http://p2p.org/?ref=p2p.org"><u>P2P.org</u></a>. </p><p><strong>Already on Taurus?</strong> Access P2P.org validator operations directly within Taurus-PROTECT. Stake with Taurus: <a href="https://www.taurushq.com/?ref=p2p.org">https://www.taurushq.com/</a> </p>
from p2p validator
<p><strong>Before You Dive In:</strong></p><ul><li>Institutional staking for SOL, XTZ, and ADA is now live directly inside the Ledger Enterprise UI, with ETH integration coming soon.</li><li>The workflow runs through the standard Ledger Enterprise approval flow, so institutions can stake without changing how they already manage custody operations.</li></ul><p>The integration is non-custodial throughout: Ledger Enterprise secures the keys while P2P.org operates the validators, meaning you never relinquish control of your assets.</p><p>For most networks, institutional staking has required blind signing: signing delegation transactions outside the standard custody approval flow institutions use for everything else. </p><p>The operational risk of blind signing is one reason many institutions have not staked, despite holding assets eligible for protocol delegation.</p><p>That changes today inside Ledger Enterprise. P2P.org is now live in the platform, allowing institutional clients to delegate SOL, XTZ, and ADA directly through the standard Ledger Enterprise UI, with Clear Signing on every delegation transaction. </p><p>No raw signing involved. </p><h2 id="the-friction-this-removes"><strong>The friction this removes</strong></h2><p>Raw signing has been the default requirement for institutional delegation on most networks. The reason is structural: most validator interfaces were not designed for institutions running formal approval workflows. </p><p>Institutions that wanted to stake had to build custom procedures around raw signing, route transactions through additional internal sign-offs, and introduce additional operational complexity and approval overhead.</p><p>For institutions where every transaction is logged, reviewed, and reconciled against policy, that overhead has been a hard stop. Many simply did not stake.</p><p>Inside Ledger Enterprise, delegation transactions now move through the same approval flow institutions already use for custody. Interface, compliance steps, and audit trail are unchanged. The operational lift of starting to stake drops from building a new workflow to using the existing one.</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/06/BLOG-P2P-x-Ledger--1-.jpg" class="kg-image" alt="" loading="lazy" width="2000" height="1125" srcset="https://p2p.org/economy/content/images/size/w600/2026/06/BLOG-P2P-x-Ledger--1-.jpg 600w, https://p2p.org/economy/content/images/size/w1000/2026/06/BLOG-P2P-x-Ledger--1-.jpg 1000w, https://p2p.org/economy/content/images/size/w1600/2026/06/BLOG-P2P-x-Ledger--1-.jpg 1600w, https://p2p.org/economy/content/images/size/w2400/2026/06/BLOG-P2P-x-Ledger--1-.jpg 2400w" sizes="(min-width: 720px) 720px"></figure><h2 id="what-is-live-today"><strong>What is live today</strong></h2><p><br>Three networks at launch:</p><p>-<a href="https://app.supademo.com/demo/cmoqttjvt2vwrw9don5b5mco3?ref=p2p.org"> <u>Solana: walk through the flow</u></a> </p><p>- <a href="https://app.supademo.com/demo/cmos1g2ge5024w9do49m717e5?ref=p2p.org"><u>Tezos: walk through the flow</u></a> </p><p>-<a href="https://app.supademo.com/demo/cmos2rnnk50y7w9doi1x9u6a9?ref=p2p.org"> <u>Cardano: walk through the flow</u></a></p><p>For each, the workflow is the same: clients select a P2P.org validator inside the Ledger Enterprise UI, approve the delegation transaction through the standard flow, and protocol rewards are distributed on-chain by the network. </p><p>No assets move into P2P.org's control at any point. Ledger Enterprise holds the keys throughout.</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/06/data-src-image-52c5ead7-499d-410a-a906-40d918705948.png" class="kg-image" alt="" loading="lazy" width="1754" height="1238" srcset="https://p2p.org/economy/content/images/size/w600/2026/06/data-src-image-52c5ead7-499d-410a-a906-40d918705948.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/06/data-src-image-52c5ead7-499d-410a-a906-40d918705948.png 1000w, https://p2p.org/economy/content/images/size/w1600/2026/06/data-src-image-52c5ead7-499d-410a-a906-40d918705948.png 1600w, https://p2p.org/economy/content/images/2026/06/data-src-image-52c5ead7-499d-410a-a906-40d918705948.png 1754w" sizes="(min-width: 720px) 720px"></figure><h2 id="what-is-coming"><strong>What is coming</strong></h2><p>ETH integration is in active development and is coming live soon. <br><br>The workflow will be the same: ETH staking support inside Ledger Enterprise, with no raw signing required. The roadmap is multi-asset by design, covering the major institutional networks under one platform with one workflow.</p><h2 id="why-p2porg"><strong>Why P2P.org? </strong></h2><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/06/data-src-image-7632505b-881c-4bac-9be0-39c642b9f74b.png" class="kg-image" alt="" loading="lazy" width="1440" height="780" srcset="https://p2p.org/economy/content/images/size/w600/2026/06/data-src-image-7632505b-881c-4bac-9be0-39c642b9f74b.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/06/data-src-image-7632505b-881c-4bac-9be0-39c642b9f74b.png 1000w, https://p2p.org/economy/content/images/2026/06/data-src-image-7632505b-881c-4bac-9be0-39c642b9f74b.png 1440w" sizes="(min-width: 720px) 720px"></figure><h2 id="about-the-partnership"><strong>About the partnership</strong></h2><p><strong>Sam Goh, Head of Partnerships and Strategy, Ledger Enterprise:</strong></p><p>"Institutional clients have been asking for broader native staking coverage inside Ledger Enterprise. The P2P.org integration expands that footprint with SOL, XTZ, and ADA today, ETH next, all running through the standard Ledger Enterprise approval flow without raw signing. The non-custodial setup keeps clients in control of their assets throughout."</p><p>This is the first integration between P2P.org and<a href="https://enterprise.ledger.com/?ref=p2p.org"> <u>Ledger Enterprise</u></a>, Ledger's flagship B2B SaaS platform. It builds on P2P.org's existing work with Ledger Wallet on the retail side, moving the same trust signal into institutional infrastructure. </p><p><em>Disclaimer: Staking rewards are protocol-generated, variable, and subject to network rules, validator performance, and applicable slashing or protocol risks.</em></p><h2 id="faq"><strong>FAQ</strong></h2><h3 id="which-networks-are-live-today"><strong>Which networks are live today?</strong></h3><p>SOL, XTZ, and ADA delegation is live inside the Ledger Enterprise UI as of launch.</p><h3 id="when-does-eth-go-live"><strong>When does ETH go live?</strong></h3><p>ETH integration is in active development. A separate launch announcement will follow when it is live.</p><h3 id="how-is-this-different-from-raw-signing"><strong>How is this different from raw signing?</strong></h3><p>Raw signing requires institutions to sign delegation transactions outside the standard custody approval flow, which adds operational steps and creates additional risk on every transaction. Inside Ledger Enterprise, delegation moves through the same approval workflow institutions already use for custody.</p><h3 id="who-controls-the-assets"><strong>Who controls the assets?</strong></h3><p>Ledger Enterprise holds the keys throughout. P2P.org operates the validator infrastructure on a non-custodial basis. Assets stay in the institution's control at all times.</p><h3 id="is-this-the-same-as-ledger-wallet"><strong>Is this the same as Ledger Wallet?</strong></h3><p>No. Ledger Enterprise is the institutional platform. Ledger Wallet is the retail product. P2P.org has worked with Ledger Wallet on the retail side; this integration is the first on the Enterprise side.</p><h3 id="how-do-i-get-started"><strong>How do I get started?</strong></h3><p>Existing Ledger Enterprise clients can find delegation options inside the platform UI. </p><p><strong>Talk to our institutional team about staking on Ledger Enterprise →</strong> <a href="https://calendly.com/p2p-staking-partnerships/discovery?ref=p2p.org">https://calendly.com/p2p-staking-partnerships/discovery</a> </p>
from p2p validator
<h2 id="learnings-for-busy-readers"><strong>Learnings for Busy Readers</strong></h2><ul><li>The barriers to institutional onchain deployment in 2026 are not technical. They are operational: policy frameworks, internal approval processes, and jurisdiction-by-jurisdiction regulatory interpretation.</li><li>MiCA clarifies the licensing perimeter but every compliance team interprets staking provisions differently - accounting treatment, capital treatment, and product scope are still institution-by-institution calls.</li><li>Late-stage deals collapse on internal alignment, not commercial or technical grounds. CISO and procurement are the most frequent blockers. Scope creep is the other deal killer.</li><li>Regulated institutions cannot interface directly with smart contracts. They need a legal counterparty they can hold accountable - a requirement DeFi protocols do not always accommodate.</li><li>Protocol selection is driven by client demand and unit economics, not by network fundamentals alone. Hyperliquid is the standout case study for ecosystem alignment right now.</li><li>Reporting and reconciliation has moved from a nice-to-have to a hard requirement. Translating onchain activity into standard accounting formats is now a non-negotiable part of the institutional stack.</li><li>The advice from every panelist: start small, move quickly on familiarisation, and build infrastructure for where you expect to be in five years - not for the first use case.</li></ul><p>On May 20, 2026, P2P.org hosted a live practitioner roundtable on institutional digital asset infrastructure. The panel brought together Alexander Loktev, CRO at P2P.org (Moderator), Pavel Jakovlev, Head of Product Growth and Innovation at <a href="https://aminagroup.com/?ref=p2p.org"><u>AMINA Bank</u></a>, John Hallahan, Director of Business Solutions and Advisory EMEA at <a href="http://fireblocks.com/?ref=p2p.org"><u>Fireblocks</u></a>, and Patrick Delaney, CEO at <a href="https://ampli.net/?ref=p2p.org"><u>Ampli</u></a>.</p><p>The conversation covered five topics:</p><ol><li>how institutions actually go from approval to live onchain deployment</li><li>compliance architecture under MiCA</li><li>the institutional go-to-market reality</li><li>multi-network exposure and validator selection</li><li>reporting and reconciliation</li></ol><h2 id="a-recap"><strong>A recap:</strong><br></h2><p>The technology works. That is no longer the question. What is holding institutions back in 2026 is the layer underneath. Compliance teams interpreting the same regulation differently, internal stakeholders who can block a deal at the last stage, operational models that were not built for onchain at scale, and reporting infrastructure that most institutions are still building in arrears.</p><h2 id="the-problem-is-never-technical"><strong>The problem is never technical</strong><br></h2><p>John Hallahan opened with a diagnosis that shaped the rest of the conversation.</p><blockquote><em>“The key issue is never technical. Where it breaks down is across three different areas: policy - the operational burden of approval processes and whitelisting; the operating model - unstaking, monitoring slashing risk, reconciling rewards; and the regulatory piece - in some jurisdictions staking is interest, in others it is a service fee. Compliance teams want to see that mapped before anything is signed off.”</em></blockquote><p>- John Hallahan, Fireblocks</p><p>Pavel confirmed it from the bank side. AMINA Bank has been operationalising <a href="https://aminagroup.com/individuals/staking/?ref=p2p.org"><u>staking </u></a>across ten protocols for several years, using a delegation model with infrastructure partners including P2P.org. The work is unglamorous and ongoing.</p><blockquote><em>“We want to make sure that our clients' </em><a href="https://aminagroup.com/individuals/custody/?ref=p2p.org#custody-services"><em><u>funds are segregated</u></em></a><em>, we know exactly who we are interacting with, we minimise smart contract risk as much as possible, and the funds are not commingled. Same rules apply. We just have to replicate them onchain.”</em></blockquote><p>- Pavel Jakovlev, AMINA Bank</p><p>Patrick added a dimension specific to agentic capital management. The security architecture around agent permissions is where institutions consistently underestimate the complexity.</p><blockquote><em>“Session keys that control the permissions of the agents are often stored on some centralised server. You have a huge risk silo where everything is in one place, and if that gets compromised, the attacker would have control over everything.”</em></blockquote><p>- Patrick Delaney, Ampli</p><p>That said, the risk concern should not obscure the upside. Patrick was clear on what agents actually deliver when the security layer is handled correctly.</p><blockquote><em>“Agents are great risk managers. They have twenty-four-seven surveillance capabilities - that is really solving a problem for institutions once you take care of the new risk that the agents themselves bring.”</em></blockquote><p>- Patrick Delaney, Ampli</p><p>The through-line across all three answers is the same: the gap between an institution receiving internal approval to go onchain and actually going live is larger than most expect, and almost none of it is explained by the technology.</p><h2 id="mica-gives-you-the-map-it-does-not-tell-you-how-to-read-it"><strong>MiCA gives you the map. It does not tell you how to read it.</strong></h2><p>The compliance discussion produced the clearest illustration of where the industry actually is on regulation. MiCA is in place. It is working. And it has not resolved the questions that matter most to compliance teams inside regulated institutions.</p><blockquote><em>“What </em><a href="https://www.fireblocks.com/glossary/markets-in-crypto-assets?ref=p2p.org"><em><u>MiCA</u></em></a><em> provides is a very clear framework around authorisation. The licensing perimeter is very clear. But every tier one that we work with is interpreting MiCA's staking provisions in a slightly different way. Accounting treatment, capital treatment, how staking is characterised - those are still being worked out on an institution-by-institution basis.”</em></blockquote><p>- John Hallahan, Fireblocks</p><p><a href="https://aminagroup.com/?ref=p2p.org"><u>AMINA Bank</u></a> is a useful case study in what operating under MiCA actually requires. The bank serves European clients through <a href="https://eu.aminagroup.com/?ref=p2p.org"><u>its Austrian entity</u></a>, which introduces hard product constraints. USDT and Ethena's USDe cannot be offered to European clients under the current framework. Every new product goes through a multi-stakeholder sign-off process spanning compliance, technology, and jurisdictional review across Europe, <a href="https://hongkong.aminagroup.com/?ref=p2p.org"><u>Hong Kong</u></a>, and Abu Dhabi simultaneously.</p><p>Switzerland, where AMINA holds its primary banking licence, has a longer regulatory history with <a href="https://aminagroup.com/individuals/custody/?ref=p2p.org"><u>digital assets</u></a>. The DLT Act predates MiCA by several years, and AMINA’s compliance team is in active dialogue with FINMA on innovations including zero-knowledge proof frameworks that could allow regulators to verify wallet history and source of funds without compromising client privacy. That is the direction the regulatory frontier is moving - not more restriction, but more sophisticated verification.</p><p>The practical implication for anyone selling into or operating within regulated institutions: MiCA compliance at the infrastructure layer does not close the compliance conversation internally. It opens it.</p><h2 id="deals-do-not-die-on-technical-grounds"><strong>Deals do not die on technical grounds</strong></h2><p>The go-to-market section was the most commercially direct part of the session. John's framing was unambiguous.</p><blockquote><em>“No one person can make a single decision to buy, but any of them can literally block the deal.”</em></blockquote><blockquote>- John Hallahan, Fireblocks</blockquote><p><a href="https://www.fireblocks.com/industry/banks?ref=p2p.org"><u>Fireblocks works with over one hundred banks</u></a>. The patterns are consistent. Two things kill late-stage deals. The first is internal alignment failure. The CISO and procurement are the most frequent blockers. Getting the CISO team comfortable with the risk basis of staking - a very different product from custody - is a step that cannot be skipped.</p><p>The second is scope creep. A <a href="https://www.fireblocks.com/blog/digital-asset-custody-strategy-banks?ref=p2p.org"><u>bank aligns on custody</u></a> and <a href="https://www.fireblocks.com/products/staking?ref=p2p.org"><u>staking</u></a>. Then at the eleventh hour, someone wants to add a <a href="https://www.fireblocks.com/blog/stablecoin-issuance-infrastructure-for-banks?ref=p2p.org"><u>stablecoin project</u></a>, a <a href="https://www.fireblocks.com/blog/next-chapter-transaction-banking?ref=p2p.org"><u>tokenisation initiative</u></a>, and a <a href="https://www.fireblocks.com/platforms/defi?ref=p2p.org"><u>DeFi</u></a> proof of concept.</p><blockquote><em>“If you are renegotiating the scope of things late stage, that is where deals can fall apart.”</em></blockquote><p>- John Hallahan, Fireblocks</p><p>Pavel added the internal knowledge dimension. Pockets of expertise do not always communicate across large organisations. The technology built in 2018 could be optimised, but doing so would require rebuilding everything from scratch - a decision most institutions are not positioned to make, and one most infrastructure providers are not helping them think through.</p><p>Patrick offered a different angle - where institutions are actually moving fast, and why. His near-term traction is not with regional banks but with a different profile entirely.</p><blockquote><em>“Latin America, Africa - those are the places where a lot of tech adoption happened, and retail users were actually skipping steps. Neo-banks there can build compliance around new technology from the start rather than retrofit it onto legacy systems.”</em></blockquote><p>- Patrick Delaney, Ampli</p><p>He also named the structural tension that sits underneath the whole DeFi institutional conversation.</p><blockquote><em>“It is kind of the paradox that we are now trying to sell the product that is supposed to replace the middleman to the middleman.”</em></blockquote><p>- Patrick Delaney, Ampli</p><p></p><h2 id="protocols-are-a-business-decision-not-a-technology-decision"><strong>Protocols are a business decision, not a technology decision</strong></h2><p>The network selection discussion moved quickly past which chains are technically capable and into how institutions actually make the call.</p><blockquote><em>“To launch an offering and be competitive as an institution, you need to cover all the major staking protocols that you can get on a Revolut or a Robinhood or an eToro, or else you are not going to be competitive. Then the validator partner choice flows quickly to unit economics.”</em></blockquote><p>- John Hallahan, Fireblocks</p><p>Pavel described AMINA’s internal process: customer requests trigger reviews, the top 100 to 200 networks are always tracked, and specific ecosystems get deeper reviews when client demand signals are strong enough. He highlighted Hyperliquid as the most interesting current case.</p><blockquote><em>“I have never seen more fanatical - in a good way - alignment across token holders, users, and developers. Most of our customers do not sell Hype. They just acquire it and keep it.”</em></blockquote><p>- Pavel Jakovlev, Amina Bank</p><p>The practical consequence is that clients are now requesting staking against Hype assets with the ability to borrow against them, which requires LST infrastructure and a rethink of how bonding and unbonding periods interact with lending products. The Hyperliquid example matters beyond the specific ecosystem: it illustrates what institutional protocol selection actually responds to - not network fundamentals in the abstract, but demonstrated user behaviour that creates specific product requirements on the institutional side.</p><p>Patrick raised the broader paradox this creates: DeFi was built to eliminate middlemen, and now banks are using it on behalf of clients. Alexander offered a reframe:</p><blockquote><em>“Agents give a feeling that it is me. When I interact with DeFi through my agentic ecosystem, it feels like I am working directly with the end product, passing all the middlemen. In reality, we are just moving all the middle players into an infrastructural layer where they interact through APIs with the agentic world. But from the user perspective, that is how it feels - and that matters.”</em></blockquote><p>- Alexander Loktev, P2P.org</p><h2 id="reporting-is-where-institutional-confidence-is-built-or-lost"><strong>Reporting is where institutional confidence is built or lost</strong></h2><p>Alexander opened the reporting section with a framing that applies across the full product stack. Staking is increasingly a commoditised product. Custody was commoditised before it. DeFi will be commoditised. The decisions clients make between infrastructure providers are increasingly driven by the operational services built around the core product - and reporting is at the top of that list.</p><blockquote><em>“Two or three years ago, clients were fine getting just a list of logs and onchain records. With the scaling of their staking operations, that stopped working. What they strictly require today is explanation.”</em></blockquote><p>- Alexander Loktev, P2P.org</p><p>John confirmed it from the infrastructure side. <a href="https://www.fireblocks.com/blog/fireblocks-acquires-tres?ref=p2p.org"><u>Fireblocks acquired TRES Finance</u></a> specifically because regulated entities were pulling blockchain data but could not get it into standard accounting formats.</p><blockquote><em>“If you are a regulated entity doing quarterly reporting, that accounting audit reconciliation offering is now a core part of the infrastructure stack. It is going to be pretty much non-negotiable.”</em></blockquote><p>- John Hallahan, Fireblocks</p><p>Pavel was direct about what AMINA’s regulatory position requires. The bank goes through both internal and external audits regularly. On occasion, the regulator comments on punctuation. The scrutiny is not going to decrease as the product set expands into DeFi and <a href="https://aminagroup.com/corporates/stablecoin-rewards-account/?ref=p2p.org"><u>more complex earn structures</u></a>.</p><p>Patrick described an emerging reporting dimension specific to agentic systems. The requirement is not just a log of what happened onchain - it is a log of intent versus execution: what did the agent propose, did it comply with the client's policy engine, was it approved or rejected and why. As institutions begin to explore agentic capital management, the reporting layer will need to account for the decision chain, not just the transaction record.</p><p><strong>Key Takeaways</strong></p><p>The closing question - what do institutions consistently get wrong when going onchain for the first time - produced four answers worth remembering: </p><blockquote><em>“Move slow on exposing yourself to risk, but move quickly in terms of familiarising yourself with the infrastructure. Eventually this is not going to be DeFi. It is going to be finance. You will be left behind if you brush it off as that crypto thing.”</em></blockquote><p>- Patrick Delaney, Ampli</p><blockquote><em>“Build your infrastructure and your operating model for where you think you are in five years, not your first use case. We have seen many early movers on the banking side who are now re-platforming. Build the stack for your strategy five years from now.”</em></blockquote><p>- John Hallahan, Fireblocks</p><blockquote><em>“I was speaking with a bank that banks other banks. They told me they know how to move billions onchain and the systems are good. They have not figured out how to move trillions yet. So once they do that, they will start moving. It is coming.”</em></blockquote><p>- Pavel Jakovlev, Amina Bank</p><blockquote><em>“Make your first step very small, but make it as soon as you can. At P2P.org, when we hire people, we give them a hardware wallet with a small amount and ask them to stake, unstake, and withdraw. It brings non-web3 people into the web3 world within a single day. They lose the stigma.”</em></blockquote><p>- Alexander Loktev, P2P.org</p><p>The replay is available <a href="https://www.youtube.com/watch?v=Md-SpGfPmOk&ref=p2p.org"><strong><u>here</u></strong></a>. P2P.org is a non-custodial validator infrastructure provider trusted by 190+ institutional clients, operating across 40+ networks with $10B+ in assets under validation and seven years of zero slashing events.</p><h2 id="frequently-asked-questions-faqs"><strong>Frequently Asked Questions (FAQs)</strong></h2><h3 id="what-are-the-biggest-operational-barriers-to-institutional-onchain-deployment-in-2026"><strong>What are the biggest operational barriers to institutional onchain deployment in 2026?</strong></h3><p>Policy frameworks, internal approval processes, and regulatory interpretation - not technical complexity. The technology is largely solved. The operational layer underneath it is where institutions get stuck.</p><h3 id="how-are-regulated-institutions-handling-mica-compliance-for-staking-products"><strong>How are regulated institutions handling MiCA compliance for staking products?</strong></h3><p>MiCA provides the licensing and authorisation framework, but accounting treatment, capital treatment, and product scope are still interpreted differently by each institution's compliance team. MiCA compliance at the infrastructure layer does not close the internal compliance conversation.</p><h3 id="what-kills-institutional-deals-at-the-late-stage"><strong>What kills institutional deals at the late stage?</strong></h3><p>Internal alignment failures - typically the CISO or procurement team raising concerns - and scope creep, where an institution expands requirements significantly during the negotiation phase.</p><h3 id="how-do-institutions-decide-which-blockchain-networks-to-support"><strong>How do institutions decide which blockchain networks to support?</strong></h3><p>Client demand first, unit economics second. EVM-compatible chains, Solana, and Cosmos are the practical shortlist for most regulated institutions. New networks get added following formal reviews triggered by specific client requests.</p><h3 id="what-does-institutional-grade-reporting-for-onchain-positions-require"><strong>What does institutional-grade reporting for onchain positions require?</strong></h3><p>Translating onchain activity into standard accounting formats, maintaining complete audit trails, and for agentic systems, logging agent intent versus execution so every capital movement can be traced back to the authorisation that triggered it.</p><h2 id="disclaimer"><strong>Disclaimer</strong></h2><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>
from p2p validator
<p><strong>Series: DeFi Infrastructure for Institutions</strong><br><br><a href="http://p2p.org/?ref=p2p.org">P2P.org</a>'s content series for regulated institutions evaluating on-chain capital allocation. Each article addresses a specific infrastructure, governance, or compliance dimension that determines whether a DeFi allocation can clear institutional approval and operate within mandate.</p><p>This is the second article in the regulatory trilogy examining the external pressure making institutional-grade vault governance a requirement rather than an option. <a href="https://p2p.org/economy/mica-defi-vaults-institutional-allocators/">The first article</a> examined what MiCA means for DeFi vault operators and institutional allocators. The third article will examine how conflict-of-interest regulatory frameworks are catching up to the curator model.</p><p><em>Previously in this series: </em><a href="https://p2p.org/economy/mica-defi-vaults-institutional-allocators/"><em>What MiCA Means for DeFi Vault Operators and Institutional Allocators</em></a></p><h2 id="introduction">Introduction</h2><p>Decentralised finance was built to remove intermediaries. The Travel Rule was built to hold intermediaries to account. That tension now sits at the centre of global AML supervision for anyone operating at the intersection of regulated institutions and DeFi vault infrastructure.</p><p>The Travel Rule is not a new concept. FATF Recommendation 16 has required originator and beneficiary information to accompany qualifying financial transfers since the 1990s, first for wire transfers, then extended to virtual assets in 2019. What is new is the enforcement environment. As of December 30, 2024, the EU's Transfer of Funds Regulation enforces the Travel Rule across all crypto-asset transfers involving a CASP with no minimum threshold. The UK has been enforcing its version since September 2023. As of early 2026, 73% of countries have enacted Travel Rule legislation. FATF updated Recommendation 16 again in June 2025 to further standardise cross-border payment information requirements. The era of aspirational Travel Rule compliance is over.</p><p>For DeFi vault operators and institutional allocators, the enforcement shift creates a specific and largely unresolved compliance problem. The Travel Rule requires a named originator and a named beneficiary to accompany every qualifying transfer. DeFi vault rebalances are executed by smart contracts. Smart contracts do not have names, addresses, or date-of-birth records. The data the Travel Rule requires does not exist in the architecture that executes the transaction.</p><p>This article explains what the Travel Rule requires mechanically, why DeFi vault architecture creates a structural compliance gap, how that gap affects both operators and institutional allocators in practice, and what the infrastructure requirement looks like for closing it.</p><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://p2p.org/economy/content/images/2026/05/travel-rule-defi-vault-compliance-gap.jpg" class="kg-image" alt="A three-section diagram showing the Travel Rule compliance gap in DeFi vault rebalances. The top row shows the problem: institutional client identity held by custodian, smart contract executing a rebalance with no originator or beneficiary data generated, and on-chain settlement with the Travel Rule obligation unmet. The middle row shows the required solution: an identity mapping layer, compliant data generated at execution, and transmission to the counterparty VASP before settlement. The bottom row shows jurisdiction thresholds for the EU Transfer of Funds Regulation with no minimum threshold, the US Bank Secrecy Act at three thousand dollars, and the FATF baseline at one thousand dollars." loading="lazy" width="2000" height="1304" srcset="https://p2p.org/economy/content/images/size/w600/2026/05/travel-rule-defi-vault-compliance-gap.jpg 600w, https://p2p.org/economy/content/images/size/w1000/2026/05/travel-rule-defi-vault-compliance-gap.jpg 1000w, https://p2p.org/economy/content/images/size/w1600/2026/05/travel-rule-defi-vault-compliance-gap.jpg 1600w, https://p2p.org/economy/content/images/2026/05/travel-rule-defi-vault-compliance-gap.jpg 2240w" sizes="(min-width: 720px) 720px"><figcaption><i><em class="italic" style="white-space: pre-wrap;">The Travel Rule compliance gap in DeFi vault rebalances and the data layer required to close it.</em></i></figcaption></figure><h2 id="learnings-for-busy-readers">Learnings for Busy Readers</h2><p>Short on time? Here are the key takeaways. For the full analysis and supporting data, continue reading below.</p><p>The Travel Rule requires originator and beneficiary information, full name, account identifier, wallet address, and in higher-value transactions, physical address or date of birth, to accompany every qualifying crypto-asset transfer. In the EU, under the Transfer of Funds Regulation, this applies to every CASP-to-CASP transfer with no minimum threshold. In the US, the Bank Secrecy Act, it applies to transfers of $3,000 or more.</p><p>The compliance gap in DeFi vault architecture is architectural, not procedural. When a curator initiates a vault rebalance, the transaction is executed by a smart contract. The smart contract is not a VASP. It does not hold customer identity data. It cannot transmit originator and beneficiary information because that information does not exist in the execution layer. The entity that is a VASP, the custodian or service provider interacting with the vault on behalf of an institutional client, must generate that data from outside the protocol and attach it to the transaction before it settles.</p><p>Most vault products were not designed with this infrastructure in mind. The gap is not a minor operational adjustment. It requires a data architecture that sits above the smart contract execution layer, holds verified identity information for every institutional participant, maps that information to every vault transaction at the point of execution, and transmits it to counterparty VASPs in a format that satisfies jurisdiction-specific Travel Rule requirements.</p><p>For institutional allocators, the Travel Rule gap adds a due diligence requirement that sits entirely outside the protocol evaluation. Before initiating vault interactions through a custodian or service provider, institutions need to verify that their intermediary's Travel Rule infrastructure can generate compliant data for every vault transaction type, including rebalances initiated by smart contracts, not just for direct custody transfers.</p><h2 id="what-the-travel-rule-requires">What the Travel Rule Requires</h2><p>The Travel Rule's core requirement is straightforward: when a VASP or CASP transmits virtual assets on behalf of a customer, it must collect and transmit specific identifying information about the originator and the beneficiary to the receiving institution. That information must travel with the transfer, not reside in a separate onboarding system.</p><p>The specific data requirements vary by jurisdiction. Under the EU Transfer of Funds Regulation, which applies from December 30, 2024, with no minimum threshold, every CASP-to-CASP transfer requires the originator's full name, account or wallet identifier, and either a physical address, official personal document number, customer identification number, or date of birth, plus the beneficiary's name and account identifier. Under the US Bank Secrecy Act, the threshold is $3,000, with requirements for the originator's full name, account or wallet number, physical address, and the amount and execution date of the transfer.</p><p>FATF's updated guidance, revised at the June 2025 Plenary, reinforces that the obligation applies wherever a financial service is being provided, regardless of whether the service is characterised as decentralised. The guidance is explicit that DeFi arrangements are not outside the scope if there are natural or legal persons who control or operate a service. As of the June 2025 FATF targeted update, 99 jurisdictions are advancing Travel Rule implementation. Only 21% of 138 assessed jurisdictions are fully compliant with FATF Recommendation 15, indicating that enforcement is still developing, but the direction is unambiguous. (Source: FATF Targeted Update, June 2025; Zyphe, VASP KYC Compliance, March 2026.)</p><p>The data must travel with the transfer in real time, not in a post-settlement report. This is the operationally demanding part. It requires infrastructure that can generate, verify, and transmit identity data at the point of transaction execution, not after the fact.</p><h2 id="the-structural-compliance-gap-in-defi-vaults">The Structural Compliance Gap in DeFi Vaults</h2><p>The Travel Rule compliance gap in DeFi vault architecture is not a documentation problem. It is an architectural problem rooted in how vault transactions are initiated and executed.</p><p>In a standard vault rebalance, the curator identifies an allocation opportunity, proposes a strategy adjustment, and the vault smart contract executes the resulting transactions across one or more DeFi lending protocols. The smart contract is the execution agent. It is not a VASP. It does not hold customer identity data. It does not have a compliance function. It simply executes the instructions encoded in its logic and settles the resulting transactions on-chain.</p><p>This creates a specific Travel Rule problem with three dimensions.</p><h3 id="the-originator-identification-problem"><strong>The originator identification problem</strong></h3><p>The Travel Rule requires a named originator: the entity instructing the transfer, with verified identity data. In a vault rebalance, the instruction comes from the smart contract executing the curator's strategy. There is no named human originator in the execution layer. The custodian or service provider who originally deposited assets into the vault on behalf of the institutional client is the economic originator, but that relationship is not encoded in the transaction that the smart contract executes. Mapping the institutional client's identity data to the smart contract execution requires infrastructure that sits above the protocol layer and maintains that mapping at every transaction point.</p><h3 id="the-beneficiary-identification-problem"><strong>The beneficiary identification problem</strong></h3><p>In a vault rebalance, assets move between protocol positions, not between named individuals or institutions. When a vault reallocates from one lending market to another, the beneficiary of the transaction is a smart contract address, not a person. Under the EU TFR, CASPs must assess whether a customer owns or controls a self-hosted wallet before making assets available for transfers over €1,000. A smart contract address is not a self-hosted wallet in the traditional sense. It is a protocol address. Generating compliant beneficiary data for smart contract destinations requires a classification and verification system that most vault products were not designed to include.</p><h3 id="the-interoperability-problem"><strong>The interoperability problem</strong></h3><p>Even where a custodian has Travel Rule infrastructure for standard crypto transfers, that infrastructure may not be designed to handle the transaction types that DeFi vault rebalances generate. DeFi vault transactions can involve multiple protocols, multiple chains, wrapped assets, and liquidity pool interactions. Each of these transaction types raises specific questions about how the Travel Rule applies and how originator and beneficiary data should be structured. As of 2026, there is no universal standard for Travel Rule data transmission, though protocols like TRISA, OpenVASP, and TRUST are operating in parallel. A custodian whose Travel Rule infrastructure uses one protocol may be unable to exchange data with a counterparty using a different one.</p><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><h2 id="how-the-gap-affects-vault-operators">How the Gap Affects Vault Operators</h2><p>For vault operators that fall within MiCA's CASP framework, or that serve clients in jurisdictions with equivalent Travel Rule obligations, the compliance gap is an operational infrastructure requirement that cannot be deferred.</p><p>The Travel Rule obligation attaches at the point where a CASP is involved in a transfer. A vault operator managing institutional assets is providing a service that places it within the CASP scope. Every vault transaction involving an institutional client's assets is a transaction that the vault operator's Travel Rule infrastructure must be able to process. That includes rebalances, protocol interactions, and position adjustments initiated by the vault's smart contract logic.</p><p>The practical requirement is a data layer that sits above the smart contract execution environment and performs three functions. First, it maintains a verified identity record for every institutional participant and maps that record to the vault addresses associated with their allocations. Second, it intercepts every transaction at the point of initiation, generates the required originator and beneficiary data from the identity record, and attaches that data to the transaction before it executes. Third, it transmits the data to counterparty VASPs in a format compatible with the applicable Travel Rule protocol and retains a timestamped record for regulatory audit purposes.</p><p>Under the EU TFR, originator and beneficiary data must be retained for five years after the end of the business relationship or transaction. That retention requirement is a data management obligation that extends well beyond the transaction itself. The vault operator's Travel Rule infrastructure must include a compliant data retention and retrieval system that can produce records on regulatory request.</p><h2 id="how-the-gap-affects-institutional-allocators">How the Gap Affects Institutional Allocators</h2><p>For institutional allocators, the Travel Rule gap creates a due diligence requirement that operates at the counterparty level rather than the protocol level.</p><p>The allocator's obligation is typically discharged through the custodian or service provider they use to interact with DeFi vault protocols. The custodian is the VASP. The custodian bears the Travel Rule obligation for transfers initiated on the allocator's behalf. But the allocator needs to verify, before initiating any vault interaction, that their custodian's Travel Rule infrastructure can handle the specific transaction types that vault interactions generate.</p><p>This verification requirement has three specific dimensions. First, the allocator needs to confirm that the custodian can generate compliant originator data for vault rebalances initiated by smart contracts, not just for direct custody transfers. The mapping of institutional identity to smart contract execution is the non-trivial part. Second, the allocator needs to confirm that the custodian can handle the vault's specific transaction types, including multi-protocol rebalances, wrapped asset interactions, and any cross-chain transactions the vault strategy involves. Third, the allocator needs to confirm that the custodian's Travel Rule protocol is interoperable with the counterparty VASPs involved in the vault's transaction flow.</p><p>For institutional allocators operating across multiple jurisdictions, the interoperability question is particularly complex. The EU applies the Travel Rule with no minimum threshold. The US applies it at $3,000. The UK applies a risk-based approach. Singapore, Hong Kong, and South Korea have their own implementations. A vault strategy that involves transactions across multiple jurisdictions requires Travel Rule infrastructure that can apply the correct data requirements for each transaction based on the jurisdictions of the parties involved.</p><p>The due diligence checklist for Travel Rule compliance is therefore not a protocol-level question. It is a custodian infrastructure question that needs to be resolved before vault interactions begin.</p><h2 id="key-takeaway">Key Takeaway</h2><p>The Travel Rule's compliance gap in DeFi vault architecture is architectural. Smart contracts do not generate originator and beneficiary data. The vault products built on top of them were not designed to produce it. And the enforcement environment, with the EU TFR applying to every CASP transfer since December 30, 2024, and 73% of countries having enacted Travel Rule legislation as of early 2026, means the gap can no longer be treated as a future compliance consideration.</p><p>For vault operators, closing the gap requires a data layer above the smart contract execution environment that maps institutional identity to vault transactions, generates compliant Travel Rule data at the point of execution, and retains records in a format that satisfies the retention and retrieval requirements of the applicable jurisdictions.</p><p>For institutional allocators, it requires a custodian due diligence process that verifies Travel Rule infrastructure at the transaction-type level, not just at the general compliance framework level. The question is not whether the custodian is Travel Rule compliant. The question is whether the custodian's Travel Rule infrastructure can handle the specific transaction types that vault interactions generate.</p><p>The infrastructure that closes both gaps is the same infrastructure that the first trilogy of this series identified as the missing governance layer: an independent data and compliance layer sitting above the execution environment, operating at the transaction level, independently of the smart contracts executing the strategy.</p><p><em>Next in this series: How Conflict-of-Interest Regulatory Frameworks Are Catching Up to the Curator Model</em></p><h2 id="frequently-asked-questions">Frequently Asked Questions</h2><h3 id="what-is-the-travel-rule-and-why-does-it-apply-to-defi-vault-operators"><strong>What is the Travel Rule, and why does it apply to DeFi vault operators?</strong></h3><p>The Travel Rule, based on FATF Recommendation 16, requires VASPs and CASPs to collect and transmit originator and beneficiary information alongside qualifying virtual asset transfers. It applies to vault operators because any entity providing crypto-asset portfolio management services to clients is providing a service that falls within the VASP or CASP scope under the applicable jurisdiction's definition. The obligation attaches at the service provider level, not the protocol level. The DeFi protocols the vault operator uses to execute transactions may not be regulated, but the vault operator managing institutional assets through those protocols is.</p><h3 id="what-data-does-the-travel-rule-require-to-accompany-a-crypto-asset-transfer"><strong>What data does the Travel Rule require to accompany a crypto-asset transfer?</strong></h3><p>Under the EU Transfer of Funds Regulation, which applies to all CASP-to-CASP transfers with no minimum threshold since December 30, 2024, the required data includes the originator's full name, account or wallet identifier, and either a physical address, official personal document number, customer identification number, or date of birth, plus the beneficiary's name and account identifier. Under the US Bank Secrecy Act, the threshold is $3,000, with requirements for the originator's full name, account or wallet number, and physical address. FATF's June 2025 update further standardised cross-border requirements, with national implementation timelines varying by jurisdiction.</p><h3 id="why-is-generating-travel-rule-data-for-defi-vault-rebalances-technically-difficult"><strong>Why is generating Travel Rule data for DeFi vault rebalances technically difficult?</strong></h3><p>Vault rebalances are executed by smart contracts, not by named human originators. The smart contract is not a VASP and does not hold customer identity data. Generating compliant Travel Rule data requires a separate data layer that maintains verified identity records for every institutional participant, maps those records to the vault addresses associated with their allocations, and intercepts every transaction at the point of initiation to attach the required originator and beneficiary data before the transaction executes. The beneficiary identification problem is equally challenging, as the beneficiary of a rebalance transaction is typically a protocol address rather than a named individual or institution.</p><h3 id="what-does-travel-rule-interoperability-mean-and-why-does-it-matter-for-vault-operators"><strong>What does Travel Rule interoperability mean, and why does it matter for vault operators?</strong></h3><p>Travel Rule interoperability refers to the ability of different VASPs' Travel Rule systems to exchange originator and beneficiary data with each other. Multiple competing protocols currently handle this data exchange, including TRISA, OpenVASP, and TRUST, and they are not universally compatible. A vault operator whose infrastructure uses one protocol may be unable to exchange data with a counterparty using a different one. For vault operators handling multi-protocol, multi-chain transactions, interoperability gaps can create compliance failures at specific transaction points even where the underlying data infrastructure is otherwise compliant.</p><h3 id="what-should-institutional-allocators-verify-about-their-custodians-travel-rule-infrastructure-before-initiating-vault-interactions"><strong>What should institutional allocators verify about their custodian's Travel Rule infrastructure before initiating vault interactions?</strong></h3><p>Allocators should verify three things. First, the custodian can generate compliant originator data for vault rebalances initiated by smart contracts, not just for direct custody transfers. Second, the custodian's infrastructure can handle the specific transaction types involved in the vault strategy, including multi-protocol rebalances, wrapped asset interactions, and any cross-chain transactions. Third, the custodian's Travel Rule protocol is interoperable with the counterparty VASPs involved in the vault's transaction flow. These are infrastructure questions that need to be resolved before vault interactions begin, not after the first transaction fails a compliance check.</p><hr><p><a href="http://p2p.org/?ref=p2p.org"><em>P2P.org</em></a><em> 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, </em><a href="https://p2p.org/?ref=p2p.org#form"><em>talk to our team</em></a><em>.</em></p><p><strong><em>Disclaimer</em></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>
from p2p validator
<p><strong>Series:</strong> Institutional Lens | Validation Infrastructure</p><p>The Institutional Lens series unpacks the protocol mechanics, infrastructure decisions, and governance considerations that matter most for institutional participants in proof-of-stake networks. Each article is written for professionals operating at the intersection of traditional finance and blockchain infrastructure, including digital asset custodians, crypto-native funds, ETF issuers, treasury teams, and staking product managers.</p><p><strong>Previously in the series:</strong> <a href="https://p2p.org/economy/why-institutional-capital-needs-a-protection-layer-in-proof-of-stake-networks/">Why Institutional Capital Needs a Protection Layer in Proof-of-Stake Networks</a></p><h2 id="introduction">Introduction</h2><p>Solana has crossed a threshold that changes how institutional participants need to think about it. Total Payment Volume on Solana surged 755% year-over-year, driven by institutional adoption and approximately $950 million in ETF inflows (Source: <a href="https://www.ainvest.com/news/sol-sees-strong-staking-transaction-growth-institutional-interest-2026-2603/?ref=p2p.org">Ainvest</a>). The March 2026 SEC and CFTC joint interpretation explicitly classified SOL as a digital commodity and confirmed that solo, self-custodial, custodial, and liquid staking models do not constitute securities transactions. The regulatory overhang that kept many compliance teams on the sidelines is gone.</p><p>What remains is a decision that carries more institutional weight than most teams have yet appreciated. The question is not whether to stake SOL, but how. For digital asset custodians, crypto-native funds, ETF issuers, treasury teams, and staking product managers, Solana staking for institutions is not a single product. Native staking and liquid staking are structurally different risk profiles, custody architectures, and capital management frameworks. Getting this decision right is as important as the allocation decision itself.</p><h2 id="learnings-for-busy-readers"><strong>Learnings for Busy Readers</strong></h2><p>What this article covers:</p><ul><li>How native and liquid staking differ structurally, not just mechanically</li><li>The risk, custody, and liquidity implications of each for institutional participants</li><li>How the current market shift across ETF approvals, LST fragmentation, and Alpenglow changes the calculus</li><li>A decision framework and due diligence checklist for institutional teams</li></ul><p><strong>The core argument:</strong> Native staking offers full custody control, no smart contract exposure, and a clean compliance posture. Liquid staking offers capital efficiency and DeFi composability at the cost of additional risk layers. For most institutional mandates, the right answer is not one or the other. It is understanding exactly which tradeoffs your organisation is equipped to underwrite.</p><h2 id="the-decision-is-not-what-most-teams-think-it-is">The Decision Is Not What Most Teams Think It Is</h2><p>The most common framing of the native vs. liquid staking question in Solana staking for institutions is a yield question. Native staking currently generates 5 to 7% APY depending on validator performance and commission rates, while liquid staking tokens such as JitoSOL and JupSOL generate between 5.89% and 6.16% APY as of early 2026, with some protocols reaching higher during periods of elevated network activity (Source: <a href="https://sanctum.so/blog/best-solana-yield-2026-staking-vs-defi?ref=p2p.org">Sanctum</a>).</p><p>For retail participants, the yield differential is the dominant consideration. For institutional participants, it is rarely the right place to start. The correct framing is a risk architecture question: what risk layers is your organisation prepared to accept, and does your mandate permit them?</p><p>Native staking and liquid staking expose participants to materially different risk categories. Understanding those categories, not the APY differential, is the foundation of a defensible institutional staking framework on Solana.</p><h2 id="native-staking-the-institutional-baseline">Native Staking: The Institutional Baseline</h2><p>In native staking, SOL is delegated directly from a client-controlled wallet to a validator. The delegator retains full custody of the private keys. The staked SOL never leaves the delegator's control. It is locked for voting weight purposes, not transferred to a third party.</p><p><strong>What native staking provides for institutions:</strong></p><p><strong>Full non-custodial architecture.</strong> The validator never holds client assets. Delegation is an instruction, not a transfer. This is structurally aligned with the non-custodial infrastructure model that institutional compliance frameworks typically require.</p><p><strong>No smart contract risk.</strong> Native staking operates at the protocol layer. There is no additional smart contract between the delegator and the network. The only code risk is Solana's base layer itself.</p><p><strong>Clean regulatory posture.</strong> The March 2026 SEC and CFTC interpretation explicitly confirmed that self-custodial staking with a third-party validator, where the custodian acts as agent and does not determine staking amounts or fix reward rates, is not a securities transaction. Native staking maps directly to this definition.</p><p><strong>Predictable reward mechanics.</strong> Protocol-generated rewards accrue each epoch, approximately every two days, are denominated in SOL, and compound automatically into the staked balance. Reward rates are determined entirely by network conditions.</p><p><strong>The institutional tradeoff:</strong></p><p>The primary constraint of native staking for institutions is liquidity. Native staking locks SOL for approximately two epochs, around four to five days, when unstaking is initiated (Source: <a href="https://hittincorners.com/guides/solana-liquid-staking-complete-guide-2026/?ref=p2p.org">HittinCorners</a>). For treasury teams managing redemption obligations or funds with liquidity covenants, this is a material consideration. It is not a disqualifying one, but it needs to be accounted for in position sizing and liquidity management frameworks before capital is deployed.</p><p>The secondary consideration is validator selection. In native staking, the delegator chooses a specific validator. That choice has direct implications for reward performance, slashing risk exposure, and governance representation. It is an active decision that requires due diligence, not a passive one.</p><h2 id="liquid-staking-capital-efficiency-with-additional-risk-layers">Liquid Staking: Capital Efficiency with Additional Risk Layers</h2><p>In liquid staking, SOL is deposited into a staking protocol such as Jito, Marinade, or Sanctum, which delegates to a set of validators and issues a liquid staking token (LST) representing the staked position plus accrued rewards. The LST can be traded, used as collateral in DeFi protocols, or swapped back to SOL through liquidity pools.</p><p>Over $3.3 billion in SOL is liquid-staked across Jito, DoubleZero, Marinade, and Sanctum as of early 2026, representing approximately 10 to 15% of all staked SOL. The segment is growing rapidly and is increasingly the focus of institutional product development.</p><p><strong>What liquid staking adds for institutions:</strong></p><p><strong>Liquidity.</strong> LSTs can be swapped back to SOL near-instantly through liquidity pools, removing the epoch lock-up constraint of native staking.</p><p><strong>DeFi composability.</strong> LSTs can be used as collateral on lending protocols, provided as liquidity in AMM pools, or deployed in structured yield strategies. This unlocks additional reward layers on top of the base staking rate, a meaningful consideration for institutions seeking to maximise capital efficiency.</p><p><strong>MEV distribution.</strong> Protocols like Jito pass a portion of MEV block tips to LST holders, which is why JitoSOL consistently generates a modest premium above the base native staking rate.</p><p><strong>The institutional risk calculus:</strong></p><p>Liquid staking for institutions introduces risk categories that native staking does not. Every institutional team evaluating LSTs needs to assess these explicitly.</p><p><strong>Smart contract risk.</strong> The LST protocol itself is a smart contract. Vulnerabilities in that contract represent a risk to staked capital that does not exist in native staking. The relevant question is not whether a protocol has been audited, as most have been, but whether your mandate permits smart contract exposure at all, and whether the protocol's audit history and incident record are acceptable to your risk committee.</p><p><strong>LST depeg risk.</strong> Under market stress, LSTs can trade below their underlying SOL value. During periods of stress, LSTs can trade below their underlying asset value. Institutions should maintain sufficient liquidity buffers and avoid over-leveraging LST positions (<a href="https://www.cobo.com/post/liquid-staking-for-institutions-complete-mpc-infrastructure-guide?ref=p2p.org">Cobo</a>). For funds with mark-to-market accounting obligations, a temporary depeg is a profit and loss event regardless of whether the underlying position eventually recovers.</p><p><strong>Validator concentration risk.</strong> LST protocols delegate to validator sets according to their own algorithms. The delegator has no direct control over validator selection. This matters for institutions with specific governance obligations, as they are effectively delegating governance representation to the protocol's delegation strategy rather than making that decision directly.</p><p><strong>Custody and compliance complexity.</strong> LSTs are tokens, not staking positions. Their treatment for accounting, tax reporting, and regulatory classification may differ from native staked SOL depending on jurisdiction. This is an active area of legal development and warrants specific advice for each institution.</p><h2 id="what-is-changing-right-now-and-why-it-matters">What Is Changing Right Now and Why It Matters</h2><p>Three developments in early 2026 have materially shifted the landscape for Solana staking for institutions.</p><p><strong>The SEC and CFTC commodity ruling.</strong> The March 17 joint interpretation formally cleared all four staking models, including liquid staking, as non-securities activities. For compliance teams that had blocked LST exposure pending regulatory clarity, that barrier is now removed. The question shifts from whether an institution can participate to whether it should, and under what framework.</p><p><strong>LST market fragmentation.</strong> JitoSOL's dominance is fracturing. Nasdaq filed a proposal in February 2026 to list the VanEck JitoSOL Solana Liquid Staking ETF, the first attempt to offer a regulated product tied directly to an LST. Galaxy Digital launched institutional SOL staking in March 2026. Hex Trust integrated JitoSOL for custodial staking, signalling that traditional custodians are beginning to treat LSTs as standard yield products. The LST landscape is maturing rapidly, but it is also becoming more complex. Institutions entering now face more protocol choices, more counterparty relationships, and more due diligence surface area than existed twelve months ago.</p><p><strong>Alpenglow's impact on native staking economics.</strong> The Alpenglow upgrade, approved by 98% of validators and deploying in 2026, will eliminate validator voting fees entirely. The elimination of voting fees means validators keep a larger portion of their earnings, effectively making staking more profitable for both validators and delegators, particularly for smaller operators who were previously losing a higher percentage of rewards to mandatory voting costs (Source: <a href="https://phemex.com/blogs/solana-alpenglow-upgrade-finality-explained?ref=p2p.org">Phemex</a>). For institutions in native staking programs, this represents an improvement in net reward rates without any change to risk posture, a meaningful compression of the native vs. liquid yield differential.</p><h2 id="the-institutional-decision-framework">The Institutional Decision Framework</h2><p>This is not a binary choice. Many institutional programs will run both: native staking for their core, compliance-sensitive position, and a controlled LST allocation where the mandate permits and the risk framework supports it. The relevant questions for each component are the following.</p><p><strong>For native Solana staking for institutions:</strong></p><p>Is your custody architecture non-custodial and client-controlled? Have you conducted due diligence on your validator's infrastructure, incident history, and governance posture? Is your liquidity management framework designed around the epoch lock-up timeline? Does your reward reporting infrastructure support validator-level attribution for accounting and audit purposes?</p><p><strong>For liquid staking as an institutional layer:</strong></p><p>Does your mandate permit smart contract exposure, and has legal confirmed the applicable standard? Has your risk committee reviewed the specific protocol's audit history, slashing incident record, and depeg history? Does your accounting framework have a defined treatment for LST mark-to-market movements? Are you clear on the tax treatment of LST rewards in each operating jurisdiction? Is the validator governance delegation of the LST protocol acceptable, given that the protocol determines it rather than you?</p><p><a href="http://p2p.org/?ref=p2p.org">P2P.org</a>'s <a href="https://p2p.org/networks/solana?ref=p2p.org">Solana staking infrastructure</a> is built for institutional native staking with non-custodial architecture, validator-level reporting, geographically distributed infrastructure, and operational safeguards aligned with the risk posture institutional partners require. Our <a href="https://docs.p2p.org/?ref=p2p.org">technical documentation</a> provides detailed guidance on integration, reward reporting, and operational architecture for teams building or evaluating a Solana staking program.</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/05/Native-vs.-liquid-staking-on-Solana-compared-across-custody--smart-contract-risk--liquidity--and-governance-dimensions-for-institutional-allocators..png" class="kg-image" alt="Native vs. liquid staking on Solana compared across custody, smart contract risk, liquidity, and governance dimensions for institutional allocators." loading="lazy" width="1600" height="900" srcset="https://p2p.org/economy/content/images/size/w600/2026/05/Native-vs.-liquid-staking-on-Solana-compared-across-custody--smart-contract-risk--liquidity--and-governance-dimensions-for-institutional-allocators..png 600w, https://p2p.org/economy/content/images/size/w1000/2026/05/Native-vs.-liquid-staking-on-Solana-compared-across-custody--smart-contract-risk--liquidity--and-governance-dimensions-for-institutional-allocators..png 1000w, https://p2p.org/economy/content/images/2026/05/Native-vs.-liquid-staking-on-Solana-compared-across-custody--smart-contract-risk--liquidity--and-governance-dimensions-for-institutional-allocators..png 1600w" sizes="(min-width: 720px) 720px"></figure><p><strong>Ready to build your Solana staking program on institutional-grade infrastructure?</strong> <a href="http://p2p.org/?ref=p2p.org">P2P.org</a> provides non-custodial, validator-level Solana staking for institutions with full reward attribution and reporting built in. <a href="https://p2p.org/networks/solana?ref=p2p.org">Explore P2P.org Solana Staking</a></p><h2 id="due-diligence-checklist">Due Diligence Checklist</h2><p>For staking product managers, risk committees, and compliance teams evaluating a Solana staking structure.</p><p><strong>Native staking:</strong></p><ul><li>[ ] Custody architecture is non-custodial with client keys and client control</li><li>[ ] Validator selected based on infrastructure quality, incident history, and geographic distribution</li><li>[ ] Epoch lock-up timeline integrated into liquidity management framework</li><li>[ ] Validator-level reward reporting available in accounting-compatible format</li><li>[ ] Validator governance participation policy documented</li><li>[ ] SLA framed around operational practices, not performance guarantees</li></ul><p><strong>Liquid staking (additional layer):</strong></p><ul><li>[ ] Smart contract audit history reviewed and accepted by the risk committee</li><li>[ ] Slashing incident and depeg history reviewed for selected protocol</li><li>[ ] LST accounting treatment confirmed with legal and finance teams</li><li>[ ] Tax treatment of LST rewards confirmed per operating jurisdiction</li><li>[ ] The validator delegation strategy of the protocol is reviewed and acceptable</li><li>[ ] DeFi deployment strategy, if any, has independent risk approval</li></ul><h2 id="key-takeaway">Key Takeaway</h2><p>For institutional participants in Solana's proof-of-stake network, the native vs. liquid staking decision is not primarily about yield optimisation. It is about risk architecture, custody posture, and mandate alignment. Native staking provides the cleanest institutional baseline with full custody control, no smart contract exposure, and a regulatory posture that maps directly to the March 2026 SEC and CFTC interpretation. Liquid staking offers capital efficiency and composability at the cost of additional risk layers that each institution must explicitly evaluate and accept.</p><p>With Alpenglow improving native staking economics, the SEC commodity ruling removing regulatory ambiguity, and the LST market becoming more complex rather than simpler, the case for starting with a rigorous native staking foundation has never been stronger. Build the baseline correctly, then evaluate whether your mandate and risk framework support expanding from there.</p><p><em>Protocol-generated rewards are determined by network conditions and are variable. </em><a href="http://p2p.org/?ref=p2p.org"><em>P2P.org</em></a><em> does not control or set reward rates. Slashing risks are protocol-defined and client-borne. Operational safeguards are implemented to reduce slashing exposure, but do not eliminate protocol-level risk.</em></p><h2 id="faq">FAQ</h2><p><strong>What is the difference between native staking and liquid staking for Solana institutional programs?</strong></p><p>In native staking, SOL is delegated directly from a client-controlled wallet to a validator. The delegator retains full custody at all times, and the staked SOL never leaves their control. In liquid staking, SOL is deposited into a protocol which issues a liquid staking token representing the staked position. The LST can be traded or used in DeFi, but introduces additional risk layers, including smart contract exposure and potential depeg risk that native staking does not carry.</p><p><strong>Is liquid staking on Solana permitted under institutional mandates following the March 2026 ruling?</strong></p><p>As of March 17, 2026, the SEC and CFTC jointly confirmed that liquid staking activities do not constitute securities transactions, provided the provider does not fix or guarantee reward amounts. This ruling removed the primary regulatory barrier that had previously caused many institutional compliance teams to restrict LST exposure. Whether a specific mandate permits LST exposure remains a question for each institution's legal and risk teams.</p><p><strong>How does the Alpenglow upgrade affect Solana staking for institutions?</strong></p><p>Alpenglow eliminates validator voting fees, which had previously represented a meaningful operating cost, reducing net rewards for both validators and delegators. When deployed in 2026, it improves the net reward rate of native staking programs without changing their risk posture. This compresses the yield differential between native and liquid staking, making native staking more competitive for institutions where the additional risk layers of LSTs are not warranted by the mandate.</p><p><strong>What is the unstaking timeline for institutional native SOL staking?</strong></p><p>Native SOL staking has an unstaking period of approximately two epochs, or around four to five days under normal network conditions. This lock-up period is a material liquidity consideration for institutional programs and should be integrated into position sizing and liquidity management frameworks before capital is deployed.</p><p><strong>How should institutions account for liquid staking tokens?</strong></p><p>LSTs are tokens representing staked positions and accrued rewards. Their accounting treatment, particularly for mark-to-market movements, reward recognition, and tax treatment, may differ from native staked SOL depending on jurisdiction and applicable accounting standards. Institutions should obtain specific legal and accounting guidance for their operating jurisdiction before deploying into LST positions.</p><p><strong>What due diligence should institutions conduct on a liquid staking protocol?</strong></p><p>Key areas include the protocol's smart contract audit history and any prior incidents, its slashing and depeg history, its validator delegation strategy and whether it aligns with governance obligations, the accounting and tax treatment of LST rewards in the relevant jurisdiction, and whether the protocol has had independent security reviews by recognised firms.</p><hr><p><strong><em>Disclaimer</em></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>
from p2p validator
<h2 id="series-hub-institutional-staking"><strong>Series: Hub | Institutional Staking</strong></h2><p>The Institutional Staking Hub is <a href="http://p2p.org/?ref=p2p.org">P2P.org</a>'s definitive reference for institutions building proof-of-stake programs. From foundational concepts to infrastructure selection and risk architecture, each article addresses a specific operational or technical dimension that determines how a staking program performs in practice.</p><p>This is article 2 in the series. Read the foundation first: <a href="https://p2p.org/economy/what-is-institutional-staking/">What Is Institutional Staking? A Complete Guide for Funds, Custodians, and Treasury Teams</a></p><h2 id="learnings-for-busy-readers">Learnings for Busy Readers</h2><p>What this article covers:</p><ul><li>What validator infrastructure is and what it actually does at the network level</li><li>The difference between self-operated and delegated validator models</li><li>The technical components that determine whether infrastructure is institutional-grade</li><li>How key management architecture affects custody, risk, and compliance</li><li>What client diversity means and why it matters for operational resilience</li><li>How DVT changes the risk architecture of validator operations</li><li>The metrics and certifications that define institutional-grade validator providers</li><li>A due diligence checklist for evaluating validator infrastructure</li></ul><p>The core argument: Validator infrastructure is not a commodity. The operational decisions made at the infrastructure layer determine uptime, slashing exposure, reward outcomes, and compliance posture. Institutions that treat validator selection as a risk management decision consistently achieve better outcomes than those that treat it as a cost optimisation exercise.</p><h2 id="introduction">Introduction</h2><p>Most institutional conversations about staking start with reward rates. They should start with infrastructure.</p><p>Validator infrastructure is the operational layer that sits between an institution's capital and the proof-of-stake protocol it is participating in. It determines whether consensus participation is reliable or fragile, whether slashing exposure is managed or assumed, and whether the reporting an institution needs for accounting, audit, and compliance can actually be produced.</p><p>Major progress in validator infrastructure, institutional custody, multi-chain staking frameworks, and enterprise-grade reporting has made staking operationally viable at scale. For large asset managers, including pension funds, endowments, and conservative allocators, the legal uncertainty and operational risk that kept them on the sidelines are now falling away (Source: <a href="https://coinshares.com/us/insights/knowledge/institutional-staking-on-the-rise/?ref=p2p.org">CoinShares</a>).</p><p>But operational viability is not the same as operational quality. As institutions move from evaluation to deployment, the question changes from whether staking is viable to whether the infrastructure underpinning a specific staking program meets institutional standards. This article answers that question from the ground up.</p><h2 id="what-validator-infrastructure-is">What Validator Infrastructure Is</h2><p>In a proof-of-stake network, validators are the entities responsible for proposing and attesting to new blocks. They do not just hold staked capital. They run software, maintain network connections, sign messages, and participate in consensus rounds continuously. When a validator goes offline, misses attestations, or double-signs a message, the protocol responds with penalties. When a validator performs correctly, the protocol distributes rewards.</p><p>Validator infrastructure is everything that makes that participation happen reliably: the hardware or cloud architecture the validator software runs on, the key management system that controls signing credentials, the monitoring stack that detects and responds to anomalies, the client software that communicates with the network, and the reporting layer that captures everything for downstream use.</p><p>Ethereum supports over 1.1 million active validators in 2026, with average validator uptime near 99.2% across the network (Source: <a href="https://coinlaw.io/cryptocurrency-staking-statistics/?ref=p2p.org">CoinLaw</a>). That network average conceals significant variance between operators. In enterprise IT, Service Level Agreements (SLAs) define the expected uptime and reliability of a service provider. The blockchain space is increasingly moving in the same direction, especially as institutions explore staking as part of their portfolio strategy.</p><h2 id="self-operated-vs-delegated-validator-models">Self-Operated vs. Delegated Validator Models</h2><p>Institutions entering proof-of-stake networks have two structural choices for how they participate at the infrastructure layer.</p><h3 id="self-operated-validators"><strong>Self-operated validators</strong></h3><p>An institution builds and operates its own validator nodes. It controls the infrastructure, manages the keys, handles software updates, and monitors performance directly. This model gives maximum control and governance participation, but it carries the full operational burden. The institution must maintain the specialised engineering capability, 24/7 monitoring, incident response processes, and protocol expertise required to operate validators safely at scale.</p><p>Rather than hiring experts, provisioning hardware or cloud infrastructure, and securing forensic-grade security, institutions using a managed service can get their staking strategy up and running in weeks or less. The inverse is equally true: institutions that choose self-operation must be prepared to build all of that capability in-house.</p><h3 id="delegated-validator-infrastructure-staking-as-a-service"><strong>Delegated validator infrastructure (staking-as-a-service)</strong></h3><p>An institution delegates its capital to a professional validator operator. The institution retains custody of its assets at all times. The provider operates the infrastructure, manages keys, monitors performance, handles upgrades, and delivers reporting. This is the dominant model for institutional participation, as it removes the operational burden while preserving custody control.</p><p>The critical requirement in any delegated arrangement is non-custody. In a correctly structured staking-as-a-service model, the validator provider never holds the institution's assets. Assets are not transferred. Delegation happens at the protocol level, and the institution retains withdrawal authority.</p><h2 id="the-technical-components-of-institutional-grade-infrastructure">The Technical Components of Institutional-Grade Infrastructure</h2><p>Not all validator infrastructure is equivalent. The gap between consumer-grade and institutional-grade validator operations shows up across five technical dimensions.</p><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://p2p.org/economy/content/images/2026/05/_p2p-validator-infrastructure-stack-institutional.jpg" class="kg-image" alt="A four-layer vertical diagram showing the institutional validator infrastructure stack: Protocol Layer at the base, followed by Infrastructure Layer, Key Management Layer, and Reporting Layer at the top, each labelled with its primary function." loading="lazy" width="2000" height="1304" srcset="https://p2p.org/economy/content/images/size/w600/2026/05/_p2p-validator-infrastructure-stack-institutional.jpg 600w, https://p2p.org/economy/content/images/size/w1000/2026/05/_p2p-validator-infrastructure-stack-institutional.jpg 1000w, https://p2p.org/economy/content/images/size/w1600/2026/05/_p2p-validator-infrastructure-stack-institutional.jpg 1600w, https://p2p.org/economy/content/images/2026/05/_p2p-validator-infrastructure-stack-institutional.jpg 2240w" sizes="(min-width: 720px) 720px"><figcaption><i><em class="italic" style="white-space: pre-wrap;">The institutional validator infrastructure stack. Four layers from protocol to reporting, showing how each layer contributes to uptime, security, and compliance.</em></i></figcaption></figure><h3 id="hardware-and-network-architecture"><strong>Hardware and network architecture</strong></h3><p>Institutional validators operate on dedicated hardware rather than shared cloud infrastructure, with redundant power, connectivity, and compute. Professional validators target near-perfect uptime backed by strict SLAs. They utilise low-latency bare-metal hardware, high-throughput connectivity, and optimised client diversity to prevent network-wide bugs from causing local outages. Geographic distribution across multiple data centres reduces single-point-of-failure risk. Active/passive failover mechanisms ensure consensus participation continues through hardware or connectivity incidents.</p><h3 id="key-management-architecture"><strong>Key management architecture</strong></h3><p>Validator keys are the most sensitive operational asset in a staking program. There are two key types relevant to institutional operations: the signing key, used to participate in consensus, and the withdrawal key, used to access staked capital and rewards.</p><p>In an institutional non-custodial arrangement, the institution retains the withdrawal key at all times. The validator operator manages the signing key through a key management system designed to prevent the signing key from being exposed, duplicated, or used in ways that would trigger double-signing penalties. Hardware security modules, remote signing services, and key sharding approaches are all architectural choices at this layer.</p><h3 id="client-diversity"><strong>Client diversity</strong></h3><p>Every proof-of-stake network runs on consensus client software. On Ethereum, multiple independent client implementations exist, including Prysm, Lighthouse, Teku, Nimbus, and Lodestar on the consensus layer. The risk of running a single client in concentration is significant. The Prysm outage in December 2025, where validator participation dropped to approximately 75% and 248 blocks were missed, vividly demonstrated the risk posed by stakers herding toward a single consensus client.</p><p>Institutional-grade providers operate diversified client environments. If one client has a bug or outage, validators running alternative clients continue participating normally. This is a meaningful differentiator that does not appear in uptime statistics measured under normal conditions.</p><h3 id="monitoring-and-incident-response"><strong>Monitoring and incident response</strong></h3><p>Validator infrastructure requires continuous monitoring: block proposal success rates, attestation participation, peer connectivity, signing latency, and software version currency. Institutional-grade operations maintain 24/7 monitoring with defined escalation paths and incident response procedures. To avoid slashing, validators must operate secure, redundant, and highly available infrastructure. This includes implementing slashing protection mechanisms such as remote signing, key sharding, or sentry node architectures, and continuously monitoring node health, block production, and consensus participation metrics.</p><h3 id="reporting-and-audit-infrastructure"><strong>Reporting and audit infrastructure</strong></h3><p>Institutions need validator-level reward attribution for accounting, tax reporting, and audit purposes. This requires a reporting layer that captures rewards at the epoch level, attributes them to specific delegations, and delivers data in formats compatible with institutional back-office systems. Performance data, slashing history, and governance participation records all require structured capture. This layer is frequently underspecified in evaluations focused on uptime and fee rates.</p><h2 id="what-dvt-changes-about-validator-risk-architecture">What DVT Changes About Validator Risk Architecture</h2><p>Distributed Validator Technology (DVT) is a protocol-level mechanism that distributes the validator signing function across multiple independent nodes. Rather than a single node holding and using the signing key, DVT allows a threshold of nodes to collectively produce validator signatures. No single node has access to the complete key.</p><p>For institutional operations, DVT addresses two risk categories simultaneously. First, it eliminates single-point-of-failure at the signing layer. A hardware failure, network outage, or compromise of a single node does not disable the validator or expose the signing key. Second, it structurally prevents double-signing, since generating a duplicate signature requires a threshold of nodes to act simultaneously, which does not occur under normal failure conditions.</p><p>DVT is not yet universally deployed across all proof-of-stake networks, but its adoption is accelerating on Ethereum and represents a meaningful infrastructure maturity signal when evaluating providers.</p><h2 id="reward-mechanics-at-the-infrastructure-layer">Reward Mechanics at the Infrastructure Layer</h2><p>Protocol rewards are generated by the network, not by the validator provider. What the infrastructure layer controls is how efficiently those rewards are captured.</p><p>On Ethereum, rewards come from two sources: consensus layer rewards (base staking rewards for correct block proposals and attestations) and execution layer rewards (priority fees and MEV). Base ETH staking rewards generally range from 3% to 4%, while restaking incentives can temporarily lift combined yields above 8% to 15% (Source: <a href="https://coinlaw.io/cryptocurrency-staking-statistics/?ref=p2p.org">CoinLaw</a>).</p><p>Infrastructure quality affects reward capture in measurable ways. A validator with sustained 99.9% uptime captures consensus rewards on nearly every eligible slot. A validator with 98% uptime misses roughly 1 in 50 attestation opportunities. At scale, that difference compounds into material reward outcomes across a staking program.</p><p>MEV capture is a separate infrastructure consideration. Validators connected to MEV relays receive a share of transaction ordering value from block builders. Institutional operators must evaluate the MEV relay landscape for compliance implications, since certain relay types may route transactions in ways that conflict with regulatory obligations around transaction ordering.</p><p>Network conditions determine protocol-generated rewards and are variable. <a href="http://p2p.org/?ref=p2p.org">P2P.org</a> does not control or set reward rates.</p><h2 id="the-institutional-standard-certifications-audits-and-compliance-requirements">The Institutional Standard: Certifications, Audits, and Compliance Requirements</h2><p>For institutions operating under regulatory obligations, independent validation of validator infrastructure controls matters.</p><p>SOC 2 Type II is the most relevant independent security attestation for validator infrastructure providers. Enterprise clients typically want Type II reports because they demonstrate how controls perform in real operations, not just at a point in time. A SOC 2 Type II report covering availability and security criteria provides meaningful independent assurance that the controls governing validator uptime and key management are operating as documented. It is a floor, not a ceiling, but it is a meaningful one. <a href="http://p2p.org/?ref=p2p.org">P2P.org</a> achieved SOC 2 Type II certification in December 2025, independently validating our operational controls across security and availability criteria (Source: <a href="https://p2p.org/economy/validator-due-diligence-framework-what-institutions-really-need-to-evaluate/">P2P.org</a>).</p><p>ISO 27001 certification for information security management systems is a second relevant attestation, particularly for institutions operating under MiCA in Europe or with data governance obligations. Penetration testing records, incident disclosure history, and governance participation policies round out the compliance picture.</p><p>Institutional adoption of crypto risk frameworks has climbed to 78%, with custodial spend reaching $16 billion in 2025. Risk compliance ranks as the top priority for 84% of institutions. <a href="https://coinlaw.io/bitcoin-staking-statistics/?ref=p2p.org">CoinLaw</a> Validator infrastructure sits at the centre of that risk framework for any institution running a staking program.</p><h2 id="how-to-evaluate-validator-infrastructure-a-due-diligence-framework">How to Evaluate Validator Infrastructure: A Due Diligence Framework</h2><p>For a complete evaluation process, including the specific questions to ask and the mechanisms to assess, see our Validator Playbook article: <a href="https://p2p.org/economy/validator-due-diligence-framework-what-institutions-really-need-to-evaluate/">Validator Due Diligence: An Institutional Framework</a>.</p><p>The criteria below are the foundational dimensions any institutional evaluation must cover.</p><h3 id="infrastructure-architecture"><strong>Infrastructure architecture</strong></h3><ul><li>[ ] Does the provider operate dedicated hardware or shared cloud infrastructure?</li><li>[ ] Are data centres geographically distributed with documented failover?</li><li>[ ] What is the provider's SLA for validator uptime, and what is the documented track record?</li></ul><h3 id="key-management"><strong>Key management</strong></h3><ul><li>[ ] How are signing keys managed? Remote signing, HSM, or key sharding?</li><li>[ ] Does the institution retain withdrawal key control at all times?</li><li>[ ] What is the key recovery process in the event of a provider incident?</li></ul><h3 id="client-diversity-1"><strong>Client diversity</strong></h3><ul><li>[ ] Does the provider run multiple consensus clients across its validator fleet?</li><li>[ ] What is the distribution across client types, and how is this documented?</li><li>[ ] How does the provider respond to client-specific bugs or vulnerabilities?</li></ul><h3 id="slashing-risk-controls"><strong>Slashing risk controls</strong></h3><ul><li>[ ] What slashing protection mechanisms are in place?</li><li>[ ] What is the provider's slashing history across all networks they operate on?</li><li>[ ] Is there a documented incident response process specific to slashing conditions?</li></ul><h3 id="reporting-and-compliance"><strong>Reporting and compliance</strong></h3><ul><li>[ ] Can the provider deliver validator-level reward attribution at the epoch level?</li><li>[ ] Are reports available in formats compatible with institutional accounting systems?</li><li>[ ] Does the provider hold SOC 2 Type II or equivalent independent certification?</li></ul><h3 id="network-coverage-and-governance"><strong>Network coverage and governance</strong></h3><ul><li>[ ] Which proof-of-stake networks does the provider support?</li><li>[ ] How does the provider handle protocol governance participation on behalf of delegators?</li><li>[ ] What is the process for network upgrades and client version management?</li></ul><h2 id="where-p2porg-sits-in-this-architecture">Where <a href="http://p2p.org/?ref=p2p.org">P2P.org</a> Sits in This Architecture</h2><p><a href="http://p2p.org/?ref=p2p.org">P2P.org</a> operates non-custodial validator infrastructure across more than 40 proof-of-stake networks, supporting custodians, funds, ETF issuers, and treasury teams with institutional-grade staking programs. Our infrastructure operates on dedicated hardware with geographic distribution, client diversity across consensus implementations, and SOC 2 Type II certification achieved in December 2025.</p><p>Institutions retain full custody of their assets throughout. Validator-level reward reporting is available for accounting and audit requirements. Governance participation policies are configurable per delegation.</p><p>Explore our infrastructure and supported networks at <a href="https://p2p.org/?ref=p2p.org">p2p.org</a>.</p><p>Building an institutional staking program? <a href="http://p2p.org/?ref=p2p.org">P2P.org</a> provides non-custodial validator infrastructure across 40+ proof-of-stake networks, with validator-level reporting and operational safeguards designed for institutional requirements. <a href="https://p2p.org/?ref=p2p.org">Explore P2P.org Staking Infrastructure</a></p><h2 id="key-takeaway">Key Takeaway</h2><p>Validator infrastructure is the operational foundation of every institutional staking program. It determines uptime, slashing exposure, reward capture, reporting capability, and compliance posture. The decision of which infrastructure to operate or delegate to is a risk management decision, not a cost decision.</p><p>The institutions that will operate effective staking programs at scale are those that evaluate validator infrastructure with the same rigour they apply to any other mission-critical operational dependency. The checklist above is a starting point. The standard is set by the protocol and by the expectations of the risk committees, custodians, and regulators that govern institutional capital.</p><p>Network conditions determine protocol-generated rewards and are variable. <a href="http://p2p.org/?ref=p2p.org">P2P.org</a> does not control or set reward rates. Slashing risks are protocol-defined and client-borne. Operational safeguards are implemented to reduce slashing exposure but do not eliminate protocol-level risk.</p><h2 id="frequently-asked-questions">Frequently Asked Questions</h2><h3 id="what-is-validator-infrastructure-in-proof-of-stake-networks"><strong>What is validator infrastructure in proof-of-stake networks?</strong></h3><p>Validator infrastructure is the technical stack that enables participation in proof-of-stake consensus. It includes the hardware or cloud architecture the validator software runs on, the key management system that controls signing credentials, the monitoring and incident response stack, the consensus client software, and the reporting layer that captures performance and reward data. Validator infrastructure determines uptime, slashing exposure, reward capture, and compliance posture for any staking program.</p><h3 id="what-is-the-difference-between-self-operated-and-delegated-validator-infrastructure"><strong>What is the difference between self-operated and delegated validator infrastructure?</strong></h3><p>In a self-operated model, the institution builds and runs its own validator nodes, retaining full control but carrying the full operational burden, including specialised engineering, 24/7 monitoring, and protocol expertise. In a delegated model (staking-as-a-service), a professional validator provider operates the infrastructure while the institution retains custody of its assets at all times. The delegation happens at the protocol level, and the institution retains withdrawal authority. Most institutional participants use the delegated model.</p><h3 id="what-makes-validator-infrastructure-institutional-grade"><strong>What makes validator infrastructure institutional-grade?</strong></h3><p>Institutional-grade validator infrastructure operates on dedicated hardware with geographic redundancy, runs diversified consensus clients to avoid single-client failure risk, manages signing keys through hardware security modules or remote signing services, maintains 24/7 monitoring with documented incident response procedures, holds independent certifications such as SOC 2 Type II, and delivers validator-level reward reporting compatible with institutional accounting and audit requirements.</p><h3 id="what-is-distributed-validator-technology-and-why-does-it-matter-for-institutions"><strong>What is Distributed Validator Technology, and why does it matter for institutions?</strong></h3><p>DVT distributes the validator signing function across multiple independent nodes. No single node holds the complete signing key. A threshold of nodes must act together to produce a valid signature. This eliminates single-point-of-failure at the signing layer and structurally prevents double-signing, since triggering that condition requires a threshold of nodes to act simultaneously under failure conditions. For institutions, DVT is a meaningful risk reduction mechanism at the key management layer.</p><h3 id="how-do-validator-infrastructure-decisions-affect-reward-outcomes"><strong>How do validator infrastructure decisions affect reward outcomes?</strong></h3><p>Protocol rewards are determined by the network, not by the provider. However, infrastructure quality determines how efficiently rewards are captured. A validator with sustained 99.9% uptime captures consensus rewards on nearly every eligible slot. A validator with 98% uptime misses approximately 1 in 50 attestation opportunities. At the institutional scale, that gap compounds into material reward differences over time. MEV relay selection is a separate infrastructure consideration with both performance and compliance implications.</p><h3 id="what-certifications-should-institutions-look-for-in-a-validator-provider"><strong>What certifications should institutions look for in a validator provider?</strong></h3><p>SOC 2 Type II is the most relevant independent certification for validator infrastructure, as it validates how operational controls perform over time rather than at a single point in time. ISO 27001 is relevant for information security management, particularly under MiCA in Europe. Institutions should also request penetration testing records, incident disclosure history, and documentation of governance participation policies as part of their due diligence process.</p><h3 id="what-is-non-custodial-staking-and-why-is-it-required-for-institutional-programs"><strong>What is non-custodial staking, and why is it required for institutional programs?</strong></h3><p>In non-custodial staking, the institution's assets remain under the institution's control throughout the staking process. The validator provider operates infrastructure but never holds the assets. Withdrawal keys remain with the institution. In custodial staking, assets are transferred to the provider or a third-party custodian, which triggers additional regulatory obligations in most institutional compliance frameworks. Non-custodial architecture is the standard requirement for institutional staking programs because it preserves custody integrity and avoids the regulatory implications of asset transfer.</p><hr><p><strong><em>Disclaimer</em></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>
from p2p validator
<p><strong>TL;DR:</strong><br>BitMart has launched staking products for ETH, SOL, and DOT, powered by P2P.org infrastructure. Users can now stake three of the largest proof-of-stake assets directly within their BitMart account. The integration runs on P2P.org's Unified Staking API — one connection covering multi-asset staking operations across all three networks simultaneously.</p><p>Staking has been one of the more fragmented corners of the exchange product stack. Offering it across multiple networks means dealing with different consensus mechanisms, different validator economics, different operational requirements per asset. ETH, SOL, and DOT are not interchangeable — each has its own architecture and its own edge cases.</p><p>BitMart launched all three at once. </p><p>That outcome is a direct function of how the integration was built.</p><h2 id="the-infrastructure-side-p2porgs-unified-staking-api"><strong>The Infrastructure Side: P2P.org's Unified Staking API</strong></h2><p>The technical foundation of this integration is P2P.org's Unified Staking API.</p><p>One connection covers ETH, SOL, and DOT — stake, unstake, sign, and retrieve data through a single endpoint. That's why BitMart was able to launch all three networks at once rather than phasing them in one at a time.</p><p>The API is built for exactly this use case. Exchanges and custodians connecting to it get access to P2P.org's validator infrastructure across multiple proof-of-stake networks without maintaining separate staking connections per asset. New networks follow the same standard, so expanding coverage doesn't require starting from scratch each time.</p><p>On the operational side, P2P.org runs the validators. The infrastructure is the same that serves regulated custodians and asset managers on the institutional side — $10B+ in staked assets, 190+ institutional clients, active across 40+ networks.</p><h2 id="why-eth-sol-and-dot"><strong>Why ETH, SOL, and DOT</strong></h2><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/04/1600x900--1--2.png" class="kg-image" alt="" loading="lazy" width="1600" height="900" srcset="https://p2p.org/economy/content/images/size/w600/2026/04/1600x900--1--2.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/04/1600x900--1--2.png 1000w, https://p2p.org/economy/content/images/2026/04/1600x900--1--2.png 1600w" sizes="(min-width: 720px) 720px"></figure><p>The asset selection reflects where staking demand is deepest. Ethereum is the largest proof-of-stake network by value staked globally. Solana has one of the most active retail staking ecosystems, with short reward cycles and straightforward delegation mechanics. provides protocol-level rewards to participants — P2P.org's position as an established DOT nominator matters here in a way it doesn't on simpler networks.</p><p>Together, these three assets cover the range of what exchange users are most likely to want to stake. BitMart's global user base — concentrated across Asia, Europe, and emerging markets — maps well to demand for all three.</p><h2 id="what-this-enables"><strong>What This Enables</strong></h2><p>BitMart's launch is a concrete example of what multi-network staking looks like when the infrastructure layer is already built. One API integration, three networks live simultaneously, validator operations handled by a provider with institutional-grade infrastructure behind it.</p><p>For BitMart users, the result is straightforward: staking rewards on three major PoS networks, accessible directly within the platform they already use to trade.</p><p><strong>Exchanges and custodians interested in adding staking to their product can learn more about P2P.org's Unified Staking API at</strong><a href="https://p2p.org/products/api?ref=p2p.org"><strong> </strong></a><a href="http://p2p.org/products/api?ref=p2p.org"><strong><u>p2p.org/products/api</u></strong></a><strong>.</strong></p><p>Disclaimer: Staking services may not be available in all jurisdictions. Staking rewards are variable and depend on network conditions. Digital assets involve risk, including possible loss of principal. BitMart does not provide investment, legal, or tax advice. </p><p><strong>FAQ </strong></p><p>Q: What is BitMart staking powered by? A: BitMart's ETH, SOL, and DOT staking products are powered by P2P.org, a non-custodial staking infrastructure provider with $10B+ in assets staked across 40+ networks.</p><p>Q: Which assets can I stake on BitMart with P2P.org? A: BitMart currently supports staking for ETH (Ethereum), SOL (Solana), and DOT (Polkadot) via the P2P.org integration.</p><p>Q: How does P2P.org's Unified Staking API work? A: The Unified Staking API gives exchanges and custodians access to P2P.org's staking infrastructure across multiple proof-of-stake networks through a single integration. Stake, unstake, sign, and retrieve data through one endpoint — covering multiple networks without a separate build per asset.</p>
from p2p validator
<p>P2P.org and iLuminary have partnered to bring onchain DeFi access directly inside the iLuminary platform.</p><p>iLuminary users can now interact with onchain DeFi protocols without leaving the app — no separate wallet setup, no bridging. The experience is built into the interface they already use, powered by P2P.org's DeFi Widget running on the backend.</p><p>This is the latest integration in P2P.org's growing network of platforms embedding onchain infrastructure directly into their products. For iLuminary, it closes the distance between their users and DeFi. For P2P.org, it's another distribution point for infrastructure that was previously only accessible to institutional clients.</p><p>If you're already on iLuminary, DeFi access is live now. <a href="https://iluminary.ai/download?ref=p2p.org">→</a> <a href="https://iluminary.ai/download?ref=p2p.org">Try it here</a>.</p><p><strong>What the DeFi Widget Is</strong></p><p>The P2P.org DeFi Widget is an embeddable module that gives any platform's users direct access to onchain DeFi protocols — without leaving the host application.</p><p>It plugs into an existing product interface. Users interact with onchain protocols through a familiar UI they already trust. The complexity of the underlying infrastructure — routing, protocol connections, transaction execution — is handled entirely by P2P.org on the backend.</p><p>For the end user, it just works. For the platform, it's a single integration.</p><p><strong>The Infrastructure Behind It</strong></p><p>The widget runs on P2P.org's core infrastructure — the same stack that powers staking and DeFi operations for institutional clients managing billions in onchain assets.</p><p>$12B+ in secured assets. 40+ networks supported. Zero slashing events. SOC 2 Type II certified.</p><p>That track record matters for platforms considering an integration. When you embed the P2P.org DeFi Widget, you're not building on experimental infrastructure. You're building on a stack that institutional clients depend on daily, with the operational standards that entails.</p><p><strong>For Platforms Looking to Integrate</strong></p><p>The integration process is straightforward. The widget is embeddable — it drops into an existing product interface without requiring a full infrastructure build on your end.</p><p>What you get: onchain DeFi access for your users, powered by P2P.org's protocol infrastructure and operational layer, delivered through your own product experience.</p><p>What your users get: access to established onchain protocols, directly inside an app they already use.</p><p>If you're building a platform and want to give your users DeFi access without the infrastructure overhead, the P2P.org DeFi Widget is built for exactly that use case.</p><p>Get in touch with the P2P.org team → <a href="https://link.p2p.org/93ab18?ref=p2p.org">https://link.p2p.org/93ab18</a> <br><br>Disclaimer: P2P.org provides non-custodial infrastructure that enables access to third-party DeFi protocols and does not control, manage, or guarantee the performance of any protocol or transaction. All interactions occur directly onchain and are subject to network conditions and protocol-specific risks, for which P2P.org assumes no responsibility.</p>
from p2p validator
<h2 id="at-a-glance"><strong>At a glance: </strong></h2><ul><li>TON staking from vesting contracts is now supported via Ledger Wallet using the P2P.org dApp.</li><li>Holders with vested TON can now delegate directly without altering vesting structures.</li><li>The staking flow integrates with standard Ledger self-custody signing workflows.</li></ul><p>Staking TON from vesting contracts is now supported through Ledger Wallet using the P2P.org dApp.<br><br>On the surface, this looks like a product enhancement. In practice, it enables additional participants to access TON’s validator infrastructure through existing vesting contracts.</p><p>Vesting contracts often represent long-term alignment — contributors, early ecosystem participants, and structured allocations tied to roadmap milestones. Until now, participation from those allocations has required additional coordination or operational workarounds.</p><p>This update streamlines the technical integration required for vesting-based delegation.</p><h2 id="vesting-as-active-participation"><strong>Vesting as Active Participation</strong></h2><p>In most ecosystems, vesting allocations sit idle by default.</p><p>They are designed to protect long-term alignment and prevent sudden liquidity shocks. But structurally, they also represent a meaningful portion of circulating supply that is committed to the network over time.</p><p>When vesting allocations can participate in staking, three things happen:</p><ol><li>Long-term holders engage more directly with network security.</li><li>Contributor allocations can participate in protocol-defined staking mechanisms.</li><li>Broader participation may contribute to more distributed delegation patterns within the network.</li></ol><p>It’s about enabling participation from capital that is already committed to the ecosystem.</p><h2 id="how-it-works"><strong>How It Works</strong></h2><p></p><p>The integration enables TON holders with vesting contracts to delegate directly through Ledger Wallet while preserving standard self-custody workflows.</p><p>The process:</p><ul><li>Connect Ledger to the P2P.org dApp.</li><li>Select the vesting contract.</li><li>Initiate staking directly from the vested allocation.</li><li>Confirm through Ledger’s signing interface.</li></ul><p>The staking action becomes part of the same workflow users already rely on for transaction signing and asset management.</p><p>For a detailed walkthrough, refer to the official guide:<a href="https://link.p2p.org/1cd04e?ref=p2p.org">https://link.p2p.org/1cd04e</a> </p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/03/TON7.png" class="kg-image" alt="" loading="lazy" width="2000" height="1500" srcset="https://p2p.org/economy/content/images/size/w600/2026/03/TON7.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/03/TON7.png 1000w, https://p2p.org/economy/content/images/size/w1600/2026/03/TON7.png 1600w, https://p2p.org/economy/content/images/2026/03/TON7.png 2048w" sizes="(min-width: 720px) 720px"></figure><h2 id="what-this-unlocks-for-the-ton-ecosystem"><strong>What This Unlocks for the TON Ecosystem</strong></h2><p>TON’s ecosystem includes:</p><ul><li>Structured token recipients</li><li>Institutional participants</li><li>Early ecosystem supporters</li><li>Long-term contributors</li></ul><p>Many of these participants operate under vesting schedules.</p><p>By enabling staking directly from vesting contracts, the network broadens participation without altering distribution mechanics. Contributors can now align long-term token commitments with active validator support.</p><p>Over time, this supports:</p><ul><li>More distributed delegation patterns</li><li>Greater engagement from aligned stakeholders</li><li>Reinforcement of validator diversity</li></ul><p>It also reflects an ecosystem maturity shift — where staking is expected to integrate cleanly into real custody workflows rather than exist as a separate operational layer.</p><h2 id="wallet-level-participation-as-a-standard"><strong>Wallet-Level Participation as a Standard</strong></h2><p>Ledger Wallet integration is important here not because it adds exposure, but because it anchors staking within a widely used self-custody environment.</p><p>When staking is embedded into wallet workflows:</p><ul><li>Participation becomes routine.</li><li>Operational complexity decreases.</li><li>Reliability expectations increase.</li></ul><p>This is where validator infrastructure becomes directly tied to user experience.</p><p>P2P.org supports TON staking through validator operations designed for continuous, production-grade performance — particularly in flows that integrate at the wallet level.</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/03/Frame-1410077858-1.png" class="kg-image" alt="" loading="lazy" width="1920" height="1080" srcset="https://p2p.org/economy/content/images/size/w600/2026/03/Frame-1410077858-1.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/03/Frame-1410077858-1.png 1000w, https://p2p.org/economy/content/images/size/w1600/2026/03/Frame-1410077858-1.png 1600w, https://p2p.org/economy/content/images/2026/03/Frame-1410077858-1.png 1920w" sizes="(min-width: 720px) 720px"></figure><h2 id="a-step-toward-broader-participation"><strong>A Step Toward Broader Participation</strong></h2><p>Enabling staking from vesting contracts via Ledger Wallet expands TON’s staking accessibility to long-term, structured participants while preserving the design principles of vesting itself.</p><p>It aligns token distribution mechanics with validator participation.</p><p>And it reflects a broader direction in staking infrastructure — one where participation fits naturally into custody workflows rather than sitting outside them.</p><h2 id="get-started"><strong>Get Started</strong></h2><p>If you hold vested TON and use Ledger Wallet, staking is now available through the P2P.org dApp.</p><p>Read the full guide here:<u> </u><a href="https://link.p2p.org/1cd04e?ref=p2p.org">https://link.p2p.org/1cd04e</a></p><div class="kg-card kg-cta-card kg-cta-bg-grey kg-cta-minimal " data-layout="minimal"> <div class="kg-cta-sponsor-label-wrapper"> <div class="kg-cta-sponsor-label"> <span style="white-space: pre-wrap;">For Wallets and Platforms</span> </div> </div> <div class="kg-cta-content"> <div class="kg-cta-content-inner"> <div class="kg-cta-text"> <p><span style="white-space: pre-wrap;">Teams interested in enabling this functionality can get in touch to explore integration options.</span></p> </div> <a href="https://www.p2p.org/products/api?ref=p2p.org" class="kg-cta-button " style="background-color: #000000; color: #ffffff;"> Learn more </a> </div> </div> </div>
from p2p validator
<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>
from p2p validator
<h3 id="at-a-glance"><strong>At a Glance:</strong></h3><ul><li>Institutions assess HYPE through market structure, custody, and operational readiness</li><li>Assets are held in custody with Komainu, enabling custody-native participation</li><li>P2P.org operates validator nodes within Hyperliquid’s active validator set</li><li>A selective operator model and clear role separation signal institutional maturity</li></ul><p>Institutional participation in crypto rarely starts with incentives. It starts with systems.</p><p>When institutions evaluate a new asset or protocol, the questions are usually straightforward and unforgiving. How does the market behave under stress? Where do assets sit operationally? Who is responsible for running critical infrastructure?</p><p>HYPE is increasingly being evaluated through this lens.</p><p>Rather than optimizing for short-term participation, Hyperliquid has focused on building a system designed to operate consistently at scale.For institutions, that distinction matters. Market structure, custody integration, and operational discipline tend to determine whether engagement is even possible.</p><h2 id="why-hype-is-drawing-institutional-attention"><strong>Why HYPE Is Drawing Institutional Attention</strong></h2><p>HYPE’s relevance is closely tied to Hyperliquid’s position as a leading <strong>perpetuals-native decentralized exchange</strong>.</p><p>Perpetuals (or perps) are widely used derivatives instruments in crypto markets. They allow market participants to maintain exposure to underlying assets without fixed expiry dates and are commonly used by trading firms and liquidity providers.</p><p>For institutions, this matters for two reasons:</p><p>First, perps are a <strong>crypto-native market structure</strong> that has proven sustained demand across market cycles. Second, decentralized perps infrastructure reduces reliance on centralized intermediaries while preserving market efficiency, a combination that is attracting growing interest from professional trading firms.</p><p>Hyperliquid’s focus on performance, market structureand system design has positioned HYPE as a core asset within this category. As institutional interest in crypto-native derivatives grows, perps DEXs are becoming an important access point, with HYPE emerging as a leading example.</p><p><em>Note: This section provides market context regarding the Hyperliquid ecosystem. P2P.org does not operate the Hyperliquid exchange, facilitate derivatives trading, or provide trading services.</em></p><h2 id="what-institutions-evaluate-before-engaging"><strong>What Institutions Evaluate Before Engaging</strong></h2><p>Before capital is allocated, institutions typically look for a small set of non-negotiables, such as:</p><p><strong>Market structure that can absorb size: </strong>Institutions care about how a system behaves when volumes increase, volatility spikes, or usage becomes sustained rather than episodic. HYPE’s design choices reflect an emphasis on efficiency, transparency, and consistency under load.</p><p><strong>Custody-native workflows: </strong>Assets are expected to remain under qualified custody. Any interaction with a protocol must integrate cleanly with existing custody, governance, and risk frameworks. Workflows that require assets to move outside custody introduce friction and operational risk.</p><p><strong>Proven infrastructure operators: </strong>Validator and staking operations are not interchangeable. Institutions look for operators with a operational experience and monitoring discipline, monitoring discipline, and experience operating infrastructure at scale.</p><p>If one of these elements is missing, engagement usually stops there.</p><h2 id="custody-as-the-foundation"><strong>Custody as the Foundation</strong></h2><p>For institutions, custody is typically the foundation everything else is built on.</p><p>In the HYPE ecosystem, assets are held in custody with Komainu an institutional-grade digital asset custodian supporting regulated funds, asset managers, and financial institutions.</p><p>Komainu’s custody framework allows institutions to engage with blockchain networks while maintaining segregation of assets, governance controls, and operational oversight. This enables participation without compromising custody.</p><p>In practical terms, this means staking activity can occur without assets leaving Komainu custody.</p><p> </p><h2 id="how-infrastructure-and-custody-work-together"><strong>How Infrastructure and Custody Work Together</strong></h2><p>Custody alone is not sufficient. Institutions also require secure infrastructure that can operate reliably within these constraints.</p><p>Within Hyperliquid’s active set of [nodes or validators], P2P.org operates validator infrastructure while assets remain secured under Komainu custody. Each party plays a clearly defined role.</p><p>In practice:</p><ul><li>Assets remain under Komainu custody at all times</li><li>P2P.org operates and maintains staking infrastructure within Hyperliquid’s active set</li><li>Monitoring, performance, and operational processes are designed for institutional standards</li><li>Custody, infrastructure, and protocol responsibilities remain cleanly separated</li></ul><p>This separation of roles reduces operational risk and increases transparency.</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/03/1080x1080-8.jpg" class="kg-image" alt="" loading="lazy" width="1080" height="1080" srcset="https://p2p.org/economy/content/images/size/w600/2026/03/1080x1080-8.jpg 600w, https://p2p.org/economy/content/images/size/w1000/2026/03/1080x1080-8.jpg 1000w, https://p2p.org/economy/content/images/2026/03/1080x1080-8.jpg 1080w" sizes="(min-width: 720px) 720px"></figure><p></p><h2 id="selectivity-signals-operational-intent"><strong>Selectivity Signals Operational Intent</strong></h2><p>Another signal institutions pay close attention to is selectivity.</p><p>Rather than allowing an unrestricted validator set, Hyperliquid maintains a curated active set of operators. Participation depends on infrastructure quality, reliability, and the ability to meet institutional standards.</p><p>P2P.org has experience operating more than $10B in secured assets across over 190 institutional clients. P2P.org’s presence in Hype‘s active validator set reflects its high standard of infrastructure discipline</p><p>On the custody side, Komainu’s support positions it among a small group of custodians enabling institutional access to HYPE today, an important factor for institutions evaluating new participation.</p><h2 id="infrastructure-as-a-prerequisite-for-institutions"><strong>Infrastructure as a Prerequisite for Institutions</strong></h2><p>Custody-native integration, a selective operator set, and production-grade operational processes are indicators that a protocol is being built for durability rather than short-term activity spikes.</p><p>HYPE’s growing institutional attention reflects these underlying choices. Rather than relying on incentives to attract participation, the ecosystem aligns with how institutions actually operate.</p><p>As institutional engagement with crypto continues to deepen, protocols that prioritize custody, operational clarity, and infrastructure quality are more likely to see sustained participation over time.</p><h2 id="learn-more"><strong>Learn More</strong></h2><p>For institutions exploring custody-native participation in the HYPE ecosystem, understanding how custody and infrastructure fit together is essential.</p><ul><li>Learn more about <strong>Komainu</strong> and its institutional custody framework: <a href="https://komainu.com/?ref=p2p.org">https://komainu.com/</a></li><li>For platforms, wallets, or infrastructure teams looking to integrate HYPE staking data, explore <strong>P2P.org’s Staking API</strong>: <a href="https://link.p2p.org/acce38?ref=p2p.org">https://link.p2p.org/acce38</a></li></ul>
from p2p validator
<p></p><p></p><h2 id="the-problem-with-restaking-today"><strong>The Problem with Restaking Today</strong></h2><p>EigenLayer has reshaped how institutional capital approaches Ethereum security. Over $10 billion in assets have been restaked to secure the protocol, and P2P.org has established itself as a leading Operator with hundreds of millions in delegated stake.</p><p>However, for many restakers the economic model has remained incomplete.</p><p>The typical restaking workflow looks like this: users delegate their stETH or rETH to an EigenLayer Operator, accumulate $EIGEN programmatic incentives, and maintain exposure to the restaking ecosystem. The underlying Liquid Staking Tokens (LSTs) delegated to Operators often remain inactive from a reward perspective, effectively functioning as collateral for restaking participation.</p><p>For institutions managing large ETH positions, capital efficiency matters. When assets serve a single purpose inside the restaking system, allocators naturally look for ways to activate additional utility while maintaining protocol exposure.</p><h2 id="introducing-aleph-finance"><strong>Introducing Aleph Finance</strong></h2><p>Aleph Finance is an EigenLayer AVS (Actively Validated Service) designed to address this limitation.</p><p>Through the integration, idle LST liquidity within EigenLayer Operators can be connected to on-chain reward strategies while remaining within the broader EigenLayer ecosystem.</p><p>This enables restakers delegating through P2P.org to participate in additional protocol-level reward mechanisms alongside their existing restaking participation.</p><p>The reward streams include:</p><p><strong>Protocol rewards on LST liquidity: </strong>Additional rewards generated through Aleph Finance integrations with on-chain strategies.</p><p><strong>Restaking incentives: </strong>Continued accumulation of $EIGEN programmatic incentives through EigenLayer participation.</p><p><strong>Optional $EIGEN restaking: </strong>Participants may restake accumulated $EIGEN incentives through Aleph’s mechanisms to enable further protocol-level rewards.</p><p>Importantly, restakers maintain their EigenLayer exposure while participating in these additional reward mechanisms.</p><h2 id="why-this-matters-now"><strong>Why This Matters Now</strong></h2><p>EigenLayer’s Programmatic Incentives v2 recently increased the allocation of $EIGEN incentives to restakers from 1 percent to 4 percent.</p><p>This structural change strengthens the incentives for continued participation in the restaking ecosystem.</p><p>The Aleph Finance integration introduces an additional protocol-level functionality related to rewards<strong> </strong>for LST liquidity already participating in EigenLayer, enabling a more capital-efficient restaking configuration without requiring users to exit the ecosystem.</p><h2 id="how-the-integration-works"><strong>How the Integration Works</strong></h2><p>P2P.org operates as an EigenLayer Operator and has integrated Aleph Finance as an AVS.</p><p>The integration functions through the following structure:</p><ol><li>Restakers delegate stETH or rETH to P2P.org as their EigenLayer Operator</li><li>LST liquidity associated with these delegations can be connected to Aleph Finance reward strategies</li><li>Strategy configurations are curated by kpk, a recognized provider of institutional DeFi strategy design</li><li>Protocol incentives and reward distributions may occur<strong> </strong>on-chain while $EIGEN programmatic incentives continue to accumulate through restaking participation </li></ol><p>The infrastructure supporting the integration includes monitoring systems, whitelisted operator configurations, and optional third-party coverage mechanisms depending on configuration.</p><p>The AVS stack has undergone multiple independent security audits, with ongoing audit programs maintained across the system.</p><p>Note: Participation in the Aleph Finance AVS requires delegation through a dedicated whitelisted <a href="http://p2p.org/?ref=p2p.org" rel="noopener noreferrer">P2P.org</a> EigenLayer Operator. <a href="http://p2p.org/?ref=p2p.org" rel="noopener noreferrer">P2P.org</a>’s primary Operator is not opted into Aleph Finance by default</p><h2 id="p2porg-as-your-eigenlayer-operator"><strong>P2P.org as Your EigenLayer Operator</strong></h2><p>P2P.org is one of the largest EigenLayer Operators by delegated stake, operating validation infrastructure across more than 40 networks and securing over $10 billion in assets.</p><p>As one of the community multisig participants securing the EigenLayer protocol, P2P.org has supported the ecosystem since its Stage 1 Mainnet launch.</p><p>Clients delegating through P2P.org benefit from enterprise-grade infrastructure, including SOC 2 compliant operational standards, geographically distributed validator architecture, and continuous monitoring systems across production environments.</p><p>Each AVS integration is evaluated prior to activation to assess operational and protocol risks, and P2P.org maintains direct coordination with protocol teams to ensure reliable infrastructure deployment.</p><p>The Aleph Finance integration has already been presented to institutional Liquid Restaking Token partners, with active coordination between the teams as the ecosystem continues to expand.</p><h2 id="activating-additional-rewards-on-restaked-lsts"><strong>Activating Additional Rewards on Restaked LSTs</strong></h2><p>For institutions holding stETH or rETH within EigenLayer, the Aleph Finance integration introduces a way to enable additional protocol reward streams while maintaining restaking participation.</p><p>P2P.org can configure a dedicated EigenLayer Operator environment tailored to Aleph Finance participation, allowing institutional clients to maintain operational separation from other delegations.</p><p>To learn more about the integration, infrastructure configuration, and participation process, you can schedule a discussion with our team.</p><p>Schedule a call:<a href="https://calendly.com/jonathan-reisman-p2p/30min-1?back=1&ref=p2p.org"><u>https://calendly.com/jonathan-reisman-p2p/30min-1?back=1</u></a></p><p><em>Disclaimer: This material is provided for informational purposes only and does not constitute investment advice, an offer, or a solicitation to invest in any financial instrument or strategy. Participation in restaking, staking, and AVS-related activities involves risks, including potential loss of assets. Past performance or protocol rewards are not indicative of future results. </em></p>
from p2p validator
<p>As on-chain financial infrastructure matures, one pattern is becoming increasingly clear: strong protocols succeed when paired with effective distribution.</p><p>High-quality lending infrastructure already exists. Capital-efficient designs, modular architectures, and professional-grade primitives are now well established. What continues to evolve is how these systems are delivered through fintech applications, neobanks, custodial platforms, exchanges, and wallets in a way that fits modern financial products.</p><p>This is where distribution layers play an important role.</p><p>The P2P.org Stablecoin Earn Widget is one example of this model in practice. It is live on the P2P.org frontend today, where users can access Steakhouse-curated Morpho vaults directly. The same product layer is also designed to be embedded by partners, enabling broader distribution across platforms.</p><h2 id="morpho-as-a-foundation-for-onchain-credit"><strong>Morpho as a foundation for onchain credit</strong></h2><p>Morpho is designed as a core DeFi primitive. Its architecture focuses on capital efficiency and modularity, making it well-suited as the infrastructure for lending and credit strategies that need to scale.</p><p>Rather than operating as a consumer-facing product, Morpho is intentionally built to serve as infrastructure. This allows strategy managers and platforms to compose on top of it, while benefiting from its underlying design.</p><p>In the context of the Stablecoin Earn Widget, Morpho provides the universal lending network that enables these strategies to function. Its role remains consistent: power credit markets at the protocol level, while higher layers focus on strategy design and distribution.</p><h2 id="turning-infrastructure-into-a-product-experience"><strong>Turning infrastructure into a product experience</strong></h2><p>The Stablecoin Earn Widget sits above the protocol layer. Its purpose is not to replace or abstract away the value of infrastructure, but to make it accessible through a controlled product interface.</p><p>Through this structure:</p><ul><li>End users engage with a simple earn experience</li><li>Platforms integrate a single component</li><li>Protocol complexity remains at the infrastructure layer</li></ul><p>This separation allows Morpho to remain focused on its core mission, while strategies and distribution are handled by specialized counterparts.</p><p><strong>Access and Distribution</strong></p><p>In addition to being embeddable by partners, the<a href="https://widget.p2p.org/select?ref=p2p.org"><u> Stablecoin Earn Widget</u></a> is also accessible directly through the P2P.org frontend.</p><p>This allows users to access Steakhouse-curated strategies on Morpho directly via P2P.org, while partners can integrate the same product layer into their own platforms.</p><p>This dual distribution model — direct access via P2P.org and embedded distribution via partners — highlights how protocol infrastructure, strategy curation, and product delivery can scale together.</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/03/data-src-image-fb2f9ce0-167f-4bb9-9111-661c193b2b29.png" class="kg-image" alt="" loading="lazy" width="1042" height="1508" srcset="https://p2p.org/economy/content/images/size/w600/2026/03/data-src-image-fb2f9ce0-167f-4bb9-9111-661c193b2b29.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/03/data-src-image-fb2f9ce0-167f-4bb9-9111-661c193b2b29.png 1000w, https://p2p.org/economy/content/images/2026/03/data-src-image-fb2f9ce0-167f-4bb9-9111-661c193b2b29.png 1042w" sizes="(min-width: 720px) 720px"></figure><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://p2p.org/economy/content/images/2026/03/data-src-image-58a80d0b-d3de-47da-86db-6520f01f0d8b.png" class="kg-image" alt="" loading="lazy" width="914" height="476" srcset="https://p2p.org/economy/content/images/size/w600/2026/03/data-src-image-58a80d0b-d3de-47da-86db-6520f01f0d8b.png 600w, https://p2p.org/economy/content/images/2026/03/data-src-image-58a80d0b-d3de-47da-86db-6520f01f0d8b.png 914w" sizes="(min-width: 720px) 720px"><figcaption><span style="white-space: pre-wrap;">Note: NRR values shown are illustrative examples for demonstration purposes only.</span></figcaption></figure><p><br><strong>The role of curation</strong></p><p>Between infrastructure and distribution sits curation.</p><p>The strategies available through the widget are curated by Steakhouse, which designs and maintains vaults built on Morpho. Steakhouse applies a structured approach to strategy construction, ensuring that protocol primitives are assembled into coherent, professional-grade products.</p><p>Each layer in the stack has a clear responsibility:</p><ul><li>Morpho provides the lending mechanics</li><li>Steakhouse curates and manages strategies</li><li>P2P.org delivers the distribution layer and interface</li></ul><p>This clarity makes it easier for platforms to offer stablecoin earn functionality without taking on roles outside their core focus.</p><h2 id="distribution-as-an-enabler"><strong>Distribution as an enabler</strong></h2><p>Capital today increasingly sits inside wallets, fintech applications, custodial platforms, and treasury systems. Distribution layers allow protocols like Morpho to reach these environments without operating user-facing products themselves.</p><p>By embedding the Stablecoin Earn Widget, platforms can surface Morpho-based strategies within products that users already trust and use. For Morpho, this expands reach through partners. For platforms, it provides a practical way to offer earn functionality backed by established infrastructure.</p><h2 id="built-on-infrastructure-designed-to-scale"><strong>Built on infrastructure designed to scale</strong></h2><p>The Stablecoin Earn Widget is supported by P2P.org infrastructure securing over $10B across more than 40 networks. This operational foundation supports the reliable delivery of strategies built on Morpho and curated by Steakhouse.</p><p>Importantly, this model does not alter how Morpho functions. It preserves the protocol’s role as infrastructure, while improving how strategies built on it are accessed and distributed.</p><h2 id="a-shared-direction"><strong>A shared direction</strong></h2><p>This collaboration reflects a broader evolution in DeFi:</p><ul><li>Protocols specialize in primitives</li><li>Strategy managers specialize in construction and oversight</li><li>Distribution layers specialize in product delivery</li></ul><p>The Stablecoin Earn Widget illustrates how these roles can work together in production today, with Morpho providing the underlying credit infrastructure.</p><p>As on-chain credit continues to grow, this separation of responsibilities creates clearer paths for adoption across platforms and users.</p><h2 id="integrating-the-stablecoin-earn-widget"><strong>Integrating the Stablecoin Earn Widget</strong></h2><p>For platforms exploring stablecoin earn functionality, the Stablecoin Earn Widget is designed to integrate directly into existing products.</p><p>It allows teams to offer access to curated strategies without managing protocol integrations or strategy design internally. Platforms interested in exploring integration can reach out to the P2P.org team to discuss fit and timelines.</p><p>Book a 20-minute discovery call <a href="https://link.p2p.org/3325c6?ref=p2p.org" rel="noreferrer">here</a>. </p><p>Learn more about the Widget in <a href="https://docs.widget.p2p.org/ ?ref=p2p.org" rel="noreferrer">our docs.</a></p>
from p2p validator
<p>In 2025, institutional crypto allocation stopped being about exposure—and started being about structure.</p><p>The difference is subtle but fundamental.</p><p>Instead of chasing market cycles, large allocators—from crypto-native funds to DAOs and exchanges—began designing portfolios for operational liquidity, onchain rewards, and capital rotation. That shift shows up clearly in the data: stablecoin holdings in large wallets rose meaningfully, native token exposures became more intentional, and Ethereum’s role as a settlement layer only deepened.</p><p>Today, P2P.org is publishing a new report: <a href="https://link.p2p.org/ike?ref=p2p.org" rel="noreferrer"><strong>“Stablecoins vs. Native Tokens: Institutional Allocation Trends”</strong></a></p><p>It’s a data-backed look at how the portfolios of institutional actors actually changed this year—built on onchain data, analytics dashboards, and infrastructure trends we observe directly across our network.</p><h2 id="what-the-report-covers"><strong>What the Report Covers</strong></h2><p>This isn’t a market recap. It’s a breakdown of how institutions allocated real capital—and what that says about the future of staking, stablecoins, and infrastructure decisions going into 2026.</p><p>Inside the report:</p><ul><li><strong>Wallet-level allocation trends</strong> from exchanges, funds, and DAOs</li><li><strong>Stablecoin usage patterns</strong>: reserves, liquidity, and treasury behavior</li><li><strong>Ethereum’s anchoring role</strong> across staking, settlement, and reserves</li><li><strong>The rise of programmatic allocation</strong> and treasury segmentation</li><li><strong>Case studies and charts</strong> </li><li><strong>Allocation frameworks</strong> emerging across institutional teams</li><li>A forward-looking view on <strong>infrastructure-aligned portfolios</strong></li></ul><p>The research draws on multi-chain data, but the patterns are clearest on Ethereum—where stablecoin reserves and native token deployments sit side-by-side in validator-linked portfolios.</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/02/1600--900-X.jpg" class="kg-image" alt="" loading="lazy" width="1600" height="900" srcset="https://p2p.org/economy/content/images/size/w600/2026/02/1600--900-X.jpg 600w, https://p2p.org/economy/content/images/size/w1000/2026/02/1600--900-X.jpg 1000w, https://p2p.org/economy/content/images/2026/02/1600--900-X.jpg 1600w" sizes="(min-width: 720px) 720px"></figure><h2 id="why-this-matters"><strong>Why This Matters</strong></h2><p>Stablecoins are no longer just “dry powder.” They’re tools for capital efficiency, onchain access, and risk-tiering in institutional portfolios.</p><p>ETH is no longer just an asset. It’s programmable liquidity, stakable yield, and the infrastructure of reserves.</p><p>And P2P.org’s view—as a validator and infrastructure partner across Ethereum and other proof-of-stake networks—is that allocation behaviors are now driven by operational design, not just exposure targets.</p><h2 id="download-the-full-report"><strong>Download the Full Report</strong></h2><p>This report is designed for crypto funds, asset managers, DAO treasurers, and institutional teams building real onchain portfolios.</p><p><a href="https://link.p2p.org/ike?ref=p2p.org" rel="noreferrer">[<strong>Download the Report</strong>] <em>Stablecoins vs. Native Tokens: Institutional Allocation </em></a> </p><p>Whether you're managing staking allocations, designing treasury structure, or evaluating validator partners, this research offers a data-grounded foundation for 2026 strategy.</p>
from p2p validator
<h2 id="at-a-glance"><strong>At a glance:</strong></h2><ul><li><strong>EigenLayer:</strong> A coordination layer enabling staked ETH to secure AVSs</li><li><strong>Why operators matter:</strong> Infrastructure quality directly impacts risk and net rewards</li><li><strong>P2P.org (EigenLayer operator):</strong> Institutional infrastructure with a <strong>5% operator commission</strong></li><li><strong>Update:</strong> Current commission structure <strong>extended through end of Q1</strong></li></ul><p><a href="https://app.eigenlayer.xyz/operator/0xd2bca64ad01f77de84be4a8acbd2e8beceed9ab3?ref=p2p.org"><strong><u>Stake with P2P.org on EigenLayer.</u></strong></a></p><p>EigenLayer is often discussed in terms of innovation. New services. New primitives. New narratives.</p><p>But underneath all of that, EigenLayer is fundamentally about coordination.</p><p>Coordination between capital and infrastructure. Between stakers and services. Between emerging AVSs and the operators that make them real.</p><p>As the ecosystem matures, one thing is becoming increasingly clear: the success of EigenLayer depends less on abstract ideas and more on the reliability, economics, and behavior of the operators securing it.</p><h2 id="eigenlayer-as-a-coordination-layer"><strong>EigenLayer as a Coordination Layer</strong></h2><p>At its core, EigenLayer allows staked capital to be reused to secure new services, known as Actively Validated Services (AVSs).</p><p>This model introduces powerful new possibilities, but it also introduces new responsibilities.</p><p>AVSs don’t just need capital.They need uptime.They need slashing-aware infrastructure.They need operators that can run production systems, not experimental nodes.</p><p>This is where the operator layer becomes critical.</p><p>EigenLayer is a coordination layer for new services that must operate under real economic and technical constraints.</p><h2 id="why-operator-choice-actually-matters"><strong>Why Operator Choice Actually Matters</strong></h2><p>As more capital flows into EigenLayer, the difference between operators becomes more pronounced.</p><p>Key variables start to matter:</p><ul><li>commission structure</li><li>infrastructure quality</li><li>operational maturity</li><li>long-term alignment with the ecosystem</li></ul><p>For stakers, operator selection plays a direct role in both risk management and net returns.</p><p>For AVSs, operator quality shapes how confidently a service can scale.</p><p>As the ecosystem matures, operator choice becomes a meaningful variable rather than a background detail.</p><h2 id="p2porg%E2%80%99s-role-in-the-eigenlayer-ecosystem"><strong>P2P.org’s Role in the EigenLayer Ecosystem</strong></h2><p>P2P.org participates in EigenLayer as an operator focused on long-term infrastructure, not short-term incentives.</p><p>The approach is simple:</p><ul><li>run robust, production-grade infrastructure</li><li>keep commissions transparent and competitive</li><li>support the AVS ecosystem as it grows</li></ul><p>Today, P2P.org operates with a 5 percent operator commission, positioning it among the lowest on the market for staking $EIGEN.</p><p>This structure is designed to maximize net rewards for stakers while maintaining the operational standards required to support EigenLayer’s expanding service layer.</p><h2 id="extending-the-promotion-through-q1"><strong>Extending the Promotion Through Q1</strong></h2><p>Originally, the current commission structure was communicated as running through the end of 2025.</p><p>Given continued demand and ecosystem growth, this structure will now be extended through the end of Q1.</p><p>The rationale is straightforward:</p><ul><li>EigenLayer is still early in its AVS adoption curve</li><li>operators and stakers are still establishing long-term relationships</li><li>maintaining predictable economics helps the ecosystem stabilize</li></ul><p>This extension gives stakers additional time to participate under the same conditions, while EigenLayer continues to evolve its service layer.</p><h2 id="the-road-ahead-for-eigenlayer"><strong>The Road Ahead for EigenLayer</strong></h2><p>EigenLayer represents a meaningful shift in how crypto networks coordinate security and services.</p><p>As that shift continues, operators move from the background to the foreground.</p><p>For stakers, operator choice is no longer just about headline APY.For the ecosystem, operator quality determines what is possible.</p><p>Extending the current commission structure through Q1 is a small step, but it reflects a longer-term view: building EigenLayer on stable, well-run infrastructure rather than temporary incentives.</p><p><strong>Stake with P2P.org on EigenLayer: </strong><a href="https://app.eigenlayer.xyz/operator/0xd2bca64ad01f77de84be4a8acbd2e8beceed9ab3?ref=p2p.org"><u>https://app.eigenlayer.xyz/operator/0xd2bca64ad01f77de84be4a8acbd2e8beceed9ab3</u></a></p>
from p2p validator
<p>Zama has opened its <strong>auction phase</strong>, marking the first step in the network’s staking rollout.</p><p>The auction allows participants to acquire ZAMA tokens ahead of delegation. <strong>Staking will follow approximately two weeks later</strong>, at which point delegators will be able to actively stake with validators on the network.</p><p>P2P.org is participating as one of <strong>18 genesis operators</strong> selected to support the network at launch and will operate a validator once delegation is enabled.</p><h2 id="what-is-zama"><strong>What Is Zama</strong></h2><p>Zama is building infrastructure to enable privacy-preserving computation, allowing applications to process sensitive data while keeping it confidential.</p><p>FHE enables computation to be performed directly on encrypted data, without requiring decryption at any point. For blockchain systems, this unlocks new categories of applications where sensitive data can be processed onchain while remaining confidential.</p><p>This cryptographic design introduces different requirements at the infrastructure layer, particularly around compute, performance, and validator responsibilities. Zama’s network is built to support these constraints from the ground up.</p><h2 id="how-the-auction-works"><strong>How the Auction Works</strong></h2><p>The auction phase is the <strong>entry point</strong> to Zama’s staking lifecycle.</p><p>Participants acquire ZAMA during the auction and position themselves ahead of delegation. While tokens are not staked yet, the auction establishes early network participation and prepares participants for staking once delegation is enabled.</p><p>Delegation to validators is expected to open approximately <strong>two weeks after the auction</strong>, at which point staking becomes active.</p><h2 id="participate-using-the-p2porg-referral-code"><strong>Participate Using the P2P.org Referral Code</strong></h2><p>During the auction phase, participants can enter a <strong>P2P.org referral code: JYT407</strong> to receive a <strong>+5% bonus in tokens</strong>.</p><p>This referral incentive applies only during the auction and is designed to reward early participants who plan to stake once delegation becomes available.</p><h2 id="why-p2porg"><strong>Why P2P.org</strong></h2><p>P2P.org’s involvement in Zama goes beyond operating a standard validator.</p><p>On Zama, P2P.org operates as an <strong>FHE co-processor</strong>, supporting the cryptographic compute workloads that are core to the network’s architecture. This infrastructure alignment enables <strong>higher APR compared to standard validators</strong>, driven by optimized execution and deeper protocol integration.</p><p>Once delegation is enabled, participants will be able to stake directly with the P2P.org validator.</p><h2 id="what-happens-after-the-auction"><strong>What Happens After the Auction</strong></h2><p>After the auction concludes:</p><ul><li>Staking will be enabled approximately <strong>two weeks later</strong></li><li>Delegation to validators will open</li><li>P2P.org’s validator will be available for staking</li></ul><p>Participants who join the auction early will already be positioned to stake as soon as delegation is live.</p><h2 id="how-to-participate"><strong>How to Participate</strong></h2><ul><li>Visit the official Zama staking portal</li><li>Enter the <strong>P2P.org referral code</strong> <strong>JYT407 </strong>during the auction</li><li>Prepare to delegate to the P2P.org validator once delegation is enabled</li></ul><p>Staking portal:<a href="https://staking.zama.org/?ref=p2p.org"> <u>https://staking.zama.org/</u></a></p><h2 id="closing-note"><strong>Closing Note</strong></h2><p>The auction phase marks the start of Zama’s staking lifecycle, setting the foundation for validator participation and long-term network security.</p><p>P2P.org’s focus is to support this transition by operating infrastructure aligned with Zama’s cryptographic design and remaining active through both the auction and delegation phases.</p><p>Further updates will follow as staking and delegation are enabled.</p>
from p2p validator