A financial institutions guide to solana

The Solana Research Institute is an independent, member-owned association. The opinions expressed in this publication are solely those of the author and do not reflect the views of the members of the Solana Research Institute. In addition, the opinions expressed in this Guide are for informational purposes only and do not constitute financial, investment, strategic or legal advice. Discussion of asset performance is based on historical data, which does not guarantee future results. Investing in any of the assets mentioned in this Guide involves risk, including the potential loss of principal. You should conduct your own due diligence or consult a professional advisor before making any investment decision.

Introduction

This is a guide to Solana for people who work in Financial Institutions (“FIs”). It is intended to provide a clear-eyed description of Solana from six different perspectives that an analyst at a fInancial institution might consider if tasked with evaluating Solana as a venue for their firm’s business:

The operation of the Solana protocol and architecture and their applicability to financial applications.
The economics of Solana, both for end users and network participants.
The funding and governance structure of the network.
The players active on Solana, their business models and how they combine to create an ecosystem that can support FI business.
How Solana, a permissionless chain, fits into regulatory frameworks.
A brief survey of some of the products that have been launched on Solana or that are under development.

It has been said (in bars, at length) that blockchains have been badly marketed to banks because each chain has come forward with its own story about why it is good, and there are so many different chains that the poor FIs find the whole thing too confusing and are in danger of giving up. There is no question that blockchain finance can be a challenging topic and it is incumbent on people working in crypto to think clearly and present their ideas appropriately, bearing in mind Einstein’s maxim that you should simplify things as far as possible, but no further. There is plenty of room for improvement in this department.

However, it seems strange to argue fundamentally that different blockchains should not compete on their strengths. That would imply that blockchains are mere commodities, which patently is not the case. The strengths of a particular chain depend on many factors: network security; speed and cost of transaction processing; cost to build and deploy applications; network effects and liquidity; the wider eco-system; resilience; and governance, to name just a few. Different systems have different combinations of these factors and the market must decide which combination it values most, which requires potential buyers to engage with both the breadth and the depth of the solutions on offer.

This Guide is a contribution to that process with respect to Solana. It is published by the Solana Research Institute (SRI), an independent, not-for-profit organisation owned by members of the wider Solana ecosystem and established to produce high quality research on blockchain and digital finance, targeted at Financial Institutions. Given that provenance, it will surprise no one that the Guide is sympathetic to Solana. However, it is not a marketing brochure. Rather it should be seen as an input to the decision making processes of FIs considering which chain(s) to develop on. At the very least, it will save a lot of duplicative legwork by banks’ digital asset teams.

Preface: Blockchain, Solana and Financial Institutions

Why blockchain and why now?

Before we get going, it is worth re-stating the case for the use of blockchain in financial services.

Since blockchain seeped into mainstream consciousness about 10 years ago, it has generated an explosion of hype, a mountain of white papers and conference speeches and a lot of Proofs of Concept. So far, however, it has had limited impact on the actual course of the super-tanker that is the financial system. So does blockchain really have anything to offer financial institutions, or is it just the proverbial solution looking for a problem?

The first thing to note is that ten years is no time at all for a new technology to influence something as deeply rooted as the financial system. The fact that blockchain has had any impact at all is therefore somewhat remarkable. And the impact may be bigger than it seems on the surface.

A lot of work has been taking place at the foundational level of policy and regulation. Regulators have been working to accommodate blockchain and related concepts like tokenisation and stablecoins into their frameworks and events such as the SEC’s recent decision to classify SOL, the native token of Solana, as a digital commodity and not a security, indicate a profound shift in regulatory stance.

This decision follows The Genius Act, which created a regulatory framework to bring stablecoins in from the cold. But its real significance lies in the fact that it did so by meeting the stablecoin pioneers on their own ground, creating rules on structure, liquidity and asset portfolios that are distinct from those faced by both banks and short term investment instruments such as money market funds. The growth of stablecoins could have a profound effect on both the financial and the wider economy, not only increasing the velocity of money, but potentially prising payments and liquidity away from the universal banks that have dominated these services for the last century.

In parallel, central banks and financial infrastructures have been actively exploring how to support on-chain business. The announcement of the Eurosystem’s Appia Roadmap initiative is important because it marks a practical project to open Euro payment infrastructure to on-chain transactions.

Building on these developments, tokenisation of financial assets is finally reaching a point of maturity on many levels, with big name issuers, increasingly sophisticated systems and operating models, and a regulatory environment that is catching up with market practice. And all this has been going on while DeFi, a potentially disruptive alternative to the financial system, has been maturing in terms of product offering, governance and resilience, to the point where it is increasingly meeting the needs of mainstream users of the traditional system.

So momentum is building. But that still leaves the question: is there really a benefit to moving on-chain? Of course, the real world answer is complex and context-specific. However, stepping back, it is increasingly clear that blockchains like Solana will have a huge impact on the costs of manufacturing, operating, and accessing financial products and services. Manufacturing costs are plummeting as composable code is reused and repurposed across multiple applications. Operating costs will be driven lower as ever more financial processes can be automated on-chain and we move to a world where tokens are not simply passive representations of asset ownership but self-executing managers of value transfers. And market structure will shift as customers gain unprecedented control over the financial products they use, from peer-to-peer payments to complex trading strategies. This shift will create opportunities for new players such as digital custodians and wallet providers to position themselves as increasingly important distributors of value-added services.

This is not to predict the imminent migration of the financial system to blockchain, let alone to make a call on what the eventual outcome will look like. But it is clear that the invention of blockchain has let a genie out of the bottle that has no intention of going back again and is set to unleash a new wave of innovation and creative destruction. No one knows where this will end, but can you afford not to be on the magic carpet?

Solana in a Nutshell

Solana is a general purpose layer 1 blockchain protocol developed by Anatoly Yakovenko in 2018. It was designed to support very high transaction volumes with low latency and fees, combined with efficient deployment and operation of on-chain applications. The genesis block of the Solana Mainnet was generated on 16th March 2020.

The Solana protocol is permissionless and uses a proof of stake mechanism to achieve consensus on which transactions to accept into its ledger. While the original protocol delivers fees and latency substantially lower than other major chains, the Solana community has committed to implementing an upgrade to the consensus-forming mechanism, known as Alpenglow, later this year. Alpenglow is expected to further improve performance, with latency reduced by roughly two orders of magnitude from approximately 12.8 seconds to around 150ms.

The native cryptocurrency of Solana is called SOL. SOL performs two core functions in the operation of the network. Firstly, it is the currency in which fees are paid by users to have their transactions validated and added to the ledger. Secondly, it is required by network validators as “stake”: collateral posted in order to gain the right to participate in the network’s consensus-forming process and thereby earn a share of the fees paid by users.

500 million SOL were minted at the genesis of the Mainnet, and additional coins are minted at a defined rate as rewards for validators. This inflation is slightly offset by burning some of the coins that are paid in transaction fees by users.

As a permissionless protocol. Solana does not have a central governance authority. However, a group of entities were established when Solana was launched to provide management services to the network at both technical, operational and strategic levels, and these work closely with the leading validator node providers such as Jito, Helius and Figment in a hybrid relationship. This model has proven itself to be effective both in terms of enhancing the protocol, for example through Alpenglow, and addressing the operational issues that can arise in any online system.

The Solana ecosystem is varied, but two sets of firms are of particular interest to FIs. Core infrastructure providers operate the protocol, route transactions, form and validate blocks, and disseminate the results. Sitting atop this core infrastructure are financial infrastructure service providers, such as exchanges and custodians. Many of these services are currently targeted at the DeFi community and therefore have a retail focus, but increasingly services targeted at institutional businesses are also emerging. These will in turn attract more institutional volume in a self-reinforcing cycle.

The attitudes of regulators towards the use of permissionless blockchain as a venue for mainstream financial business are evolving and some regulators are looking for points of accommodation. Solana, through both features available in its core protocol and services provided by firms in the ecosystem, supports solutions to many of the concerns expressed by regulators. Ongoing dialogue and detailed work at both technical and policy levels will close the gap further.

Issuance of financial assets on Solana is nascent. So far, issuance has been dominated by stablecoins and these are gaining increasing acceptance among FI users. For example, Visa is now using USDC on Solana as a settlement mechanism between acquirers and issuers on its network. The market cap of RWAs other than stablecoins has just topped $2bn and a healthy pipeline is building as high profile issuers look to develop asset tokenisation as a focus for future growth.

What Makes Solana Well Suited for Institutional Finance?

Why should a Financial Institution consider building on Solana? Here are six reasons.

1. Very high capacity

Solana is designed for high transaction throughput. It typically processes around 3,000-4000 transactions per second (TPS) but has a (theoretical) peak capacity of 65,000 to 100,000 TPS. By way of comparison, Visa processes an average of 1,700 TPS, with a peak network capacity of 65,000 TPS.

2. Speed to finality

Solana reaches finality - the point at which there is zero probability of change to a record in the ledger - very quickly. Currently, blocks are typically “Confirmed”, that is accepted as valid by a supermajority (66%) of validators, within 400 milliseconds (ms), and reach full finality in 12.8 seconds (s). Moreover, although there is a theoretical possibility that a block accepted by the Supermajority could subsequently be rolled-back before reaching finality, this has never happened in practice so many people treat confirmed status as synonymous with final. Later this year, Alpenglow will radically reduce the time to achieve full finality from 12.8s to a mere 150ms. This speed is essentially the fastest speed possible within the physical constraints of the network and is similar to the round trip processing speed of many centralised online transaction processing systems. Having transactions processed within these time frames eliminates uncertainty and accelerates liquidity.

3. Very low transaction cost

Solana’s transaction costs are low- often fractions of a cent. What is more, the protocol's design means that heavy traffic in one set of tokens or accounts has no impact on the fees paid for transactions in other tokens. This contrasts with many other blockchain protocols, where congestion in one token can lead to spiking fees for all users. It is also close to one of the ideals aspired to by financial infrastructure providers when setting their rate cards, which is that users should pay only for the resources they consume.

4. Native, composable functionality

Much of the functionality required to build applications and tokens on Solana is natively deployed on the network, available to be called at run-time and fully battle-tested. This “composability” compresses build time, reduces test requirements and simplifies audits and risk sign-off. With a newly-launched API-based development platform making this functionality available code-free, costs of development and deployment are low compared to other environments and development can often be removed from the critical path for financial product launches.

5. Inbuilt compliance features

Solana has in-built access control features at token level, meaning compliance comes as standard. Tools such as Yellowstone Shield also make it possible automatically to bypass validators, applications and wallets operated by sanctioned or otherwise unsuitable entities.

6. A genuine settlement system

Stablecoin on Solana circulate 5 times faster on Solana than they do on Ethereum. This demonstrates that Solana is functioning as a real transaction settlement system with liquidity circulating and being recycled at scale and speed, which is precisely what is needed for mainstream financial applications such as payments and trade settlement.

Chapter 1: Solana by Numbers

Solana by numbers by the Solana research institute

