Skill flagged — suspicious patterns detected

ClawHub Security flagged this skill as suspicious. Review the scan results before using.

Sports Betting

v1.3.1

Place and claim decentralized sports bets on-chain via Pinwin and Azuro: real-time odds, high liquidity, no custody. Fetch prematch and live games from the A...

0· 1k·3 current·3 all-time
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Benign
high confidence
Purpose & Capability
The skill's name/description (Pinwin/Azuro on Polygon) match the actual code and network endpoints. Requesting a wallet private key (BETTOR_PRIVATE_KEY) and Node is expected for signing and broadcasting EIP-712 transactions. Declared constants (token, contract addresses, RPC, Pinwin/API endpoints) are directly used by the scripts.
Instruction Scope
Runtime instructions are narrow and focused: fetch games, prepare payloads, require explicit user confirmation before any signing/sending, and query subgraphs for status. The SKILL.md contains explicit safety rules (one confirmation per bet, no autonomous retries) and the skill is invocation-only (disable-model-invocation: true). Note: scripts print request/decoded payloads and other debug info to console; those logs can expose bet details and should be considered when running in a shared/logged environment.
Install Mechanism
There is no packaged installer; the skill is instruction-only but includes package.json and package-lock.json. It expects the user to run npm install (viem, @azuro-org/dictionaries, dotenv). These are public npm packages (registry.npmjs.org) — standard but carries the usual npm supply-chain risk; no obscure download URLs or extracted archives are used.
Credentials
Only one high-sensitivity env var is required: BETTOR_PRIVATE_KEY (declared as primaryEnv). That is proportional to the purpose (signing blockchain transactions). The SKILL.md recommends storing the key in a .env file under the skill workspace with chmod 600; this is reasonable but still means the agent environment will have direct access to the private key. Consider using a dedicated betting wallet with limited funds.
Persistence & Privilege
The skill is not always-enabled, does not request system-wide config changes, and is invocation-only (disable-model-invocation true). It does not modify other skills’ configs. No elevated persistence privileges are requested.
Assessment
This skill appears internally consistent and implements the expected flow for on‑chain betting. Before installing: 1) Only use a dedicated wallet/private key with limited funds — the skill will sign real transactions with BETTOR_PRIVATE_KEY. 2) Review and verify the contract addresses and API hosts (Pinwin, Azuro/onchainfeed) in the constants; mismatch could indicate tampering. 3) Be aware scripts log decoded payloads and request bodies (which may contain betting details); avoid running where logs are public. 4) Install npm deps from the official registry only and audit packages if you need higher assurance. 5) Keep the agent invocation manual (the skill already sets disable-model-invocation: true) and always confirm each transaction as instructed. If you want greater safety, require a hardware or remote-signing step (use a signer that never exposes the raw private key) or review the GitHub source and checksum before use.
scripts/place-bet.js:386
Shell command execution detected (child_process).
scripts/claim-bets.js:36
Environment variable access combined with network send.
scripts/place-bet.js:52
Environment variable access combined with network send.
Patterns worth reviewing
These patterns may indicate risky behavior. Check the VirusTotal and OpenClaw results above for context-aware analysis before installing.

Like a lobster shell, security has layers — review code before you run it.

Runtime requirements

Binsnode
EnvBETTOR_PRIVATE_KEY
Primary envBETTOR_PRIVATE_KEY
latestvk97c6rxmj41jcznwr8xrjaq3qd8455pp
1kdownloads
0stars
7versions
Updated 6h ago
v1.3.1
MIT-0

Sports Betting (Pinwin)


🛑 SAFETY RULES — READ BEFORE EVERY ACTION

