KIP-91: Hire Green for Optimistic Oracle and V2 reviews

greenlucid · June 10, 2026, 4:39pm

KIP-91: Hire Green for Optimistic Oracle and V2 reviews

Summary

The DAO requests that the Cooperative hire Green as a full-time senior smart contract developer, on the Cooperative’s standard senior compensation terms. The role’s two initial responsibilities are:

Responsibility A — Kleros Optimistic Oracle: specify, implement, launch, and maintain a Kleros-native Optimistic Oracle built on Court V2, timed with the Kleros V2 launch, and coordinate the migration of the V2 apps onto it. Structured in two gated milestones, followed by ongoing development and maintenance.
Responsibility B — Kleros V2 review: continuous independent review and testing of the Kleros V2 contracts throughout the term.

As with any full-time role, more responsibilities may be added over time as needs arise. Progress is reported publicly each month either way.

Motivation

A. Optimistic oracle

Kleros currently relies on Reality.eth, a third-party contract maintained by one person as a side project, for optimistic resolution. This dependency has several problems:

The frontend is barely maintained, and question data depends on the subgraph: some data, like question creation timestamps, is not stored in the contract and can only be read through an indexer. When the subgraph fails, Kleros V1 evidence display breaks — and Kleros V2 data mappings will break the same way unless they also go through a subgraph. A native oracle exposes this data directly to disputes and data mappings.
Reality.eth’s evidence and dispute formats are not Kleros formats. Every integration needs proxy and adapter contracts, which have been a recurring source of bugs and complexity.
Reality.eth has no cross-chain support. Cross-chain is the most time-consuming part of the dependency: for each new chain, Kleros has to build, deploy, and operate its own proxies. In other words, the dependency gives no help exactly where the work is heaviest, so it offers little advantage over self-owned infrastructure. Kleros is also building its own bridge, Vea. It makes more sense to build an oracle that uses Vea directly than to keep maintaining Reality.eth proxies next to it.
Reality.eth includes a bond-doubling escalation mechanism. Kleros Court already provides appeals, so integrations carry this complexity without using it.

On top of that, most Kleros arbitrables (Curate, Proof of Humanity, Escrow) implement the same optimistic pattern internally — post, bond, challenge, escalate. The logic is duplicated at every layer: each application’s contracts, subgraphs, and frontends carry their own copy of the same flow, and each copy has to be developed, audited, indexed, and maintained separately. Kleros V2 already moved appeal handling out of arbitrables into a shared component; a shared optimistic oracle does the same for optimistic submission.

B. V2 review capacity

V2 development was recently postponed indefinitely after vulnerabilities and design disagreements. Adding developers does not speed things up, but adding reviewers makes it less likely that vulnerabilities slip through, and every vulnerability found late means more delay.

Specification

Request

The Cooperative hires Green as a full-time senior smart contract developer. The role starts with Responsibilities A and B below; as with other team members, more can be added over time by agreement with the Cooperative.

Responsibility A — Kleros Optimistic Oracle

The oracle uses Court V2 as its arbitrator, not Court V1. I will coordinate this development and the migration of all V2 apps onto the oracle.

Milestone 1: Specification (4 weeks)

A written specification covering:

Contract interfaces: home oracle, chain connector, arbitrable integration.
Ruling semantics, including whether and how partial or proportional rulings are supported — keeping the core protocol minimal while extensible.
The Vea integration model, produced in collaboration with the Vea team, documenting which interfaces are stable and which are in flux.
A migration path for each existing arbitrable: retire-and-redeploy, adapter, or stay on Reality.eth.
An inventory of what gets simpler: which contract, subgraph, and frontend components in existing arbitrables can be retired or simplified once they adopt the shared oracle.
Frontend and indexing data requirements, defined alongside the contracts.

Gate: technical review by Cooperative reviewers. The Cooperative owns the specification regardless of outcome.

Milestone 2: Implementation (12 weeks)

Home oracle contracts integrated with Kleros V2 Court; a first chain connector via Vea (Arbitrum as initial target); a reference frontend covering the full loop (post question, propose answer, challenge, view dispute in Court); developer documentation as described under Agent readiness below.

Gate: testnet deployment and demonstration. Acceptance test: integrating with the Kleros Oracle must take fewer steps and less custom code than the equivalent Reality.eth integration.

Timing and termination

Milestone durations count only the weeks spent on oracle work. Weeks spent on V2 review (Responsibility B) or other work assigned by the Cooperative push the active milestone’s deadline back by the same amount; the split is recorded in the monthly reports.

If a milestone misses its adjusted deadline or fails its gate review, the role is terminated.

Post-launch development and maintenance

After Milestone 2, work continues for the rest of the term without milestone gates:

