Software​/Systems Architect

About Consensys

Consensys Incorporated is an independent blockchain infrastructure company, spun out of Consensys Software Inc.

--- one of the world's leading blockchain technology companies and the primary development organization behind the Ethereum ecosystem.

We build and operate neutral, institutional-grade blockchain infrastructure that connects banks, asset managers, custodians, and financial market infrastructures to digital asset networks, meeting the non-negotiable standards of institutional finance: privacy, scalability, resilience, security, and regulatory readiness.

Headquartered in Miami, Florida, and operating across the US, Europe, and Australia, Consensys Incorporated launched as an independent entity in September 2026 and is building the team to match its ambition.

We build and operate blockchain infrastructure for financial market infrastructure --- settlement, custody and clearing institutions. The platform spans a sequencer and coordinator, a ZK proving stack, cross-ledger interoperability, privacy and settlement components, and the infrastructure that runs all of it in production for clients with contractual commitments.

Someone has to hold that whole picture and make the pieces fit. Not in a diagram --- in the code, in the design decisions, and in the answers we give institutional architects who are deciding whether to put real value on our networks.

This is a hands-on role. You will write code, build proofs of concept, and be in the design reviews. If you haven't shipped something yourself in the last year, this isn't the right role.

• Architecture across the platform --- how the sequencer, coordinator, proving stack, interop layer, privacy components and infrastructure fit together, and where the seams are.
• Cross-ledger interoperability architecture. This is our differentiator and our IP, not a commodity --- the design choices here decide what we can sell and what we can charge for.
• Turning institutional requirements into designs. Our clients issue detailed requirement documents --- availability, finality, privacy isolation, RBAC, key custody, emergency deployment. You turn those into architecture the team can build and we can evidence, and you are honest about which requirements we meet technically and which we meet by control and attestation.
• Proofs of concept. Built by you in partnership with the Engineering team, after specified to a high quality by you. Ambiguity gets resolved by building the smallest real thing.
• Design reviews and architecture decisions --- written down, with the reasoning and the discarded options, so the next person doesn't re-litigate them.
• Build versus buy. Where we take a third-party component, where we build, and what that costs us in dependency.
• Technical depth in client and partner deep-dives when the conversation goes past what a slide can carry.
• Architecture decisions are final. You time-box spikes and PoCs, you write down the discarded path, and you freeze the call so engineering is not implementing two designs at once.
• You own the design so other people can build. That means interfaces, constraints and written decisions --- not sitting in every review. Teams should be able to ship against an Architecture Decision Record without you in the room.
• You use AI daily to explore designs, write and test PoCs and draft ADRs. You set that practice for the people who implement your designs.
• Designs that survive production. Availability, finality, rollback and proving upgrades are architecture constraints, not an ops surprise after merge.

• Product --- you pair closely with Product on what we build and why. Architecture that isn't anchored in a client problem is a hobby.
• Cryptography and ZK research (prover, zkEVM, arithmetization) --- a separate line. Their output is a major input to your architecture; you need enough depth to reason about proving costs, latency and constraints without needing to be a cryptographer.
• Core protocols (Besu, Teku and related clients) --- sits with our Head of Protocols. Client capabilities and roadmap commitments there shape what you can design.
• Engineering and infrastructure --- your designs are built and operated by these teams. They will tell you quickly if a design doesn't survive contact with production, and you should want them to.

• Has designed distributed systems and built them --- recent, hands-on, in a language we use (Kotlin, Go, Rust, Solidity, Type Script, Zig).
• Has strong hands-on…