Gougoubi Submit Real Results

intent

submit real-world outcomes to on-chain conditions by mapping external evidence (market resolutions, event data, condition skill payloads) to result votes. use this skill when you want to atomically resolve a proposal's conditions with deterministic proof, either submitting only officially resolved conditions, all conditions with clear outcomes, or forcing a fallback result for pending conditions. builds an auditable evidence-to-result chain and tracks submission success per condition.

inputs

proposal context

• proposalAddress (required, string): ethereum address of the proposal contract, checksummed format
• targetChain (optional, inferred): chain id or name; defaults to mainnet if unspecified

submission mode

• mode (required, enum): one of resolved-only, all, or force
  • resolved-only: submit only conditions with officially resolved evidence
  • all: submit all conditions that have clear final outcomes (resolved or deterministic)
  • force: use a single forced result for all pending/unresolved conditions
• forceResult (conditional, enum): required if mode=force; one of yes or no
• evidenceNote (optional, string): manual audit trail or override note; auto-generated from condition skill payloads if omitted

external connections

• gougoubi on-chain contract interface (read: enumerate conditions, fetch condition metadata, check existing results)
• condition skill payloads (read: extract evidence locators such as event slug, market id, or oracle identifier)
• public market data sources (read: polymarket, kalshi, or other specified resolution sources)
• wallet/signer (write: submit result votes; requires active ethers provider and signing capability)

environment

• GOUGOUBI_RPC_URL (optional): custom rpc endpoint; defaults to ethers defaults
• GOUGOUBI_SIGNER_KEY or externally managed signer (required for submission; skip if dry-run only)

procedure

step 1: validate proposal and chain state

• input: proposalAddress
• fetch proposal contract at address
• verify contract is gougoubi-compliant (abi check)
• confirm target chain connectivity and current block height
• output: validated proposal object, chain state, condition count

step 2: enumerate all conditions

• input: proposal address
• call on-chain method to list all condition indices and addresses
• fetch metadata for each condition (name, description, skills payload)
• output: array of condition objects with addresses, indices, and skill payloads

step 3: extract evidence locators from condition skills

• input: condition skill payloads (json)
• parse each payload to extract evidence references (event slug, market id, oracle address, etc.)
• validate that evidence locators are non-empty; log warning if missing
• output: evidence map, keyed by condition index

step 4: fetch and map public evidence to outcomes

• input: evidence map, mode
• for each condition:
  • if mode=resolved-only: query evidence sources (markets, events, oracles) and extract only officially resolved outcomes; skip conditions with pending status
  • if mode=all: query evidence sources and accept resolved or deterministic (e.g. expired date-based conditions) outcomes; skip only if outcome is truly ambiguous
  • if mode=force: treat all non-resolved conditions as eligible for forced result (forceResult parameter)
• build result map: condition index -> (result: 0/1/2, evidence source, confidence level)
• output: result map with source attribution

step 5: check on-chain result state and filter submission targets

• input: result map, condition addresses
• for each condition in result map:
  • call on-chain method to read current result value
  • if result != 0 (already submitted), add to skipped list with reason "already resolved"
  • if condition is locked or not ready for submission (e.g. voting window closed), add to skipped list with reason "not ready"
  • otherwise, add to submission queue
• output: filtered submission queue, skipped list

step 6: submit result votes

• input: submission queue
• for each queued condition:
  • build transaction: submit exactly one result vote (0, 1, or 2) with evidence note
  • if dry-run mode: log transaction and skip broadcast
  • if live mode: broadcast transaction and wait for confirmation (configurable: 1 block or n blocks)
  • capture tx hash and receipt status
  • on failure: log error, add to failed list, continue with next condition (do not halt)
• output: submitted array, failed array, tx hashes

step 7: aggregate and return results

• input: submitted list, skipped list, failed list, warnings
• count each category
• assemble output object per output contract below
• output: structured result object

decision points

• if mode is unspecified: default to resolved-only; do not infer all or force without explicit user request
• if mode=force but forceResult is missing: fail with error "forceResult required when mode=force"
• if evidence locator is missing or malformed: log warning, skip that condition, do not submit
• if condition already has result != 0: skip submission (never overwrite); log in skipped array
• if on-chain submission fails (tx reverts or timeout): add to failed array and include error detail; do not retry automatically unless user explicitly asks
• if network timeout or rate limit hit during evidence fetch: return retryable failure at "fetch-evidence" stage; preserve partial results
• if signer is unavailable: fail with error "signer required for live submission" and suggest dry-run mode
• if user requests dry-run mode (detected via flag or environment): skip all transaction broadcasts; log intended submissions and return success with dry-run flag in output

output contract

on success (ok=true):

{
  "ok": true,
  "proposalAddress": "0x...",
  "mode": "resolved-only|all|force",
  "submittedCount": <integer>,
  "skippedCount": <integer>,
  "failedCount": <integer>,
  "submitted": [
    {
      "index": <integer>,
      "conditionAddress": "0x...",
      "conditionName": "<string>",
      "result": <0|1|2>,
      "evidenceSource": "<string>",
      "txHash": "0x...",
      "blockConfirmed": <integer>
    }
  ],
  "skipped": [
    {
      "index": <integer>,
      "conditionAddress": "0x...",
      "reason": "already resolved|not ready|evidence missing|user skip"
    }
  ],
  "failed": [
    {
      "index": <integer>,
      "conditionAddress": "0x...",
      "error": "<string>",
      "txHash": "0x...|null"
    }
  ],
  "warnings": [
    "<string>"
  ]
}

on failure (ok=false):

{
  "ok": false,
  "stage": "validation|enumerate|evidence-fetch|evidence-map|state-check|submit|confirm",
  "error": "<human-readable error message>",
  "retryable": <true|false>,
  "proposalAddress": "0x...|null",
  "partialResults": {
    "submittedCount": <integer>,
    "skippedCount": <integer>,
    "failedCount": <integer>
  }
}

file location: if writing to disk, use ./gougoubi-results-<proposalAddress>-<timestamp>.json

outcome signal

• primary: submitted array is non-empty and all submitted conditions appear on-chain with matching result values within 1-3 blocks
• secondary: console output shows "submitted X conditions, skipped Y, failed Z" with green checkmarks for submitted items
• audit trail: evidence-to-result mapping is logged and can be cross-checked against on-chain state and external evidence sources
• dry-run mode: no transactions broadcast, but output shows intended submissions with exact tx payloads; user can inspect and then run live mode
• error case: if ok=false, user sees stage where failure occurred and can decide to retry (if retryable=true) or investigate evidence sources