Production launch, once Kleros V2 launches (and the audit and Vea are ready). Frontend, UX, and integration work continue in the meantime, so the oracle is ready to launch alongside V2.
Notification and backend services, exposed both through the oracle frontend and as part of the documented API.
Frontend and developer-experience iteration based on integrator feedback.
Coordinating the step-by-step migration of all V2 apps (contracts and frontends) onto the shared oracle, retiring the duplicated optimistic logic and the Reality.eth adapter layer.
Ongoing maintenance: adapting to Vea and V2 changes, fixes, and operational support.

Dependencies: multichain support depends on Vea being ready. Work targets whatever Vea and V2 standards are current at each stage.

Agent readiness

The oracle is designed to be directly usable by AI agents, both as integrators and as participants (posting questions, proposing answers, monitoring and challenging).

Responsibility B — Kleros V2 review

Independent review and testing of the Kleros V2 contracts throughout the term — an extra set of eyes alongside the existing V2 developers. This runs in parallel with Responsibility A for the whole role and has no milestone gates. Findings go into the monthly reports.

Other Responsibilities

When there is capacity left beyond Responsibilities A and B, work defaults to the core of the protocol:

Development and maintenance of a secure Arbitrator that uses PNK.
Notifications and user experience for jurors.
Documentation and ease of integration — off-chain, on-chain, and across chains.
Wrappers and abstractions that serve the above.

This is a default, not a limit: other responsibilities can be agreed with the Cooperative, as stated in the Request.

Compensation

Standard Cooperative terms for a senior developer: total compensation in the $90k–$120k annual range, including the Cooperative’s usual vested component.

Reporting

The hire is made on the DAO’s recommendation, so the role answers to both the Cooperative and the DAO. Concretely:

Monthly public progress reports on the forum: shipped work, V2 review findings, time split between Responsibilities A and B (and anything added later), and blockers.
Each milestone gate decision (pass/fail, with the reasons) is published.
Reporting continues for as long as the role exists, including for responsibilities added after this proposal.

Rationale

Why a full-time role and not a fixed-scope contract. Much of the work is ongoing rather than one-off:

An oracle in production needs maintenance: keeping notification and backend services running, fixing bugs, and adapting to Vea and V2 as they change. Reality.eth’s problems come from being maintained as a side project; the replacement should not repeat that support model.
Integration quality comes from iterating after the first release: improving user experience, developer experience, and documentation.
The V2 apps migrate to the shared interface step by step, as each application’s situation allows — I will coordinate that across teams.
V2 review only works if it is continuous through the development cycle.

Consolidation. One audited optimistic component replaces the per-arbitrable implementations and the Reality.eth adapter layer across contracts, subgraphs, and frontends. That means less to audit and maintain — and the effort now spent re-implementing the same flow in every application goes to user experience, developer experience, and the applications themselves instead.

Why pair the two responsibilities. Both need the same profile (Solidity, deep knowledge of the Kleros contracts), and the oracle plugs directly into the V2 Court, so oracle work and V2 review feed each other.

The deadline-extension rule in Timing and termination keeps the milestone commitments real while letting review take priority when needed.

Candidate

Green, the author of this proposal — 3 years at the Kleros Cooperative as a full-stack developer. Independent deliveries for Kleros: PGTCR.sol and the Vea validator (Rust).

Vote

For: The DAO requests the Cooperative to make this hire.
Against: No request is made.

clesaege · June 10, 2026, 7:45pm

I would oppose this proposal for many reasons (while still thinking there could be some collaboration with Green):

Relation KIP-88

First about the relation to KIP-88.

Here hiring someone in particular doesn’t fit into “large cooperative orientation”.
The spirit of KIP-88 is to let the DAO give the big orientations, not for the DAO to micro-manage the cooperative. The relation between the DAO and coop should be that of a client to a service worker. The clients doesn’t tell the service worker whom to hire.
We should be careful not to overshoot and go from “the DAO has almost no input on the project” to “the DAO micromanages everything”.

Opportunity of hiring

Due to the current market condition, the cooperative is reducing costs. It would be weird to remove workers and then rehire someone at the same position at a higher price/productivity ratio.

Risks of politics

Positions, and particularly technical ones, should be attributed according to needs and skills. Not according to DAO politics. Otherwise, we run the risk of wasting funds in workers which are good at politics, but not good technically (technical skills, is hard for the DAO to evaluate).
Here Green already applied to the coop (despite no position being opened). If we were to add such position, it should be a competitive position, not granted without alternative by the DAO.

On the individual

Green has been a long time supporter of Kleros and has been a developer contractor before. He was an OK dev, not very good, not very bad, just OK. If he gets something he is motivated about he can be productive. But he can also be stuck and demotivated, such that he is improductive (cf stake curate).

Green is someone who really responds to economic incentives. I would not be having him on a fixed compensation as it would lead to poor incentives and poor productivity. For example, we had to warn him before due to performances while at the same time he was taking other engagements instead of focusing on his work for the coop.

