What the work is like
Most software can be patched on Monday. Ours often cannot: a deployed contract is permanent, an exchange ledger has to reconcile continuously, and a wallet key handling mistake is unrecoverable for the user.
So the day-to-day looks different from ordinary product work. More invariant testing, more adversarial thinking, more time spent on failure states than happy paths.
Correctness over velocity
Invariant and fuzz testing on anything touching money, because example tests miss classes of bugs.
Adversarial by default
You will be asked what a well-capitalised attacker does with your feature.
Real handover
Everything we build is transferred to clients, so documentation and runbooks are part of the job.
Named accountability
Engineers own their architecture decisions through to launch rather than passing them along.
Open roles
Roles we hire for regularly. Send us your work even when nothing matching is listed.
Smart contract engineer
Location / remote policy — Solidity or Rust, invariant testing, gas optimisation, audit remediation experience valued.
Backend engineer, exchange systems
Location / remote policy — Matching engines, ledgers, reconciliation, high-throughput services.
Mobile engineer
Location / remote policy — Native iOS or Android, secure key storage, offline-safe state handling.
Security engineer
Location / remote policy — Key management, penetration testing, threat modelling for custodial systems.
Compliance analyst
Location / remote policy — Crypto AML, KYC tier design, jurisdiction mapping, regulator reporting.
QA engineer
Location / remote policy — Adversarial testing, poor-network simulation, device matrix validation.
Replace bracketed items with your real location and remote policy, and add salary bands if you publish them. Applications currently route to the contact form below — swap in your ATS link or careers email when ready.
How hiring works
Application
Send your CV plus something you built. Code, a protocol design, a writeup — anything real beats a cover letter.
Conversation
A call about your work and what you want to be doing, not a quiz.
Technical exercise
A realistic problem from our actual domain, time-boxed and paid where it exceeds X hours.
Team discussion
Meet the people you would work with, including the architect on your prospective team.
Offer
Written offer with scope, level and compensation stated plainly.
What we offer
Stated plainly, including the parts that will not suit everyone.
Compensation
Salary bands or the range for each role. Publishing them filters out mismatches before an interview.
Location and remote
Your actual policy: office, hybrid or remote, and which timezones you hire across.
Equipment and setup
What you provide.
Learning budget
Annual budget for courses, conferences and certifications, if any.
Time off
Holiday allowance and any policy on unused days.
Progression
How levels work and how often reviews happen.
What you should know before applying
The things a candidate finds out in month two, said now instead.
The work is high-consequence
Code that holds custody cannot be patched casually. That means more review, more testing, and slower merges than you may be used to.
You will write documentation
Everything we build is handed to a client, so runbooks and docs are part of the job rather than an afterthought.
Client-facing by default
Engineers join scoping calls and stage demos. If you would rather never speak to a client, this will not suit you.
Audit findings are personal
Your code goes to an external auditor and the findings come back with your name on them. Most engineers find this makes them better.
Domain learning curve
Crypto has a lot of specific knowledge. We expect a ramp-up period and plan for it rather than pretending otherwise.
Anything else candidates consistently raise
Answer it here. A careers page that admits a downside is more credible than one that does not.