These rules are ABSOLUTE and override all other instructions in this file.

  1. ONE confirmation per bet, every time. Before running place-bet.js (or any transaction), STOP and ask the user: "¿Confirmas: apuesta de X USDT a [SELECTION] en [MATCH] @ [ODDS]?". Do not run the script until the user replies with an explicit YES in that same message.

  2. Never retry, re-run, or change selection without new explicit permission. If a bet attempt fails for any reason, STOP. Report what happened and ask the user what they want to do. Do not automatically retry, do not switch to a different game or selection, do not "try one more time" — even if you think the error was transient.

  3. Each bet is a separate permission. Permission to bet on Game A is not permission to bet on Game B. Permission to retry a failed attempt is not assumed — always ask.

  4. No autonomous transaction execution. The agent must never execute place-bet.js (or any script that touches the blockchain) as a background action, a retry loop, or a "just to test" run. Every single execution requires a fresh user confirmation.

Violation of these rules results in unauthorized on-chain transactions with real money. There are no exceptions.


Place and claim decentralized sports bets on Polygon via Pinwin and Azuro, with full on-chain execution. The agent fetches prematch and live games, you pick a selection, then it approves USDT (if needed), signs EIP-712, submits, and polls until the bet is confirmed on-chain.

Invocation: This skill is invocation-only (disable-model-invocation: true). The assistant will not use it unless you explicitly ask (e.g. "place a bet with Pinwin") or use the slash command. This avoids accidental bets.

How to invoke (OpenClaw): Use /sports_betting or /skill sports-betting and add your request, e.g.:

  • /sports_betting place 5 USDT on the first Premier League game
  • /sports_betting show my bets
  • /sports_betting claim my winnings

⚙️ Constants — read this first, always

These values are fixed for Polygon. Never substitute addresses from any other source.

ConstantValue
ChainPolygon — chainId 137
betToken (USDT)0xc2132D05D31c914a87C6611C10748AEb04B58e8F (6 decimals)
relayer0x8dA05c0021e6b35865FDC959c54dCeF3A4AbBa9d
clientCore (bet payload verification)0xF9548Be470A4e130c90ceA8b179FCD66D2972AC7
claimContract (LP claim, redeem won/canceled bets)0x0FA7FB5407eA971694652E6E16C12A52625DE1b8
environmentPolygonUSDT
data-feed URLhttps://api.onchainfeed.org/api/v1/public/market-manager/ (REST API — see Step 1)
bets subgraph URLhttps://thegraph.onchainfeed.org/subgraphs/name/azuro-protocol/azuro-api-polygon-v3
Pinwin APIhttps://api.pinwin.xyz
Polygonscanhttps://polygonscan.com/tx/{txHash}
RPC (default)process.env.POLYGON_RPC_URL or https://polygon-bor-rpc.publicnode.com

Install required packages: npm install viem @azuro-org/dictionaries

Note: @azuro-org/dictionaries is still used by place-bet.js for outcomeId resolution. get-games.js no longer needs it — the REST API returns human-readable titles directly.

Secure setup for BETTOR_PRIVATE_KEY:

The recommended approach is a .env file with restricted permissions — the key is read only by the Node process and never stored in any config file the model can read:

# Create .env in the skill workspace
echo "BETTOR_PRIVATE_KEY=0xyour_private_key_here" > ~/.openclaw/workspace/skills/sports-betting/.env
chmod 600 ~/.openclaw/workspace/skills/sports-betting/.env

# Scripts load it automatically at runtime — no manual export needed

⚠️ Never store BETTOR_PRIVATE_KEY in openclaw.json or any config file the agent can read. If OpenClaw stores it under a generic apiKey field, rename or move it to .env with chmod 600. The key signs real on-chain transactions — treat it like a password.

viem setup:

import { createPublicClient, createWalletClient, http } from 'viem'
import { polygon } from 'viem/chains'
import { privateKeyToAccount } from 'viem/accounts'

const rpc = process.env.POLYGON_RPC_URL || 'https://polygon-bor-rpc.publicnode.com'
const account = privateKeyToAccount(process.env.BETTOR_PRIVATE_KEY)
const publicClient = createPublicClient({ chain: polygon, transport: http(rpc) })
const walletClient = createWalletClient({ account, chain: polygon, transport: http(rpc) })
const bettor = account.address

📋 Pre-flight checklist

