Build systems that hold real money.
We are a research led software house. We build our own products, we build and run the infrastructure other teams depend on, and we review the security of all of it before it reaches mainnet. The team is small on purpose, so the person who designs a system is the person who ships it and answers for it.
Three kinds of work, and you will touch all three.
We are not a consultancy that also has a side project, and not a protocol team that occasionally takes contracts. Both sides fund each other, and the same people move between them.
Our own protocols
Vaults, routing and the rails behind compliant real world asset issuance. Mechanism design through mainnet, and the monitoring that runs long after launch.
Systems other teams run on
Nodes, indexers, oracle integrations and data APIs, operated as a service with real uptime obligations. Someone else's product breaks if you get this wrong.
Research that ships
Execution and risk modelling, and longer horizon work including post quantum migration. Findings become implementations and published notes, not internal slide decks.
The parts most job posts leave out.
These are the working conditions, not aspirations. If any of them sound wrong to you, this is not the right team and we would both rather know now.
- Written by default. Decisions live in documents that outlast the people who made them, not in someone's memory of a call.
- Few meetings, and they have agendas. Deep work is the normal state of the week rather than the thing you schedule around.
- You ship it and you run it. Nothing gets thrown over a wall to an operations team that did not design it.
- Research time is in the calendar. It is protected work, not something you fit into evenings once delivery is done.
- Security is part of the build. Our own products get the same threat modelling and testing as client work.
- Postmortems are blameless and public internally. We write them for every incident that reached a user, including our own products.
Five roles open now.
All remote. If you are close on three of the four requirements and can show us something you built, apply anyway and tell us which one you are light on.
Senior Protocol Engineer
EngineeringDesign and ship the contracts behind our vaults, routing and real world asset work. You own systems end to end, mechanism through deployment, and work directly with the research team rather than receiving specs from them.
- Deep Solidity, and enough of a second ecosystem to read it (Rust or Move)
- You have shipped contracts that held real value in production
- You think about failure modes before you think about features
- You can write the spec, not only implement one
Infrastructure Engineer, Nodes and Indexing
EngineeringBuild and run the node, indexer and data layer we deliver to clients. Custom schemas, reorg handling, backfills, and the alerting that means nobody finds out from the client first.
- Strong Go, Rust or TypeScript, and real operations instincts
- You have run archive nodes and know why that sentence is a warning
- Postgres, Kafka, and a healthy suspicion of eventual consistency
- You have been on call for something that mattered
Smart Contract Security Engineer
EngineeringReview everything before it ships and after it changes. Threat modelling, invariant testing and fuzzing, on our own protocols and on client work. You work alongside the engineers who build it, early enough to change the design.
- A public record of findings, or internal work you can describe
- Foundry and Echidna, or strong opinions about why something else
- You can explain a finding to someone who did not write the code
- You are comfortable being the person who says not yet
Quantitative Researcher
ResearchModel the strategies before they become products. Execution research, basis and funding analysis, and the risk framework that decides what we are willing to publish and what we are not.
- Python, and the statistics to know when a backtest is lying to you
- Familiarity with on-chain market microstructure
- You write up negative results as carefully as positive ones
- You can hand an engineer something they can actually implement
Cryptography Researcher, Post-Quantum
ResearchWork on what migration to post-quantum signatures actually means for live networks and for the assets settled on them. Long horizon research with a path to shipped implementations and published work.
- Background in lattice-based or hash-based signatures
- Comfortable moving between a paper and an implementation
- Interested in the engineering reality, not only the proof
- You can write for engineers as well as for reviewers
What happens after you hit send.
Four steps. We aim to go from application to decision inside three weeks, and we tell you where you stand at every step rather than leaving you to guess.
You apply
Send the form with something we can read: a repository, a writeup, an audit report, a paper. A CV on its own tells us very little. Every application is read by an engineer, and you get a reply either way within five working days.
First conversation, 45 minutes
With the engineer you would actually work alongside. What you have built, what you want to build next, and what you would want from us. No whiteboard, no trick questions, no algorithm puzzles.
Technical deep dive, 90 minutes
Your choice: walk us through something you have already built, or take a short exercise in your own time. We do not set unpaid work longer than four hours, and anything longer than that we pay for at contract rate.
Team conversation, then a written offer
Meet two more people, including someone outside your discipline, and use it to interrogate us properly. Offers come in writing with the scope and the reasoning, and we answer follow-up questions in writing too.
The conditions to do the work properly.
Before you apply.
Do I need existing Web3 experience?
For the protocol and security roles, yes. Real value moves through this code and there is no gentle version of that learning curve. For the infrastructure and research roles, no. Strong distributed systems or quantitative backgrounds transfer well, and we have hired people who learned the chain specifics on the job.
Where can I work from?
Anywhere you are legally able to work, as long as you can overlap a few hours with the rest of your team. We run in writing precisely so that time zones are a scheduling detail rather than a career limit.
Do you set take-home tests?
Only if you prefer one. You can walk us through work you have already done instead. If you do take an exercise, it is capped at four hours, and anything beyond that is paid at contract rate. We do not ask candidates to build things we then use.
How long does the whole process take?
We aim for three weeks from application to decision. The slowest part is usually scheduling the deep dive around your existing job, and we will work around you rather than the other way round.
What if none of the open roles fit?
Send an open application. We hire when we meet someone good rather than only when a role is posted, and several of the team joined that way. Tell us what you would want to work on and show us something you built.
Will you tell me why if you say no?
Yes, if you want it. Ask at any stage and you get specific written feedback rather than a template. We would rather you left the process with something useful.
Tell us what you would want to work on.
We hire when we meet someone good, not only when a role is posted. If the work interests you and you can show us something you have built, write to us and say so.