Kate Desk — request for proposal
Nicholas Levenstein & Company · issued 21 September 2026 · all figures on this page are illustrative · confidential — provided to named recipients only, not for redistribution
Contents
What this is. We run a small automated trading system. It works, but it is operated by editing files and reading logs, and the person who built it has moved on. We want a single screen an operator can run it from, and the plumbing underneath to make that screen real. This document is the brief. The numbers on the mock below are illustrative; the strategy logic behind the "Fair" column is ours and is supplied on engagement, not here.
1 · The screen we want built
One page, no menus, nothing to scroll on a 27-inch monitor. Left to right: what the market is offering (asset cards) → what the runner is told to do about it (Algorithm and Sizing) → what it is holding (Positions) → what just happened (the tape). The toggles, knobs, stake box, HALT and PUSH buttons below actually work, so you can feel the intended flow. Nothing here is wired to a live system.
BTC$118,420 ▲0.6%1 HELD
| Sep 19 · 16:00 UTC | PM | Fair | Edge | Kate |
|---|---|---|---|---|
| > $120k | 14¢ | 11¢ | −3 | THRESHOLD |
| $118k–120k | 41¢ | 44¢ | +3 | BELOW FLOOR |
| $116k–118k | 33¢ | 40¢ | +7 | NO @ 68¢ · $5 |
| $114k–116k | 9¢ | 5¢ | +4 | BELOW FLOOR |
| < $114k | 3¢ | 1¢ | +2 | THRESHOLD |
Fair = model (supplied on engagement)next scan 04:52
ETH$4,312 ▼0.2%1 ARMED
| Sep 19 · 16:00 UTC | PM | Fair | Edge | Kate |
|---|---|---|---|---|
| > $4,400 | 12¢ | 9¢ | −3 | THRESHOLD |
| $4,300–4,400 | 52¢ | 47¢ | +5 | NO @ 48¢ · outside band |
| $4,200–4,300 | 28¢ | 37¢ | +9 | NO @ 72¢ · fill check |
| $4,100–4,200 | 6¢ | 5¢ | −1 | — |
| < $4,100 | 2¢ | 2¢ | 0 | THRESHOLD |
Fair = model (supplied on engagement)next scan 04:52
SOL$224.5 ▲1.4%NEW · PAPER
| Sep 19 · 16:00 UTC | PM | Fair | Edge | Kate |
|---|---|---|---|---|
| > $230 | 21¢ | 17¢ | −4 | THRESHOLD |
| $225–230 | 30¢ | 36¢ | +6 | PAPER NO @ 70¢ |
| $220–225 | 34¢ | 33¢ | −1 | — |
| $215–220 | 10¢ | 9¢ | −1 | — |
| < $215 | 5¢ | 5¢ | 0 | THRESHOLD |
Fair = Deribit SOL chain · daily expiry: verifypaper until 30 fills
Algorithm runner: v1.1 · desk: v1.2-draft
BandThreshold
Desk matches runner. Nothing to push.
Last push: 01 Sep 2026 · Risk Limits v1.1 · flat $5 · acked by runner
Sizing & denomination
= $5.00 per ticket · 12% of the wallet · max at risk with 3 open: $15.00
BTC
ETH
SOL
0x0000…0000
Positions 1 live · 1 paper
| Asset | Market · side | In | Mark | P&L | Resolves | |
|---|---|---|---|---|---|---|
| BTC | $116–118k · NO | 68¢ | 71¢ | +$0.22 | 3h 26m | |
| SOL | $225–230 · NO P | 70¢ | 70¢ | $0.00 | 3h 26m |
Settled · all time2 · −$1.55
Win rate · backtest—
ROI · backtest—
N stuck — fills open past close · dead pendings
Tape every decision, every scan
12:34:02ZFILLBTC $116–118k NO 68¢ × 7.35 = $5.00 · order 0x0000…0000
12:34:01ZSKIPETH $4,200–4,300 NO 72¢ · edge +9 · book would fill at 73¢ (window top) — waiting
12:34:01ZSKIPETH $4,300–4,400 NO 48¢ · below 55¢ window floor
12:34:00ZPAPERSOL $225–230 NO 70¢ × 3.57 = $2.50 (×0.5) · logged, not sent
12:33:59ZSKIP5 threshold markets · rule 1 (band only)
12:29:00ZSCAN3 assets · 15 markets · 0 actionable · Deribit 19SEP/20SEP interp
11:59:00ZINFOblackout 08:00–11:59Z ended · entries enabled
08:00:11ZWARNrunner heartbeat 41s (expect ≤ 10s) · openclaw-api 404 on /health
Today & this week
Scans today64
Entries today1 live · 1 paper
Week P&L (settled)+$3.10
Since Aug 26 (band-only)+$11.67
Rule breaches this week1
Config hash on runnera41f·v1.1
2 · Scope of work
Four pieces. Three are unblocked and are what we are asking you to quote. The fourth depends on an infrastructure move that is not yet scheduled.
| Piece | What ships | Status |
|---|---|---|
| B. Third-asset data path | Add a third asset to the existing two: options-chain fetch from our derivatives data source, daily-market discovery on the prediction venue, and making the pricing module asset-agnostic where it currently hard-codes contract formats. Roughly six new endpoints mirroring twelve that already exist. | Quote this. Not blocked. |
| C. Desk API | A thin local service (FastAPI or equivalent, same box as the runner) that the screen polls every 5 s: state (balance, positions, feed ages, current config hash), ladders (one per enabled asset, with the skip reason per row), tape (last 200 events), plus POST endpoints for push, halt, asset toggle, close and backtest. These all exist already as internal tools or engine functions — this wraps them for a browser. No new trading logic. | Quote this. Not blocked. |
| D. Window and logging | Enforce a daily entry cut-off time inside the runner itself rather than only in the UI; apply our supplied exit model to positions still open past that cut-off; make an existing observation log append automatically instead of by hand; regenerate a small monitoring page on a schedule. The model and its calibration are done and will be given to you — this is wiring, not research. | Quote this. Not blocked. |
| A. Config push channel | A versioned config file with a hash, a /v1/config GET/PUT, hot-reload in the cycle loop between cycles, and a journal line per reload — so the PUSH button on the screen reaches the running system. | Price separately, do not schedule. The production daemon is being moved onto company infrastructure. Until that move completes, a push cannot reach it. Build and demonstrate against a local paper instance; do not commit to a live push date. |
Suggested order: B first (it generates evidence while nothing else is blocked), then C against a paper-mode instance, then D.
↑ Go to Top3 · Acceptance criteria
- Entry window. There is a daily cut-off after which the runner must not open new positions. The exact time is supplied on engagement. This gate lives in the runner, not only in the screen, and is not operator-settable from the UI — it is a rule, not a setting. Any code path that can open a position after the cut-off is a defect.
- Stake, per asset. The operator types the stake for each asset into the screen — any value from $0 to $1,000,000, independently per asset. No stake value may be hard-coded, capped, or offered only as a dropdown. Whatever is typed is enforced before the order goes out, not merely displayed, and $0 is a valid way to switch an asset off.
- Entry band. The operator types both ends of the price band. Free-entry fields across the full 0.00–1.00 range, validated only for
low < high. The values shown on the mock are placeholders. - Push. One click, no confirmation step, for both rule changes and sizing changes. Every push writes a journal line.
- Third-asset go-live. No paper-fill gate is built. The new asset runs in paper mode until the operator flips it live from the screen, and that flip is available from day one. Any waiting period is our decision on the day, not a condition the software enforces.
- Demonstrable on the screen. Every criterion above must be checkable by clicking through the screen itself and seeing real numbers — not only in a separate test harness.
The principle behind four of those six. Every number describing how much, what price, or when to go live is a setting, not a specification. The operator types it and pushes it; the software accepts it, sanity-checks it, enforces it and journals it. A value that can only be changed by editing code and redeploying has been built wrong, however correct that value is on the day it ships. The entry cut-off is the one deliberate exception.
↑ Go to Top
4 · Known unknowns you should price for
Third-asset daily expiries. We are confident our derivatives source lists weekly and monthly options on the third asset; we have not verified it lists daily expiries the way the first two have. If it does not, the pricing method falls back to a noisier single-chain approach. Verifying this is day-one work and it can reshape Piece B — say how you would handle that case.
Third-asset market structure on the prediction venue. The first two assets use an identical bucket ladder. We have not confirmed the third uses the same band structure and the same daily resolution time. If it is quoted differently, the ladder still renders but there may be nothing tradeable under our current rule.
↑ Go to Top
5 · Access, credentials and security
No private key changes hands. Wallet custody stays with us. Access you are given will be scoped and read-limited wherever the underlying service supports it: API keys with the narrowest available permission, and a paper/testnet path for anything touching order placement. We will not export a wallet private key to you over chat, email or any messaging app, and you should not ask us to. If a task genuinely requires live write access, that is a separate decision we make at the time — it is not granted by this document.
You will receive the repository, the relevant specifications, and the internal tool documentation on engagement. Work product stays within the project structure we give you.
↑ Go to Top6 · Timetable
Our target is five working days for Pieces B, C and D. We recognise that is aggressive, and question 4 below asks for your dates rather than agreement with ours. For reference, this is how we would sequence it:
| Day | Target |
|---|---|
| 1 | Read the brief and the codebase. Resolve the two unknowns in section 4 — they can reshape Piece B, so they go first. |
| 2–3 | Piece B, and start the new asset paper-trading in the background so it accumulates a record regardless of when the rest lands. |
| 3–4 | Piece C, wired to the screen above. |
| 4–5 | Piece D. |
| 5 | Walkthrough against the live screen: every acceptance criterion in section 3, clicked through, with real numbers. |
7 · What we need back from you — answer these six
Reply in writing, point by point, before any work begins. Short answers are fine; missing answers are not. This is the whole of what we need in order to say yes.
| # | Question | What a complete answer looks like |
|---|---|---|
| 1 | Do you understand the spec? Confirm it — or ask whatever you need to ask. | Either a plain confirmation that sections 2 and 3 are clear and buildable as written, or your list of questions. Questions are welcome and expected; a confirmation with no questions on a brief this size will read as not having read it. If you think any part of this is wrong, say so now rather than building it. |
| 2 | What do you need from us to start? | Name it specifically: access, credentials, files, machine time, a call, decisions still open on our side. Anything you need that is not on your list will be assumed not to exist. See section 5 for what we will and will not hand over. |
| 3 | What do we need from you to start? | Paperwork, identification, an invoice, a signed engagement and IP assignment, a deposit, a start date you can hold. Tell us what we must produce on our side so nothing stalls on day one. |
| 4 | What is your timetable? | Your dates, not ours. Tell us whether you accept the five days in section 6 and, if not, what you are committing to instead. Give a date per piece (B, C, D) and name the dependencies that could move them. A schedule we can check against is worth more to us than a fast one. |
| 5 | What is your payment schedule? | Total, currency, and how it splits. State what each payment is tied to — a date, or a deliverable we can verify. We prefer payment against demonstrated work over payment against elapsed time. Include any expenses you expect us to carry. |
| 6 | What discount do we get if you are late? | State it as a number: a percentage of the fee per day or per week past your own committed date in question 4, and the point at which we may end the engagement without further payment. We are not looking to penalise an honest overrun you flag early — tell us how you would handle that too. "None" is an acceptable answer; no answer is not. |
One standing condition on all six. Every milestone you invoice against must come with something we can independently verify without your help — a paper-trade log, a screenshot of the screen showing live data, a diff, a run we can reproduce. Please price and schedule on that basis.
↑ Go to Top
8 · How to respond
Send your answers to the six questions, in writing, to nick@levenstein.net. Please put "Kate Desk RFP" in the subject line. We are speaking to a small number of people and will come back to you either way.
This document is confidential and is provided to named recipients for the purpose of preparing a proposal. Please do not forward or republish it.
↑ Go to Top