How Gemini’s Hyperdrive Wallet Helps Us Build on Blockchain Infrastructure

In recent years, new blockchains have emerged at a rapid pace, each offering their own set of features and tokens. It is the responsibility of a crypto exchange to ensure users can easily deposit, withdraw, and stake various assets all in one secure place. By continuously adding support for more blockchains, we are able to provide customers with straightforward access to the latest networks without compromising on safety or reliability.

Here, we detail how Gemini has created secure wallets and systems while remaining flexible so we can quickly deliver the value of the multichain, multi-asset world to our customers.

In January 2023, we developed and launched our latest wallet architecture, Hyperdrive, with the release of Cosmos network support. Since then, we have launched on every blockchain network using this platform, including XRPL, Optimism, Ethereum Consensus chain. Now, we are in the process of migrating every blockchain network we support to this platform.

Before Hyperdrive, our approach to building wallets made it difficult to quickly add new blockchains. We maintained separate codebases for each network, which often duplicated similar logic. Over time, we realized that even networks as different as Bitcoin (UTXO) and Ethereum (account-based) share enough core principles to unify our code. By consolidating these shared elements, we’ve significantly reduced onboarding, often shortening integration time from months to weeks. For example, our recent XRP Ledger integration was completed in approximately two weeks, showcasing a significant improvement compared to our previous timelines.

Hyperdrive allows us to operate at speed by simplifying core components of our wallet architecture, which allow us to enable basic transactions like native and token transfers, and other natively supported operations such as complex contract calls or onchain transactions.

Speedy

Hyperdrive groups four main services—chain monitor, broadcast issuer, chain consumer, and network sidecar—into a single “cohort.” The first three share a common codebase, while the network sidecar handles network-specific details. Because the sidecar is stateless, adding a new blockchain only requires updating this one service, making integrations much faster.

The chain monitor reads every block and transaction from the blockchain. The service fully handles re-orgs, finds convergence on forked chains, and writes the blockchain state to the database. Given that each network has specific serialization formats that it supports, we push network specific constructs to the network sidecar which handles these concerns. This is important as it allows our core services to remain as universal/abstract code and re-usable for every single network we add. This means we no longer need to write additional code in universal services for every new network!

The broadcast issuer is responsible for reading state from the database and submitting transactions to the blockchain network via our node infrastructure. This is where all Exchange, Custody, and other product transactions are submitted from. We have a set of universal pre-checks that are validated for every network. One example of this is ensuring that the blockchain network itself is healthy, which in our case is the state of our node infrastructure. Network specific checks, like Ethereum Virtual Machine simulations, are delegated to the network sidecar.

These simulations allow us to perform test transactions without actually sending them to the blockchain. This service then constructs the transaction and acquires the signature from our secure signing infrastructure. Ultimately, if all of our generic, network specific, and security guardrails are successful, we submit the transaction to the blockchain.

The chain consumer is responsible for consuming events from the database and emitting them to a pub/sub queue for downstream product use cases. In case of the exchange, deposits would be credited to the associated account after the subscriber processes the corresponding chain transaction event emitted to the pub/sub queue. This allows us to build many products on top of this single architecture, including enhancements to our custody processes.

The network sidecar is dedicated to handling all network specific logic. For example, it manages how transactions are encoded at the bytes level for blockchains and how they are decoded for the rest of the cohort. A critical feature of this service is that it remains stateless, meaning it does not retain any transaction or session data. This statelessness is essential as it allows the network sidecar to be easily horizontally scaled, ensures consistency across network integrations, and simplifies updates, making the overall system more resilient and flexible.

Secure

The security of customer funds is priority number one at Gemini. As part of the Hyperdrive architecture, we decouple private key management and transaction signing from other application logic. This separation enables robust security guardrails at transaction signers and ensures that applications requesting public keys or signatures comply with the established security model. Furthermore, message attestations take place for any messages received through the database or the pub/sub queue, which allows us to ensure the integrity of the message by verifying that it came from trusted boundaries rather than an external, uncontrolled source.

For example, we have a guardrail at our signer for value-based rate limiting which allows normal customer withdrawals to be processed but not “abnormal” ones:

The signer in this diagram exists outside of the Hyperdrive architecture and validates transactions in a zero trust environment. This ensures that transactions constructed are always validated before they are signed for.

We welcome contributions from security researchers to help us build and secure the future of money. To submit a security vulnerability to Gemini, or to learn more about our coordinated disclosure program, please visit our security.txt file for details.

Dynamic

Previously, the Gemini exchange was built using a monolithic architecture with products and wallets tightly coupled together. This resulted in a significant burden when extending the existing functionality, building new features, and scaling engineering teams.

With the introduction of the Hyperdrive architecture, the Exchange, Custody, and Staking systems are now built individually on top of Hyperdrive's low level APIs. This enables Gemini to build new products, vertically scale engineering teams, and address customers' needs more quickly and easily.

Reliable

Gemini’s new back-end applications have been designed with high levels of availability and resiliency as a core objective, allowing continuous processing of cryptocurrency deposits and withdrawals even with partial system outages.

We chose to build the cohort in a mixed state of service oriented architecture (SOA) and microservice architecture depending on our needs and the use case of each application. Each blockchain network gets its own cohort infrastructure, which means every blockchain has its own database, chain monitor, broadcast issuer, chain consumer, and network sidecars.

Given every network has its own infrastructure, we isolate failures, load concerns, and code change cycles locally to that set of services. For example, if the Ethereum cohort faces performance issues on the database, only that network will be impacted. We can then independently scale up that database instead of needing to scale up the whole fleet. This localizes cost, performance, and other factors of running a distributed system to that specific cohort.

The patent details for this design is filed under: US-12182801-B1

At Gemini, we’re on a mission to unlock the next era of financial, creative, and personal freedom. If you are interested in joining us, please visit our Careers page!

Onward and Upward,
Gemini