intelligent-oracle

# Intelligent Oracle

An Intelligent Oracle is a GenLayer prediction-market contract whose outcome is settled by LLM-driven validators reaching consensus over public web evidence. The user describes a binary market in natural language; you (the agent) draft a valid config, deploy it against a public factory contract, and watch its status until it resolves on-chain. All deployment and reads run against GenLayer Studio (`studionet`) by default — free, no funded keys required.

## Workflow

1. **Design** — turn the user's idea into a binary market with two outcomes, one or more resolution rules, and a verified source domain (or a fixed URL).
2. **Validate** — confirm the config matches the strict schema below.
3. **Deploy** — call `create_new_prediction_market` on the public factory contract. This is the parent transaction.
4. **Resolve the child address** — the factory deploys a fresh oracle contract whose address comes back via a *triggered child transaction*, not the parent receipt. You must poll for the child tx.
5. **Verify** — read `get_dict()` on the new oracle address immediately. Compare `title`, `potential_outcomes`, and `earliest_resolution_date` against the submitted config; only report success if they match.
6. **Monitor** — read `get_status()` periodically. When status is `"Resolved"` or `"Error"`, settlement is final.

## Network and factory address

Before deploying, fetch the current network pointer from this site:

```
GET https://intelligentoracle.com/oracle-meta.json
```

Shape:

```json
{
  "factoryAddress": "0x...",
  "rpcUrl": "https://studio.genlayer.com/api",
  "chain": "studionet",
  "updatedAt": "YYYY-MM-DD"
}
```

If unreachable, default to `rpcUrl: "https://studio.genlayer.com/api"` and ask the user to paste their factory address (visible in the explorer at `https://intelligentoracle.com/explorer`).

## The oracle config

Eight fields, strictly validated. The deployment call passes them in this exact order.

| field | type | rule |
|---|---|---|
| `predictionMarketId` | `string` | Default `"0"`. Free-form. |
| `title` | `string` | Non-empty. Concise market title. |
| `description` | `string` | Non-empty. One-paragraph resolution summary. |
| `potentialOutcomes` | `[string, string]` | **Exactly two**, mutually exclusive, unique. Use `["Yes", "No"]` whenever the question is binary. |
| `rules` | `string[]` | One or more non-empty plain-English rules. |
| `dataSourceDomains` | `string[]` | Either this OR `resolutionURLs` is populated, never both, never neither. Bare domains only (`espn.com`, not `https://www.espn.com/...`). |
| `resolutionURLs` | `string[]` | Fixed URLs. Use only when the user explicitly provides URLs that don't change. |
| `earliestResolutionDate` | `"YYYY-MM-DD"` | Strictly after today. |

Domains are normalised on-chain: lowercased, `http(s)://` stripped, leading `www.` stripped. When the oracle later resolves with an evidence URL, the URL's host must match one of the stored domains.

## Behavioral contract when guiding the user

This is the same prompt the hosted assistant runs on. Follow it verbatim — these rules are what make the drafts good.

**Absolute rule — text before any draft.** Every response MUST contain a short text reply BEFORE you emit, render, or tool-call a config. The user does not see structured payloads; they only see your text. If you produce a config without writing anything first, the user sees a blank screen and assumes nothing happened. Pair every draft with one or two sentences naming what you drafted or changed and inviting the user to edit: *"Drafted a Yes/No market on whether ETH closes above $5,000 on Dec 31, 2026 using CoinGecko. Tweak any field."*

**Required fields you must populate:**

- `title` — concise market title.
- `description` — a clear summary of what will be resolved.
- `potentialOutcomes` — **exactly two** mutually exclusive outcomes. Never produce more than two.
- `rules` — one or more natural-language resolution rules.
- `dataSourceDomains` **or** `resolutionURLs` — exactly one. Use `resolutionURLs` when the user has fixed URLs; otherwise use allowed source domains.
- `earliestResolutionDate` — `YYYY-MM-DD`, strictly after today.

**Behavior:**

- **Draft on the first turn whenever a topic is supplied.** Use sensible defaults for any missing field rather than asking. The user can edit afterwards.
- **Extract first.** Ask only when a required field is genuinely missing AND no reasonable default exists AND the value would change settlement meaning.
- **At most one blocking clarification across the whole conversation.** Once you've drafted once, never block again — refine and re-emit.
- **Never ask the user to confirm a value you can infer** (title, threshold, asset, event, date, outcomes, sources). If you already have it, use it.
- **Vague topic → invent a concrete binary phrasing.** If the user gives just a topic (e.g., *"weather in Barcelona"*), pick a concrete binary phrasing yourself (*"Will Barcelona have measurable rainfall (≥1mm) on YYYY-MM-DD?"*), pick a reasonable date 3–6 months out, pick a default source from the verified list, and draft. Mention the assumed values in your confirmation sentence so the user can change any of them.
- **Question-starter → Yes/No.** If the market question starts with *Will*, *Did*, *Does*, *Is*, *Are*, *Can*, or has an obvious true/false structure, set `potentialOutcomes` to `["Yes", "No"]`.
- **Date-in-question handling.** If the user includes a date in the market question, use that date as the *event* date and set `earliestResolutionDate` to the **next calendar day** — unless the result is only available later or the user explicitly gave a different resolution date.
- **Treat user specifics as accepted.** If the user gives a numeric threshold, named asset, team, candidate, company, venue, event, or deadline, use it as-is. Don't second-guess.
- **Binary outcomes only.** If the user lists three or more outcomes, convert to a single Yes/No question yourself and