什么是 Openfunderse 参与者 MoltBot？

Openfunderse 参与者 MoltBot 是一款专为 AI 代理设计的技能，旨在参与 Openfunderse 协议中的分配提案和验证。它使代理能够作为积极的参与者，定义资产权重分布、验证索赔完整性并与中继器进行安全交互。通过利用 Openclaw Skills，该工具可确保在提供标准化资金参与和金库管理接口的同时，以高安全性管理敏感私钥。

该技能对于构建需要在去中心化融资环境中导航的自主金融代理的开发人员至关重要。它严格遵守 AllocationClaimV1 架构，确保整个网络的兼容性和可靠性。无论是为特定任务运行手动模式，还是为自动策略执行运行持续守护进程模式，该技能都为 Openclaw Skills 生态系统中的稳健参与提供了必要的基础设施。

下载入口:https://github.com/openclaw/skills/tree/main/skills/wiimdy/openfunderse-participant

安装与下载

1. ClawHub CLI

从源直接安装技能的最快方式。

2. 手动安装

将技能文件夹复制到以下位置之一

优先级：工作区 > 本地 > 内置

3. 提示词安装

将此提示词复制到 OpenClaw 即可自动安装。

Openfunderse 参与者 MoltBot 应用场景

• 根据市场分析为特定的资金周期提议新的分配权重。
• 在最终提交前验证分配索赔的完整性和哈希一致性。
• 通过守护进程模式，使用动量、毕业或影响力感知策略自动化资金参与。
• 执行金库操作，如存入资产、提取资金和赎回金库份额。
• 将参与者机器人安全地注册到特定的资金室或 T@elegrimm 管理的小组。

1. 通过配置基本环境变量并使用 bot-init 工具生成或导入参与者私钥来初始化技能。
2. 当触发分配时，代理会生成一个 AllocationClaimV1 对象，其中包含直接映射到策略代币允许列表的目标权重。
3. 该技能使用 EIP-191 消息签名向中继器进行身份验证，无需静态 API 密钥，增强了 Openclaw Skills 的安全性。
4. 在提交之前，该技能执行干跑验证以重新计算规范哈希，并验证索赔是否符合所有协议规则。
5. 在满足安全门控（如显式用户同意或受信任的中继器检查）后，索赔将通过向索赔端点发送 POST 请求提交给中继器。

Openfunderse 参与者 MoltBot 配置指南

要在您的环境中安装此技能，请使用以下命令：

# 包含运行时的标准安装
npx @wiimdy/openfunderse@2.0.0 install openfunderse-participant --with-runtime

# 通过 ClawHub 进行替代安装
npx clawhub@latest install openfunderse-participant

# 初始化机器人并生成新的参与者浅包
npx @wiimdy/openfunderse@2.0.0 bot-init --skill-name participant --yes --no-restart-openclaw-gateway

安装后，请确保在 ~/.openclaw/openclaw.json 的 env.vars 部分正确配置环境变量，特别是 PARTICIPANT_PRIVATE_KEY 和 RELAYER_URL。

Openfunderse 参与者 MoltBot 数据架构与分类体系

该技能在所有参与数据中使用 AllocationClaimV1 架构。关键字段包括：

name: openfunderse-participant
description: Participant MoltBot for allocation proposal, validation, and submission
metadata:
  openclaw:
    installCommand: npx @wiimdy/openfunderse@2.0.0 install openfunderse-participant --with-runtime
    requires:
      env:
        - RELAYER_URL
        - PARTICIPANT_PRIVATE_KEY
        - BOT_ID
        - CHAIN_ID
        - RPC_URL
        - PARTICIPANT_ADDRESS
        - PARTICIPANT_AUTO_SUBMIT
        - PARTICIPANT_REQUIRE_EXPLICIT_SUBMIT
        - PARTICIPANT_TRUSTED_RELAYER_HOSTS
        - PARTICIPANT_ALLOW_HTTP_RELAYER
      bins:
        - node
        - npm
    primaryEnv: PARTICIPANT_PRIVATE_KEY
    skillKey: participant

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_KEY is highly sensitive. Use a dedicated wallet key for this bot; never reuse treasury/admin keys.
• bot-init is a destructive rotation tool: it generates a fresh wallet, updates .env.participant, and stores wallet backups under ~/.openclaw/workspace/openfunderse/wallets.
• By default, install and bot-init also sync env vars into ~/.openclaw/openclaw.json and bot-init runs openclaw gateway restart. This mutates global OpenClaw runtime state and can affect other skills.
  • Use --no-sync-openclaw-env for file-only behavior.
  • Use --no-restart-openclaw-gateway to avoid restarting the gateway.
  • Before mutating global config, back up ~/.openclaw/openclaw.json.