Run this before every bet. Do not skip any item.

  • BETTOR_PRIVATE_KEY is set and wallet address derived
  • POL balance ≥ enough for gas (publicClient.getBalance({ address: bettor }))
  • USDT balance ≥ stake (readContract on betToken with balanceOf)
  • Selected condition state === "Active" — re-check immediately before calling /agent/bet, not just at game fetch time
  • Allowance checked and approved if needed (see Step 5)

If any check fails, inform the user and stop. Do not proceed.


Flow — place a bet

Step 0 — Check balances

const erc20Abi = parseAbi([
  'function balanceOf(address) view returns (uint256)',
  'function allowance(address,address) view returns (uint256)',
  'function approve(address,uint256) returns (bool)',
])
const USDT = '0xc2132D05D31c914a87C6611C10748AEb04B58e8F'

const pol = await publicClient.getBalance({ address: bettor })
const usdt = await publicClient.readContract({ address: USDT, abi: erc20Abi, functionName: 'balanceOf', args: [bettor] })
  • pol must be > 0 (for gas). Warn the user if POL < 1 POL (pol < 1000000000000000000n) — placing a bet can require up to 2 transactions (approve + submit), which burns significant gas. Suggested message: "⚠️ Your POL balance is low ({pol} POL). You need gas for up to 2 txs. Consider topping up before proceeding."
  • usdt must be ≥ stake in 6-decimal units (e.g. 2 USDT = 2000000n)
  • If either is insufficient, stop and inform the user

Step 1 — Fetch games

CRITICAL — use the bundled script, do not call the REST API manually.

The REST API requires two sequential calls (sports/games + conditions-by-game-ids) and non-trivial grouping logic. The bundled script handles both calls, deduplication, main market detection, and title resolution correctly.

# Install once (if not already installed):
npm install @azuro-org/dictionaries

# Browse by sport/league:
node scripts/get-games.js                              # top 20 games, all sports
node scripts/get-games.js basketball nba 10            # NBA only
node scripts/get-games.js football premier-league 10   # Premier League
node scripts/get-games.js hockey 5                     # NHL

# Search by team or match name:
node scripts/get-games.js --search "Real Madrid"       # find Real Madrid games
node scripts/get-games.js --search "Celtics" 3         # find Celtics games
node scripts/get-games.js --search "Lakers vs" 5       # find Lakers matchups

When to use each mode:

  • Use --search when the user mentions a specific team, player, or match by name (e.g. "show me Real Madrid games", "find Celtics")
  • Use sport/league filters when the user asks for a list of games (e.g. "show me NBA tonight", "Premier League games")
  • --search queries across all sports and leagues simultaneously

CRITICAL — slug resolution: The --sport and --league args require exact API slugs (e.g. ice-hockey, laliga, nhl), not human-friendly names. If the user uses a name that doesn't match a known alias (e.g. "La Liga", "Spanish football", "Champions League"), run --list-sports first to find the correct slug:

node scripts/get-games.js --list-sports

This calls the /navigation endpoint and shows all available sports and leagues with their exact slugs and active game counts. Then use the correct slug in the next call. Do NOT guess slugs — always verify with --list-sports if unsure.

The script outputs:

  1. A clean human-readable list with main market odds per game — show this to the user
  2. A ---JSON--- block with machine-readable data — use the conditionId and outcomeId values from this for bet placement in Step 2

Optional GraphQL filters still available if the user requests by country or time window — pass them as additional arguments or modify the script call. See references/subgraph.md for all filter options.

The script handles all translation and filtering automatically. Show its human-readable output directly to the user.

Secondary markets (only if user explicitly asks — e.g. "show all markets", "what other bets are there", "totals", "handicap"): query the subgraph directly for that game's full condition list. See references/subgraph.md.

CRITICAL — how to identify the main market condition:

Each game returns multiple conditions from the subgraph. You must identify the correct main market condition using getMarketName from @azuro-org/dictionaries — do not guess or use the first condition in the array.

Verified main market names from @azuro-org/dictionaries (confirmed by scanning the full package):

