Careers
One open role
We are a digital-asset investment firm with a deliberately unusual structure: a small human team in Bali supported by a fleet of AI agents that handle research, operations and content production. We are hiring one engineer — the person who rebuilds the software that executes our trading programme and then owns it, and everything we build after it.
The open role — tap to jump straight to it
Applying takes one email: write to gabriella@levenstein.net with the subject line Runner rebuild.
Full contents
About the firm
Nicholas Levenstein & Company is a digital-asset investment firm based in Bali. The team is small by design and sits together in one office; a fleet of in-house AI agents carries the load that would otherwise require a much larger staff — research, operations, content production, and parts of the trading stack.
That structure sets the terms of the role below. Our engineer works alongside AI assistance but owns, reviews and answers for every line that reaches the trading path. We are hiring judgment, not throughput.
The position is on-site and permanent. We do not run it remotely, and we are building a team rather than buying a piece of work. That cuts both ways: we expect people to stay, and we pay people who stay and deliver accordingly — see 1.10.
↑ TopOpen role 1 · Shadow Edge
Trading-Systems Engineer
Full-time, permanent · on-site in Bali · Python
We run a small, live, options-informed trading programme on Polymarket. The strategy works. The software that executes it does not, and we are replacing it. We are hiring one engineer, permanently, to rebuild the execution runner from a written specification, prove it against golden test vectors, and then own it — along with everything we build after it.
On being in the room. You would work from our office, alongside the person whose money is at risk. We have run this programme with a remote developer and we are not doing it again — the failures in 1.3 took weeks to surface across a chat window and would have taken an afternoon across a desk. If a permanent move to Bali is not something you want, this is the wrong role, and we would rather you knew that from the first paragraph than from the third conversation.
What we do
We trade daily crypto price markets on Polymarket, and we price them off the professional options market. Deribit's option surface gives an implied probability for the same outcome band that Polymarket is quoting; where the two disagree by more than our cost of trading, we take the side the options market says is cheap, and we hold to resolution.
That is the whole idea, and it is deliberately simple. The maths is written down, frozen, and independently validated. The book is small on purpose — positions are $5 and the account is in the low hundreds of dollars — because we are proving the machinery before we scale the capital, not the other way around.
The programme runs on a weekday cadence with a daily 12:00 meeting: the previous day's trades are audited against the exchange, and the next day's parameters are signed off before they run. The team is small and sits together in Bali — the principal, a verification analyst, and (this role) one engineer who owns the code.
↑ Top+1.2 What exists todayThe specification, the golden test vectors, the running service, and four months of trade history to regression-test against
You would not be starting from a blank page.
| Piece | What it is | State |
|---|---|---|
| Strategy specification | Fair-value formula (skew-adjusted, Breeden–Litzenberger style), entry gates, exit policy, risk limits, expiry-bracket rule — versioned documents | Current and authoritative |
| Golden test vectors | A live market snapshot with hand-computed fair values for every bucket, to four decimal places | Ready to test against |
| Runtime config | A JSON file holding thresholds, caps and the master kill switch; the runner re-reads it every loop, so parameter changes need no redeploy | Design is good, keep it |
| Execution runner | Python service on a Linux box; polls Polymarket CLOB and the Deribit public API on a ~60s loop; places and cancels limit orders; exposed as MCP tools and a small HTTP API | To be rebuilt — this job |
| Ledger and API | Trade records, summary, P&L and decision endpoints consumed by our dashboards and daily audit | Unreliable — see 1.3 |
| Dashboards | Public read-only pages on this site, fed from the API | Working; low priority |
| Repo and deploys | Git, daily commits, full history | In place |
| Trade history | ~80 live orders, ~42 resolved markets, with matched option-chain snapshots captured at decision time | Available for regression |
+1.3 Why we are rebuilding rather than patchingFour specific defects in the current runner, described honestly. This is the problem you would be hired to end
We want to be straight with candidates about the state of the code, because the honesty is the job description. The current runner has drifted from its specification in ways that are not visible from the outside, and patching it has repeatedly failed. Four problems, in order of how much they cost us:
- The ledger books an acknowledgement as a fill. When an order is accepted by the exchange, a row is written as though we hold a position — and then nothing ever reconciles it. Orders that never filled sit open forever; orders that did fill still read as resting. Our internal record and the exchange currently disagree by more than three times the size of the actual book. Every number downstream inherits the error.
- Controls that exist in the spec do not bind in the code. Rules that are written down, agreed and believed to be live — a market-type exclusion, an entry-time cutoff, one position per asset per day — have each been breached by orders the runner placed itself. The gates are evaluated somewhere upstream of the code path that actually signs the order.
- It fails silently. The runner once took no trades for sixteen days without raising anything, because a dead branch of logic was quietly rejecting every candidate. There is no alerting on a stalled loop, and the endpoint that would tell us why a candidate was skipped has been returning 404 for three weeks. We cannot currently distinguish “the strategy correctly declined” from “the software is broken.”
- Failure states are persisted as trades. Retry loops write a new trade row per attempt; a single bad afternoon produced 74 of them. Two hundred-odd of ~300 records are failed attempts, and a single API response is now six megabytes because each row embeds an entire option chain.
What this means for the role. The strategy is not in question — split by market type, the book we are supposed to be trading is profitable and the book we were not supposed to be trading is where every loss sits. What is in question is whether the code does what the document says. Your job is to close that gap permanently, and to build the instrumentation that proves it stays closed.
Your first month — the rebuild
Rebuild the runner in Python from the written specification, treating the existing service as a reference implementation to read and not as a base to extend. Seven deliverables:
A deterministic strategy core
Fair value from the option chain, in a pure, side-effect-free module that reproduces the golden test vectors to four decimal places. No network calls, no clock reads, no model inference inside it. Unit-tested, with the test vectors in CI.
A gate layer that binds at submit time
Every entry rule — permitted market type, entry price band, minimum net edge after costs, one position per asset per day, per-trade and per-day size caps, entry-time cutoff, hard price ceiling — implemented as an individually testable pure function and evaluated at the last point before the order is signed. Not in a reader, not in a config comment, not upstream. If a gate rejects, the reason is recorded.
Correct order lifecycle and fill reconciliation
An order and a position are different objects and must never be conflated. Place, acknowledge, rest, partially fill, fill, cancel, expire, redeem — model the whole lifecycle, poll the exchange after placement, and reconcile continuously. Support always-on quoting: post at our price, cancel-and-replace on a ~60s cadence until filled, and cancel every resting quote at the daily cutoff and on kill. Idempotent, so a restart mid-flight never double-submits.
A ledger that is true by construction
One record, reconciling to the exchange to the cent, checked automatically every day. A row becomes a position only on a confirmed fill. Failed attempts are logged as errors, not as trades. No derived field is ever written when its source is absent. Append-only audit of every evaluation the runner makes, including the ones it declines.
Observability
A decisions endpoint that answers, for every candidate market on every loop, “taken or skipped, and precisely why.” A health endpoint. Alerting on a stalled loop, an authentication failure, a reconciliation break, and a gate breach. We should learn about a problem from an alert, not from an audit three weeks later.
Kill switch and safe restart
The master switch stops all new orders immediately, with documented and tested behaviour for resting orders and open positions. Restart is safe from any state and does not need the engineer who wrote it.
Handover
Runbook written so a non-technical operator can start, stop, kill, check health and read the day's decisions without opening a terminal session with you. Deploys reviewable and reversible, with more than one person holding admin.
↑ Top+1.5 Acceptance criteriaNine tests. Not negotiable and not subjective — this is how the rebuild gets signed off
| # | Criterion |
|---|---|
| 1 | The fair-value module reproduces every golden test vector to 4 decimal places, in CI. |
| 2 | Every gate has a unit test that proves it rejects, and an integration test that proves the rejection reaches the signing path. |
| 3 | A 14-day live run in which internal records and the exchange reconcile to the cent, every day, automatically, with the check itself recorded. |
| 4 | Zero orders placed outside the permitted market type, price band, size cap, position limit or time window across that run. |
| 5 | Every candidate market on every loop appears in the decisions log with an outcome and a reason. |
| 6 | A deliberately induced stall raises an alert within one loop interval. |
| 7 | The kill switch is exercised, on a live position, in front of us. |
| 8 | The historical trade set replays through the new engine and its decisions are explainable against what actually happened. |
| 9 | Someone other than you deploys it, from the runbook, while you watch. |
After the rebuild — what you own
The rebuild is the first month, not the job. Once it is signed off, this is the ongoing work:
- Own the runner and the box it runs on. Watch it, patch it, keep it current.
- Be in the office for the daily 12:00 meeting on weekdays — usually short, occasionally not.
- Implement the parameter and rule changes signed off on that call, same day where the change is small.
- Incident response when a trade misbehaves, with a written post-mortem that names the code path.
- Extend the universe as we grow it — additional assets, additional venues — under the same specification discipline.
- Scale the machinery as position size and frequency increase.
- Take on what comes after the runner. This is the first hire on the technical side, not the last piece of work, and the stack we build next is yours too.
+1.7 House rules you would be agreeing toSeven conditions of the job, each learned the expensive way. Worth reading before you apply
- The exchange is the oracle. Where our records and the venue disagree, the venue is right and our records are the bug. Never the reverse.
- The written spec is the contract. If the code needs to differ from the document, the document changes first, in writing, with sign-off.
- AI proposes, a human approves, a human deploys. We use AI assistance heavily for analysis and drafting. It does not ship its own logic into the trading path unreviewed. We have been burned by exactly this.
- Nothing runs unsigned. The next day's parameters are agreed on the daily call before they trade.
- Credentials are never sent over chat. Keys live on the server, in a documented custody arrangement, rotated on handover. More than one person holds repo admin.
- Silence is a bug. A system that stops trading without saying so is considered broken, whatever the reason.
- Non-technical operability. A capable non-engineer must be able to run, stop and read the stack from written instructions.
Who we are looking for
Required
- Strong Python. Production services, not notebooks.
- You have built against a real exchange or broker API and understand what that actually costs you: order state machines, partial fills, idempotency, retries that don't duplicate, reconciliation against the venue as the source of truth.
- Testing is a habit, not an afterthought. You are comfortable being held to the acceptance criteria in 1.5.
- Linux service operations — process supervision, logging, alerting, a sane deploy you can roll back.
- Enough options literacy to implement the pricing correctly and to notice when an input is wrong: strikes, expiries, deltas, implied volatility, and why the expiry you price off has to bracket the contract you are trading.
- Git discipline, and the temperament to replace code rather than layer over it.
- You write clearly. Specs, post-mortems and runbooks are part of the deliverable, and you will be explaining your reasoning to non-engineers on a daily call.
- In our office in Canggu, five days a week, permanently. Not for the first month — for the job.
- The right to work in Indonesia, already in place. We do not sponsor visas and we do not pay relocation. If you live elsewhere in Indonesia and are willing to move to Bali yourself, apply.
On the money, plainly. We publish the number rather than asking you to guess it: IDR 10,000,000 a month, nett of tax and BPJS, plus a monthly performance bonus of USD 100 to USD 400, decided against the previous month's work. That is the starting rung of a staff career here, not a ceiling, and it is not where anyone who does the job well stays.
We are a small firm, not a cheap one. The bonus is not an annual ritual — it is set every month, on what you actually delivered, and someone doing this job properly is expected to be at the top of the band rather than the bottom of it. The base is reviewed when you come off probation and again whenever the work has outgrown it. Our most recent staff hire joined on exactly these terms, has been paid the maximum bonus every month since, and has already had a raise. That is the pattern here, not the exception.
If the opening number is the reason you would say no, tell us that in your reply rather than not writing. We would rather have the conversation.
Helpful, not required
- Prediction markets — Polymarket, Kalshi — or crypto derivatives venues such as Deribit.
- Risk-neutral density work: Breeden–Litzenberger, skew adjustment, short-horizon variance scaling.
- On-chain plumbing: wallets, USDC on Polygon, signing, key custody.
- Small-team quant or prop experience, where the same person writes it, runs it and answers for it.
Not a fit if you need remote or hybrid working at any point, want to redesign the strategy, prefer to own only the code and not its behaviour in production, or would rather add a flag than delete a module.
+1.9 What we provideSpec pack, live data, four months of history, live capital, and an analyst who checks your numbers
- The full specification pack — pricing formula, gates, exit policy, risk limits, schema, test vectors, testing regimen.
- Live market data infrastructure for Polymarket and Deribit, already built and working.
- Four months of live trade history with option-chain snapshots captured at decision time, for regression.
- Live capital, deliberately small, from day one — you are not building against a simulator.
- A daily call with the decision-maker in the room. Answers in hours, not weeks.
- An independent verification analyst who checks the numbers, so you are not also the auditor of your own work.
- A clean brief: rebuild it right, once.
Pay, progression and terms
| Item | Terms |
|---|---|
| Structure | Full-time employee of Nicholas Levenstein dan Rekan, permanent. A seat on the team, not a fixed-scope project. |
| Base pay | IDR 10,000,000 per month, nett of tax and BPJS, paid on the 1st. The same staff scale every employee here starts on — we do not run one scale for the advert and another for the offer. |
| Monthly bonus | USD 100–400 every month, set against the previous month's work and paid before the 15th. Decided on results, monthly, not once a year. A person doing this job well sits at the top of that band. |
| Progression | Three months probationary, then permanent appointment — at which point BPJS health and employment cover begins and the base is reviewed. It is reviewed again whenever the work has outgrown it, on merit rather than on the calendar. Our most recent staff hire came in on exactly these terms, has drawn the maximum bonus every month since starting, and has already had a base raise. Raises here follow delivery, and they follow it quickly. |
| Location | On-site in Canggu, Bali, five days a week, permanently. No remote option and no hybrid arrangement, at any stage. |
| Who can apply | You must already have the right to work in Indonesia. We do not sponsor visas or pay relocation. Candidates elsewhere in Indonesia who are willing to move to Bali themselves are welcome to apply. |
| First month | The rebuild in 1.4, judged against the acceptance criteria in 1.5. We would rather see something narrow and correct in week one than everything at the end. |
| After that | Ongoing ownership of the runner and of what we build next, as set out in 1.6. |
| Start | Immediately. The programme trades every day and is currently running on software we do not trust. |
How to apply
- A short note on the closest thing you have built to this, and what broke in it.
- Where you are based now, confirmation that you hold the right to work in Indonesia, and when you could start.
- Code we can look at, or a description of what you cannot show and why.
- The screening question, answered in a paragraph or two: our current system treats an order acknowledgement as a fill. Describe how you would design the order-and-position model so that this class of error is structurally impossible rather than merely fixed — and how you would prove to us, daily and automatically, that our records match the exchange.
We have already told you what the job pays, so there is nothing to guess at and no number to pitch. If the terms work for you, answer the four items. If they do not, say so in a line — we will thank you and close the file, and there are no hard feelings in either direction.
No cover letters and no CV formatting exercises. The screening question is the filter; answer it in your own words and we will read every one.
How we hire
One short process. Write to gabriella@levenstein.net with the subject line “Runner rebuild” and the four items listed under 1.11. We read applications ourselves.
If your note lands, you will hear back within a few days and we will talk. Expect a working conversation about your screening answer rather than a whiteboard exercise, and then a visit to the office in Canggu — we will put a section of the current runner in front of you and ask you what is wrong with it. The role is on-site, so meeting in person is part of the process rather than a formality at the end of it.
We reply to every serious application. We do not use recruiters or agencies, and we do not want CV-blast volume — a specific, honest note beats a polished one.
↑ TopNicholas Levenstein & Company · Bali, Indonesia. Posted 27 August 2026; terms updated 9 September 2026; pay and progression stated in full 14 September 2026. This posting describes employment only, and is not an offer of investment, a solicitation, or a representation of trading performance. Figures cited are drawn from our own live trading records and are given to describe the engineering problem, not to advertise returns.