AMINA Bank AG and P2P.org Partner to Expand Institutional Access to Digital Asset Infrastructure

<p><strong>TL;DR.</strong> On October 21st, Solana switched its consensus engine to Alpenglow. For stakers, nothing changes: stake accounts, delegation, rewards and reports work as before. What changes sits underneath: transactions become final in about 150 milliseconds, the network handles failures and heavy load better, and validators pay for consensus with a flat fee that costs less than half of what voting cost before. Every P2P.org validator went through the switch smoothly.</p><p>For most of Solana’s history, a transaction executed in under half a second and took several more seconds to become final: about 12.8 seconds at the original 400ms slots, around 6 seconds after this fall’s slot-time cuts. Most users never noticed the wait. Risk teams built their processes around it: exchanges held incoming transfers in a confirmation buffer, custodians wrote the gap into settlement policy, and funds treated a “confirmed” transaction as very likely final, without a guarantee that it was.</p><p>On October 21, Solana switched to Alpenglow, the largest change to its core protocol since mainnet launched in 2020. Finality now targets around 150 milliseconds, votes have moved off the chain, and a flat 0.8 SOL fee per epoch replaces per-vote costs.</p><p>For stakers, nothing changed in how a staking position earns rewards. What changed is how the network performs, how much stress it can absorb, and the economics of running a validator. This post covers all three, starting with how we prepared.</p><h2 id="how-we-prepared-at-p2porg"><strong>How we prepared at P2P.org</strong></h2><p>We moved every validator we ran to the Alpenglow-ready client before activation - as soon as the testnet cluster went live.</p><p>Our SRE team is watching each node through the switch, and our analytics team is tracking finality, vote participation, and reward attribution.</p><p>We will share what we see as the data comes in.</p><h2 id="what-stays-the-same-for-stakers"><strong>What stays the same for stakers</strong></h2><p>Alpenglow changes consensus and leaves everything a staker touches in place:</p><ul><li><strong>Your stake:</strong> Stake accounts, their addresses and their delegations stay exactly where they were. No action was needed before or after the switch.</li><li><strong>Staking and unstaking:</strong> Delegation, deactivation and withdrawals follow the same rules as before.</li><li><strong>Rewards:</strong> Alpenglow keeps the existing reward mechanics. Inflation rewards are still paid by the network every epoch, and they remain variable.</li><li><strong>Transactions and fees:</strong> Execution, programs and transaction fees are untouched.</li><li><strong>Reporting:</strong> At P2P.org, rewards stay attributed per validator, and reports keep their schedule.</li></ul><p>One change stakers may notice predates Alpenglow. Solana cut slot times from 400 to 200 milliseconds in four steps between August and October (SIMD-0525), so an epoch now lasts about a day. Rewards arrive daily, and unstaked SOL becomes withdrawable within roughly a day. Reward distribution and reporting snapshots now happen twice as often, so any reconciliation built around two-day epochs deserves a check.</p><h2 id="what-changes-network-performance"><strong>What changes: network performance</strong></h2><p>Under TowerBFT, validators voted by sending transactions, and a block became final once 32 slots of votes had stacked up on top of it. That stacking is where the seconds of waiting came from.</p><p>Under Votor, validators send votes directly to each other and aggregate them into compact certificates. When at least 80% of stake votes for a block, it is final after one round. When participation lands between 60% and 80%, a second round at 60% finalizes it. Both paths run at once, and the faster one decides.</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/10/data-src-image-393ecdce-6a16-4019-8876-569b13441659.png" class="kg-image" alt="" loading="lazy" width="2000" height="1059" srcset="https://p2p.org/economy/content/images/size/w600/2026/10/data-src-image-393ecdce-6a16-4019-8876-569b13441659.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/10/data-src-image-393ecdce-6a16-4019-8876-569b13441659.png 1000w, https://p2p.org/economy/content/images/size/w1600/2026/10/data-src-image-393ecdce-6a16-4019-8876-569b13441659.png 1600w, https://p2p.org/economy/content/images/2026/10/data-src-image-393ecdce-6a16-4019-8876-569b13441659.png 2048w" sizes="(min-width: 720px) 720px"></figure><p>For exchanges, custodians and funds, this collapses the window between “included” and “irreversible” to a fraction of a second. Deposits can be credited as soon as they are final, and settlement on Solana becomes close to instant for redemptions and end-of-day books.</p><p>Two caveats for policy: The 150ms figure is a target from testing and will move with the stake distribution, so base settings on observed mainnet data. And integrations need no change on day one: statuses stay the same, and the separate “confirmed” level is retired in a later release. We recommend keeping current confirmation settings for the first weeks, in line with the Solana Foundation’s guidance.</p><h2 id="what-changes-readiness-for-load"><strong>What changes: readiness for load</strong></h2><p>Alpenglow makes Solana sturdier in three ways.</p><p><strong>More room for real activity:</strong> Vote transactions made up the majority of everything Solana processed. With votes off the chain, that block space goes back to user transactions, which gives the network more headroom during demand spikes. Network-wide transaction counts drop sharply for the same reason, while real activity stays where it was, so re-baseline any dashboard that counted votes.</p><p><strong>Better tolerance for the failures Solana has actually had:</strong> Past outages came from software bugs, congestion and validators going down at once. Alpenglow is built differently: it stays safe with up to 20% of stake acting maliciously and keeps finalizing blocks with a further 20% offline.</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/10/data-src-image-3a16514f-a8c0-4380-8dca-b64fe495ab8b.png" class="kg-image" alt="" loading="lazy" width="2000" height="617" srcset="https://p2p.org/economy/content/images/size/w600/2026/10/data-src-image-3a16514f-a8c0-4380-8dca-b64fe495ab8b.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/10/data-src-image-3a16514f-a8c0-4380-8dca-b64fe495ab8b.png 1000w, https://p2p.org/economy/content/images/size/w1600/2026/10/data-src-image-3a16514f-a8c0-4380-8dca-b64fe495ab8b.png 1600w, https://p2p.org/economy/content/images/2026/10/data-src-image-3a16514f-a8c0-4380-8dca-b64fe495ab8b.png 2048w" sizes="(min-width: 720px) 720px"></figure><p>The trade lowers the bar for a coordinated attack, which would still require control of a fifth of all staked SOL, in exchange for much stronger resilience to crashes. We think that is the right trade for a network carrying financial flows. Teams that model adversarial scenarios should move their threshold from one third of stake to one fifth.</p><p><strong>Predictable timing, higher bar for operators:</strong> Each slot now has a fixed deadline, and a block that misses it is skipped, so the leader loses that slot’s rewards. With 200ms slots, a leader’s four-slot window lasts about 800 milliseconds, and slow hardware or poor network placement shows up quickly. When you compare operators, skip rate, latency, monitoring and incident response now have a more direct effect on the rewards your stake earns.</p><p>The switch itself showed how this works under pressure. The migration ran on its own in five steps, and user transactions paused for only about two slots, roughly 400 milliseconds, while the network handed over to the new protocol.</p><h2 id="what-changes-validator-economics"><strong>What changes: validator economics</strong></h2><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/10/data-src-image-930bd4e8-c898-4cdd-ab9c-c68626b4ab60.png" class="kg-image" alt="" loading="lazy" width="2000" height="853" srcset="https://p2p.org/economy/content/images/size/w600/2026/10/data-src-image-930bd4e8-c898-4cdd-ab9c-c68626b4ab60.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/10/data-src-image-930bd4e8-c898-4cdd-ab9c-c68626b4ab60.png 1000w, https://p2p.org/economy/content/images/size/w1600/2026/10/data-src-image-930bd4e8-c898-4cdd-ab9c-c68626b4ab60.png 1600w, https://p2p.org/economy/content/images/2026/10/data-src-image-930bd4e8-c898-4cdd-ab9c-c68626b4ab60.png 2048w" sizes="(min-width: 720px) 720px"></figure><p>The biggest shift is on the validator’s side of the ledger. Under TowerBFT, every vote was a transaction with a fee, paid from the validator’s identity account.&nbsp;</p><p>Alpenglow replaces that stream with the Validator Admission Ticket (VAT): a flat fee charged from the vote account once per epoch and burned. At today’s 200ms slots it is 0.8 SOL per epoch of about 24 hours, paid one epoch ahead.</p><p><strong>Voting got cheaper:</strong> Because vote fees were charged per slot, this autumn’s slot-time cuts pushed them up with every step. Alpenglow brings the cost back down.</p><p>Rising vote costs over the last two months came from faster slots, and the admission ticket reverses them. The saving has one offset: half of every vote fee used to go to the leader of the block that included it, so validators producing many blocks also lose that income. The net effect depends on each validator’s share of block production&nbsp;</p><p><strong>The vote account becomes an operating balance:</strong> If it cannot cover the fee, plus its rent-exempt minimum, at the start of an epoch, the validator does not vote or produce blocks in the next one and earns no rewards for it. Funding that used to sit on identity accounts now has to live on vote accounts, with monitoring and alerts around it.</p><p>For white-label validators this raises a practical question: who holds the vote account’s withdraw authority. If the client holds it, the client controls withdrawals and carries the risk of drawing the balance below the fee. If the operator manages it, the operator keeps a buffer and withdraws rewards above it. Both models work, as long as the balance rules are written into the process.</p><h2 id="what-we-are-watching-in-the-first-weeks"><strong>What we are watching in the first weeks</strong></h2><ul><li><strong>Real finality on mainnet: </strong>The 150ms target was measured in testing. We are tracking how finality behaves under live load and stake distribution before recommending any change to confirmation settings.</li><li><strong>Reward data across the ecosystem:</strong> Some operators may collect rewards from many validators into a single account to simplify operations. That removes the per-validator view funds and white-label clients use for reconciliation, and rebuilding it requires certificate data that current RPC methods do not expose cleanly. Vote credits now derive from those certificates, so a validator’s inflation rewards also depend partly on how the rest of the network performs.</li><li><strong>Metrics and tooling:</strong> Figures computed from vote transactions, such as vote success rate, stop working at activation until Anza ships new RPC methods. Explorers, indexers and analytics providers will update on their own timelines.</li><li><strong>Client diversity: </strong>The migration ran on Agave-based clients only. Firedancer supports Alpenglow in <strong>later</strong> releases.</li></ul><h2 id="what-comes-next"><strong>What comes next</strong></h2><p>Votor is the first phase. Agave 4.4 brings fast leader handover, which lets the next leader start building before the previous window is fully decided. Rotor, the second half of Alpenglow’s design, will replace Turbine’s multi-hop block propagation with a single relay layer in a later, still unscheduled release.</p><h2 id="faq-alpenglow-and-solana-staking-for-institutions"><strong>FAQ: Alpenglow and Solana staking for institutions</strong></h2><p><strong>What is Solana Alpenglow?</strong></p><p>Alpenglow is Solana’s new consensus protocol, activated on mainnet at epoch 1064 on October 21, 2026. Its first phase, Votor, replaces TowerBFT. Validators send votes directly to each other, combine them into certificates, and finalize a block after one or two voting rounds, with a target of roughly 150 ms. Transaction execution, the SVM, and fees are unchanged. A second phase, Rotor, will change how block data is propagated in a later release.</p><p><strong>I stake with your validators. Do I need to do anything?</strong></p><p>No. Your stake stays where it is, and delegation, unstaking, and withdrawals work as before. We handle the switch on our side.</p><p><strong>Will my protocol rewards change?</strong></p><p>The reward mechanics remain the same.&nbsp;</p><p><strong>Will my reports change?</strong></p><p>No. Reports keep the same schedule and format.</p><p><strong>What does the Validator Admission Ticket cost?</strong></p><p>A flat 0.8 SOL per epoch, charged from the vote account, burned, and paid one epoch ahead. With 200 ms slots, an epoch lasts about a day. If the vote account cannot cover the fee when an epoch starts, the validator does not vote or produce blocks in the following epoch and earns no protocol rewards for it.</p><p><strong>I run a white-label validator. What changes for me?</strong></p><p>How consensus is paid for, what balance has to stay on the vote account, and who is responsible for keeping it there. The right setup depends on how your validator is configured today. <a href="https://p2p.org/?ref=p2p.org"><u>Talk to our team</u></a>, and we will walk you through it.</p><p>Evaluating Solana staking or a white-label validator? <a href="https://p2p.org/?ref=p2p.org"><u>Talk to our team</u></a>.</p><h3 id="further-reading"><strong>Further reading</strong></h3><p><a href="https://solana.com/upgrades/alpenglow?ref=p2p.org"><u>Solana Foundation: Alpenglow upgrade guide</u></a></p><p><a href="https://www.anza.xyz/alpenglow?ref=p2p.org"><u>Anza: Alpenglow</u></a></p><p><a href="https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0326-alpenglow.md?ref=p2p.org"><u>SIMD-0326: Alpenglow</u></a></p><p><a href="https://github.com/solana-foundation/solana-improvement-documents/blob/main/proposals/0384-alpenglow-migration.md?ref=p2p.org"><u>SIMD-0384: Alpenglow migration</u></a></p><h2 id="disclaimer"><strong>Disclaimer</strong></h2><p>This material is provided for informational purposes only and does not constitute investment, financial, legal, or tax advice. <a href="http://p2p.org/?ref=p2p.org"><u>P2P.org</u></a> accepts no liability for any actions taken based on it. Latency and performance figures referenced are estimates based on internal benchmarks and may vary depending on network conditions, geography, and client infrastructure. Past performance is not indicative of future results.</p>