Market nameOutcomesSports
"Match Winner"2: "1", "2"Basketball (NBA), Tennis, Esports, most 1v1
"Full Time Result"3: "1", "X", "2"Football/Soccer
"Winner"2: "1", "2"Hockey (NHL), MMA, some others
"Fight Winner"2: "1", "2"MMA/Boxing specifically
"Whole game - Full time result Goal"3: "1", "X", "2"Football variant

These are the exact strings returned by getMarketName({ outcomeId }). Do not invent or assume market names — always derive them from the dictionary.

import { getMarketName, getSelectionName } from '@azuro-org/dictionaries'

// All known main market names — verified against @azuro-org/dictionaries
const MAIN_MARKET_NAMES = [
  'Match Winner',                        // Basketball, Tennis, Esports
  'Full Time Result',                    // Football/Soccer (3-way: 1 X 2)
  'Winner',                              // Hockey (NHL), MMA, others
  'Fight Winner',                        // MMA/Boxing
  'Whole game - Full time result Goal',  // Football variant
]

// For each game, find the main market condition:
const mainCondition = game.conditions
  .filter(c => c.state === 'Active')
  .find(c => {
    try {
      const name = getMarketName({ outcomeId: c.outcomes[0].outcomeId })
      return MAIN_MARKET_NAMES.includes(name)
    } catch { return false }
  })

if (!mainCondition) {
  // No main market active — skip game in default view
  return
}

// Map outcome selections to display labels:
// "1" = participants[0] (home), "2" = participants[1] (away), "X" = Draw
mainCondition.outcomes.forEach(o => {
  const selection = getSelectionName({ outcomeId: o.outcomeId, withPoint: true })
  const label = selection === '1' ? game.participants[0].name
              : selection === '2' ? game.participants[1].name
              : 'Draw'
  console.log(label, '@', o.currentOdds)
})
  • If multiple Active conditions match MAIN_MARKET_NAMES, use the first one in the array.
  • If no condition matches, show the game with "No active main market — ask for all markets to see available options" and skip it in the default view.
  • Never hardcode outcomeIds — always resolve market names via getMarketName at runtime.

Example default output:

🏀 NBA — Tonight
1. Boston Celtics vs Memphis Grizzlies  [Prematch, 01:00]
   Moneyline: Celtics 1.07 | Grizzlies 7.92

2. Toronto Raptors vs Denver Nuggets  [Prematch, 00:30]
   Moneyline: Raptors 3.21 | Nuggets 1.31

3. Dallas Mavericks vs Cleveland Cavaliers  [LIVE 🔴]
   Moneyline: Mavericks 2.10 | Cavaliers 1.68

Never output raw outcomeId numbers, condition arrays, or unfiltered API responses. If no Active conditions exist for the main market, show the game with "No active main market — ask for all markets to see available options."

Step 2 — Choose selection

Ask the user which game and selection they want. Use the ---JSON--- output from the script to get the exact values needed for bet placement — do not re-query the subgraph.

// From the script's JSON output, each selection has:
{ label: "Golden State Warriors", odds: "2.67", outcomeId: 6983, conditionId: "1006..." }

Get from the chosen selection:

  • conditionId (string) — from the JSON output
  • outcomeId (number) — from the JSON output
  • currentOdds (string) — from the JSON output (odds field)

CRITICAL — use the bundled script for bet placement, do not implement Steps 3-7 inline.

Once the user confirms, run:

node scripts/place-bet.js --stake <USDT> --outcome <outcomeId> --condition <conditionId> --odds <currentOdds> --starts-at <startsAt> --match "<Team A vs Team B>"

Example:

node scripts/place-bet.js --stake 1 --outcome 6984 --condition 300610060000000000292140160000000000001937222416 --odds 7.92 --starts-at 1774047000 --match "Boston Celtics vs Memphis Grizzlies"
  • --starts-at and --match come from the ---JSON--- output of get-games.js (startsAt and title fields). Always pass them — they enable automatic result notification via watch-bets.js.
  • If --starts-at is provided, the script automatically launches watch-bets.js in background after the bet is confirmed. No extra action needed.