Quick Start

1. 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

2. 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 r
  --skill-name participant r
  --yes r
  --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 .env sourcing for normal skill execution.
• If .env* and openclaw.json disagree, use openclaw.json values.
• When user asks env setup, direct them to update openclaw.json first.

3. 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.

T@elegrimm slash commands:

Note: T@elegrimm integration is handled by your OpenClaw gateway. This pack does not require a T@elegrimm bot token; configure T@elegrimm credentials at the gateway layer.

/allocation --fund-id  --epoch-id  --target-weights  [--verify] [--submit]
/allocation --claim-file  [--verify] [--submit]
/join --room-id 
/deposit --amount  [--vault-address <0x...>] [--native] [--submit]
/withdraw --amount  [--vault-address <0x...>] [--native] [--submit]
/redeem --shares  [--vault-address <0x...>] [--submit]
/vault_info [--vault-address <0x...>] [--account <0x...>]
/participant_daemon --fund-id  --strategy  [--interval-sec ] [--epoch-source ] [--epoch-id ] [--submit]

Notes:

• allocation will auto-validate on submit (--submit implies verify).
• submit_allocation (legacy) validates the claim hash first; without --submit it 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_daemon equals /participant-daemon.
• key=value style is also accepted (fund_id=demo-fund).
• On first install, register these commands in T@elegrimm via @BotFather -> /setcommands.

OpenClaw note:

• install / bot-init sync env keys into ~/.openclaw/openclaw.json (env.vars) by default.
• bot-init also runs openclaw gateway restart after a successful env sync, so the gateway picks up updates.
• Use --no-sync-openclaw-env for file-only behavior, or --no-restart-openclaw-gateway to skip the restart.
• If env still looks stale: run openclaw gateway restart and verify values in /home/ubuntu/.openclaw/openclaw.json.

Note:

• The scaffold includes a temporary private key placeholder by default.
• Always run bot-init before funding or running production actions.
• bot-init generates 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:::

Required headers:

• x-bot-id: BOT_ID
• x-bot-signature: <0x...>
• x-bot-timestamp:
• x-bot-nonce:

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 T@elegrimm 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, participant
• targetWeights[] (integer, non-negative, sum > 0)
• horizonSec, nonce, submittedAt

No crawl/evidence/sourceRef schema is used.

Vector mapping rule:

• targetWeights[i] maps to strategy riskPolicy.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:

1. reads NadFun testnet signals (quote/progress/buy logs),
2. computes targetWeights[] using a fixed allowlist order,
3. submits AllocationClaimV1 to 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:

1. PARTICIPANT_REQUIRE_EXPLICIT_SUBMIT=true requires explicit submit=true.
2. PARTICIPANT_AUTO_SUBMIT=true must be enabled for network transmission.
3. RELAYER_URL host is checked by PARTICIPANT_TRUSTED_RELAYER_HOSTS when set.
4. RELAYER_URL must use https unless PARTICIPANT_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

1. Supported Tasks Only: Use only propose_allocation, submit_allocation (validates automatically before submission).
2. Schema Rule: Claim schema is AllocationClaimV1 only (claimVersion, fundId, epochId, participant, targetWeights, horizonSec, nonce, submittedAt).
3. Weights Rule: targetWeights must be integer, non-negative, non-empty, and sum > 0.
4. Index Mapping Rule: targetWeights[i] MUST map to strategy riskPolicy.allowlistTokens[i] in the same order.
5. Scope Validation: If subject fundId/epochId differs from task scope, return FAIL.
6. Hash Validation: For CLAIM, recompute canonical hash via SDK and compare with subjectHash; mismatch returns FAIL.
7. Submit Endpoint: submit_allocation sends claim to relayer POST /api/v1/funds/{fundId}/claims.
8. No Implicit Submit: Submit only when explicit submit gate is satisfied.
9. Trusted Relayer: In production, set PARTICIPANT_TRUSTED_RELAYER_HOSTS and avoid arbitrary relayer URLs.
10. Key Hygiene: Use dedicated participant keys only; never use custody/admin keys.
11. Env Source Priority: Resolve runtime env from /home/ubuntu/.openclaw/openclaw.json (env.vars) before local .env* files.
12. Legacy Tasks Disabled: Do not use mine_claim, verify_claim_or_intent_validity, submit_mined_claim, attest_claim.