How We Evolved Robinhood’s Derivatives Platform for a New Market in Under Three Weeks

The best trading infrastructure isn't just performant; it's also built to be extensible and adaptable. We carefully design our tech stack to be flexible, allowing us to support new assets and regulations as we grow without needing expensive updates or risking stability. Let’s talk about a recent example.

To set the scene, it was a handful of weeks before the 2024 Presidential Election and our team had just been tasked with building a brand new prediction market product into Robinhood. It was an asset class with zero support inside our systems and it needed to be generally available to our customers in a matter of weeks. Our team, never one to turn down a good challenge and allergic to failure, responded with “sure, no problem.”

That commitment was tested right away when we needed to adapt our core derivatives trading service, named Ceres after the Roman agricultural deity, to support event contracts. In less than three weeks, we were going to launch support for a fundamentally different product, requiring a new subaccount type, new symbology, accounting logic, settlement flows, and risk controls. Instead of a costly new system build, we were able to use our flexible architecture and extend the system we already had to support this.

In this post, we'll walk through the design decisions that made that possible, how we evolved our derivatives infrastructure under significant time pressure, and what we learned to keep this system flexible to upcoming changes.

Ceres plays the role of a “front-office” service powering Robinhood Derivatives (RHD). It handles account management, onboarding, order processing, holdings management, settlement, ledger adjustments, and the various layers of risk controls required to support derivatives trading in production. This was also the most recent incarnation of a front-office system at Robinhood, with previous iterations supporting trading of other asset classes such as equities, options, and cryptocurrency.

Originally, Ceres was designed around the operational and regulatory requirements of futures outright trading. From its inception, the system was modular and built on top of technologies such as Golang, PostgreSQL, Kafka, and Kubernetes - all running on top of AWS infrastructure such as Graviton, RDS Aurora, S3, etc. Separate modular components inside Ceres form subsystems that handle public and private API traffic, order management, ledgering, and many administrative functions. Rebuilding or duplicating major subsystems for a new product category would have introduced substantial risk under an already aggressive timeline. The only realistic path forward was extending Ceres carefully enough that the new event contract workflows could coexist with the futures platform already running in production.

Event contracts introduced a very different operational model from futures trading. Under CFTC rules, the specific event contracts we wanted to offer were classified as cleared swaps rather than futures. That distinction affected much more than account labeling. It introduced different account ledgering behavior which required an isolated subaccount, different clearing relationships to designated contract markets (DCM) and derivatives clearing organizations (DCO), and overall different regulatory handling requirements across the platform.

The differences showed up on day one in the implementation details. Our existing pre-trade validations were built around futures trading conventions which entailed SPAN margin risk calculations since futures are leveraged products. Event contracts introduced probability-style pricing on a (0, 1) scale while futures used concepts such as performance bonds and contract multipliers. We also had to support entirely new settlement lifecycles and schedules. Futures have their unrealized profit and loss incorporated into buying power in real-time whereas event contracts settle on contract-specific schedules, sometimes months after the trade is made. This is due to the diverse nature of real-world events. Supporting event contracts added operational complexity as well: integrating with each additional clearing venue, carried its own unique programmatic interfaces for order entry, market data, symbology distribution, reporting, and more. We added multiple clearing venues as part of this project! 

Ceres was designed with a single futures-focused account model. To support event contracts, we introduced a new swaps subaccount type alongside the existing futures account. This distinction mattered because it allowed us to have a data model where each asset type would be isolated from each other, in particular when it came time to incorporate the asset-specific accounting logic. Futures activity would be under the futures subaccount hierarchy in the database and event contract activity would likewise be organized under the swaps subaccount. Our approach allowed for independent cash balances, contract holdings, and accounting rules. This isolation was also a critical safety feature because we were reducing the risk of mixups between futures logic and event contract logic.

The pre-trade risk check system turned out to be one of the stronger parts of the existing architecture. By the time we started work on event contracts, the pre-trade validation pipeline already consisted of dozens of independent validation functions covering concerns like buying power, margin requirements, instrument restrictions, and position limits.

Because those validations were isolated and composable, we did not need to redesign the pipeline itself. We only needed to introduce additional validation behavior specific to event contracts and route orders to the proper set of checks depending on the asset type on the order.

