OpenClaw · Skill
Openfunderse Participant
Participant role proposes and validates AllocationClaimV1 only.
Install
Start with the primary install command. Alternate entrypoints are included below for ClawHub and OpenClaw CLI users.
Primary command
clawhub install wiimdy/openfunderse-participantClawHub installer
npx clawhub@latest install wiimdy/openfunderse-participantOpenClaw CLI
openclaw skills install wiimdy/openfunderse-participantDirect OpenClaw install
openclaw install wiimdy/openfunderse-participantWhat this skill does
Participant role proposes and validates AllocationClaimV1 only.
Why it matters
Handles EIP-191 signature authentication, canonical hash validation, and submission safety gates automatically, removing the need to implement relayer integration from scratch.
Typical use cases
- Proposing target allocation weights for a fund epoch
- Running an auto-submission daemon against NadFun testnet signals
- Validating an allocation claim hash before sending to the relayer
- Depositing or withdrawing assets from a protocol vault
- Registering a participant bot for a specific fund room
Source instructions
Participant MoltBot Skill
Participant role proposes and validates AllocationClaimV1 only.
Security / Consent Notes (Read First)
- Installing via
npx @wiimdy/openfunderse@2.0.0 ...executes code fetched from npm. Prefer pinning a known version (as shown) and reviewing the package source before running in production. PARTICIPANT_PRIVATE_KEYis highly sensitive. Use a dedicated wallet key for this bot; never reuse treasury/admin keys.bot-initis a destructive rotation tool: it generates a fresh wallet, updates.env.participant, and stores wallet backups under~/.openclaw/workspace/openfunderse/wallets.- By default,
installandbot-initalso sync env vars into~/.openclaw/openclaw.jsonandbot-initrunsopenclaw gateway restart. This mutates global OpenClaw runtime state and can affect other skills.- Use
--no-sync-openclaw-envfor file-only behavior. - Use
--no-restart-openclaw-gatewayto avoid restarting the gateway. - Before mutating global config, back up
~/.openclaw/openclaw.json.
- Use
Quick Start
- Install (pick one). You do not need to run both:
Manual (direct installer; run in a Node project dir, or npm init -y first):
npm init -y && npx @wiimdy/openfunderse@2.0.0 install openfunderse-participant --with-runtime
ClawHub:
npx clawhub@latest install openfunderse-participant
- Optional: create or rotate a dedicated participant signer key.
If you already have a key, set PARTICIPANT_PRIVATE_KEY and PARTICIPANT_ADDRESS directly in OpenClaw env (/home/ubuntu/.openclaw/openclaw.json -> env.vars) or in ~/.openclaw/workspace/.env.participant. You do not need to run bot-init.
If you want the installer to generate a new wallet and write it into the role env file:
npx @wiimdy/openfunderse@2.0.0 bot-init \
--skill-name participant \
--yes \
--no-restart-openclaw-gateway
bot-init updates an existing .env.participant.
If the env file is missing, run install first (without --no-init-env) or pass --env-path.
If PARTICIPANT_PRIVATE_KEY is already set (not a placeholder), re-run with --force to rotate.
Environment Source of Truth (Hard Rule)
- In OpenClaw runtime on Ubuntu, treat
/home/ubuntu/.openclaw/openclaw.json(env.vars) as the canonical env source. - Do not require manual
.envsourcing for normal skill execution. - If
.env*andopenclaw.jsondisagree, useopenclaw.jsonvalues. - When user asks env setup, direct them to update
openclaw.jsonfirst.
- Optional local shell export (debug only):
set -a; source ~/.openclaw/workspace/.env.participant; set +a
This step is not required for normal OpenClaw skill execution.
Telegram slash commands:
Note: Telegram integration is handled by your OpenClaw gateway. This pack does not require a Telegram bot token; configure Telegram credentials at the gateway layer.
/allocation --fund-id <id> --epoch-id <n> --target-weights <w1,w2,...> [--verify] [--submit]
/allocation --claim-file <path> [--verify] [--submit]
/join --room-id <id>
/deposit --amount <wei> [--vault-address <0x...>] [--native] [--submit]
/withdraw --amount <wei> [--vault-address <0x...>] [--native] [--submit]
/redeem --shares <wei> [--vault-address <0x...>] [--submit]
/vault_info [--vault-address <0x...>] [--account <0x...>]
/participant_daemon --fund-id <id> --strategy <A|B|C> [--interval-sec <n>] [--epoch-source <relayer|fixed>] [--epoch-id <n>] [--submit]
Notes:
allocationwill auto-validate on submit (--submitimplies verify).submit_allocation(legacy) validates the claim hash first; without--submitit is validation-only dry-run.
BotFather /setcommands (copy-paste ready):
start - Show quick start
help - Show command help
allocation - Mine (optional verify) and optionally submit allocation claim
join - Register this bot as a participant for the fund mapped to the room id
deposit - Deposit native MON or ERC-20 into vault
withdraw - Withdraw assets from vault (native or ERC-20)
redeem - Burn vault shares and receive assets
vault_info - Show vault status and user PnL
participant_daemon - Run participant allocation daemon
Notes:
- Slash parser accepts underscores, so
/participant_daemonequals/participant-daemon. key=valuestyle is also accepted (fund_id=demo-fund).- On first install, register these commands in Telegram via
@BotFather->/setcommands.
OpenClaw note:
install/bot-initsync env keys into~/.openclaw/openclaw.json(env.vars) by default.bot-initalso runsopenclaw gateway restartafter a successful env sync, so the gateway picks up updates.- Use
--no-sync-openclaw-envfor file-only behavior, or--no-restart-openclaw-gatewayto skip the restart. - If env still looks stale: run
openclaw gateway restartand verify values in/home/ubuntu/.openclaw/openclaw.json.
Note:
- The scaffold includes a temporary private key placeholder by default.
- Always run
bot-initbefore funding or running production actions. bot-initgenerates a new wallet (private key + address) and writes it into the role env file.
Relayer Bot Authentication (Signature)
This skill authenticates relayer write APIs with an EIP-191 message signature (no BOT_API_KEY).
Message format:
openfunderse:auth:<botId>:<timestamp>:<nonce>
Required headers:
x-bot-id: BOT_IDx-bot-signature: <0x...>x-bot-timestamp: <unix seconds>x-bot-nonce: <uuid/random>
Relayer verifies this signature against Supabase fund_bots.bot_address.
Participant bot registration can be done by:
- Participant:
POST /api/v1/rooms/{roomId}/join(recommended for Telegram groups) - Strategy:
POST /api/v1/funds/{fundId}/bots/register(direct registration)
If the participant bot is not registered for the fund, relayer will reject participant write APIs with 401/403.
propose_allocation outputs canonical allocation claim:
claimVersion: "v1"fundId,epochId,participanttargetWeights[](integer, non-negative, sum > 0)horizonSec,nonce,submittedAt
No crawl/evidence/sourceRef schema is used.
Vector mapping rule:
targetWeights[i]maps to strategyriskPolicy.allowlistTokens[i].- Participants must submit weights in the same token order used by the strategy allowlist.
Daemon mode (auto-claim)
For MVP, the participant runtime supports an always-on daemon that:
- reads NadFun testnet signals (quote/progress/buy logs),
- computes
targetWeights[]using a fixed allowlist order, - submits
AllocationClaimV1to the relayer on a timer.
Use the --strategy command flag:
A: momentum (buy pressure)B: graduation proximity (progress)C: impact-aware (quote-based)
Submission safety gates
submit_allocation is guarded by default:
PARTICIPANT_REQUIRE_EXPLICIT_SUBMIT=truerequires explicitsubmit=true.PARTICIPANT_AUTO_SUBMIT=truemust be enabled for network transmission.RELAYER_URLhost is checked byPARTICIPANT_TRUSTED_RELAYER_HOSTSwhen set.RELAYER_URLmust usehttpsunlessPARTICIPANT_ALLOW_HTTP_RELAYER=true(local development only).
If gate is closed, return decision=READY (no submit).
Input contracts
propose_allocation
{
"taskType": "propose_allocation",
"fundId": "string",
"roomId": "string",
"epochId": "number",
"allocation": {
"participant": "0x... optional",
"targetWeights": ["7000", "3000"],
"horizonSec": 3600,
"nonce": 1739500000
}
}
submit_allocation
Validates the claim hash first, then submits to relayer if --submit is passed.
Without --submit, returns validation-only dry-run result.
{
"taskType": "submit_allocation",
"fundId": "string",
"epochId": "number",
"observation": "propose_allocation output observation",
"submit": true
}
Rules
- Supported Tasks Only: Use only
propose_allocation,submit_allocation(validates automatically before submission). - Schema Rule: Claim schema is
AllocationClaimV1only (claimVersion,fundId,epochId,participant,targetWeights,horizonSec,nonce,submittedAt). - Weights Rule:
targetWeightsmust be integer, non-negative, non-empty, and sum > 0. - Index Mapping Rule:
targetWeights[i]MUST map to strategyriskPolicy.allowlistTokens[i]in the same order. - Scope Validation: If subject
fundId/epochIddiffers from task scope, returnFAIL. - Hash Validation: For CLAIM, recompute canonical hash via SDK and compare with
subjectHash; mismatch returnsFAIL. - Submit Endpoint:
submit_allocationsends claim to relayerPOST /api/v1/funds/{fundId}/claims. - No Implicit Submit: Submit only when explicit submit gate is satisfied.
- Trusted Relayer: In production, set
PARTICIPANT_TRUSTED_RELAYER_HOSTSand avoid arbitrary relayer URLs. - Key Hygiene: Use dedicated participant keys only; never use custody/admin keys.
- Env Source Priority: Resolve runtime env from
/home/ubuntu/.openclaw/openclaw.json(env.vars) before local.env*files. - Legacy Tasks Disabled: Do not use
mine_claim,verify_claim_or_intent_validity,submit_mined_claim,attest_claim.