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.

Why this role exists

• 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.

What you'll own

• 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.

How this fits

• 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.

What we are looking for

• Has designed distributed systems and built them — recent, hands-on, in a language we use (Kotlin, Go, Rust, Solidity, TypeScript, Zig).
• Has strong hands-on background of Software Development/Engineering, 8+ years.
• Can hold a large system in their head and see where it doesn't fit together, and reason down to detailed technical level— the failure modes, the coupling, the thing that breaks at scale–and be able to effectively communicate this to colleagues.
• Ethereum and EVM knowledge, or the demonstrated ability to get there fast from adjacent distributed-systems work.
• Writes clearly. Design documents and diagrams that a bank's architecture team will accept without a meeting. Not just for external, but for internal too. The architect should leave behind clear written artifacts that make it clear what engineers need to build and why, and what success looks like.
• Can be in a room with institutional architects and stay technical — credible on resilience, key custody, finality and privacy without drifting into sales language.
• Pragmatic. Knows when the right architecture is the boring one.
• Decisive under ambiguity. Makes the call when Product, a client requirement and a protocol constraint disagree.
• Experience architecting for secure mission-critical systems.

Useful, not required

• ZK proof systems — enough to reason about cost, latency and trust assumptions.
• Privacy technologies: privacy pools, MPC, trusted execution, tokenisation frameworks.
• Regulated financial infrastructure — payments, clearing, settlement, custody.
• Understanding of governance dynamics and key stakeholders within the Ethereum ecosystem.
• Experience of cloud and infra deployments and topologies.
• Experience in Fintech/Banking/Trading or similar domains.

What this role is not

• Not a PowerPoint architect. If the last two years of your work are diagrams and decks, this is the wrong role and the interview will find that out.
• Not a pre-sales function. You'll join client technical sessions, but delivery is the job.
• Not a people-management role. This is an individual contributor position with real technical authority.