(Source: Blockworks.com)

Chapter 2: Overview of Solana Operations

The Solana project often describes itself as building the Internet Capital Market. A key plank of this vision is that assets, markets, participants and services all coexist - to the greatest extent possible- on the same shared network. This stands in contrast to today’s siloed and fragmented capital markets and also to competing blockchains, many of which have pursued a scaling model based on layer 2 chains that achieve speed at the expense of creating new silos and fragmentation.

In this chapter, we take a non-technologist’s tour of how the Solana protocol design delivers on the promise of Solana’s, focusing on four aspects in particular:

The way the core protocol is configured to maximise throughput and minimise latency.
The token model and the way it minimises time to market and coding risk through a library of functionality pre-deployed on the network and available to be called at run-time by any application that needs it.
Privacy and interoperability between public and private chains
Network stability, even in extreme conditions, with early teething issues resolved

A. Core System Protocol: Designed for Speed

We start by looking at the operation of Solana’s protocol; that is the mechanism that allows people who do not know or trust one another to reach a consensus on the correct state of a set of data to which anyone in the world can propose updates. By correct state, we mean that all changes to the data are based on proposals that are correctly formatted, made by people with the authority to request the changes and sequenced in a way that everyone on the network accepts as valid. We will focus on the features that enable the protocol to reach such a state at very high speed and low cost, despite supporting a large and disparate group of tokens and very high transaction volumes.

At the time of writing, Solana is poised between the original version of the protocol and a new version, known as Alpenglow, which is due to be adopted later in 2026. Alpenglow will make fundamental changes to certain operations, while staying true to the core principles underpinning the Solana design. Given this inflexion point, we touch on both versions of the protocol in this section in order to highlight the improvements Alpenglow will bring.

a) Overview of the Protocol

Solana operates using a proof of stake consensus mechanism with delegation of stake, organised around a shared concept of time, known as “Proof of History”. Computers (controlled by people) can participate in network operations as “validators” whose job is to approve proposals to add new data to the Solana ledger, known as transactions. Validators qualify for the role by “staking”, that is, committing capital in the form of SOL for a fixed period of time, known as an Epoch. The more SOL a validator stakes, the more direct and indirect fee-earning opportunities it will have. Epochs are broken down into shorter time periods called “Slots”, each of which lasts 400ms and is the time allotted to group a set of transactions into a “block” for validation. There are 432,000 slots per Epoch, summing to approximately 48 hours.

At the start of each Epoch, the protocol generates a schedule of “Leaders” from amongst the validators that have committed stake for that Epoch. Validators take up the role of leader during the times published in the schedule and each turn lasts for four Slots (1.6 seconds). Leader turns are allocated randomly on a stake-weighted basis: the bigger a proportion of the total stake a validator has committed, the more turns it will receive as leader.

Leaders are tasked with organising transactions into blocks- finite sets of transactions which can be approved by other validators. Transactions can perform many functions such as minting new tokens, transferring ownership of an existing token from one user to another user or changing control of accounts. Anyone can construct a transaction and submit it to the next leader in the schedule for inclusion in a block. Leaders check that each transaction they receive is correctly formatted and authorised before adding it to the block they are working on. In many cases, the order in which transactions are added to blocks does not matter. However, when two or more transactions both relate to the same pre-existing record, it can matter a great deal.

Once the leader has placed a transaction in the block sequence, it timestamps the transaction and broadcasts it to other validators on the network as part of a streaming feed that continues until the block is complete.

The flow of data through the Solana Transaction Lifecycle

When a block is complete, validators vote to accept it and add it to Solana’s ledger, a canonical record of all valid transactions accepted by the network. There are times when more than one valid block, each containing a different transaction set, is in circulation at the same time, usually because the network has become partitioned for some reason. These situations are called “Forks”, and the protocol contains mechanisms to deal with them based on incentives for validators to add their vote to the fork supported by the majority as quickly as possible. Once validators controlling a supermajority of stake have committed to a block and enough subsequent blocks have been built on top of it, it is considered to be final and becomes an immutable record in the ledger.

b) Minimising Time to Finality

While blockchain records are immutable once they are finalised, blockchain protocols have been criticised because of the time they take to reach finality on a given set of transactions. Bitcoin famously takes up to an hour to reach finality as the network slowly resolves forks through iterations of its ten-minute mining cycle. Until that point, a given block may be rejected and so the status of the transactions it contains is uncertain, which can be problematic for financial applications that depend on knowing the state of data definitively for legal, risk management and operational reasons.

There are significant technical challenges to achieving low latency in a distributed, permissionless network. Individual network nodes may have differing access to computer power and network bandwidth, making synchronisation difficult. Moreover, the network’s topography itself is fluid and unpredictable, with nodes free to join and leave at will, and the possibility of disruption caused by technical outage or malicious attacks ever present. Solana’s solution to these challenges is based on four elements:

A shared concept of time.
An account and transaction structure that enables parallel processing in order to minimise bottlenecks.
A data dissemination approach designed to minimise both the quantity of data that must be transmitted over the network and the bandwidth required to do so.
Voting mechanisms that enable validators to reach consensus on blocks quickly.

i. Shared time

Organising resources is much easier when you can incorporate a concept of time. “Let’s meet at the pub” is not useful unless we also agree, “at seven o'clock". On a computer network, a shared concept of time between nodes enables coordination that can transform efficiency:

Activities can be pre-scheduled. On Solana, Leader slots are allocated well in advance. This allows users to send their transactions directly to the leader who will process them, dispensing with the need for a “mempool”, where transactions sit idle until a leader selects them.
Records can be time-stamped. Solana leaders time-stamp transactions when they accept them into a block, enabling them to stream block data to the rest of the network before the block is completed, which gives validators earlier access to data and more time to process them before voting on the block

But time is difficult to manage on a network with no central authority. Each node will have a different clock, and these will tend to drift apart as some run slightly faster than others, making it hard for the nodes to agree when exactly events have happened. Solana’s solution to this problem is known as “Proof of History.”

In the original version of the protocol, the leader continuously iterates an algorithm known as the SHA-256 hashing algorithm. Each iteration returns an output that will always be identical for a given data input, but cannot be predicted except by running the algorithm. The input to each iteration of the algorithm is the output of the previous iteration, periodically mixed with new transactions accepted by the leader.. Each iteration of the algorithm takes a more or less fixed amount of time, so the iterations act as both a “verifiable delay function” - a standard ticker that can be used both to schedule events in the future- and a timestamp for transactions that have already happened. Other validator nodes can verify the sequence on receipt because, while the Proof of History can only be generated in sequence, it can be broken up to be checked in parallel.

Alpenglow replaces an external clock with a frequently re-set stopwatch operated by each node, and definitive sequences of events such as leader slots that are scheduled or transactions that have already been accepted by a leader. Under Alpenglow:

The schedule of leader slots for each Epoch uses index numbers which show where slots occur relative to one another, but do not allocate specific times measured against an external clock.
Transactions are published by the leader as they are verified, as in the original protocol, but instead of being time-stamped, they are indexed and grouped into a “slice” for distribution. Multiple slices can be created, each also indexed, which establishes a definitive relative order of events. Leaders keep publishing slices until the block is full, at which point they close the block.
Validators wait a fixed amount of time to receive finished blocks from each leader. The waiting time is set as a parameter of the protocol and is determined with reference to the expected maximum time it will take messages to move across the network. Each node runs its own stopwatch, which it resets every time a parent block in the chain is finalised, which takes about 150ms, described in part vi below. Resetting the watch with this frequency ensures that time drift never becomes significant enough to impact network operations. If a validator does not receive a block within the time limit, it stops waiting and turns its attention to the next leader’s block.

ii. Accounts and Transactions

When two or more transactions refer to the same piece of data in the ledger there is potential for a clash whereby execution of one transaction renders the other invalid. Often, this takes the form of two instructions attempting to transfer the same token holding to different people, hence it is often referred to as “double-spending”. To avoid this risk, many blockchain protocols enforce strictly sequential processing by leaders- each transaction must be selected, validated and placed in sequence before the next one can be processed. However, this approach can create bottlenecks where, say, heavy trading activity in one particular token stops the leader from working on transactions in unrelated tokens and wallets. The result is unpredictable delays and increased competition for the leader's attention, which pushes up fees, even for transactions which pose no double-spending risk.

Solana’s data structure is designed to enable transactions that cannot cause clashes to be processed in parallel, minimising bottlenecks and preventing congestion spilling out across the network. All data on Solana, including token meta and holdings data, are stored in accounts linked to specific tokens. When people create transaction instructions, they specify all the accounts the transaction will need to read from or write to in the instruction header.

Using this information, leaders can quickly separate transactions that pose double spending risk from those that are completely independent, such as payments from a private user’s wallet. The leader can process the latter transactions simultaneously while, in parallel, it works to arrange those that could cause clashes into an appropriate sequence.

Solana also maintains a strict segregation of processing logic from data about tokens and holdings. This structure means that leaders can run the same code for many different tokens at the same time. Not only does this approach eliminate another source of bottlenecks, but it also allows code to be reused efficiently in different applications across the network, which, as we shall see in Part B below, significantly reduces development cost. For example, almost all applications will use the same code, deployed only once on the entire network, to mint new tokens.

The overall outcome is that congestion affects only specific tokens, and non-clashing transactions achieve faster execution and avoid fee spikes, even if overall network volumes are peaking.

iii. Data dissemination

Reaching final consensus among validators requires rapid and accurate dissemination of transaction and block data from leaders to validators. A leader’s outbound bandwidth is another potential bottleneck that could delay the network reaching finality on a block. In Solana v1.0, this bottleneck is addressed via a protocol called Turbine. Alpenglow uses an evolution of Turbine called Rotor to reduce latency still further. While Turbine and Rotor are different in detail, they both use 3 core steps:

Blocks are split into sub-units called shreds. A shred is a fixed quantity of data that fits inside a defined message format. Shreds are created in real time, as soon as transactions have been validated and sequenced, and can be broadcast before the block is completed. Streaming broadcast of shreds optimises the use of network bandwidth over time.
Shreds are disseminated from the leader to validators through a hierarchical distribution structure that optimises use of bandwidth in space.
Shreds undergo “Erasure coding”, a process that enables recipients to reconstruct data even if they do not receive all the shreds, insulating overall network performance from localised disruption that may impact the flow of data to certain validators.

Under Turbine, the distribution hierarchy is made up of several layers. Recipients in the first layer forward the data to a pre-designated subset of nodes in the second layer, who then forward them to a third tier and so on. The hierarchy changes with every thread, with each validator’s chance of being near the top of the tree and hence getting first sight of the data, weighted by its stake. Multiple layers reduce the bandwidth required by any node, including the leader, to disseminate information, but add delay and increased risk of data loss.

