What Sphere and Anza are Building

As of today, the realms of traditional banking and blockchain technology are divided by decades of cultural differences, legacy institutional tech debt, and regulatory hurdles. While blockchain technology has proceeded to innovate at light-speed, traditional institutions have been cautious in adoption. Sphere and Anza are collaborating to bridge these worlds by developing a next-generation payments protocol which offers the speed and decentralization of the Solana network, while maintaining compatibility with the existing global financial regulatory system through rigorous native compliance, risk management, mechanism design, and privacy.

The end objective is a world where traditional regulated financial activity is able to operate at the speed of Solana, while easing the transition of institutions and governments to embrace distributed system rails: Spherenet. Read on to learn interesting technical and architectural details of how Spherenet will be designed using Anza and Solana core technologies.

The State of Cross-border Payments

Before understanding the architecture of Spherenet, it will be helpful to gain a quick understanding of the current state of cross-border payments.

Established in 1944 with the introduction of international institutions (Bretton Woods) and, in 1973, a common financial messaging standard (SWIFT), the cross-border payments market is estimated to represent more than $190 trillion in value as of 2023. This system is based on a permissioned network of ~10,000 correspondent banks that communicate with each other via the SWIFT messaging protocol to settle international transactions. However, despite recent advancements such as SWIFT GPI and ISO20022, the system has inherited many entrenched manual processes and dependencies on legacy technology systems like COBOL (a programming language from the 1950s which is estimated to comprise 40% of global banking systems). This system has experienced several notable failures to date.

In order to send an international payment, it is typical to mix a set of obscure manual and automated processes, which include regulatory compliance checks, wire room operation, and interaction with SWIFT. This leaves significant room for error and lost transactions. Moreover, SWIFT access is limited to a minority (20-40%) of chartered banks, with the least support in emerging markets that often need international access the most. Spherenet, once complete, will help streamline international payments by leveraging techniques in modern distributed systems and cryptography to help financial technology companies and institutions. Through a dedicated shared account-to-account ledger, Spherenet helps regulated entities from around the world source, verify, and settle with each other in a locally compliant, trust-minimized, and privacy-preserving environment to help businesses scale more efficiently around the world.

The Architecture of Spherenet

The following is a summary of the technologies and key enabling innovations of Spherenet:

• A permissioned and closed-loop modified Solana Virtual Machine (“SVM”, “Sealevel”).

• A set of enshrined programs and consensus-level changes for compliant privacy by default. These leverage technologies such as zero-knowledge proofs of identity, hardware acceleration, and multi-party computation over extractable commitments of compliance.

• A programmatic governance mechanism to maintain a registry of elected validators to enable a geographically distributed, but permissioned, network of nodes.

• Dedicated account level metadata to classify entity types by jurisdiction, and automatically enable logic for local payment methods and regulatory compliance.

• A bridging mechanism involving fulfillment auctions on internal/external smart contracts for stablecoin funding, as well as a prover system for attestations of fiat funding.

• Native sanction screening for both internal and external transactions, automated suspicious/unusual activity reporting, and rigorous KYC/AML processes.

We will visit each of these areas after a brief introduction to the SWIFT messaging system, to help illuminate the underlying structural hurdles that Spherenet is aiming to solve.

The SWIFT Messaging System

The primary objective of building a permissioned version of the SVM is to offer regulated financial technology companies and institutions a closed-loop and natively compliant distributed ledger that is backwards compatible in composing with existing financial rails. By leveraging an append-only and cryptographically verifiable database, licensed entities that must manage risk can benefit from a significantly more efficient, transparent, and auditable alternative to a web of private ledger that each plug into SWIFT upstream to process international transactions.

MT103 is a type of standardized SWIFT payment message used for cross-border transactions. Recently upgraded to the ISO20022 standard, the MT103 is one of 10 SWIFT message categories, with each having up to 60 message types. With over 200 supported countries and thousands of potential recipient banks, fragmentation between bespoke peer-to-peer banking ledgers can introduce weeks to months of latency and expensive fees. 

