Software / Systems Architect

About the Company

Responsibilities

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