Your day-to-day work spans four key areas:
High-throughput optimisation
Every block, we process tens of thousands of transactions, each simulated hundreds to thousands of times through the VM when running different sorting algorithms trying to find the optimal transaction ordering in an NP-hard problem. Alongside the other blockchain problems like computing the full state merkle trie for each block. At this scale, saving even a single microsecond in frequently called code compounds across millions of calls.
Low-latency systems
Parts of our stack run end-to-end in low microseconds. Alongside the large sorting algorithms we have parts of our system that we keep ultra simple and low-latency. For example, when a bid update comes in from a relay, we need to calculate a bid response and forward it to the relay before competitors do. This is the kind of work where finding big improvements is hard and requires smaller, specific optimisations.
Competitive dynamicsBlock building is an adversarial game. We compete against other builders every slot, watching how they sort transactions, how they adjust bids, what patterns emerge in their behaviour. A lot of the work here requires spending significant time analysing patterns, finding insights, and turning them into engineering or strategic changes that directly affect P&L.
Innovation
The block building landscape is constantly evolving. Sorting algorithms and types of orderflow are changing. New ways for traders to access blockspace keep emerging. Protocol changes reshape the competitive surface. For example, for the Ethereum builder ePBS ships in the next hardfork, moving bid submission from direct connections to relays to (at least for a subset of blocks) the Ethereum p2p layer. Optimising here is an entirely different problem to optimising a direct TCP connection to a relay. This isn't a mature domain where you're only optimising at the margins. There's genuine room to define how things work, both within Gattaca and across the ecosystem.
You'd own systems end-to-end, from design through deployment through iteration. The code you write can be shipped to one of our builders within the hour and will directly affect market share and P&L.
How we work
We believe the best work comes from small, focused teams with full ownership over their domain. Deciding what to build and how to build it.
We keep hierarchy as minimal as possible. Engineers own problems, not tasks. You'll have significant autonomy from day one. After a few months you'll be driving the full loop: ideation → building → deploying → monitoring → iterating.We keep teams small. We'd rather hire a few exceptional engineers with high ownership and agency than a larger team of good ones.