This issue will become more acute as the number of nodes on the network grows. Hence, Rotor takes an alternative approach to avoiding bottlenecks. A “committee” of relay nodes is selected on a stake-weighted basis. These relays form a single layer between the leader and the rest of the network. Each relay is responsible for sending a certain amount of the overall broadcast to all other nodes on the network. This limits the bandwidth each relay requires but maintains a flatter structure with lower latency compared to Turbine’s deeper hierarchy. Recipients reconstruct the total feed from the shreds received from each relay, relying on the erasure coding if any are missing.

iv. Voting

The final stage of reaching finality is for validators to vote on the blocks they believe to be correct. This requires two steps. Firstly, validators check the leaders’ work, making sure that transactions included in a block are valid and protocol rules have been correctly followed. Secondly, validators vote to include the block they have validated in the ledger. Voting is weighted by stake: the more stake a validator has, the more their vote counts. This step is vital to ensure that all records in the ledger are unique and consistent.

At certain times, two or more valid blocks representing the same Slot may exist in the network, vying for the votes of validators. Solana can fork when a leader is offline or its block fails to propagate in time because of disruption to the network. When it happens, the network needs a mechanism to choose between the resulting forks.

The existing version of Solana uses a voting mechanism called “Tower BFT”. Under Tower BFT, validators send votes in favour of the last block they received to the current leader, who records the votes in the block they are working on. Blocks are finalised in two steps. Step one, known as “Confirmation”, is completed when the votes of validators representing at least ⅔ of the stake are recorded on chain. Step 2, “Finality”, happens when an additional 32 blocks have been built on top of the original block, at which point Solana’s lock-out mechanism would make it impossible for any validator to change its mind.

The lockout mechanism is Tower BFT’s primary tool to manage forks. Faced with more than one block for the same slot, a validator must make a choice on which to vote for. Generally, it will favour the block that has already received the most votes. However, there may be cases where a validator backs a fork that attracts only a minority of votes and so has to change lanes to enable it to vote on future blocks on the dominant fork. When this happens, the validator gets locked out of voting for a number of slots that doubles with each block it signed on the defunct fork. Being locked out of voting means missed revenue and so there is a strong incentive for validators to converge on the winning fork as quickly as possible.

Tower BFT has operated effectively. However, it has three drawbacks. Firstly, on-chain voting means that a significant proportion of block space, often up to 75%, is filled with voting transactions, which restricts capacity. Voting transactions also incur transaction fees that increase costs for validators and act as a barrier to participation for new nodes whose low stake-weight restricts their opportunities to earn revenue. Finally, adding 32 blocks to the Solana chain takes 12.8 secs which, while fast compared to many other blockchain protocols, is still very slow compared to the centralised online transaction processing systems used by traditional exchanges and settlement services.

Addressing these drawbacks is one of the prime objectives of Alpenglow, and its approach to voting marks its most radical departure from the original protocol. It starts from the observation that, on a large proof of stake network, a malicious node seeking to interrupt or corrupt network operations would need to control a very large value of stake to achieve its objectives. The amounts are big enough to make even the opportunity cost of bad behaviour intolerable, but Solana is also planning to introduce rules to automatically confiscate stake from validators that breach protocol rules by, for example, voting on more than one block for the same slot. This confiscation policy, known as “slashing”, will turn an opportunity loss into a capital loss, undermining the economic incentives for malicious attacks still further.

Based on this observation, Alpenglow assumes that the stake controlled by any attacker will not exceed 20%. Currently, approximately 425 million SOL, valued at $37bn, are staked on SOL. A malicious attacker hoping to launch a sybil attack would therefore need to risk over $7bn of capital just to interrupt network operations. Alpenglow also assumes that up to a further 20% of stake may be controlled by nodes that are offline at any given time for technical reasons. This means that Alpenglow allows blocks to be finalised with the votes of honest nodes controlling only 60% of the stake, in contrast to the ⅔ required in Tower BFT. If less than 60% of the stake can be mustered, the network will cease confirming new blocks.

Alpenglow runs two voting procedures. If a validator receives a correctly constructed block within the time limit specified in the protocol, it will vote to “notarize” it. Votes are off-chain messages broadcast to all other active nodes. If the validator receives notarization votes for a valid block from nodes representing 80% of committed stake it declares the block to be final and produces a “Fast-finalisation certificate”. Any validator receiving such a certificate will also accept the block as final and broadcast a certificate of its own. This is known as the fast voting procedure.

The slow voting procedure runs in parallel. As soon as the validator notices that 60% of the stake has voted for the block (i.e. before it has reached the 80% threshold) it broadcasts a finalisation vote. Again, as soon as any validator receives such votes from other nodes controlling 60% of the stake, it also declares the block final.

A third case can occur where a validator does not receive a correct block within the time limit. If this happens, the validator votes to skip the slot and if 60% of the stake votes the same way the next leader starts from the last block that was finalised. This ensures that the network keeps rolling forward, even when an individual leader loses touch.

Alpenglow’s dual voting procedure provides a back up mechanism. If the network is operating properly, it can rapidly achieve 80% consensus in a single round of voting. This is the basis for the claims of 150ms finality. The 80% threshold means that, even with 20% of validators offline and 20% malicious validators, the honest majority of 60% would still carry the day, overpowering double voting or other shenanigans tried by the attackers.

If the network is experiencing difficulties and cannot get to the 80% threshold, the two step slow voting procedure still enables it to achieve consensus and finalise the block, without compromising safety. This is because, once the 60% threshold has been reached, honest nodes following the protocol will not change their votes, again rendering malicious nodes powerless.

v. Overall impact of Alpenglow

We have touched on the operational changes that Alpenglow will implement at various points in this section. However, we have not yet looked at the implications of these changes for the network as a whole. Their impact will be felt in four major ways.

First, Alpensglow will have a dramatic impact on latency. The new voting mechanism, working in conjunction with the other optimisations, reduces the time to finality from 12.8 seconds to an average of 150ms. These speeds are comparable to Web 2 and even centralised online processing systems. For many financial services applications, including payments, settlements, they are fast enough to eliminate uncertainty and allow real time transaction processing on a public blockchain.

Second, Alpenglow will increase the scalability of the network, eliminating potential bottlenecks such as the Turbine data distribution hierarchy. In the words of its Whitepaper, Alpenglow achieves “asymptotically optimal throughput”, which means that its performance, measured by various key parameters, stays constant, even as network load increases.

Thirdly, Alpenglow will significantly reduce the cost of running a validator node by eliminating transaction fees on voting. This should make validation profitable for nodes with less access to stake, mitigating concentration risk and improving security.

Finally, Alpenglow will increase network resilience, enabling consensus to be achieved even with only 60% of the stake available. This resilience is achieved while still retaining a high bar to malicious activity.

B. Solana Token Model - Stateless Programs and Standard Functions

Solana’s account model with its rigorous segregation of code, metadata and dynamic data, means that successful code can be shared very easily by multiple tokens and related applications, an architectural feature known as ‘composability’. Organisations linked to Solana have used this capability to pre-fabricate many of the common building blocks needed to support financial products on-chain and deploy them on the network, ready for anyone to use, making it faster, cheaper, and less risky to launch new products and applications.

a) Tokens and Accounts

Tokens and accounts are intrinsically connected on Solana. Each token is associated with three sets of accounts:

One or more Executable Accounts that contain the code that determines the behaviour of the token. These accounts can be shared by many different tokens and so are prohibited from storing any data, which is a central principle underpinning both parallel processing and composability on Solana.
A Mint Account, which stores the token’s metadata, such as how many tokens are in issue;
Program derived accounts (PDAs), which are system generated accounts used to store dynamic data associated with the token. PDAs have a variety of uses within Solana including:
Acting as “Associated Token Accounts”, which record the number of the tokens controlled by each user’s wallet or by other program accounts.
Storing data that is needed as inputs to the programs used by the token, such as fee schedules, allow-lists of permitted users or price feeds;
Storing data output by a program

b) Programs

i. Overview of Solana Programs

Programs, the Solana term for Smart Contracts, are computer applications that perform specific functions such as minting new tokens or checking that a transaction originates from an approved person.

Programs are stored in Executable Accounts, which, by default, are available for use by any application deployed on the network. A feature called Cross Program Invocation (CPI) enables one program to call another program at runtime, enabling complex applications to be assembled from pre-existing building blocks.

Many of the most commonly used programs on Solana were developed by product teams working for the Anza or other organisations at the heart of Solana’s ecosystem and are deployed in a collection known as the Solana Program Library (SPL). SPL programs support basic operations including minting, burning and transfer of tokens and delegation and freezing of accounts. Another set of programs, known as Token 2022, greatly expands the range of functionality available to manage tokens and transactions, and includes features such as:

Confidential balances, which hide token balances and transaction values from public view.
Metadata enhancements, which can specify a canonical source of metadata about the token or enable metadata to be embedded in the token itself. Metadata in this context is broader than the technical data in the mint account and can include real-world data like a prospectus for a fund represented by a token.
Transfer fees, collected by the token issuer on transactions.
Automated corporate actions such as coupons, dividends and stock splits.
Access Control Lists, which specify who can or cannot own the token.
Non-transferable tokens that can permanently encode attributes about the token holder’s identity, enabling the development of self-sovereign identity (SSI) applications.
Permanent delegation, which allows a control authority to be created for a token mint with privileges over all the accounts associated with the token, including the right to burn, freeze or transfer user tokens.
“Memo on transfer”, which lets issuers specify certain data that must be included as a message in a transaction instruction.
Grouping, where sets of tokens can be linked in a group that shares metadata and classification schemas.

Many of these features have been incorporated into the Solana Security Token Standard (SSTS), which was developed by an industry consortium led by security specialist Halborn to “support regulated token workflows that require configurable verification, controlled operations and corporate action support, while remaining adaptable to different operational and policy requirements”.

The composability of programs on Solana brings significant benefits including:

Reduced development time- common or commoditised functions are readily available, freeing application developers to focus their efforts on unique or value added features.
Reduced testing overhead- Programs accessed via CPI are already deployed in a live environment, and their performance can be observed. Some, like those in SPL, have been used thousands of times and tested in the most extreme conditions experienced by the network, giving developers and sponsors a high degree of confidence that they will perform as expected.
Reduced audit requirements- data on feature performance are readily available, giving auditors and risk managers comfort when signing off live deployments.
Reduced surface for malicious attackers- bugs and vulnerabilities are quickly identified and flushed out.

ii. Using Composable Programs to Build Financial Applications

Table 1 maps some of the ready made programs available on Solana (rows) to possible use-cases along the finance value chain (columns). It is an illustrative list only and necessarily generic. For that reason, we follow Table 1 with a worked example based on a tokenised bond where we show how some of these features could be combined to create a full-lifecycle financial product.

Table 1: Illustrative Financial Use Cases for Solana Token Extensions

Table 1 continued.

Table 1: Illustrative Financial Use Cases for Solana Token Extensions 2

A worked example- combining features to create a tokenised bond

C. Privacy and Permission

Confidentiality is vital to many financial transactions, and providing it is a key area of focus for public blockchain. Solana offers three sets of solutions to this requirement.

a) Confidential Balances

