Background
Jamal Okafor grew up in Lagos and Houston and read computer science at the University of Waterloo, finishing an MEng in 2015 with a thesis on lock-free data structures for low-latency network packet processing. His first job out of school was at a fintech payments company in Toronto, where he spent four years on the team responsible for the cross-border settlement engine. The product was unglamorous but the constraints were instructive: every transaction had a hard SLA, every failure had an audit trail, and every deploy had to be reversible. He still cites that period as the most useful single stretch of his career.
In 2019 he joined a top-five crypto exchange as a senior engineer on the deposits and withdrawals team and was promoted to staff engineer in 2021. By 2023 he was the engineering lead on the on-chain settlement system — the part of the exchange that signs, broadcasts, and confirms every withdrawal, and the part where mistakes are extremely expensive. His team rebuilt the signing pipeline in 2023 and the result, by his account, was that the exchange’s mean time to confirmed withdrawal across the top five EVM networks dropped from minutes to seconds without any change in security posture. The work involved deep collaboration with the open-source EVM tooling community, and Jamal became a meaningful contributor to Ethers.js and to Foundry over that period. Both projects still show his commits.
He left the exchange in late 2025 to co-found Poly Syncer. The decision was, in his framing, the natural extension of work he had already been doing — building reliable execution paths over EVM networks — applied to a much more interesting market structure problem than the one centralized exchanges face.
What he works on at Poly Syncer
Jamal owns engineering for the Polymarket bot Poly Syncer ships: the listener, the execution engine, the RPC fleet, and the on-call rotation. The listener is the Rust service that watches the Polymarket order book and the relevant on-chain events for the wallets being copied. It runs on co-located infrastructure adjacent to the Polygon validator set Jamal selected for proximity, and it is the single most latency-sensitive piece of the stack. He owns it personally; the most recent rewrite, in Q1 2026, took mean signal-to-decision time from 240 milliseconds to under 90.
The execution engine is the part of the system that takes a signal and turns it into a signed, broadcast, confirmed mirror trade on the user’s wallet. It uses an EIP-712 message signed in the user’s browser, routes through a Flashbots-style private mempool to prevent front-running, and falls back to a redundant RPC vendor if the primary endpoint stalls. The MEV-protection design is documented in the whitepaper and in Jamal’s post on the MEV protection blog piece.
The RPC fleet is, in practice, the most operationally demanding piece of the system. Poly Syncer maintains relationships with three premium Polygon RPC vendors plus a self-hosted full node, with automatic failover and health-checking on every endpoint. Jamal also owns the public API, which exposes the leaderboard data and a subset of the wallet-tracking primitives to authenticated developers.
Perspective
Jamal’s engineering philosophy is shaped by a long stretch of working on systems where downtime is measured in lost dollars per second. He is a vocal opponent of architectural fashion in trading infrastructure.
“The right architecture for a low-latency execution path is the one you can fully reason about at three in the morning when something is wrong. That usually means fewer services, fewer queues, fewer abstractions, and a lot more discipline about state. Most of the production incidents I have seen in my career came from somebody’s clever distributed systems decision running into a reality the original author hadn’t anticipated. The boring architecture — one listener, one decision engine, one signed transaction path, three RPC endpoints — survives contact with reality.”
The same principle drives how he thinks about MEV protection. The Poly Syncer execution path is built around the assumption that any public broadcast on Polygon is observable by an adversary capable of running a sandwich attack, and the system therefore routes through a private bundle relay by default. The cost of being wrong about that assumption, in expected user dollars, is much higher than the engineering cost of running the relay. Jamal would rather pay the engineering cost.
On the topic of stablecoin payments, which is increasingly relevant as more of Poly Syncer’s users settle in USDC on Polygon, Jamal is generally optimistic that the rails are mature enough to be production infrastructure for retail trading. The remaining concerns, in his view, are fragmentation across L2s and the lack of cross-chain settlement guarantees that match what users have come to expect from centralized payment networks. He has written about both.
Recent writing
- Copy Trading vs Manual — A Real Cost Analysis
- Inside a Polymarket Bot: Architecture of Automated Polymarket Trading
- Polymarket Bot vs DIY Scripts: A Buyer's Guide for Copy Traders
- USDC on Polygon — A Payment Network Guide for Traders
- MEV Protection for Polymarket Copy Trading
- Poly Syncer public API documentation