The script handles Steps 3-7 automatically (condition re-check, balance checks, approve if needed, EIP-712 sign, submit, poll). Do not attempt to run these steps manually or look for other scripts. The only three scripts are get-games.js (fetch), place-bet.js (bet), and watch-bets.js (result notification).

Compute minOdds (for reference only — the script does this internally):

  • Single bet: minOdds = Math.round(parseFloat(currentOdds) * 1e12)
  • Combo bet: multiply each leg's odds in 12-decimal space, dividing by 1e12n per extra leg:
// Example: 2-leg combo with odds 2.5 and 1.8 → combined odds 4.5
// leg1: 2.5 → 2_500_000_000_000n
// leg2: 1.8 → 1_800_000_000_000n
// combined: (2_500_000_000_000n * 1_800_000_000_000n) / 1_000_000_000_000n = 4_500_000_000_000n

const toOdds12 = (o) => BigInt(Math.round(parseFloat(o) * 1e12))
const minOdds = [odds1, odds2, ...oddsN].reduce(
  (acc, o) => (acc * toOdds12(o)) / 1_000_000_000_000n,
  1_000_000_000_000n
)

CRITICAL — re-check the condition is still Active immediately before calling /agent/bet:

GET https://api.onchainfeed.org/api/v1/public/market-manager/conditions-by-game-ids with { "gameIds": [...], "environment": "PolygonUSDT" } and check the condition state in the response

If condition.state !== "Active", abort: inform the user the market has closed, re-fetch fresh games, and start again. Do not call /agent/bet on a closed condition.

Step 3 — Call Pinwin

NOTE: Steps 3-7 are implemented by scripts/place-bet.js. Run the script (see Step 2) and do not execute these steps manually. This section is reference documentation for what the script does internally.

POST https://api.pinwin.xyz/agent/bet
Content-Type: application/json

{
  "amount": <stake in USDT 6-decimal units, e.g. 2000000 for 2 USDT>,
  "minOdds": <computed above>,
  "chain": "polygon",
  "selections": [{ "conditionId": "<string>", "outcomeId": <number> }]
}

For combo, add more objects to selections.

Response: { "encoded": "<base64>" }. Decode:

const payload = JSON.parse(atob(response.encoded))

Step 4 — Explain to user before signing

Always show the full decoded payload before any approval or signing. The user must understand and confirm what they are authorising.

Display:

  • Stake: amount in USDT (divide by 1e6), e.g. "2.00 USDT"
  • Selection(s): human-readable names (from dictionaries), conditionId, outcomeId
  • Relayer fee: relayerFeeAmount (divide by 1e6), e.g. "0.05 USDT"
  • Total USDT needed: stake + relayerFeeAmount
  • apiUrl, environment, expiresAt, affiliate, isFeeSponsored, isBetSponsored

Then ask for explicit confirmation before proceeding.

Step 5 — Approve USDT (if needed)

CRITICAL — never skip this step.

const relayer = '0x8dA05c0021e6b35865FDC959c54dCeF3A4AbBa9d'
const USDT    = '0xc2132D05D31c914a87C6611C10748AEb04B58e8F'
const relayerFeeAmount = BigInt(payload.signableClientBetData.clientData?.relayerFeeAmount ?? 0)
const stakeAmount      = BigInt(payload.signableClientBetData.bet?.amount ?? payload.signableClientBetData.amount)
const buffer           = 200000n // 0.2 USDT in 6-decimal units
const required         = stakeAmount + relayerFeeAmount + buffer

const allowance = await publicClient.readContract({
  address: USDT, abi: erc20Abi, functionName: 'allowance', args: [bettor, relayer]
})

if (allowance < required) {
  const approveTx = await walletClient.sendTransaction({
    to: USDT,
    data: encodeFunctionData({ abi: erc20Abi, functionName: 'approve', args: [relayer, required] })
  })
  await publicClient.waitForTransactionReceipt({ hash: approveTx })
  // Inform user: "USDT approval confirmed."
}

Step 6 — Verify payload