The first is “Confidential balances”, a set of functions that enable token holders to hold and transfer on the public Mainnet, with its security and low fees, without revealing transaction details to other blockchain users. Confidential balance functions are offered as extension programs under Token 2022 and must be incorporated into the token design by the issuer. They enable:

Confidential Transfers, that hide the quantity of tokens moved between two wallets
Confidential Transfer Fees, which keep the amount of any fees associated with the transaction secret; and
Confidential Minting and Burning, which hides the total number of tokens in issue.

Confidential balances use advanced cryptographic techniques such as zero-knowledge proofs and homomorphic encryption to ensure privacy without compromising the integrity of transactions. However, not all of this technology is currently supported by wallet providers which limits the availability of Confidential Balances to specialist applications and user groups. This is likely to change over time as the required cryptography is adopted into mainstream technologies: for example, zero-knowledge proof libraries are now available in JavaScript.

b) Permissioned Environments

In cases where a public blockchain is not considered appropriate, the Solana protocol can be deployed on a private network using Solana Permissioned Environments (SPE). SPEs enable network managers to establish closed participation groups while still utilising Solana’s technical architecture and functionality.

Using permissioned environments, network administrators can vet and approve validators, enforce their own validation methodologies and control key parameters such as block time, the size of transaction fees or the tokens used to pay them.

At the same time, key features of the Solana mainnet, such as high throughput, parallel processing and rapid finality, remain available, as do all of the programs deployed in the SPL and Token 2022. This makes it quick and easy to deploy functionally rich, private networks to support specific use-cases. Further, enhancements and programs released on the Mainnet can easily be copied over to the private network, enabling network operators to leverage the continued development of the wider community.

Although SPEs are fully stand-alone networks, it is easy to make them interoperable with the Mainnet or other chains using cross-chain bridging solutions such as LayerZero that enable data and assets to be transferred, and programs to interact, across networks. For example, a wholesale bond issuing agency could establish an SPE for initial distribution of new issues to a private dealer network that then onward distributes some of the bonds to a retail client base that uses the Mainnet.

Examples of applications that use SPEs include:

SphereNet, an institutional settlement layer, designed to interoperate with core banking systems, market infrastructure and stablecoins.
Pythnet, a permissioned Solana fork used to aggregate submissions on prices published by various participants.
AlphaLedger, a Real World Asset tokenisation platform.

c) Corda

Corda is a leading private distributed ledger system, developed by R3, a bank-owned software development company founded in 2014, and targeted at financial institutions. It was designed to be highly configurable while maintaining a strong focus on privacy: transaction details are only visible to their direct counterparties, while an automated notary function provides time stamps and signatures over transaction hashes as proof of execution.

Corda has achieved significant penetration in the financial sector with high-profile clients including SDX, the digital wing of the Swiss Stock Exchange Group, and Spunta, an interbank reconciliation service developed in Italy by ABI Lab.

In the summer of 2025, R3 and Solana announced an alliance to integrate the private Corda environment with the Solana DeFi community, creating new funding and investment opportunities. The first fruit of this alliance is the Corda Protocol, a Solana vault that gives access to the yield generated by RWAs.

D. Network Stability

Since February 2024, Solana has operated with 100% uptime, despite exponential growth in the numbers of different tokens, transactions and users on the network and major market events such as the price collapse and deleveraging that occurred on 10/10 2025. However, in its first years of operation, Solana had several major outages that significantly degraded or halted network performance, leading some to claim that it is unstable or unreliable. This section briefly reviews the outages, looking at both their root causes and the network’s recovery, which is sometimes seen as a weakness for permissionless, distributed systems.

Our conclusion is that, somewhat counter-intuitively, the Solana experience shows that decentralised systems can incorporate frameworks that are very effective at implementing both short-term fixes and long-term solutions to problems that may arise, comparable in terms of timeliness to solutions implemented by traditional centralised system operators when faced with similar situations.

a) Outage by Design

During each of the outages experienced, the Solana network stopped creating and approving new blocks and ground to a halt. This was by design. Distributed systems face a constraint, known as CAP Theorem or Brewer’s Theorem, whereby they can only guarantee to achieve two out of three outcomes:

Consistency, which ensures that, once data is accepted by the system, all users have access to it at the same time;
Availability, which means users can always get a response from the system; and
Partition Tolerance, which means the network will keep functioning even when part of it becomes separated from the rest.

Solana is designed to sacrifice Availability in favour of Consistency and Partition Tolerance. That choice ensures that the integrity of the data is maintained at all times but at the risk of operational interruptions when problems arise. This trade-off is obviously correct for a system that keeps public records with real-world implications. But does the existence of CAP Theorem invalidate the use of distributed systems by Financial Institutions for critical services?

b) Bugs and their Fixes

While CAP theorem applies only to distributed systems, all systems are vulnerable to outages, whether caused by malicious attack or software bugs. The impact of such events may be different for centralised systems, but no less severe. For example, a centralised d\tabase architecture may be vulnerable to catastrophic data loss to which a distributed system would be immune.

Arguably, distributed systems are more vulnerable to software bugs because anyone is free to deploy code on the network, making it hard to enforce consistent governance and release standards. Most of the Solana network outages were the result of bugs in one or other of the software clients used by validators, which prevented validators controlling at least ⅓ of total stake from participating in block validation, halting the ledger.

An additional vulnerability faced by open systems is that business logic may interact with other programs or with human users in unexpected ways, with knock-on impacts across the network. For example, another of the Solana outages was caused by the launch of the Candy Machine, a platform for minting NFTs, which caused a huge spike in volumes as people deployed bots to spam the application in the hope of gaining freshly minted tokens, which were being allocated on a first come, first served basis.

However, both bugs and reflexive behaviour have also impacted centralised systems. The Bank of England’s Real Time Gross Settlement (RTGS) system, responsible for all wholesale Sterling payments, went down for a full day in 2014 as a result of defects introduced by system changes.

Centralised systems are also vulnerable to problems in the client applications deployed by their users. In 2008, for example, a problem in HSBC’s e-payment system prevented it from processing retail payments for a whole weekend, with knock-on impacts across the UK payment network. Finally, there have been well documented cases of software glitches interacting with human behaviour to cause catastrophic failure: the Flash Crash of 2010, which impacted both the NYSE and the CME, being a well-known example.

Another charge made against permissionless systems is that they take longer to recover from failures than centrally managed systems. It is certainly true that developing and deploying fixes may be more complex in distributed networks than in centralised systems since it requires coordination between independent validators and developers to identify the problem, come up with a solution, roll it out across the network and agree on the state of data from which to restart operations.

However, Solana’s experience shows that, when problems do arise, network participants display a high degree of urgency and collaboration to resolve them with both short and long-term fixes. Average downtime during the outages experienced on Solana prior to 2024 was 9.7 hours, with a maximum of 19 hours and a minimum of 4.5 hours, which is comparable to the 9 hours taken by the Bank of England to recover its RTGS system in 2014.

Solana’s performance in this respect is partly because validators have a direct economic incentive to get the business working again, which may be missing in more bureaucratic institutions. It is also because of the existence of well-funded organisations such as Solana Labs, Anza and the Solana Foundation whose mandate to take leadership roles in finding solutions to emergencies is recognised by the wider community.

Collaboration among network participants can also lead to long-term fixes. Following the Candy Machine outage, Metaplex, the developer of the application, implemented a “Bot tax”, a small fee applied to transactions that appear non-human . At the same time, Solana Labs and leading validators worked on changes to the core protocol, switching to a new messaging standard better able to handle high transaction volume and introducing priority fees to enable genuine transactions to distinguish themselves from spam.

While it is impossible to say what problems may be lurking around the corner, the stability of Solana over the last two years shows that large scale, high performance, permissionless systems can work very effectively, even in high-stress conditions. A successful switch to Alpenglow will prove that they can also handle major upgrades.

As a result, Financial Institutions that leverage Solana at scale are using a system in which they can increasingly have similar confidence to the traditional platforms on which they have hitherto relied.

c) Recovery Procedure

Solana has a well-documented procedure for dealing with outages. The lead role is taken by the Solana Foundation, via its Incidence Response Group (IRG). The IRG communicates with engineers at the validators and other organisations such as ANZA via Discord channels to identify root causes and agree remedial action. They also agree on a finalised block close to the point at which the outage occurred, from which to restart operations.

Each validator implements any required software patches to address the cause of the outage and restarts its node. Operations restart at a synchronised time, contingent on nodes controlling at least 80% of stake coming online beforehand. Any transactions submitted between the designated last pre-outage block and the restart are lost and must be resubmitted to the network.

Chapter 3: Network Economics

The smooth operation of blockchain networks depends on the interaction of people and technology. Blockchain protocols therefore contain incentives for humans as well as rules for machines and the design of these incentives is as important to a protocol’s success as the technical design. Incentive structures sit in the realm of economics, and so this section looks at the rewards and costs of participation on Solana, from the points of view of both those who provide the infrastructure necessary for the blockchain to function and those who use it to manage transactions.

A. Design of SOL

Cryptocurrencies are central to the blockchain economy. The native cryptocurrency of Solana is SOL, and it plays two roles in network operations. It serves as:

collateral, staked by validators as an investment that determines the scale of rewards they receive for their participation, and as a pledge that they will abide by the rules of the protocol;
a settlement asset, paid by network users to validators to have their transactions added to the ledger.

As of 22nd April 2026, there were approximately 625 million SOL tokens in issue, up from 500 million minted in the genesis block. About 575 million of the tokens issued are in general circulation. The remainder are held in locked accounts. Of these, most are owned by the Solana Foundation and have been allocated to people running smaller or newer validators under its delegation programme (see Chapter 4). Others are held by investors who funded the early development of Solana, or were acquired on the liquidation of Alameda Research, following the collapse of FTX.

The supply of SOL increases as new coins are minted at the end of each Epoch< New coins are allocated to validators as commission, based on the number of blocks they voted on and their stake-weight. The rate of inflation and its rate of change are parameters in the protocol. Starting at 8% per annum at the Mainnet’s genesis, the inflation rate is set to decrease by 15% per annum until it reaches a long-term target rate of 1.5%. It is currently at 3.975%. The initial rate was set high to create incentives for validators to participate in the network when few people were using it and transaction volumes, the other major source of validator revenues, were low. Its decline over time reflects an assumption that, as the network matures, fees from increasing transaction volumes will take over and provide a correspondingly greater proportion of validator rewards.

Counteracting inflation, the protocol also contains a deflationary mechanism which burns 50% of base transaction fees paid in each block. However, the effect of this is insignificant compared to inflation and it appears to be a residual feature from a design idea that has not been pursued, rather than a central component of Solana’s tokenomics.

Inflation obviously lowers the unit value of SOL, and since the new coins are allocated to stakers, the overall effect is to transfer value from holders of unstaked SOL to those who have staked it. This seems fair in principle- stakers are sacrificing liquidity to secure the network. However, there is ongoing debate about the level and use of inflation in the protocol. Issues raised include:

