About Poly Syncer
Poly Syncer is the production Polymarket copy trading platform that mirrors the trades of profitable Polymarket wallets in seconds, without ever holding subscriber funds. Two services define the user experience: the listener (which watches on-chain activity and triggers intent generation) and the executor (which submits private-bundle orders on Polygon). Both run under sub-second SLOs. When they are healthy, subscribers get exactly what they paid for. When they are not, they do not. The whitepaper covers the architecture; the security page the posture.
The role
You will own the production environment that keeps the listener and the executor alive across multiple cloud regions and across four RPC providers. The current setup runs on a mix of dedicated bare-metal (for the latency-critical paths) and managed cloud (for the rest), tied together with Terraform, observed with Prometheus and Grafana, and instrumented with a custom latency exporter we are mildly proud of. It is solid. It is not finished. The next iteration needs a more honest tail-latency story, better RPC-provider failover, and a runbook discipline that survives the team doubling.
Concretely, you will: own the Terraform that defines our infrastructure across three providers; lead the observability redesign (Prometheus is staying, the dashboards are getting overhauled, and we are evaluating whether to introduce eBPF-based tracing); maintain and extend the on-call rotation; and be the person engineering goes to when "is this slow because of us or because of the RPC?" needs to be answered in under sixty seconds. You will also drive the chaos-engineering practice — we do controlled failovers monthly, and that practice needs an owner.
You'll be a fit if
- You have production experience operating low-latency, multi-region services with sub-second SLOs — not "eventually consistent" and not "five-nines" theatre. Real numbers, real production.
- You have strong Linux fundamentals. You can read a flame graph, you know what a syscall is, and you have an opinion about io_uring.
- You are fluent with Terraform and one of Pulumi or CDK. You have written modules other people depend on.
- You have a real, substantive opinion about when Kubernetes is worth its weight and when it is not. Either answer is fine; "always" or "never" is not.
- You have stood up an observability stack from scratch at least once. Bonus if you have torn one down because it stopped paying for itself.
- You are calm during incidents and you write good post-mortems. You separate "what happened" from "who is to blame."
- You can write Go or Rust well enough to fix a small bug in the executor or the listener when the SRE-side fix is not the right one.
Bonus points
- You have run RPC infrastructure (your own node, or a managed one) for a real workload and have opinions about provider tradeoffs on Polygon.
- You have shipped an eBPF-based tracing tool to production.
- You have written a chaos-engineering harness from scratch.
Process
- Intro call (45 min). A conversation with the engineering lead and the current on-call lead.
- Paid take-home (10–14 hours, $1,500). A scoped problem covering Terraform, an observability decision, and a runbook write-up. You keep the work and the IP regardless of outcome.
- Technical deep-dive (90 min). Two engineers walk through your take-home, then through a real recent incident from our timeline.
- Founder call + offer (60 min). Compensation, equity, and the values described in the manifesto. Offer within five business days.
Compensation
$160k–$210k base + meaningful equity. Equity vests over four years with a one-year cliff. We pay top-tier health coverage in your home country, fund a co-working stipend, and cover a quarterly off-site. On-call rotation is compensated separately and explicitly.
Location
Remote-first, HQ Stockholm. We hire across EU and US time zones with at least four hours of overlap with European working hours, so live debugging across the on-call rotation is possible. The listener and the executor do not respect calendars; the rotation does.
How to apply
Email [email protected] with a short note describing one production incident you owned end to end — what broke, how you found it, what you changed afterward. That is more useful to us than a resume.
For technical context, see the whitepaper and the methodology page. For posture, see the manifesto. For prior incidents and how we have written about them publicly, the changelog is the canonical record.
One last note: we expect the SRE seat to push back hard on engineering when reliability and velocity are in tension. The CEO will back that pushback. The role is not a service organization sitting downstream of feature work; it is a peer voice with a real veto over what ships and when.