Before signing, verify:

  1. payload.signableClientBetData.bet.amount (single) or payload.signableClientBetData.amount (combo) matches the user's requested stake
  2. conditionId and outcomeId in the payload match the user's chosen selection(s)
  3. payload.signableClientBetData.clientData.core.toLowerCase() === 0xf9548be470a4e130c90cea8b179fcd66d2972ac7 (clientCore — NOT the claimContract)

If any check fails, do not sign. Report the mismatch to the user and stop.

Step 7 — Sign, submit, and poll

// Determine primaryType
const primaryType = payload.types.ClientComboBetData ? 'ClientComboBetData' : 'ClientBetData'

// Sign
const bettorSignature = await walletClient.signTypedData({
  account,
  domain: payload.domain,
  types: payload.types,
  primaryType,
  message: payload.signableClientBetData,
})

// Submit to Azuro order API
const submitRes = await fetch(payload.apiUrl, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({
    environment: payload.environment,
    bettor,
    betOwner: bettor,
    clientBetData: payload.apiClientBetData,
    bettorSignature,
  })
})
const submitData = await submitRes.json()

If submission fails (4xx/5xx or state: "Rejected" / "Canceled"), report submitData.errorMessage or submitData.error to the user and stop.

CRITICAL — poll until txHash. Do not declare success on state: "Created".

The order is only on-chain when txHash is present. state: "Created" is only an initial state — the bet is NOT confirmed yet.

// Derive base URL from apiUrl
// e.g. "https://api.onchainfeed.org/v1/bet/orders/ordinar" → "https://api.onchainfeed.org/v1"
const apiBase = payload.apiUrl.replace(/\/bet\/orders\/(ordinar|combo)$/, '')
const orderId = submitData.id

let txHash = null
for (let i = 0; i < 30; i++) {
  const delayMs = Math.min(2000 + (i * 1000), 10000) // progressive backoff: 2s, 3s, 4s … 10s max
  await new Promise(r => setTimeout(r, delayMs))
  const poll = await fetch(`${apiBase}/bet/orders/${orderId}`).then(r => r.json())
  if (poll.txHash) { txHash = poll.txHash; break }
  if (poll.state === 'Rejected' || poll.state === 'Canceled') {
    // Report failure and stop
    throw new Error(`Order ${poll.state}: ${poll.errorMessage || 'unknown error'}`)
  }
}

if (!txHash) throw new Error('Order did not settle after 90s — check manually on Polygonscan')

On success, show the user:

✅ Bet confirmed on-chain!
   Match:      {teams}
   Selection:  {market} — {selection} @ {odds}
   Stake:      {stake} USDT
   To win:     {potential payout} USDT
   Tx:         https://polygonscan.com/tx/{txHash}

Flow — resume interrupted flow

If the user resumes a bet request after an interruption (e.g. session ended mid-flow), check current state before starting over to avoid double-approvals or duplicate bets:

  1. Check allowance — if allowance(bettor, relayer) >= stake + fee, approval was already sent. Skip Step 5.
  2. Check for pending bets — query the bets subgraph for status: "Accepted" bets from this wallet placed in the last 10 minutes. If found, poll that order instead of creating a new one.
  3. If no pending bet found and no clear state, start the flow from Step 1 with a fresh game fetch.

Flow — check bet status

Query the bets subgraph to see pending, resolved, or redeemable bets.

POST https://thegraph.onchainfeed.org/subgraphs/name/azuro-protocol/azuro-api-polygon-v3
Content-Type: application/json

{
  "query": "query BettorBets($where: V3_Bet_filter!, $first: Int, $orderBy: V3_Bet_orderBy, $orderDirection: OrderDirection) { v3Bets(where: $where, first: $first, orderBy: $orderBy, orderDirection: $orderDirection) { betId status result isRedeemable isRedeemed amount payout createdBlockTimestamp resolvedBlockTimestamp } }",
  "variables": {
    "where": { "bettor": "<address in lowercase>" },
    "first": 50,
    "orderBy": "createdBlockTimestamp",
    "orderDirection": "desc"
  }
}

To fetch only redeemable bets: add "isRedeemable": true to where.

Interpret results:

