Gougoubi Submit Real Results

Submit real-world outcomes for Gougoubi conditions using deterministic evidence from condition skills and public market data. Use when users want resolved-on...

Security Scan

The skill claims to submit on-chain condition results but omits the credentials, RPC/provider details, and runnable scripts required to do that, creating an incoherent and potentially risky footprint.

Purpose & Capability

The skill's stated purpose is to submit on-chain results (transactions, tx hashes) for Gougoubi conditions, but the package declares no credentials, no config paths, and includes no signing/provider instructions. Submitting blockchain transactions normally requires a signer/private key and RPC endpoint; those are not declared or explained. The SKILL.md also references local node scripts as primary entry points, but those scripts are not present in the shipped files.

Instruction Scope

Runtime instructions describe enumerating conditions, reading each condition's 'skills' payload, fetching public market evidence, and submitting one vote per condition. The instructions do not specify which external APIs to call, how to access other skills' payloads, or how to obtain permissions to read them — leaving ambiguity about what the agent should access. The steps themselves are coherent for the stated task, but incomplete.

Install Mechanism

This is an instruction-only skill with no install spec and no code files to execute in the package, which minimizes direct install risk. However, SKILL.md and INSTALL.md reference project scripts and a repository; those referenced artifacts are not included in the distributed files.

Credentials

No environment variables, secrets, or primary credential are declared despite the skill describing transaction submission. A signing key, wallet provider URL, or other sensitive config would normally be required. The absence of declared credentials is disproportionate to the claimed capability and leaves unclear how signing and broadcast of on-chain transactions would occur.

Persistence & Privilege

The skill does not request always-on presence and does not declare modifications to other skills or system-wide settings. No elevated persistence or privileged flags are present.

What to consider before installing

This skill claims to perform on-chain submissions but the package omits the code and credentials needed to do that. Before installing or using it: 1) ask the author for the missing scripts and a clear description of how transactions are signed and which RPCs/endpoints are used; 2) do not provide private keys or secrets until you have reviewed the actual code that will use them; 3) verify whether the intended node scripts exist in the source repository and inspect them for where they read keys, provider URLs, or network endpoints; 4) if you only want to inspect results, use a read-only tool rather than this skill. The current package is internally inconsistent — treat it with caution.

Use this skill to map external evidence to on-chain condition results and submit one result per condition.

Use This Skill When

• The user wants to submit real outcomes for all conditions in a proposal.
• The user wants to submit only officially resolved conditions first.
• The user wants a forced fallback such as No for remaining unresolved conditions.

Do Not Use This Skill When

• The user only wants to inspect missing results without submitting. Use gougoubi-recovery-ops.
• The user only wants activation or LP staking.

Input

{
  "proposalAddress": "0x...",
  "mode": "resolved-only|all|force",
  "forceResult": "yes|no",
  "evidenceNote": "optional"
}

Defaults:

• mode=resolved-only
• evidenceNote should be auto-generated when missing

Pipeline

Step 1: Validate proposal address and target chain.

Step 2: Enumerate all conditions under the proposal.

Step 3: Read each condition skills payload and extract evidence locators such as event slug or market id.

Step 4: Fetch public evidence and build a result map:

• resolved-only: only officially resolved markets
• all: all markets with clear final outcomes
• force: use the same forced side for still-pending conditions

Step 5: For each target condition:

• Skip if result != 0
• Skip if the condition is not ready for submission
• Submit exactly one result vote

Step 6: Return submitted, skipped, failed, and tx hashes.

Checkpoints

• Prefer resolved-only unless the user explicitly asks for all or force.
• Never duplicate a submission for a condition that already has result != 0.
• Keep evidence mapping and tx results together in the output.

Output

{
  "ok": true,
  "proposalAddress": "0x...",
  "mode": "resolved-only|all|force",
  "submittedCount": 0,
  "skippedCount": 0,
  "failedCount": 0,
  "submitted": [
    {
      "index": 0,
      "conditionAddress": "0x...",
      "conditionName": "",
      "result": 1,
      "txHash": "0x..."
    }
  ],
  "skipped": [],
  "failed": [],
  "warnings": []
}

Failure:

{
  "ok": false,
  "stage": "validation|fetch-evidence|submit|confirm",
  "error": "reason",
  "retryable": true
}

Project Scripts

• scripts/pbft-submit-all-condition-results.mjs
• scripts/pbft-submit-results-from-skills-once.mjs
• scripts/pbft-submit-real-results-1605.mjs
• scripts/pbft-submit-real-results-c427-confirmed.mjs
• scripts/pbft-submit-real-results-ba0c-resolved-only.mjs
• scripts/pbft-submit-remaining-no-ba0c.mjs

Script Entry Points

• Generic fixed-side submission: scripts/pbft-submit-all-condition-results.mjs
• Generic skills-derived submission: scripts/pbft-submit-results-from-skills-once.mjs
• node scripts/pbft-submit-all-condition-results.mjs --help
• node scripts/pbft-submit-all-condition-results.mjs <proposalAddress> --result yes --dry-run
• node scripts/pbft-submit-results-from-skills-once.mjs --help
• node scripts/pbft-submit-results-from-skills-once.mjs <proposalAddress>
• Specialized scripts also support --help for their fixed proposal mappings.

Boundaries

• Do not infer unresolved results unless the user explicitly asks for all or force.
• Preserve an auditable mapping from evidence to submitted result.