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

Proposal
1

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.

A lucid observation of Kleros and the path to follow
2

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.

1 Like
3

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.

  1. 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.
  2. 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.
  3. 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.

4

Agreed that this seems premature.

I am not sold on Optimistic Oracles in general, and making it chain native further increases my skepticism for how this will properly engineered architecturally.

5

How do you plan on using it for tasks such as resolving Prediction Markets, without it being chain native?

6

I don’t know the details of that. I meant that making it cross-chain increases the complexity, which increases my skepticism for this project. You are probably correct on the necessity of it.

7

I think that hiring process should NOT be performed by the DAO. What DAO should be doing, imo, is to provide objectives or milestones to the cooperative.

I agree that Reality should be “nationalized” and maintained by Kleros. And some modifications and simplifications are needed on those smart contracts to improve UX.
With respect to the site, there is no need to ask permission to anybody, we can create a new frontend if that’s desired, using the same smart contracts that are already deployed (I remember some vibe-coded frontend made by Guagmian in that direction).

Also, I’m not very confident about migrating all the kleros-apps (curate, poh, escrow) to use the same subjective oracle.. those apps had different requirements and when you try to make a standard too generic you usually end up with a poor ux. It would be nice to work first on the specs and interfaces + have a very basic MVP before moving in that direction.

2 Likes
A lucid observation of Kleros and the path to follow
8

That would still entail using a difference standard for KlerosV2 disputes and Reality questions, which is one of the things to stop doing.

Summoning @jaybuidl on this since this complexity came up to be particularly difficult to integrate with the DataMappings. Also, a common standard allows us to use DisputeTemplate and DataMappings for the OO as well.

When you duplicate something like this, you end up with a custom implementation for contract, for subgraph, for frontend. When something is broken, you need to debug in multiple places. Or you need to setup notifications for each thing, etc. It doesn’t scale.

Instead, you can have one single understanding of how the Optimistic Oracle works, in one place, everyone consumes it and it behaves predictably.

Optimistic Oracle can use a library, or whatever, for whenever the other interfaces want to display information related to it. Doesn’t need to redirect user to a OO frontend.

Would like to work on this, but it would have to be paid.

Would it be better to refactor this KIP into an open request to create a budget of 80k$, during a year, to be spent towards building the Optimistic Oracle, according to this specification? And then the Coop chooses if hiring, or repurposing current devs to do it internally.

But it would have to be done according to the specification, and there would be accountability to the DAO if the goals are not met during the timeframe.

9

100% agree.

Also the DAO should be careful on voting for things that are not enforceable by the DAO itself.

10

How much can be requested in KIPs? There appear to be a lot of surprising lines in what can be asked. At this point I’m going to have to ask “is it ok to ask?” every time?

Also the DAO should be careful on voting for things that are not enforceable by the DAO itself.

These requests were never going to be enforceable, the Coop is not legally obliged to follow them. What the Coop loses by ignoring them is legitimacy, and maybe future PNK grants.

Also, a KIP-88 request is by definition something the Coop wasn’t going to do by itself. If the Coop was already planning to do it, there would be no point in requesting it, because they would’ve already done it. So requests being uncomfortable to the Coop, or disrupting current plans, is expected, that’s the only case where the mechanism does anything.

Money and dev time are finite, so a request implies deprioritizing something else. So in anticipation of further nitpicks I may get with this request, and thinking about the scenario in which it passes and the Coop doesn’t do an earnest effort in fulfilling it, “we have other priorities” can’t count as an excuse either. If DAO and Coop are a client and service provider relationship, then it has to be a professional relationship and take accountability.

So, before rewriting this into an open request version for the Optimistic Oracle, I’d like to know what a KIP-88 request is allowed to contain, so we’re on the clear:

  • a deliverable (“build the Optimistic Oracle”)
  • a budget (“up to 80k$ over a year”), or is allocation only Coop discretion, and the DAO can only request outcomes?
  • deadlines and milestones
  • mandatory public progress reports, so “fulfilled vs not fulfilled” is decidable
11

That’s the major reason why I’ve oposed initially to the coop-dao pnk purchase. Because we don’t have a framework to make proposals in the DAO that can be somehow enforced (even light enforced as I will not grant you anymore in the future).

A Constitution is needed, a framework for proposal is needed (what a proposal must have in order to be approved, etc). KIP-90 goes in the right direction imo, the DAO should know where we are so we can propose changes for the future. But to propose changes, some framework should be created.

Maybe can be refactored to have a 1 time job to create the specs and check if it is feasible (1/2 months), and after that is approved, a longer term contract can be reviewed. I really think (in general terms, not just for this proposal) that Kleros should have some milestones where the decisions should be reviewed before keep moving forward. I think that we are slow killing projects that goes nowhere, then, wasting resources

2 Likes
12

No comment on the rest of the thread but agreed on this part. Many mentions in previous threads and now more relevant than ever to do it.

In a previous thread it was suggested that proposals could also go through the Kleros court with the constitution as the policy.

1 Like
13

that hiring process should NOT be performed by the DAO

Disagree

I’m broadly in favor of people proposing to be hired by the Cooperative (not as a rule, but as a possibility). It legitimizes contributors: today it’s quite opaque who is actually working and who isn’t, and if we can make it more transparent, that forces accountability while allowing expenses to be detailed far more precisely.

The spirit of KIP-88 is to let the DAO give the big orientations, not for the DAO to micro-manage the cooperative.

I’d also push back on the “micro-management” framing. Proposing a person to the Coop isn’t the DAO dictating internal staffing. It’s the DAO surfacing a candidate it finds valuable, which I think is a legitimate and useful input. Hiring someone isn’t “micro-managing” the Cooperative; it’s a structural decision, not a day-to-day operational one. Who joins the team shapes the direction of the work for months or years, which is exactly the kind of high-level orientation KIP-88 is meant to cover.

That said, if the concern is precisely the client/service-worker boundary, then a grant paid directly to the contributor (in ETH/USDC) seems more coherent IMO than a Coop hire. This could take the form of retro-funding for work already delivered, or an MVP-funded model where an initial milestone unlocks funding for the rest. That keeps the DAO out of the Coop’s internal management entirely, while still backing the work and tying payment to results.

1 Like