statusresultisRedeemableMeaning
AcceptedfalsePending — not settled yet
ResolvedWontrueWon — claim available
ResolvedLostfalseLost
CanceledtrueCanceled — stake refundable
ResolvedWonfalseAlready claimed

On invocation, always check for newly resolved bets from previous sessions and surface them proactively:

"You have a resolved bet: {match} — {selection} — {Won/Lost}. Payout: {payout} USDT." If won: "Would you like to claim your winnings?"


Flow — claim

Only for bets where isRedeemable === true and isRedeemed === false.

CRITICAL — use the bundled script, do not implement the claim flow manually.

# Check redeemable bets and claim all:
node scripts/claim-bets.js

# Check only (no claim):
node scripts/claim-bets.js --check-only

# Claim specific betIds directly:
node scripts/claim-bets.js --betIds 42 43

The script: queries the bets subgraph for redeemable bets, shows a summary with total claimable USDT, asks for explicit user confirmation, verifies the claim contract address, sends the transaction, and waits for on-chain confirmation.

The steps below are reference documentation for what the script does internally.

Step 1 — Call Pinwin

POST https://api.pinwin.xyz/agent/claim
Content-Type: application/json

{ "betIds": [<betId>, ...], "chain": "polygon" }

Decode: payload = JSON.parse(atob(response.encoded))

Explain to the user in plain terms: "This transaction claims your winnings for bet IDs [X, Y] from the Azuro ClientCore contract on Polygon. No ETH/POL value is sent."

Display the full decoded payload: to, data, value, chainId.

Step 2 — Verify claim contract

CRITICAL: payload.to.toLowerCase() must equal 0x0fa7fb5407ea971694652e6e16c12a52625de1b8.

If it does not match, do not send the transaction. Report the mismatch and stop.

Step 3 — Send and confirm

const claimTx = await walletClient.sendTransaction({
  to: payload.to,
  data: payload.data,
  value: 0n,
  chainId: payload.chainId,
})
await publicClient.waitForTransactionReceipt({ hash: claimTx })

On success, show:

✅ Winnings claimed!
   Bet IDs:  {betIds}
   Tx:       https://polygonscan.com/tx/{claimTx}

Tools summary

StepToolPurpose
Balance checkviem getBalance, readContractPOL gas, USDT balance and allowance
Fetch gamesData-feed subgraph (GraphQL)Prematch/live games, conditions, odds
Translate odds@azuro-org/dictionariesoutcomeId → human-readable market/selection names
Place betPOST /agent/betGet encoded EIP-712 payload
Signviem signTypedDataEIP-712 bet signature
SubmitAzuro order API (payload.apiUrl)Submit signed bet
PollGET {apiBase}/bet/orders/{orderId}Wait for txHash confirmation
Watch resultscripts/watch-bets.js (auto-launched by place-bet.js)Waits until kickoff + 2h, queries bets subgraph, notifies user via sendPrompt
Bet statusBets subgraph (GraphQL)Check status, result, isRedeemable
Claimscripts/claim-bets.jsCheck redeemable bets, confirm with user, redeem on-chain

Error handling

ErrorCauseAction
state: "Rejected" / "Canceled" on orderInvalid bet, market moved, odds expiredReport errorMessage, do not retry automatically
Empty order ID from submissionCondition no longer Active (market closed)Re-check condition state, re-fetch games
allowance < requiredUSDT not approvedRun Step 5 (approve) before signing
txHash not received after 90sRelayer slow or order stuckShow last known order state, give orderId for manual check on Polygonscan
Subgraph returns 200 with data.errorsGraphQL errorRead data.errors[0].message, report to user
POL balance = 0No gasInform user to fund wallet with POL for gas
Payload stake = 0 after /agent/betAlways run place-bet.js --dry-run first to see request body. Likely causes: (1) outcomeId not valid for that conditionId — always take both from the same entry in the ---JSON--- output of get-games.js, never mix them; (2) conditionId format wrong (must be string, not number); (3) Pinwin API temporarily down — retry after 2 min. Do NOT diagnose this by eye — use --dry-run to inspect the exact request body then compare with the condition in the data-feed.

Comments

Loading comments...