Whether it encourages “over staking”, reducing the pool of liquid SOL available for other purposes. At 68%, the total proportion of SOL staked is high compared to other chains although it is unclear whether this has wider significance in terms of network adoption or operation.
The fact that inflation-based rewards are taxable in some jurisdictions puts additional downward pressure on the price of SOL as validators must sell holdings to meet the resulting liabilities.
The perception that a long term decline in the unit price of SOL does not look good and may discourage participation in Solana, even if the aggregate value of the network remains stable.

Whether or not these points have merit, there are no current plans to adjust Solana’s inflationary bias. In any case, as we shall see in section C, network mechanics do not seem to have exerted much influence over the price of SOL in the real world.

B. Regulatory Status of SOL

SOL is classified as a digital commodity. This status is very recent; until March 2026, the SEC had been attempting to classify SOL as a security. Classification of SOL as a commodity is important because it means that activities such as staking or trading SOL are not securities transactions, which would have brought significantly greater regulatory oversight and would likely have been a barrier to adoption for institutions. It is also good that an area of uncertainty has been eliminated.

C. Price Performance of SOL

Figure 3 shows the price history of SOL in USD, up to the time of writing. There are six distinct phases, labelled on the chart. In the first phase, the network was largely used by developers and early adopters, and the price of SOL rarely topped a dollar. However, in 2021, a crypto bull market kicked in, driven by the NFT craze and the growth of DeFi. SOL rode the escalator all the way up, its ascent supercharged as the wider world noticed Solana, with its revolutionary combination of low latency and low fees, for the first time. The bull market hit the wall in 2022, with high profile failures in the DeFi world topped by the collapse of FTX. In phase 3, the price of SOL fell as sharply as it had risen, from around $260 all the way down to $8. The slide was exacerbated by the liquidation of the large amounts of SOL held by Alameda Research, FTX’s sister company. The system outages discussed in Chapter 2 above did not help, either.

Phase 4 was a period of consolidation as the network stabilised. The price of SOL flatlined near the bottom of its range for over a year before interest in crypto began to recover in late 2023. In phase 5, the recovery became a rebound, became a second bull market, driven to its eventual peak in 2025 as the Trump administration’s supportive stance on crypto created a newly optimistic environment. SOL hit an all-time high of approximately $293 in early 2025. Since then, phase 6 has been characterised by volatility, with macro uncertainty and a pullback from high-beta assets.

More than just a speculative asset

It is said that crypto is an asset that, like a currency or a collectible, can be priced but not valued, since it has no direct link to economic activity. The price history of SOL might seem to support that view: it is certainly true that the primary drivers of the price have been the tumultuous macro forces unleashed by the growth of crypto, rather than the business performance of the Solana network. However, SOL’s central role in Solana’s operating model distinguishes it from purely speculative assets and provides a basis for modelling a theoretical fair value, correlated to the demand for transaction validation and the supply of staking capital. This theoretical value may continue to be overwhelmed by speculation in the short term, but it hints at the possibility of a more stable future as the network matures in the long run.

D. Costs of Node Operations

Operating validator nodes represents the primary source of cost on the core Solana network. These costs include:

Server costs. Validator nodes have a high minimum hardware specification that makes server hosting relatively expensive: typically in the range of $500 to $1800 a month
Bandwidth: The high bandwidth requirement of Solana means that communication costs can be a multiple of server costs.
Transaction fees for votes. In the current version of the Solana protocol, validators pay base transaction fees on the votes they submit. Base transaction fees are 0.000005 SOL. Assuming a validator votes once on each block in an Epoch (432,000 blocks), the transaction costs will be 2.16 SOL per epoch, or approximately 315 SOL per year. As noted above, Alpenglow takes voting off-chain and so eliminates these costs, which will have a significant impact on the profitability of smaller validators.
Opportunity cost of stake. Acting as a validator requires SOL to be purchased and locked up as stake. This stake may come from a validator’s own resources but it is often delegated to the validator by 3rd parties, in which case the opportunity cost falls on the delegators. As at 22nd April 2026, approximately $37bn was staked on Solana, down from over $90bn in November 2024
Validators offering delegated staking services may also incur customer acquisition and support costs.

So, what do network participants earn in return?

E. Infrastructure Revenues and User Fees

Validators have access to various sources of revenue, some paid directly as fees, others managed by the protocol. These revenues, after deduction of expenses, are shared between the node operators and those that have delegated stake to them with more than 90% typically paid to the delegators.

In 2025, validators earned aggregate fees of $690m, of which $480m were transaction fees, $124m inflation commission and $86m Jito tips. This represents a CAGR of 364% compared to 2023, when total fees of $32m were dominated by inflation commission of $24m and transaction fees $7.5m

Table 3 sets out what these revenues are, who pays them and who receives them.

Chapter 4: History, Funding and Governance of Solana

A. Origins and History of Solana

The Solana protocol was developed by Solana Labs, founded by Anatoly Yakovenko, an engineer from Qualcomm, along with fellow engineer Greg Fitzgerald, who helped turn the vision into practical code, and Raj Gokal, who focused on business and ecosystem development.

Yakovenko’s intention was to remove the bottlenecks inherent in earlier blockchains such as Bitcoin and Ethereum, in order to achieve processing times and rates of throughput comparable to those of centralised Online Transaction Processing Systems used to run traditional applications, such as exchanges and payment networks. This intention is echoed in Solana’s self-description as the “Internet Capital Market”.

Table 4 lists key milestones in the development of Solana:

B. Funding and Ownership of Sol

Development of Solana was funded through several rounds of capital raising, as set out in Table 5 below.

Currently, the largest single holder of SOL is the Solana Foundation, which was granted 167m SOL tokens at the time of its incorporation. The remit for use of these funds is outlined below.

Solana’s founders may also retain significant holdings. The founders were allocated 62.5m tokens from the genesis mint, representing 12.5% of the total. A recent story on Binance, quoting a report by Arkham, estimated that Anatoly Yakovenko still controls over 3 million SOL.

Looking more broadly, ownership of SOL is relatively dispersed. SOL is held in around 9.2m separate wallets, with the top ten holders owning approximately 6.6% of the issuance and the top 100 owning 22.8%. This dispersed structure is partly a result of the collapse of FTX and Alameda Research, whose large holdings were sold by the administrators. Many of the largest current holders of SOL are digital asset treasuries (DATs), listed companies that act as investment vehicles for cryptocurrencies. Table 6 lists the top corporate holders of SOL at the time of writing.

C. Corporate Structure

Although the Solana protocol is open-sourced and instantiates a permissionless blockchain network, its governance remains surprisingly centralised and efficient in terms of system operations and product management.

Three related corporate entities sit at the heart of Solana’s governance structure, taking a close interest in the growth and development of the network and its ecosystem.

The original development of the protocol was carried out by Solana Labs, a for-profit company that was established in 2018 by Anatoly Yakovenko. Solana Labs focus has now shifted to developing products and incubating and investing in companies that use the Solana blockchain. For example, it incubated Metaplex, a protocol for launching tokens and NFTs on Solana while Jito, a developer and operator of core Solana infrastructure, received investment from Solana Lab’s venture portfolio.

Responsibility for development of the Solana protocol has shifted to Anza, a software engineering company spun out of Solana Labs in January 2024. Anza developed Alpenglow. It also maintains Agave, one of the software clients used by validators.

A second entity spun out of Solana Labs was the Solana Foundation, a Swiss-registered non-profit set up in 2020. The Solana Foundation is charged with strengthening and growing the network. It does this through:

Oversight of network operations, in particular through the Incident Response Group, noted in Chapter 1.
A Delegation Programme that seeks to prevent over-concentration of validators by lending stake to new and smaller validator nodes, helping them to achieve sufficient stake weight to make a return on the cost of node operations. A significant portion of the non-circulating portion of SOL in issue is accounted for by this program.
Product development activities focused on ease of adoption and use of Solana. For example, the Product Team has recently released the Solana Developer Platform, a no-code, API-based development tool that aggregates functionality available in the Solana Program Library with third party services, making it faster and easier to build new applications.
A programme of grants to encourage development of the ecosystem, particularly targeting projects that develop “public goods” for the network.
Educational, promotional, lobbying and business development activities, directed both from the centre and through associated entities including “Superteams”, charged with developing local markets in strategic geographic locations, and the Solana Policy Institute. The highlight of these activities is Breakpoint, an annual conference for the whole ecosystem.

D. Operational and Product Governance

Since the operation of Solana depends on a large number of independent validators and other users, the three organisations listed above do not have direct control over the evolution and operation of the Solana network in the same way as a traditional corporate system operator. Nevertheless, there are several channels through which they can exert their influence.

Changes to the protocol or network, whether as part of a strategic roadmap or to fix an outage, require a consensus among the validators before they can be implemented. Formal mechanisms have been established for building this consensus.

Day-to-day coordination is done using a dedicated Discord channel accessible to all validators. This channel is also the conduit for emergency discussions when outages occur, and CTOs of many validators have permanent alerts set to monitor it.

Secondly, there is a process for reviewing and implementing proposals to change core components of the protocol, known as Solana Improvement and Development (SIMD) proposals. SIMD proposals are published on GitHub, with public channels for comments and discussion. Anyone can submit a SIMD proposal, but the major ones tend to come from Anza.

The most significant SIMDs, especially those with implications for network economics, are formally voted on. Voting tokens are distributed to validators on a stake-weighted basis and recipients cast their votes by transferring the tokens to designated wallet addresses representing different voting options. Clearly this process gives more influence to validators than other users of the network, although the wider community of SOL holders has indirect influence via their delegation relationship with their validators. However, a forthcoming change to the Solana governance processes will introduce “validator override,” providing SOL holders with the ability to take control of their voting preferences during network-wide votes.

These formal mechanisms help streamline decision making. However, the central organisations are also able to exert significant informal influence over the ecosystem by virtue of the resources that they dedicate to network development, including:

Development resource to improve the network or create new products. For example, if Anza had not developed Alpenglow, it is unlikely that anyone else would have.
Direct grants and payments, including the Foundation’s delegation programme and various hackathons and incubation schemes run by Solana Labs and the Foundation
The Foundation’s promotional and business development activities, which are explicitly aimed at supporting network integrity and increasing token issuance and transaction volumes, leading to higher revenues for validators and RPC nodes.

Such activities amount to public goods for the wider network and it is only natural that people follow the lead of those who provide them.

E. Litigation

It would be surprising if a high-profile player in a sector as new and, at times, controversial as crypto avoided all litigation and Solana and its associated entities have not done so. The network has faced three major lawsuits since launch.

1. In July 2022, the law firm Roche Freedman filed a class action lawsuit against Solana Labs and related parties, alleging that SOL was in fact an unregistered security, and had been sold at inflated prices to retail investors while the overall supply remained concentrated in the hands of a small group of investors. The case suffered a setback when recordings emerged of Kyle Roche, lead partner of Roche Freedman, discussing a secret “Pact” with Ava Labs, developers of Avalanche blockchain, to discredit competitor chains. This led to Roche Freedman being disqualified from the case. The suit continued but was overshadowed by the SEC action outlined below.

