Resolution Engineering v1.0.0

ResolutionLint Methodology & Architecture

A pre-publication resolution-rule verification engine designed to prevent ambiguous settlements and oracle disputes in prediction markets.

1. The Prediction Market Settlement Gap

Most prediction market disputes do not originate from malicious oracles or corrupt data feeds. They originate from ambiguous, contradictory, or under-specified market rules written prior to market launch.

Classic Settlement Ambiguities in Sports Markets:

•Player Participation: A question asks “Will Player X play?”. The player is listed on the bench as an unused substitute. One source counts the player in the squad roster; box scores record 0 minutes. Is the outcome YES or NO?
•Postponement vs Deadline: Rules specify “Bets stand if replayed within 48 hours”, yet the settlement expiration cutoff forces the oracle to resolve on the scheduled event evening.
•Stat Corrections & Source Priority: A broadcast outlet reports a final score of 105-104. The official league review committee adjusts a 2-pointer to a 3-pointer 12 hours later. Without a strict source hierarchy and cutoff policy, settlement collapses into dispute.

2. Honest System Boundaries

WHAT RESOLUTIONLINT DOES

• Discovers contradictory interpretation pairs before capital is deposited.
• Tests 8–10 bounded hypothetical scenarios relevant to the market type.
• Records immutable revisions and canonical hashes on GenLayer.
• Binds validated rules into a cryptographically anchored Sealed Rules Packet.

WHAT RESOLUTIONLINT IS NOT

• NOT a betting platform or prediction market exchange.
• NOT a live results oracle or market settlement engine.
• NOT a guarantee that a market will never face human disagreement.
• NOT a legal certification or regulatory endorsement.

3. Canonical Content Hashing

To ensure parity between the browser interface and the on-chain intelligent contract, revisions are normalized into a canonical JSON representation before computing the SHA-256 digest:

// Alphabetically sorted keys, normalized whitespace, compact separators

{
  "allow_void": false,
  "author_notes": "...",
  "clauses": [{"id": "C1", "text": "..."}],
  "cutoff_policy": "...",
  "event_identity": "...",
  "event_time_context": "...",
  "no_condition": "...",
  "question": "...",
  "reference_urls": ["..."],
  "schema_version": 1,
  "source_priority": "...",
  "timezone": "UTC",
  "void_condition": "",
  "yes_condition": "..."
}

This golden vector guarantees that an author and contract agree on byte-level integrity.

4. Deploying the GenLayer Contract (Studio Guide)

The only deployable source is contracts/main.py. The running app is configured for Studionet contract 0x3f60297b10d7547Cf214c120C640262BC7E21E4d (chain 61999). The steps below are how that deployment was produced. A replacement address would start with an empty registry.

Step 1: Open GenLayer Studio

Navigate to studio.genlayer.com and sign in with your browser wallet.

Step 2: Upload Contract File

In the Studio File Explorer, click Upload File and select contracts/main.py. Verify that the header specifies # { "Depends": "py-genlayer:1jb45aa8ynh2a9c9xn3b7qqh8sm5q93hwfp7jqmwsfhh8jpz09h6" }.

Step 3: Deploy to Studionet

Click Deploy. Studionet is gasless (gasPrice 0x0). Confirm the deployment in your wallet. Wait until the deployment transaction reaches FINALIZED.

Step 4: Configure Frontend

Copy the deployed contract address and set PUBLIC_CONTRACT_ADDRESS in your PM2 or .env.local configuration.

5. Integration for Market Interfaces

Prediction market frontends (such as Polymarket wrappers or custom dApps) can verify a proposed ruleset by reading the contract seal directly:

// Direct read via genlayer-js SDK
const isSealed = await client.readContract({
  address: CONTRACT_ADDRESS,
  functionName: "is_revision_sealed",
  args: [marketId, revisionId]
});

// Fetch canonical revision rules
const rev = await client.readContract({
  address: CONTRACT_ADDRESS,
  functionName: "get_revision",
  args: [marketId, revisionId]
});