If it were to be an engagement paid by results, I would be more inclined to consider it.

On the price

This seems to be way above his average productivity (albeit not his peak). I think on a well defined engagement with clear success metrics, he could have this type of productivity. But on a fixed compensation, productivity would be more in the 60-80k$ total comp range

On the responsabilities

Good idea.

At this point, it may be a bit premature (not by much, but maybe just by something like 3 months) as V2 contracts are still immature. Moreover it is not even clear if those will reach a point of maturity such that we can have high TVS (total value secured) apps on top, or if V2 will serve similarly to V0 as mainly a prototype for a final version we would have the merge with (V3).
The strategy about this should be informed by the results of further security procedures (for now it is immature to consider a launch with high TVS, but if after some modifications the next security procedures show no serious issues, it could be fine. Note that this point is only for high TVS apps. Low TVS apps will be able to use V2 no matter what similar to the Gnosis court.).

I would support Green being one assign an audit with result based compensation. No need of DAO vote for that.

greenlucid · June 10, 2026, 9:23pm

In this case, DAO politics is token holders. Why would they not be qualified to make this decision, more than the final deciders in the Coop? It’s been a contested topic these weeks that Coop leadership needs to be counterbalanced by the DAO, why is this something that Coop leadership gets an exemption on?

Would you be more prone to agree, if a futarchy market determined that me getting hired on these terms would be better for PNK price, instead of plurality token voting?

I agree positions need to be attributed to needs and skills, but the creation of this proposal is precisely due to leadership disagreeing of what the needs are, and the skills of people are. I don’t agree with your opinion on my skills or productivity.

I am the only party championing for this Optimistic Oracle, or ideating it, explaining why it’s needed. It makes sense that I’m the most qualified person to build it as well. I already know how to build it, what to build. And it is an urgent effort.
I have advocated for this for a year, and talked to multiple team members about it, most (actually all?) of them agree this should be built. Since there’s not been any update on this for so long, and given the urgency, makes sense to force push it.
Given experiences with the Coop, I am not sure that if there was a competitive position, I would be given a fair chance. Also, the hiring process is not transparent. In my case, I was hinted a position would be open, and then ghosted.

On my productivity

I don’t think you have a good assessment of what my productivity is, because as a developer I was allocated mostly to supportive roles (user support, Court/Curate maintenance, reward distribution, integrating with other projects).

Whereas you’re biased on appraising the value of a developer based on the amount of products that have been shipped.

On the projects I took ownership over, and championed: Slot Curate (a version of Curate with 3x gas savings I designed while I was an Intern, which failed), and Stake Curate (a version of Curate that allows for indefinite, capital efficient item collateralization, which was cancelled after ~3 months of truly continuous development).

Note: In hindsight, Slot Curate was a bad idea, and the cancelled version of Stake Curate was overengineered. This is something I have no issue admitting, and having time off it allowed me to figure out a better design. And I was able to, very quickly, build a Permanently Collateralized version of Curate thanks to the learnings, so the time was not wasted.

But in this case, you’re comparing me to developers that came before me, that did not have to carry and maintain technical debt, and at the same time, I’m judged on my ability to deploy applications. Why are you comparing my productivity to bootstrapping, if I was mainly used by the Cooperative as a maintainer, and FSE? I’m not disclosing these FSE activities I did during my stay, since I don’t know what should be public or what should stay private, but tl;dr I was assigned to try to integrate multiple projects that failed.

There’s a world in which I did not maintain Curate, which became the most active Kleros Arbitrable, and it would’ve probably be a defunct application, why not judge the work of a maintainer similar in merit as the work of the creator of the application?

Also, you’re comparing “2023 Green” with your current AI tool powered developers, which is another unfair comparison.

During past 1.5 month, I’ve (essentially solo) built, designed, deployed a prediction market tournament application that got +130 users registered so far. Of course, this is with AI tools aiding development, which really speeds up the iterative process.

I would be interested in seeing the appraisal of my productivity by other devs that have worked with me, or know about my work.

There are terms that terminate the role if I don’t meet milestones, so there are already economic incentives.

And developing, designing and maintaining an entire product (which shouldn’t take more than a year) for 90k$ - 120k$ is not a bad deal considering what the Coop is paying for other products, which sometimes need multiple staff + incentives, which are not being requested here. More defensible if the product is Core functionality, which would multiply the usability of all other products.

Everyone reacts well to economic incentives. If there were more penalties for improductivity and bonuses for productivity within the Cooperative, you will see that’s not a special trait I possess.

I don’t agree, there’s a lot that needs to be done here. UX/DX, Vea integration, notifications, etc. Kleros V2 frontend and services have been live for a long time, but this would have to be done by scratch. In fact it may already be late, which adds to my point on the urgency of this.