2. In June 2023, the SEC started actions against Binance and Coinbase, alleging that SOL qualified as an unregistered security under the Howey Test and that the two defendants were acting improperly by offering it on their exchanges. The case never went to trial and in March 2026 the SEC and CFTC jointly classified SOL as a digital commodity and not a security, taking the issue off the table.

3. In January 2025, a class action lawsuit was launched against Pump.fun, a Solana-based memecoin launch platform, alleging that it was operating pump and dump schemes in unregistered securities. Alongside Pump.fun, the lawsuit also named Solana Labs and Jito Labs, accusing the former of profiting through transaction fees and increased value of Sol; the latter of facilitating Pump.fun’s schemes by use of its “transaction bundling infrastructure”; and both of acting in concert with Pump.fun to disadvantage retail investors. Jito has dismissed the claims, saying it is not responsible for how people use its technology which was developed before Pump.fun even existed. This case was ongoing at the time of publication. Jito’s transaction bundling infrastructure is discussed in more detail in Chapter 5.

Chapter 5: The Solana Ecosystem

This section looks at the players that operate in and on the Solana blockchain. It is divided into three sections. The first part covers the roles required to operate the infrastructure that keeps the blockchain running. The second part addresses the accusation, sometimes levelled at Solana, that its ecosystem is too concentrated and therefore lacks resilience. The final part provides a brief survey of the emerging financial infrastructure that is being built on Solana and that might support the business of financial institutions.

A. Core Infrastructure Roles

a) Validators

Validators can be divided into those that provide delegated staking services to other people, and those that stake their own capital. Of the top 20 validators currently operating on Solana, fourteen offer delegated staking services and the remainder are private.

Delegated staking is generally non-custodial, meaning that the SOL delegated to the validator remains locked in the delegator’s wallet.

Validators offering delegated staking services use a variety of business models. Differentiators include:

Deep Solana specialists vs cross-chain validators. Firms like Jito, Helius or Triton One run Remote Procedure Call (RPC) nodes (see below) as well as validators, making them core players in the message infrastructure of the network. This can help them spread operating costs over a larger revenue base and may enable specific product synergies such as faster access to broadcast data. Other firms, like Figment, offer staking on multiple blockchains, offering diversification benefits that spread risk and may increase returns.
Target client base: Some providers specialise in servicing institutional clients, while others target retail users. Institutional providers may offer enhanced security through audited infrastructure, API integrations and enhanced data services. They may also operate dedicated nodes on behalf of larger clients.
Liquidity provision. So-called “native staking” locks the collateral staked for an entire epoch. Some validators, including Jito, Figment, and Solana Compass, offer liquidity services that mitigate this tie-in. These include liquid staking tokens, which are transferable claims on the value staked and can be used, for example, as collateral in DeFi applications; and auctions where locked stake can be sold for immediate liquidity.
Custodial services. While most staking is non-custodial, custody providers such as centralised exchanges and custodial wallet providers may also offer staking services as a value-add, in the same way that a traditional custodian might offer stock lending to its institutional clients

Private nodes are operated by major holders of SOL, such as DATs, investment funds, proprietary trading firms or individuals trading large holdings as principal (called “whales”, in the jargon). These organisations rarely maintain a public profile.

b) Data Centres

Most validator nodes are hosted in specialist data centres, that offer “bare metal” servers optimised to run validators’ software clients. Major providers in this space include Teraswitch Networks, Latitude-SH, Allnodes, UAB Cherry Servers and OVH SAS.

Two factors have influenced the emergence of these specialists:

The high bandwidth and specialised hardware required to operate a validator node successfully.
The informational advantages that come from physical proximity to other validators. Under both the Turbine and Rotor data dissemination architectures, data is distributed from leaders to a first tier of relay nodes before being broadcast to the wider network. Relay nodes, like leaders, are selected based on stake-weight, and so larger validators will tend to dominate the rosters for both roles. It makes sense for other validators to co-locate their nodes with these players in order to maximise their advantage in terms of receiving broadcasts of block data. These advantages are similar to those sought by high frequency traders when placing servers in the data centres used by the exchanges on which they trade.

c) Validator Software Client Vendors

All validator nodes run software clients that encode the Solana protocol and manage their interactions with the rest of the network. As part of the original implementation of Solana, a client called Agave was developed and this is now maintained by Anza, although it only has residual usage. Since then, four additional clients have been built on top of the Agave code base: Jito-Solana, Frankendancer; Harmonic; and Rakurai. In addition, Firedancer, built by Jump Crypto (which also offers Frankendancer) on a completely new code base launched Dec 2025 and has a small but growing use base.

Historically, the Jito product has led the market, because of its link to Jito’s Block Engine, an important source of revenue for many validators. However, other Clients now also provide access to Block Engine, which is helping to open up the market.

d) Remote Procedure Call (RPC) Nodes

RPC nodes route transactions to leaders and are essential players in the block formation process. They typically work for users that generate high volumes of transactions, such as trading applications, ensuring that their transactions make it into a block in the shortest possible time. While routing transactions, RPC nodes often carry out a preliminary validation of the instructions, filtering out those that are incorrect before they reach the leader and so reducing load on the leaders’ computational resources.

As noted above, there are potential synergies available to organisations that combine the roles of RPC node and Validator node. Leading RPC node providers include Triton One, Helius, Jito and Alchemy.

Specialist RPC Add-ons

Some RPC nodes have developed specialist additional services to help clients manage their transactions on Solana. Among these are Jito’s Block Engine, and Triton One’s Yellowstone Shield service.

i. Block Engine and BAM

There are circumstances where a blockchain user may want to link two or more transactions together, so that they all execute together or none do. Examples include arbitrage trading where the user buys one asset and simultaneously sells another, or liquidation events, where the user attempts to bid for and sell the collateral simultaneously, creating a self-funded trading profit.

The nature of blockchain protocols, which hand leaders discretion to decide which transactions to include in a block and what order to arrange them in makes it difficult for users to manage these situations with certainty and, worse, may create opportunities for a leader to exploit its privileged position to front-run or otherwise capture the value from the user’s trades.

To help manage these situations, Jito developed Block Engine, a tool that enables users to bid for block space for bundles of up to five transactions that they wish to execute as an atomic set. Users submit their transaction bundles to the Block Engine rather than directly to the leader, accompanied by a “tip”- an additional transaction fee for the leader that adds the bundle to its block. The Block Engine runs an optimiser that seeks to find the combination of bundles that generates the highest aggregate tip for the lowest use of the leader’s computational resources. Regular transactions are processed after bundles, in the last period of the slot.

In order to process transaction bundles, a leader must be running a compatible software client. If the current leader does not run one of these clients, the Block Engine holds the bundles until the turn of a leader that does.

As an evolution to this architecture, Jito has recently launched BAM (Block Assembly Marketplace), which utilises Trustless Execution Environments (TEEs) to introduce high fidelity control over blockspace dynamics as blocks are being built. BAM is designed to introduce predictable execution and application controlled logic to the Solana execution environment.

ii. Yellowstone Shield

Yellowstone Shield is an open-source, permissionless service developed by Triton One that lets users create allow-lists or block-lists of accounts, including validators, wallets and programs, to which they want/do not want to send transactions. It works in conjunction with RPC node providers like Triton, Helius or Jito. It could be a vital tool for a Financial Institution concerned about the risk of paying transaction fees to a sanctioned entity that set up a validator node on the network.

iii. Stake pools

Stake Pools act like mutual funds for staking, gathering stake from multiple delegators and distributing it across several different validators for diversification purposes. In return for their stake, delegators receive transferable stake pool tokens, which are similar to liquid staking tokens described above.

B. Is the Solana Ecosystem Over-centralised?

Decentralisation is the raison d’etre of public, permissionless blockchains, underpinning their unique selling points of censorship resistance and operational resilience. Solana has faced accusations of being over-centralised. In this section, we look at whether these accusations are justified, and what that means for the integrity of the network.

Centralisation has several dimensions. As we noted in Chapter 4, for a permissionless network, Solana has a relatively centralised governance structure, which deploys significant resources to influence network development. Although this might challenge decentralisation purists, for an FI it is likely to be an advantage because it facilitates issue resolution and product development, while still giving the community a veto on change.

A second source of concentration could arise from the structure of holdings of SOL. It is true that the Solana Foundation has a very large holding. However, as we also noted in Chapter 4, most of this is delegated to small validators in an effort to reduce validator concentration. Beyond the Solana Foundation, ownership of SOL appears to be well distributed and the big concentrations that characterised the early phase of the network, particularly those of FTX and Alameda Research, have been broken up.

The more important dimension for an FI is likely to be centralisation in the operational ecosystem of the network. Concentration in network operations could create risks to service continuity if there is over-reliance on one provider that fails, or significant clustering of validators in one geographic region that goes offline because of technical failure or a geopolitical event. It could also undermine Solana’s censorship resistance, exposing the network to the risk of an attack in which a malicious validator gains control of a super-minority of stake and stops the network reaching consensus

We look at three key areas where concentration risk could materialise:

The physical data centres in which the node servers are located.
The software clients used by validators to run their nodes.
The validators themselves.

The picture that emerges is of a moderate degree of operational concentration, with a geographical bias to Europe but with no firm dominating the market and plenty of alternatives. The exception to this is in the provision of validator client software, but the dominance of the market by a single provider is reducing and the introduction of Firedancer, creates a more diversified code base.

a) Physical Locations

As noted above, the heavy hardware required to operate a node pushes most validators to use specialist data centres. Solana nodes are distributed across 208 physical data centres, located in 36 countries. Figure 4 shows the distribution of data centres by region. The distribution is tilted towards Europe, with 44% of centres located in the EU and a further 10% in non-EU European countries, principally the UK and Norway. North America is next, with 29%.

From an entity perspective, five firms lead the data centre market, hosting 69% of the total stake. The number one position is occupied by Teraswitch networks, a privately owned US company with 36% share. Lithuanian firm Cherry Servers holds second place with 14%. There is a long tail of smaller firms sharing the final third of the market.

Data Centre Operators Supporting Solana Nodes by Value Staked (SOL)

b) Validator client software

The market for validator clients is shared as follows:

Jito-Solana (Agave fork): ~60–65%
Frankendancer: ~21%
Harmonic: ~13%
Rakurai: ~2%
Firedancer small but growing
Agave: residual

The dominance of Jito-Solana has declined over time. However, the fact that five of the six products are built on the same Agave codebase means that there may be a vulnerability to bugs or exploits that attacked that code. Firedancer has been developed explicitly to address this problem. However, it was only launched into Mainnet production in December 2025, so it is too soon to tell what impact it will have on the structure of the market.

c) Validators

Validator nodes display a geographical distribution similar to that of the data centres that host them, with a strong weighting towards Europe, by both the number of nodes and stake. Of 768 validators active at the time of writing, 61% were located in the EU and a further 7% in the rest of Europe. The geographical distribution of nodes is shown in Figure 6

