André Caldeira

13 posts
Travel Rule Enforcement and the Onchain Compliance Gap

<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>

André Caldeira

from p2p validator

Solana Staking for Institutions: Native vs. Liquid. A Decision Framework.

<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>

André Caldeira

from p2p validator

Validator Infrastructure for Institutions: A Complete Guide

<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>

André Caldeira

from p2p validator

BitMart Now Offers ETH, SOL, and DOT Staking - Powered by P2P.org

<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.&nbsp;</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.&nbsp;</p><p><strong>FAQ&nbsp;</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>

André Caldeira

from p2p validator

iLuminary Integrates P2P.org DeFi Widget, Giving Users Direct Onchain Access

<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>

André Caldeira

from p2p validator

Stake TON from Vesting via Ledger Wallet

<h2 id="at-a-glance"><strong>At a glance:&nbsp;</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>

André Caldeira

from p2p validator

P2P.org Brings DVT-Powered Staking to Japan's Corporate ETH Market - Together with BITPOINT, Def Consulting, and SSV Labs

<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>

André Caldeira

from p2p validator

HYPE’s Institutional Stack: Komainu Custody and P2P.org Infrastructure

<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>&nbsp;</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>

André Caldeira

from p2p validator

EigenLayer: Activating Additional Rewards for Restaked LSTs

<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&nbsp;</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>

André Caldeira

from p2p validator

From Protocol to Product: How Morpho Strategies Reach Users Through P2P.org

<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/&nbsp;?ref=p2p.org" rel="noreferrer">our docs.</a></p>

André Caldeira

from p2p validator

How Institutional Crypto Portfolios Are Evolving: Stablecoins, Native Tokens, and What Comes Next

<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>

André Caldeira

from p2p validator

Why Operators Matter in EigenLayer and What Comes Next

<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>

André Caldeira

from p2p validator

Zama Auction Is Live, Ahead of Staking Enablement

<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>

André Caldeira

from p2p validator