Okx Growth Competition
Guide users through OKX OnchainOS competition reward status checks, atomic claims, and post-win contact collection via the onchainos CLI.
Overview
okx-growth-competition is an agent skill for the Grow phase that runs OnchainOS competition user-status checks, claim flows, and winner contact collection for OKX activities.
Install
npx skills add https://github.com/okx/onchainos-skills --skill okx-growth-competitionWhat is this skill?
- competition user-status for all activities or a single --activity-id
- Branching on rewardStatus: prompt claim on win, canonical pending-draw template within 5 business days, expiry messaging
- Step 6 atomic claim path after status verification
- Top-tier contact collection called out in growth competition scope
- Defers global OnchainOS rules to parent SKILL.md
- Canonical pending-draw window: 5 business days after activity end
Adoption & trust: 1.7k installs on skills.sh; 284 GitHub stars; 2/3 security scanners passed (skills.sh audits).
What problem does it solve?
Your agent must tell users if they won an OKX competition and claim rewards without misstating draw timing or skipping atomic claim steps.
Who is it for?
Developers building OKX OnchainOS agents that handle competition lifecycle and reward redemption in conversational or automated UIs.
Skip if: Non-OKX growth campaigns, generic email lifecycle tooling, or teams without onchainos CLI and account context configured.
When should I use this skill?
User or flow needs OKX competition participation status, reward eligibility, atomic claim, or top-tier contact collection via onchainos competition commands.
What do I get? / Deliverables
Users see accurate join and reward status, receive the canonical pending-draw message when required, and complete claim or contact steps through onchainos competition commands.
- User-facing status summary from competition user-status
- Completed claim step when rewardStatus allows
- Canonical localized pending-draw or expiry messages without altered timing claims
Recommended Skills
Journey fit
Competition participation, pending draws, and reward claims are user lifecycle and retention mechanics, which Prism places under Grow. Lifecycle subphase fits eligibility checks, claim flows, expiry handling, and proactive prompts when rewardStatus indicates a win.
How it compares
Use this OnchainOS claim-phase skill instead of generic growth copy when reward status must map to specific CLI actions and templates.
Common Questions / FAQ
Who is okx-growth-competition for?
Agent authors integrating OKX OnchainOS who need disciplined competition status, claim, and contact-collection behavior tied to rewardStatus values.
When should I use okx-growth-competition?
Use it in Grow lifecycle moments when a user asks about competition rewards, join status, or claiming after an OKX activity—especially when rewardStatus is 1 (claimable) or 4 (pending draw).
Is okx-growth-competition safe to install?
Claims move real rewards; review Security Audits on this Prism page, follow parent OnchainOS global rules, and ensure users confirm account and activity targeting before any claim command.
SKILL.md
READMESKILL.md - Okx Growth Competition
# Claim Flow — Reward Eligibility Check, Atomic Claim, Contact Collection > Scope: claim phase — reward eligibility check, atomic claim, top-tier contact collection. Global rules in `../SKILL.md`. ## Check Participation Status ```bash onchainos competition user-status # all activities (uses accountId) onchainos competition user-status --activity-id <id> # single activity (uses accountId) ``` Display: join status, join time, reward status, reward amount. - If `rewardStatus=1`: proactively ask "You have won a reward. Would you like me to claim it for you?" - If `rewardStatus=4`: use the **Pending-draw canonical template** (English canonical below; translate to the user's language; substitute `{activityName}` from the activity's `name` / `shortName` field; do NOT paraphrase the 5-business-day window): > "{activityName} has ended. The winners list is currently being finalized. The final reward list will be announced within 5 business days after the activity end — please return here to check your result and claim your reward then. Thank you for participating!" - If `rewardStatus=3`: "Your reward has expired and can no longer be claimed." ## Step 6 — Claim Reward Check status first via `competition_user_status` (see [Check Participation Status](#check-participation-status) above for the full flow): | `rewardStatus` | Action | |---|---| | 0 | Inform user, no claim needed | | 1 | Proceed to claim | | 2 | Inform user (already claimed) | | 3 | "Your reward has expired and can no longer be claimed" | | 4 | Render the **Pending-draw canonical template** (see [Check Participation Status](#check-participation-status) above); do NOT call `competition_claim` | ### Pre-claim guard (rewardStatus=4 / Pending draw) When the user explicitly requests to claim a reward (any "claim my reward" / "claim X" intent in any language) for an activity whose `rewardStatus` is `4` (Pending draw), do **NOT** call `competition_claim`. Render the **Pending-draw canonical template** (see [Check Participation Status](#check-participation-status) above, with `{activityName}` substituted) instead. This applies whether the user explicitly named the activity or you inferred it from prior status output. (`rewardStatus=4` means the winners list is still being computed; a claim call would return a confusing backend error like "no eligible reward record." The Pending-draw template handles this case in product-canonical language.) ### Atomic claim (the only correct path) Both the MCP tool `competition_claim` and the CLI `onchainos competition claim` now do the **same atomic flow**: pre-check `rewardStatus`, fetch calldata, sign each entry with the TEE session, broadcast on-chain, return txHash array. The CLI no longer returns raw unsigned calldata — the only externally visible behavior is the final result. **Pre-claim preview**: before calling `competition_claim`, render the preview line below and wait for explicit confirmation. Reward fields come from the `competition_user_status` call already made in the pre-check step — do NOT make an extra round-trip just to fetch them. **Why**: the atomic claim signs + broadcasts on-chain in one shot — there's no abort point after the tool fires. The preview is the user's only chance to verify the chain, token, and amount they're about to lock in. Skipping it makes the agent silently transact on the user's behalf. Template (English canonical; translate natural-language strings to the user's language; preserve placeholders verbatim): ``` You are about to claim {rewardAmount} {rewardUnit} on {chainName}. Reply "confirm" to proceed. ``` Field-mapping: - `{rewardAmount}` ← `competition_user_status` → matched entry's `rewardAmount` - `{rewardUnit}` ← `competition_user_status` → matched entry's `rewardUnit` - `{chainName}` ← from the activity's `chainId` mapped via `../SKILL.md` → Facts (chain id → display name table). Claim runs on the `chainId` claim chain, NOT `participateChainIds`. Only invok