While the data fields in an MT103 are sensible, the software form-factor is not. When a SWIFT based cross-border payment goes out, virtually no one in the world knows where exactly the funds are, aside from the current processing institution. With many default fields left blank and different compliance standards across countries in various time zones, even the upgraded ISO20022 message can result in significant delays and fees from manual intervention.

Obviously, blockchain technology is a useful basis for a solution. Of the various blockchains available, the high performance and low cost of Solana make it a superior choice for carrying large volumes of international payments while also granting flexibility for adhering to international compliance requirements and sensible risk management.

This paves the way forward for decentralized payments that are compatible with existing international legal and compliance standards, starting with fintechs & non-bank institutions.

Permissionless vs. Permissioned Networks

Generally speaking, blockchain networks are valued above all for the quality of being “decentralized” which means they are free from being tampered or interfered with by malicious actors seeking to disrupt the flow of payments or impede the use of the network. 

However, for regulated entities that must abide by anti-money laundering and counter-terrorism financing laws, permissioned networks that are still sufficiently decentralized offer a promising balance between staying compliant and inheriting useful technology properties. This is a hard requirement for any financial institution attempting to operate in the territory of most nations.

From trust-minimization and the coordination of potentially adversarial agents, to maintaining proper risk controls such as counterparty due-diligence and auditable reporting, permissioned networks that are sufficiently decentralized enable regulated entities to safely utilize blockchain technology while rigorously abiding by local and international regulatory requirements.

Critically, a permissioned environment de-risks regulated participation. Whereas permissionless environments may introduce additional operational overhead or risk vectors in ensuring regulated entities are solely interacting with identified counterparties, with examples such as receiving compromised funds or paying fees to a sanctioned block builder, permissioned environments are an ideal closed-loop in reducing risk and hence facilitating adoption.

Where Spherenet Diverges From Solana

Here are a few of the ways in which Spherenet will diverge from Solana mainnet.

Like Solana, there will be a leader schedule per epoch where a given system node is appending entries to the ledger and the next tick to the SHA-256 chain. Spherenet also inherits Delegated Proof of Stake (DPoS), Turbine, PlumTree gossip, and so on.

A key difference between Solana and Spherenet is that Spherenet will enforce a metadata standard per account to conveniently classify entity types by jurisdiction, and therefore seamlessly give participants an automatic way to meet bespoke regulatory requirements

Another primary difference is that the validator set will be permissioned, with a constrained quorum. Initially, the nodes will be managed by the Sphere Foundation, with external partners joining the permissioned set as the network matures through a federated governance model.

Spherenet will utilize multiple pubkey registries, from approved validator nodes to market makers, and build enshrined programs that will generally require the signature of a validator supermajority to take effect – such as the escalation of a valid law enforcement order. There will be corresponding modifications to programs such as the VoteProgram to reference these registries, so only approved pubkeys are able to initialize vote accounts and act in consensus.

Another key departure from the original Solana design is that Spherenet will modify the SDK and runtime to make regulated entity participation more convenient. This includes primitives such as enshrined gasless relayers, so that regulated entities don’t need to hold volatile assets in order to be able to pay fees and use the network. Similarly, innovations such as provers for certificate signatures and governance delegation enable regulated entities to comply with requirements such as geographic compute restrictions and limited liability in network decisions that are difficult to implement in fully permissionless settings. 

Last, Spherenet leverages some unique mechanism design schemes to dynamically adjust network economics as activity increases/decreases to ensure predictability in fees, taxation, and auditable reporting. We will explore these further in a future blog post!  

Closing Thoughts

Spherenet is an ambitious and technologically driven approach to bridging the gap between legacy cross-border payments infrastructure and modern advancements in distributed systems, cryptography, and hardware. This article only touches on the basic elements of how Spherenet, once complete, will be architected. To learn more, we recommend following Sphere on X (@sphere_labs) as well as Anza (@anza_xyz) to keep up to date about future developments.