This file assembles founder histories, research connections, and role descriptions. Those records provide a picture of capabilities, even where names remain undisclosed.
Hear the Simplex reference ↗PEOPLE & CONNECTIONS
Before the product,
the people.
Follow the founders, the research, and the public records behind the ambition.
Meet the foundersOpen the investigation brief
THE INVESTIGATION / READ THE CASE BEFORE THE EXHIBITS
Does the visible team support the scale of the ambition?
The mix suggests a project spanning cryptography and GPU systems. Professional overlap can also arise through ordinary academic and industry networks.
An impressive background is evidence of experience, not proof of execution, customer adoption, or the identity of an unnamed contributor.
Public team disclosures and attributable technical contributions could resolve identities; deployed systems and documented adoption would test execution.
Historical September briefing; new research sections below identify their sources and observation dates.
Inspect the original exhibits ↓THE EXHIBITS / SOURCES, QUOTES & EDITORIAL READS
How this identity file began
0
Names in the original site review
The starting point of this investigation.
≠
~20
Profiles in the archived research
Public GitHub history and published papers.
The founders
The supplied recordings and public research records supply different kinds of evidence. Founder-role attribution comes from the archive; professional and academic history requires its own sources.
Founder · CEO
Omri Weinstein
Algorithms & computational efficiency
Princeton-trained computer scientist, Hebrew University associate professor, and former Columbia faculty member. His work connects information theory, data structures and optimization. Explore Omri’s research and industry record ↘
Founder · Co-founder
Ilan Komargodski
Cryptography & proof-of-work research
Hebrew University associate professor whose work spans cryptographic proofs, private computation and distributed agreement. Weizmann PhD; former Cornell Tech postdoc; joined NTT Research in 2019. Explore Ilan’s research record ↘
Founder · Co-founder
Idan Sugarman
Venture capital & company building
Public records connect his background to Zero Knowledge Ventures and AI startup QuantHealth. The September AMA supplies the Pearl co-founder attribution. Explore Idan’s professional record ↘
FOUNDER ROLES ON TAPE / COMMUNITY-IDENTIFIED (SEP 15 AMA). OUTSIDE RÉSUMÉS FROM PUBLIC PROFILES. ALSO ON THE RESEARCH BENCH: RAFAEL PASS (CORNELL; CO-CREATOR OF THE SIMPLEX CONSENSUS PROTOCOL) — NAMED BY THE TEAM AS "ONE OF OUR RESEARCHERS."
Fifteen résumés, no names attached
These archived profiles show the range of contributions, with names withheld. Roles and backgrounds are inferred from public records; the cards are not a verified staff directory.
Protocol Engineer
Prior: core contributor, major L1 blockchain
Owns the Go node / consensus layer, and is listed in the archived release-review configuration.
Public activity observed by Apr 2026
ZK / Cryptography Engineer
Prior: Hebrew University; open-source ZK proving contributor
Owns the zero-knowledge proving stack — the math that makes it trustless.
Public activity observed by May 2026
GPU Kernel Engineer
Prior: joint industry-academic PhD, ML systems
The reference implementation behind Hawkeye — a GPU-arithmetic research project — lives in a personal repo under this same work email.
Public activity observed by Feb 2026
Mining Systems Engineer
Prior: Hebrew University PhD, medical-AI research background
Added themself as codeowner in their very first commit — a public review-ownership record, not proof of seniority.
Public activity observed by Apr 2026
Cryptography Engineer
Prior: cryptography PhD, Paris
The bench runs deep on ZK math — not a one-person job.
On the bench
Infra & DevOps
Prior: —
Default owner across nearly the entire repo — reviews almost everything that ships. The archive also associates this contributor with release review. First commit: literally "Initial Pearl implementation."
Public activity observed by Mar 2026
Infra / CI Engineer
Prior: Technion-trained, compiler background
Builds the tools that build the chain.
On the bench
Desktop Client Engineer
Prior: —
Ships the actual UI, and is associated with release review in the archive.
Public activity observed by May 2026
Wallet Engineer
Prior: ran a bot/automation startup before this
Owns the money-facing surface, and is associated with review of that surface in the archive.
On the bench
Desktop Engineer
Prior: long-tenured open-source contributor
Committing to public repos years before Pearl existed.
On the bench
CUDA Kernel Engineer
Prior: —
Low-level GPU kernel work — the unglamorous, load-bearing engineering the verification scheme actually runs on.
On the bench
CUDA Kernel Engineer
Prior: —
A second kernel engineer on the same effort — this is a two-person specialty, not a one-person job.
On the bench
ML Engineer
Prior: computer vision & edge-AI background
Pointed a very different skill set at mining.
On the bench
Inference Optimization Engineer
Prior: ex-Tel Aviv University
Makes inference fast — the day job, now pointed at Pearl.
On the bench
ML / Research
Prior: —
Surfaced only through org-membership records — exact role isn't disclosed anywhere public. We're not going to guess at one.
On the bench
◉ Pattern — review ownership is a clue
●
●
●
●
The archive records review ownership across several code areas. CODEOWNERS can help route reviews; it does not disclose every administrator, signing key, release permission or network operator. This is a contribution map, not a complete map of authority. What CODEOWNERS establishes ↗
Feb 2026
1
Mar 2026
1
Apr 2026
2
May 2026
2
ARCHIVED PUBLIC-ACTIVITY DATES FOR SIX CONTRIBUTOR PROFILES — THE REST AREN'T DATED IN PUBLIC RECORDS. FIRST COMMIT ON THE BENCH: FEB 2026.
COMPILED FROM PUBLIC RECORDS — PUBLIC GITHUB COMMIT HISTORY AND PUBLISHED ARXIV PAPERS. ROLE AND TENURE INFERENCES ARE NOT EMPLOYMENT VERIFICATION; ATTRIBUTION TO SPECIFIC PEOPLE IS INTENTIONALLY NOT PUBLISHED.
The shape of the team — no names required
Public code and papers show areas of contribution and research overlap. Shared handles and metadata do not establish a complete organization chart or an employee headcount. Read the archived diagram as an editorial map of observed connections.
▬▬ Duplex identity (email / handle)
▬ co-founder
▬ Hawkeye paper
▬ crypto co-author
▬ shared code area
dashed box = candidate / external
ROLES ONLY, NO NAMES. EVERY GROUPING AND EVERY LINK IS DERIVED FROM PUBLIC GITHUB CODEOWNERS, COMMIT METADATA, HUGGINGFACE MEMBERSHIP, AND PUBLISHED PAPER AUTHORSHIP.
FOUNDER DOSSIER / OMRI WEINSTEIN
Before Pearl,
the cost of computation.
His record spans the mathematics of computational limits and the engineering of faster AI. That combination deserves more than a one-line biography.
Public-source review / 26 September 2026Princeton. Courant.
Columbia. Jerusalem.
Weinstein completed his Princeton PhD in 2015 under Mark Braverman, after a mathematics and computer-science degree at Tel Aviv University. The Simons Foundation records his 2015 Junior Fellowship at NYU and subsequent move to Columbia.
Columbia introduced him as a new faculty member in 2017. His Hebrew University page now identifies him as an associate professor, on leave from Columbia.
Simons fellowship biography ↗Columbia’s 2017 profile ↗Hebrew University biography ↗Research with
institutional backing.
Columbia’s NSF CAREER announcement describes his work on information theory and data structures as a foundation for scaling digital storage. His university biography also lists the Samson Prime-Minister Award for Innovation.
The Simons Foundation records a 2015 Siebel Scholarship and two Simons graduate awards. These are documented research distinctions, separate from Pearl’s commercial progress.
Columbia’s CAREER announcement ↗University awards record ↗From theory
to AI infrastructure.
His university industry page, last updated in November 2021, describes collaboration with Deci.AI on “Neural Data Structures”: bringing data-structure techniques into neural networks to accelerate matrix multiplication with little accuracy loss.
His CfC St. Moritz speaker biography lists previous roles as Chief Scientist at VAST Data and Senior Research Scientist at NVIDIA (previously Deci.AI). Those titles are attributed to the event biography; it does not provide employment dates.
His account of the Deci work ↗Industry-role biography ↗The research
behind the résumé.
Faster Dynamic Matrix Inverse for Faster LPs, with Jiang, Song and Zhang, studies faster maintenance of matrix inverses under low-rank updates for linear-programming solvers.
His university publication record also lists A Framework for Building Data Structures from Communication Protocols at STOC 2025 and work on discrepancy minimization at ICML 2025.
Matrix-inverse research ↗University publication catalog ↗FOUNDER DOSSIER / ILAN KOMARGODSKI
Who checks
the computation?
A research career in proving, protecting and coordinating computation—years before Pearl.
Public-source review / 26 September 2026Weizmann to Cornell.
Then Jerusalem.
Komargodski is an associate professor at Hebrew University. He studied for his master’s with Ran Raz and his PhD with Moni Naor at Weizmann, then worked at Cornell Tech with Rafael Pass and Elaine Shi.
NTT Research dates his doctorate to 2017 and his arrival at its Cryptography & Information Security Lab to 2019.
University biography ↗NTT’s research interview ↗Outsource the work.
Check the answer.
In his NTT interview, Ilan explains a motivation behind SPARKs: a limited device delegates computation to a cloud service but still needs assurance that the result is correct.
The paper, with Naomi Ephraim, Cody Freitag and Rafael Pass, appeared at EUROCRYPT 2020 and later in the Journal of the ACM. It is an earlier research connection to verifiable computation, not a claim that Pearl deploys SPARKs.
Read the SPARKs paper ↗Privacy, with
an efficiency problem.
FutORAMa: A Concretely Efficient Hierarchical Oblivious RAM, co-authored with Gilad Asharov and Yehuda Michelson, received a Distinguished Paper Award at ACM CCS 2023.
His publication record also spans memory checking, hashing, time-lock puzzles and distributed agreement.
ACM’s award record ↗The research
keeps moving.
The university catalog lists Sub-linear Secure Broadcast and Applications, with Yuval Gelles and Merav Parter, at STOC 2026, and Improved Rate for Non-Malleable Codes and Time-Lock Puzzles at ITCS 2026.
These give readers a wider view of his active research beyond the Pearl-related papers.
Explore the publication catalog ↗FOUNDER DOSSIER / IDAN SUGARMAN
From building companies
to backing founders.
The public trail leads through AI entrepreneurship and early-stage investing.
Public-source review / 26 September 2026Zero Knowledge.
A public role before Pearl.
BNB Chain’s report on its July 2024 Brussels Incubation Alliance names Sugarman as a judge and a general partner at Zero Knowledge Ventures.
In a separate launch post, venture partner Yoav Vilner credits Sugarman and Nicky Montana with launching the pre-seed fund. This establishes a public startup-investing history before the September AMA.
BNB’s organizer report ↗Venture partner’s launch account ↗QuantHealth.
An earlier venture.
IVC Data & Insights lists Sugarman as a QuantHealth co-founder. Its company profile describes an AI business focused on simulating clinical trials.
This part of the biography rests on an attributed industry-directory record. We have not established his precise tenure or current operating role from a company-authored biography.
IVC’s company and founder record ↗PUBLIC RECORDS / FOLLOW THE AUTHORS
Ideas have a history.
So do collaborations.
Research edition / 22 September 2026
Moni Naor → Ilan Komargodski
Ilan’s university biography names his doctoral advisor.
University biography ↗Rafael Pass & Elaine Shi
The same biography records Ilan’s Cornell Tech hosts. This link predates the current product story.
Read the academic history ↗Yogev Bar-On joins the trail.
A paper connects Bar-On with Ilan and Omri. A sourced relationship, with a precise label.
Inspect the author list ↗Academic relationships do not establish employment, investment or deployment. Read the collaboration story ↗
THE COMPUTE MARKET / FOLLOW THE PAYMENT
If PRL buys compute,
how does the payment move?
Research reviewed 23 September 2026 · L2 clarification added 25 September
The Simplex clue begins with a customer buying inference.
Pearl’s earlier AMA describes a flywheel: computation earns PRL, then PRL pays for inference. In September, a question about throughput on L1 or L2 leads to an answer about researching approaches beyond L1—and a reference to Rafael Pass’s Simplex work. Read together, the two passages open a payment-infrastructure story.
01 / THE FIRST DIRECTIONCompute→PRL
The mining side of the story.
02 / THE STATED AMBITIONPRL→Compute
The customer side still being investigated.
From compute to PRL.
Then back to compute.
The team describes an inference service that would accept PRL. That makes payment part of the market’s ambition, rather than only a way to acquire the token.
Hear the compute flywheel ↗Read the full setup · 10:29–13:15 ↗Does every payment
belong on L1?
The answer prioritizes decentralization and security on L1, then discusses L2 approaches with different trust assumptions, ongoing research and invitations for designs. Pass’s consensus expertise appears in that same answer.
Hear the extended answer · 19:35–22:03 ↗Hear the Simplex excerpt ↗The short Simplex clip starts near the end of the answer; the full passage supplies the L1/L2 context. These are supplied automatic transcripts, not a newly audited transcription. The answer discusses possible approaches, without selecting a Pearl payment architecture.
The connection worth investigating
Benjamin Y. Chan and Rafael Pass co-authored Simplex Consensus. Its job is to help participants agree on an ordered history. For a payment system, that concerns which transfers have been accepted and in what order. It does not itself define the currency, the market or an L2.
THE RESEARCH ROOT
Benjamin Chan + Rafael Pass
↓Simplex
One research origin. Distinct implementation paths.Tempo, via Commonware
Tempo’s repository identifies Simplex through Commonware as part of its payment-focused architecture. This is the most direct comparison here between consensus research and payment infrastructure.
Tempo’s architecture ↗Solana’s Alpenglow / Votor
The Simplex project identifies Votor as a heavily modified descendant. Anza describes voting paths that finalize in one or two rounds depending on responsive stake. That is a real research connection, with a distinct protocol design.
Simplex’s lineage map ↗Ava Labs
Ava Labs publishes a Go implementation of Simplex. It adds another concrete codebase to explore; the repository alone does not establish Avalanche mainnet adoption.
Inspect the implementation ↗These are connections to the research, not announced Pearl integrations. The Alpenglow comparison describes design lineage; this review does not establish Solana mainnet activation or claim that Solana runs unmodified Simplex.
A payment can be smaller than a chain transaction
There is a second useful clue outside Pearl. The Machine Payments Protocol’s sessions description separates usage metering from a separate payment for every request. A client authorizes spending and increases that authorization as a service is consumed. Tempo’s current wallet CLI exposes reusable payment channels alongside one-time charges.
Our inference: a future PRL inference market could explore this kind of separation: frequent usage updates, with a different cadence for settlement. This is a design comparison, not evidence that Pearl has adopted Tempo, MPP, channels or Simplex for payments.
- 01 / CUSTOMERAuthorize PRL spending
A buyer funds a request or a session under a defined budget.
- 02 / INFERENCE SERVICEDeliver and meter compute
Usage could be recorded per request or incrementally.
- 03 / PAYMENT SYSTEMAgree and settle
L1, a separate layer, or channels would impose different costs and trust assumptions.
Where could Simplex fit? In the agreement mechanism of a possible separate payment system. How it connects to PRL and L1 remains the design question.
FROM PRL TO COMPUTE / OPEN THE JOURNEY
What would buying an answer look like?
A developer arrives with a question, a model in mind and a spending limit. The ambition on tape is to pay for inference with PRL. The interesting part is how that becomes an ordinary action. Follow the proposed experience below; each step opens the design question behind it.
EDITORIAL SCENARIO · NOT A LIVE PRODUCT OR AN ANNOUNCED ARCHITECTURE
01Bring a balanceWhat does the buyer control?
The buyer would need PRL available to the service. A wallet balance, a prepaid account and funds committed to a separate payment system are different ways of getting there.
The evidence to look for: a documented funding route, who holds the funds, and how an unused balance can be recovered.
Start with the May payment ambition ↗02Choose compute. Set a limit.What exactly is being bought?
A usable service needs a model, a price and a budget. A quote could be denominated directly in PRL or translated from another unit; the archived ambition does not settle that choice.
The evidence to look for: a published pricing rule, an example request and an explanation of what happens when the budget runs out.
03Receive the answerWhen does usage become a charge?
As the service generates output, it must account for usage. Charging each request, deducting from prepaid credit and authorizing a session would create different customer experiences.
The evidence to look for: a receipt connecting delivered inference to the amount charged, plus a rule for interrupted or failed requests.
04Settle. Keep the remainder.Where could consensus enter?
A payment system needs an agreed record of balances and transfers. Simplex could be relevant to that agreement in a separately designed system. It does not supply a PRL bridge, a withdrawal mechanism or a billing policy by itself.
The evidence to look for: the settlement route, participant and trust assumptions, and a demonstrated exit. The September answer opens this research direction without choosing the design.
Read the full throughput answer ↗
The bullish possibility
PRL becomes something a customer spends to get a useful answer. If an operator makes that experience simple and competitive, the compute market gains a reason for people to return beyond watching the token.
The alternative worth keeping in view
The service could begin with ordinary prepaid accounting, or payment research could take longer than inference integration. More providers and faster consensus research would not, on their own, demonstrate PRL checkout.
The exhibit that would change this file
A reproducible demo: fund a budget with PRL, request inference, inspect the charge, and recover what remains. That would connect the two AMA passages through an actual customer experience.
Scenario developed 24 September 2026 from the linked AMA archive. The Simplex project’s implementation map, rechecked on that date, provides research context; it does not announce a Pearl payment deployment.
The exciting part is the missing middle.
The archive gives us a destination—PRL spent on compute—and a scaling discussion that explicitly reaches beyond L1. Simplex’s path into payment-oriented engineering makes that combination worth following. It suggests a plausible research direction for the inference market, without turning the AMA into a product announcement.
What would turn this possibility into an architecture?
- Payment unit: one transaction per request, prepaid balances, or sessions?
- Agreement and security: who participates, who can censor, and what happens during failures?
- PRL settlement: how do funds move, and how can a customer exit or recover a balance?
- Service accounting: how are delivered inference, disputed usage and refunds handled?
- Working evidence: a specification, public code and a reproducible payment-to-inference demo.
Fast finality is time to settlement; throughput is capacity. Neither alone proves a usable compute market. Wallets, pricing, provider acceptance and failure handling complete the experience.
Start with the market ambition ↗ · Then read the scaling answer ↗