That included checks around tick size behavior, probability-scale pricing, and binary outcome logic. We rolled those validations out behind feature flags so behavior could be introduced incrementally while production systems remained stable.

The underlying structure of the pipeline stayed the same. That ended up saving a significant amount of implementation time during a very tight launch window.

One of the more important architectural decisions we validated during this project was the design of the append-only ledger. The ledger was intentionally built to avoid product-specific behavior. Its responsibility is not to understand futures contracts or event contracts directly but rather to record immutable financial adjustments consistently.

That abstraction held up much better than we expected under the new settlement model. Event contract settlements flowed through the same downstream accounting systems already trusted for futures trading without requiring separate ledger infrastructure or parallel accounting paths. From the ledger’s perspective, an execution remained just another immutable adjustment record.

That simplicity mattered a lot under tight deadlines. We were able to introduce a fundamentally different settlement lifecycle without introducing duplicated accounting logic throughout the platform.

Settlement processing introduced some of the largest operational differences in the system. Before event contracts, Ceres primarily operated around a single daily settlement workflow for all the futures contracts pre-scheduled to expire that day. Supporting event contracts meant supporting settlements which could happen anytime as determined by the exchange venue offering the contract which in turn were dependent on event outcomes in the world. Additional clearing exchanges meant integrating entirely new ingestion formats and operational processes while still preserving consistency downstream.

Instead of scattering venue-specific logic throughout the system, we introduced independent settlement processors for each venue. Each processor handled its own ingestion and normalization logic before feeding standardized outputs into the shared downstream accounting pipeline.

That separation kept the complexity localized. The settlement layer became responsible for understanding venue-specific operational differences, while the rest of the platform continued operating against a consistent internal accounting model.

Under the timeline we were working against, isolating complexity like that became extremely important. It reduced the number of systems that needed to change simultaneously and made rollout behavior much easier to reason about operationally.

By the end of the project, we had evolved Ceres from a futures-focused platform into a more generalized derivatives infrastructure layer.

The account hierarchy now supports both futures and swaps accounts within the same structure. The pre-trade risk checks absorbed new event contract logic without changing its overall architecture. The append-only ledger continued operating as a product-agnostic accounting layer, and settlement processing expanded to support multiple clearing venues feeding into the same downstream cash adjustment systems.

The launch itself introduced a new regulated product line, multiple new clearing relationships, additional settlement processors, and new validation logic. In the end, this occurred all within 16 days of engineering effort and without disrupting the existing futures platform.

While the immediate goal was supporting event contracts, the longer-term value came from validating how the system could evolve as Robinhood expands into new markets and products.

The settlement architecture now scales much more cleanly across venues because venue-specific behavior stays isolated inside dedicated processors rather than leaking into accounting and risk systems. Adding support for a new venue is largely operational and integration work instead of a redesign of the broader platform.

The same principles apply at the infrastructure level. Ceres operates as a sharded system similar to our other front-office systems powering equities, options, and cryptocurrency trading. Each shard functions as an independent functional unit allowing us to easily add new deployments to new regions for futures trading, such as the United Kingdom, or more shards to pre-existing regions for extra capacity.

We saw the same flexibility when integrating with new venues such as Rothera, our new prediction markets exchange managed through a joint venture with Susquehanna. Because the architecture was built around composable abstractions rather than tightly coupled product logic, additional execution venues could be integrated much more easily.

• Extensible systems reduce the cost of entering new markets.

• Instrument-agnostic infrastructure creates long-term leverage.

• Composable validation and settlement pipelines make incremental evolution possible.

• Additive architectural changes are often safer and faster than structural rewrites.

• Building modular systems upfront enables teams to move quickly under real-world deadlines.

Building a brand-new product and business line under such a compressed timeline required above and beyond collaboration from many teams within Robinhood. Engineering teams from trading platforms (reference data, market data, order entry), frontend teams, infrastructure, data science, brokerage, and many more provided support at all hours of the day to ship this product. Product, design, finance, legal, communications, compliance, risk teams made this their top priority to ensure it was a safe launch. Basically every department at Robinhood came together for this launch!

Edmond Wong is a Senior Staff Software Engineer at Robinhood Derivatives, where he works on trading system infrastructure to support scalable, resilient product expansion.

Interested in learning more about building at Robinhood? Check out the careers page: careers.robinhood.com