Geographical Distribution of Solana Validator Nodes February 2026

Figure 7 shows the cumulative distribution of validator stake by number of firms.

Cumulative Stake by Number of Validators February 2026

At the time of writing, the validator controlling the largest proportion of stake was Helius, with 3.46% of the stake committed, followed by Jupiter with 3.17% and Figment with 3.11%. The largest of the private validators is at number 12 in the overall rankings, controlling 1.35% of the total stake.

The super-minority of stake, that is ⅓ of the total value, was controlled by 19 firms which, were they to collude, would have the power to disrupt block formation. This number is known as the Nakamoto coefficient and is a widely used measure of network concentration.

A Nakamoto coefficient of 19 puts Solana in the top third of its blockchain peers, most of whom have a similar or lower value, as shown in Figure 8. The outlier is Polkadot, whose protocol contains explicit incentives to encourage delegators to spread stake across many validators.

Solana’s Nakamoto coefficient of 19 is easily large enough to absorb the corporate failure of any of the leading validators without interrupting the network. Further, the value staked by the 19 firms is significant, at approximately 140 million SOL or USD12bn. This likely makes the opportunity cost of any direct attempt to disrupt the network prohibitive. And for a would-be hacker, 19 firms, many of which operate with institutional-grade security, represent a formidable target for an attack. Finally, Alpenglow’s elimination of transaction fees for voting should make it easier for new entrants to build market share, which may be expected to increase the Nakamoto coefficient in future.

C. Financial Infrastructure

This section looks at financial infrastructure services available on Solana.

Financial infrastructures typically have the following characteristics:

Support financial transactions at various stages of their lifecycle, including: issuance and listing; price and counterparty discovery; trade execution; clearing; funding and payments and custody.
Combine operational services with robust legal frameworks to offer a high degree of certainty to their users. Often treated as the “golden record” for transaction status
Often support the needs of “the market”: that is, the collective needs of a group of counterparties that have multilateral transacting relationships with one another, rather than the individual needs of each client
Strong focus on risk management and governance, if necessary at the expense of value-added services
Operate on a neutral, agency basis, never taking trading positions, even delta-neutral positions, and earning revenue primarily through transparent fees or Net Interest Income on portfolios of high-quality liquid assets, rather than spreads or trading profits
Open access, with published, objective onboarding criteria for clients.

Financial infrastructures are often closely regulated. However, we have not included regulation in our definition, because it is a consequence of the central position infrastructures occupy in the financial system, rather than intrinsic to the infrastructures themselves.

Blockchain Protocols like Solana offer functionality that mirrors that of many traditional infrastructures, and firms in the DeFi ecosystem have incorporated these features into solutions that address the same market requirements. These include things like price transparency, fair execution, counterparty credit risk management, liquidity optimisation, or custody risk. The DeFi versions of infrastructure services may lack the legal or governance frameworks of traditional players but there is nothing in the role of an infrastructure that is inherently incompatible with the use of blockchain.

So might the financial infrastructure of the future emerge from the DeFi landscape or will the TradFi incumbents colonise digital space? We believe both will happen. The size of the prize represented by the traditional financial system is too large for DeFi to ignore, and the innovation of DeFi is too valuable for TradFi not to notice, so the push for convergence will come from both sides, with DeFi firms making the leap to support institutional financial business and TradFi infrastructures attempting to move on-chain.

The dynamics of industry disruption might suggest that the advantage lies with the DeFi challengers. Leveraging innovations like smart contracts and Distributed Autonomous Organisation (DAO) structures, DeFi firms have built businesses that serve clients excluded from the traditional financial system on much lower cost structures and with more open access policies than traditional incumbents.

However, TradFi infrastructure services also have some strong cards to play. These include scale economies and network effects that mean that an infrastructure’s total cost base has only a small effect on the marginal transaction cost paid by users, and strict regulatory regimes that can raise barriers to entry.

Whatever the eventual outcome, there is still a long way to go, as this brief survey will show. We use a conventional financial value chain, as set out in Figure 9, as a framework. Where services exist, we look at them from a functional perspective, although we acknowledge the fact that their legal and regulatory status will ultimately be critical to adoption by institutional users. Where services are missing, we will briefly consider the implications.

a) Asset Issuance

A number of platforms support the tokenisation and distribution of real-world assets and stablecoins on-chain. These platforms provide tools to help structure tokens based on standardised legal frameworks, and directly link to the smart contracts that instantiate the tokens on chain. They may also offer support with onboarding investors and distributing tokens.

Asset issuance services are offered by both digital specialists and established names from TradFi. Examples of digital specialists include Bitbond and Cashlink, both of which support issuance of tokenised bonds and structured products. TradFi names include Calastone, which supports fund managers in tokenising and distributing unitised funds and SGForge, a unit of French Bank Societe Generale, which offers a bond tokenisation service to third-party issuers in addition to supporting structured products and stablecoins issued by its parent.

As yet, there are no global standards on how to structure real-world assets on-chain, and so important details like the legal rights of token holders to underlying assets may differ by token and jurisdiction, potentially creating risks for investors. Developing such standards is an urgent task for those building services to support Real World Assets (“RWAs”) on-chain.

b) Price and counterparty discovery and execution

The trading landscape on Solana looks like a turbocharged version of the landscape that emerged in TradFi in the late ‘90s after centralised exchange monopolies were broken up and there was a proliferation of alternative trading platforms. That change created a need for new services like smart order routing and price aggregation, and was accompanied by innovations in execution, like Dark Pools that attempted to match counterparties without leaking information to the wider market.

The Solana trading landscape is similarly diverse. It includes centralised exchanges like Binance and Kraken, DEX’s and Automated Market Markers like Jupiter or Orca and dark AMMs like Solfi, which hide executions from public view. Exchanges span crypto asset classes. Many offer spot trading in currency pairs and RWAs, and some also offer innovative DeFi products like perpetual futures (“perps”). Finally, DeFi credit marketplaces like Kamino have emerged, based on peer-to-peer lending backed by standardised, automated collateral management systems.

The number of venues reflects the much lower cost of setting up and operating on-chain compared to a traditional exchanges or Multilateral Trading Facility. This is partly because smart contracts enable the creation of fully automated operating models. It is also because regulators are still working to create regimes for on-chain services equivalent to those that exist for off-chain venues.

As in traditional finance, the number of venues makes price formation and execution management unpredictable for traders. Liquidity aggregators and smart order routing services like Jupiter or Titan guide traders through the landscape to find the best prices. Oracles like Pyth Networks aggregate prices across venues to create consolidated tapes.

The existence of multiple venues also creates arbitrage opportunities, and a significant volume of transactions is generated by bots seeking to exploit them. Solana’s parallel processing architecture, combined with localised transaction fees that are linked directly to activity in specific tokens and accounts help to stop this activity from becoming spam that impacts the wider performance of the network. Jito’s Block Exchange Service also helps reduce network traffic by taking competition for arbitrage opportunities off-chain and auctioning block space to those that value it most.

No Tradifi exchange has yet launched a venue on any public blockchain, although many have explored incorporating private chains into their operating model. However, the Chicago Mercantile Exchange has launched a future on SOL that trades on its established off-chain trading platform.

c) Clearing and Counterparty Risk Management

Clearing - that is, services to manage counterparty risk in the period between trade execution and settlement - is unnecessary in DeFi spot markets because trading and settlement happen based on a single instruction. This is efficient from a risk point of view but it is expensive in terms of settlement liquidity, since trades are effectively pre-funded and settled gross. It is possible to imagine that settlement netting services emerge to address the liquidity cost, but in doing so,reintroduce a time lag between trading and settlement, requiring additional risk management solutions.

For transactions with a longer lifecycle, such as peer-to-peer loans or perps, automated clearing services have been developed that take in collateral, make margin calls and maintain their own versions of the default waterfalls employed by traditional central counterparties.

In DeFi, these waterfalls typically have three stages:

Individual defaulting positions are automatically closed out and margin collateral auctioned off. These automated liquidations have created new trading opportunities for bots, which scour the chain looking for positions close to the liquidation threshold in the hope of buying the collateral at a discount if the threshold is crossed.
If these auctions are insufficient, trading venues call on 3rd party facilities they have arranged to cover this risk. These may include insurance funds or liquidity vaults that specialise in funding against distressed assets.
The third tier is known as “auto-delveraging” (ADL) and essentially involves the exchange taking a skim off the most profitable and leveraged positions on the other side of the trade to cover the losses.

All of these techniques came into play during the crypto crash of 10/10/2025, when the imposition of tariffs on Chinese imports to the US led to over $20bn in liquidations of Perp positions in 24 hours across DeFi, including on Solana. The implications of this event have been debated at length. Some have argued that it highlights systemic vulnerabilities in DeFi, with forced liquidations and ADL driving further price falls in a self-reinforcing feedback loop, and no system-wide circuit breakers to stabilise the market. However, there were no exchange defaults and the system as a whole absorbed the losses and kept functioning, which is usually considered a success for financial infrastructures faced with a crash. In any event, post-trade risk management will continue to be an area of keen interest as traditional finance colonises the chain.

d) Liquidity Management

Liquidity mismatches, where financial resources are locked into long term assets and unavailable to settle immediate obligations, are a central problem in finance and one of the major sources of systemic risk. Conversely, holding or accessing liquid assets for settlements can be expensive for financial businesses, who therefore have an incentive to minimise the amount they hold. This tension between minimising risk and minimising cost sits at the heart of the financial system and is one of the main objects of prudential regulation.

As a result, specialist services have been developed that aim to reduce the amount of liquidity required by banks and other FIs to settle their obligations, without introducing new risks. Among the most prominent is CLS, which provides multilateral netting for inter-bank FX transactions and reduces the liquidity required to settle them by between 96% and 99%. Central Bank wholesale payment systems often incorporate “liquidity saving mechanisms” in their processing models, as do the settlement systems operated by Central Securities Depositories. CSDs may also offer services such as auto-collateralisation, which uses securities received by a purchaser directly as collateral with the Central Bank to generate liquidity for the settlement. Finally, there are innovative fintech solutions such as the intra-day liquidity exchange built by Finteum.

There are, as yet, no equivalents of these types of service available on public blockchain. Instead, solutions have focused on mechanisms to trade less liquid assets for more liquid assets. Liquid staking tokens are one example of this, converting a term asset into a transferable instrument. Another is Marinade’s “Instant Unstake” service, which lets delegators sell stakes they have locked with validators to buyers who pay in SOL in unencumbered SOL. It is conceivable that, in future, liquidity saving mechanisms could be built into block formation processes themselves.

e) Settlement

While blockchains like Solana are effective at operational settlement, this may not be enough to enforce legal transfer of title. The law concerning title transfer differs substantially by jurisdiction and asset class. In some places, including the US, it is based largely on private contract law, even for the largest publicly traded securities. Other jurisdictions have enacted specific statutes, such as the European Settlement Finality Directive, which limits the power of courts to unwind transactions settled in a designated Settlement System in the event of the bankruptcy of one of the settlement counterparties.

Laws also mandate regulatory approval for organisations providing settlement services in certain asset classes. For example, in the EU, exchange-listed securities must be settled by a Central Securities Depository designated under the CSD Regulation (CSDR).

Obtaining a license to operate a settlement infrastructure is often onerous, with strict requirements around governance, risk and operational resilience. There may also be specific requirements that are difficult to fulfil in practice, such as those in the CSDR governing the nature of the cash assets to be used in the payment legs of DVP transactions.

Officially designated settlement infrastructures have yet to appear on blockchain. This absence may have important ramifications for the adoption of blockchain-based infrastructures for institutional applications. For example, banks could be unwilling to accept collateral if there is a risk that the transfer could be unwound by a court on the bankruptcy of their counterparty, which is precisely when they would need it. It may also limit adoption of stablecoins for wholesale payments on-chain.

However, a number of initiatives are underway to bring on-chain settlement within the remit of regulatory structures. Most prominent is that of the DTCC, which has received a no-action letter from the SEC allowing it to tokenise assets issued into its custody. The European Central Bank has also launched an initiative to examine how it should open Target 2, its central bank money payment system, to on-chain settlement activity.

Other companies are building regulated, off-chain systems to settle digital assets held with custodians. These include Montis Digital, a subsidiary of UK-based regulated digital exchange Archax, which is seeking a license under CSDR to facilitate settlement of digital assets traded on Archax exchange; and Cleartoken, which has launched a DVP net settlement service for financial institutions trading in stablecoins, cryptocurrencies and fiat currencies.

f) Custody

Digital asset custody is amongst the most mature services for FIs available on blockchain. Institutional participants have strict requirements for any custody solution, including asset segregation, protection from supplier insolvency, and high standards for operational risk management. Increasingly, these requirements are being baked into regulatory regimes in major jurisdictions, including the US, EU and UK.

There is a spectrum of digital custody options available on Solana, ranging from non-custodial wallets like Solflare, through specialist crypto custodians, to traditional global custodians. The demands of institutional participation are driving the evolution of this landscape, with partnerships forming between crypto and traditional custodians. For example, State Street Bank has entered a partnership with Taurus and BNY has invested in Fireblocks. Such partnerships are likely to continue because the relationships of the traditional custodians with an institutional client base, backed up by expertise in risk management, complement the technology and product focus of the crypto specialists.

Chapter 6: Fitting Solana to Financial Regulation

Financial regulation is unlikely to apply directly to Layer 1 blockchains like Solana. However, in targeting institutional business, Solana will become increasingly exposed to firms that are regulated and these firms will need to demonstrate to their regulators that their use of Solana is consistent with regulatory requirements.

The Official Monetary and Financial Institutions Forum (OMFIF), a London-based think tank, has recently published a report that contained a breakdown of the areas that should concern regulators when evaluating businesses that use public blockchain. This breakdown provides a useful framework for evaluating the strengths and weaknesses of Solana as a venue for regulated business activities. Table 7 sets out our analysis of how Solana stacks up.

Analysis of Solana as a Business Venue for Regulated Financial Services, Using the OMFIF Framework

Analysis of Solana as a Business Venue for Regulated Financial Services, Using the OMFIF Framework cont.

Chapter 7: Products

This section looks at real world assets launched on Solana. It divides RWAs into two categories: stablecoins and other assets such as fund units and tokenised securities. It also takes an outside-in view by looking at ETFs on SOL.

a) Stablecoins

Real world assets on Solana are dominated by stablecoins, which have a market capitalisation of approximately USD15bn.

Table 8 shows the leading coins and their issuers, as at the time of writing.

Top 10 Stablecoins on Solana by Market Cap as of 24/2/2026

It is clear that the stablecoin market is highly concentrated with the top three issuers, Circle, Tether and Paxos responsible for 88% of the total market capitalization.

The term "stablecoin" covers a diverse set of products. One point of differentiation is yield. The top three coins are all non-yield bearing. USDG is yield bearing, but the interest is paid to network partners, rather than retail holders. PYUSD also pays yield, but only to holders using Paypal or Venmo wallets. A second differentiator is the pegging mechanism. The majority of the coins are backed by reserves of cash and High-Quality Liquid Assets. However, USX is a synthetic stablecoin that takes USDT and USDC as collateral and generates yield by deploying collateral assets in delta-neutral trading strategies. Similarly, JupUSD takes USDtb as collateral, a stablecoin issued by Ethena that invests its reserves in Blackrock’s BUIDL token.

The list also illustrates the evolution of stablecoins as settlement assets. Their origins in DeFi are exemplified by coins such as USDC and USDC. However, increasingly stablecoins are being integrated into mainstream payment flows.

Paypal, Stripe and Visa all use stablecoins on Solana, either for consumer-to-merchant payments or to settle balances between acquirer and issuer banks. Also interesting from an institutional perspective, although not yet in the top ten list, is Coinvertible, a pair of Stablecoins in USD and EUR issued by Societe Generale, the French Bank.

Issuance of RWA’s other than stablecoins is fast growing but remains in its infancy. As of April 2026, the total value issued has just surpassed $2bn. The largest issue is the BlackRock USD Institutional Digital Liquidity Fund (BUIDL), a money market fund open to approved institutional investors.

Second on the list is YLDS. YLDS describes itself as a stablecoin, but it is registered with the SEC-as a Public Security under the Securities Act 1933, and is yield bearing, making it look very much like a tokenised money market fund and illustrating that the classification of these assets is somewhat arbitrary. Other interesting RWAs on the list include PRIME, a vehicle to fund HELOCs, which are credit facilities offered to homeowners and secured on the equity in their property; the ONRe Tokenised reinsurance fund, and X-stocks’ tokenised version of Tesla equity.

Top 10 RWAs by Market Cap, excluding Stablecoins

Outside the top ten list, some big names from TradFi have dipped a toe into Solana’s the tokenised RWA pool. These include Hamilton Lane, which has launched a private credit token called Scope, and Citi’s Proof of Concept to tokenise Bills of Exchange.

While the RWA base is still small, there is a significant pipeline of issuance expected in 2026 that could see it grow rapidly. Highlights include:

SWEEP, a liquidity fund issued by State Street and Galaxy
Expansion of Franklin Templeton’s FOBXX US Treasuries Fund
Tokenised Equity Offerings from Superstate and Ondo Finance
Apollo Finance’s Diversified Private Credit Fund
Direct Lending Pipelines to real-world borrowers from Kamino and Maple Finance
Real Estate Tokenisation Projects such as Metawealth

b) ETFs

ETFs that track SOL are an emerging asset class. There are currently 9 ETFs that are live, managing just over USD 1bn between them. A further eight are pending approval.

Of the live ETFs, the largest is the Bitwise Solana Staking ETF, which, as the name suggests, stakes the SOL it holds and pays out the resulting yield as well as spot returns. Seven of the nine live funds are priced based on the spot price of SOL, with two priced based on the future. Among pending funds, five are futures-based, and three spot based.

Issuers include both crypto specialists like Bitwise and Greyscale, and TradFi names including Fidelity, Franklin Templeton and Morgan Stanley.

Acknowledgements:

Many thanks to everyone who waded through drafts of this document and provided insights, corrections and improvements to content, language and punctuation: Richard Brown, David Liang, Steve Whyman, Caroline Scott, Angus Tookey and the Product Team at the Solana Foundation. Any errors that remain are my own.

About the Solana Research Institute

The Solana Research Institute (SRI) is an applied research forum dedicated to rigorous, independent analysis of blockchain-based financial infrastructure and its implications for the wider financial system. Through research, structured discussion, and working groups, we convene practitioners from traditional finance and the digital asset ecosystem to examine the technical, legal, and structural questions that will determine how the transition to digital finance unfolds. Our work centres on Solana as a high-performance public blockchain with serious institutional potential, but does not lose sight of the bigger picture.

www.solresearch.institute

Additional References

https://blockworks.com/

https://www.anza.xyz/alpenglow-1-1

https://blockworks.com/analytics/solana/solana-supply-staking-and-validators/solana-validator-operator-revenue

https://www.acquired.fm/episodes/solana-with-ceoTable-anatoly-yakovenko

https://www.binance.com/en/square/post/293274504336561

https://www.coincarp.com/currencies/solana/richlist/

https://payments.org/solutions/sdp

"The Innovator’s Dilemma”, Clayton Christenson, 1997

Driving Public Blockchain Integration in Banking. OMFIF 2025 - https://www.omfif.org/driving-public-blockchain-integration-in-banking/

Founding Members

Thanks to the Founding Members of the Solana Research Institute who made this possible:

A Financial Institution's Guide to Solana

Introduction

Preface: Blockchain, Solana and Financial Institutions

Why blockchain and why now?

Solana in a Nutshell

What Makes Solana Well Suited for Institutional Finance?

1. Very high capacity

2. Speed to finality

3. Very low transaction cost

4. Native, composable functionality

5. Inbuilt compliance features

6. A genuine settlement system

Chapter 1: Solana by Numbers

Chapter 2: Overview of Solana Operations

A. Core System Protocol: Designed for Speed

a) Overview of the Protocol

b) Minimising Time to Finality

i. Shared time

ii. Accounts and Transactions

iii. Data dissemination

iv. Voting

v. Overall impact of Alpenglow

B. Solana Token Model - Stateless Programs and Standard Functions

a) Tokens and Accounts

b) Programs

i. Overview of Solana Programs

ii. Using Composable Programs to Build Financial Applications

C. Privacy and Permission

a) Confidential Balances

b) Permissioned Environments

c) Corda

D. Network Stability

a) Outage by Design

b) Bugs and their Fixes

c) Recovery Procedure

Further Reading

Chapter 3: Network Economics

A. Design of SOL

B. Regulatory Status of SOL

C. Price Performance of SOL

More than just a speculative asset

D. Costs of Node Operations

E. Infrastructure Revenues and User Fees

Further Reading

Chapter 4: History, Funding and Governance of Solana

A. Origins and History of Solana

B. Funding and Ownership of Sol

C. Corporate Structure

D. Operational and Product Governance

E. Litigation

Further Reading

Chapter 5: The Solana Ecosystem

A. Core Infrastructure Roles

a) Validators

b) Data Centres

c) Validator Software Client Vendors

d) Remote Procedure Call (RPC) Nodes

i. Block Engine and BAM

ii. Yellowstone Shield

iii. Stake pools

B. Is the Solana Ecosystem Over-centralised?

a) Physical Locations

b) Validator client software

c) Validators

C. Financial Infrastructure

a) Asset Issuance

b) Price and counterparty discovery and execution

c) Clearing and Counterparty Risk Management

d) Liquidity Management

e) Settlement

f) Custody

Further Reading

Chapter 6: Fitting Solana to Financial Regulation

Further Reading

Chapter 7: Products

a) Stablecoins

b) ETFs

Further Reading

Acknowledgements:

About the Solana Research Institute