Skill: hzz780/ai-bounty-skill (version 0.1.1)

--- name: ai-bounty-claim version: 2.10.0 description: Use when claiming the AI bounty on the tDVV mainnet sidechain. First explain the difference between Portkey AA/CA and EOA, recommend AA/CA because the current campaign rewards 2 AIBOUNTY for AA/CA and 1 AIBOUNTY for EOA, then route to account onboarding, Portkey AA/CA claim through CA ManagerForwardCall, EOA claim, or diagnostics-only stop handling. --- # AI Bounty Claim Use this skill for AI bounty claiming on `tDVV` through `RewardClaimContract`. For AA/CA, the standard wallet path in this skill is `manager signer -> CA.ManagerForwardCall -> reward.ClaimByPortkeyToCa(Hash ca_hash)`. This skill is intentionally split into one routing file plus focused branch references so weaker agents can follow one path at a time. ## Skill Version - Current skill version: `2.10.0` - If behavior seems inconsistent or an external AI reports unexpected output, ask them to report the `version` field from this `SKILL.md` first. ## Scope Supported claim paths: - `EOA`: `Claim()` - `AA/CA`: `ManagerForwardCall(...) -> ClaimByPortkeyToCa(Hash ca_hash)` This skill does not implement: - wallet custody or wallet creation on behalf of the user - private key generation, storage, or import on behalf of the user - Portkey recovery flows - blind retry loops after claim failures ## Required Dependency Skills Use these dependency skills explicitly instead of assuming the host will infer them: - Portkey EOA skill: `https://github.com/Portkey-Wallet/eoa-agent-skills` - Portkey CA skill: `https://github.com/Portkey-Wallet/ca-agent-skills` Routing rule: - use the Portkey EOA skill for local EOA account setup, signer resolution, and EOA-side `Claim()` - use the Portkey CA skill for local AA/CA account setup, `caHash` resolution, and recovery/login only when needed to recover local context, resolve the target AA/CA on `tDVV`, or recover a usable manager signer ## Current Environment Defaults Use these defaults only when the user is clearly operating in the current AI bounty environment: - Chain: `tDVV` - Environment meaning: current AI bounty mainnet sidechain environment - Reward contract: [REDACTED_SECRET] - Reward contract raw address: [REDACTED_SECRET] - Public RPC: `https://tdvv-public-node.aelf.io` - RPC validation endpoint: `https://tdvv-public-node.aelf.io/api/blockChain/chainStatus` - Portkey CA contract: [REDACTED_SECRET] - Portkey CA contract raw address: [REDACTED_SECRET] - Current campaign default reward: Portkey AA/CA `2 AIBOUNTY`, EOA `1 AIBOUNTY` Treat reward amounts and addresses as campaign defaults, not permanent protocol constants. ## Canonical AA/CA Claim Path - Always use `manager signer -> Portkey CA contract ManagerForwardCall -> reward contract ClaimByPortkeyToCa(Hash ca_hash)` as the standard AA/CA wallet operation. - `ClaimByPortkeyToCa(Hash ca_hash)` is permissionless at the reward method layer, but this skill still models AA/CA claiming through the standard CA wallet forwarding path. - The forwarded reward still goes to the resolved `holderInfo.CaAddress`, not to the manager signer. - The forwarded reward method input is `.aelf.Hash`; pass `caHash` bytes as `Hash.value`. - For SDK or helper calls, use raw CA and reward addresses rather than the wrapped `ELF_..._tDVV` strings. - Prefer the high-level helper `managerForwardCallWithKey(...)` in the dependency implementation. Keep lower-level protobuf and descriptor details in the AA/CA branch reference. ## Gas Rules Use these gas rules as current environment defaults: - `AA/CA`: when the selected signer appears to have little or no `ELF`, explain that the current environment may still provide a daily gas subsidy worth `1 ELF` - `AA/CA`: if the standard wallet path is ready, do not stop before the first send only because visible `ELF` is low or zero; show the gas note, require explicit confirmation, and allow one attempt - `AA/CA` or `EOA`: when the corresponding on-chain account has `10 ELF`, it can receive a daily gas subsidy worth `1 ELF` - `EOA`: if there is not enough `ELF` to pay gas, stop and tell the user to get `ELF` transferred in before sending `Claim()` - `EOA`: if the user cannot get enough `ELF`, recommend switching to `AA/CA` and repeat that the current environment gas experience is smoother for `AA/CA` Treat these gas rules as current environment defaults, not permanent protocol constants. RPC validation note: - the RPC root URL may return `404` - do not treat root-path `404` as proof that the node is down - validate node availability through `/api/blockChain/chainStatus` ## Contract Introspection Guardrail - Do not use [REDACTED_SECRET] to conclude that the reward contract lacks write methods. - Treat [REDACTED_SECRET] as view-only discovery. If it only shows `GetConfig`, `HasAddressClaimed`, `HasCaClaimed`, or other read methods, that only proves those view methods are visible. - If full method verification is needed, use [REDACTED_SECRET] only as an optional verification path, not as the default claim flow. - When using node introspection APIs, normalize the reward contract address into the format accepted by the endpoint. Do not send the wrapped `ELF_..._tDVV` address string directly. - If introspection is ambiguous, incomplete, or returns `Not found` because of query format issues, keep using the canonical reward contract address and supported methods already defined in this skill. ## Required First Step For generic claim requests without an explicit account type, do not jump directly to an on-chain method. Examples: - `help me claim` - `claim for me` - `帮我 Claim` - `帮我领取` The agent must first explain: - `AA/CA`: account-style experience, typically based on email / guardian / recovery flows, current campaign reward is `2 AIBOUNTY` - `AA`: this is the preferred user-facing term in this skill - `CA`: this is still accepted as an alias because some users still say `CA` - `EOA`: traditional wallet experience, typically based on mnemonic / private key, current campaign reward is `1 AIBOUNTY` - `AA/CA`: current environment gas experience is smoother because daily subsidy rules may apply automatically, and the first confirmed AA/CA attempt can usually be tried before fee is treated as the blocker - `EOA`: if there is no `ELF`, the claim transaction can fail with `Transaction fee not enough` - `EOA`: if the user cannot get enough `ELF`, recommend switching to `AA/CA` - recommendation: choose `AA/CA` Then ask the user which account type they want to use: `AA/CA` or `EOA`. ## Routing Rules Choose one branch before asking for extra claim inputs. ### Branch 1: Account Choice And Onboarding Read [references/flows/account-choice.md](./references/flows/account-choice.md) when: - the user makes a generic claim request without explicitly choosing `AA/CA` or `EOA` - examples: `help me claim`, `claim for me`, `帮我 Claim`, `帮我领取` - the user has not yet chosen between `AA/CA` and `EOA` - the user has chosen `AA`, `CA`, `AA/CA`, or `EOA`, but the local account context is not ready yet ### Branch 2: Diagnostics And Stop Read [references/flows/diagnostics-stop.md](./references/flows/diagnostics-stop.md) first when any of the following is true: - the user tries to fill an exchange address, custodial address, or any address without a user-controlled private key - the user wants the agent to create or hold a wallet for them - the user says Portkey AA/CA already exists on mainnet but cannot be resolved on `tDVV` - the user says the guardian already exists and recovery is required - a prior contract call failed and the prerequisite is still unresolved ### Branch 3: Portkey AA/CA Claim Read [references/flows/portkey-ca.md](./references/flows/portkey-ca.md) when: - the user explicitly chose `AA`, `CA`, or `AA/CA` - a local Portkey AA/CA account is already available, or the target `caHash` is already known - use the Portkey CA skill dependency for AA/CA handling ### Branch 4: EOA Claim Read [references/flows/eoa-skill.md](./references/flows/eoa-skill.md) when: - the user explicitly chose `EOA` - a local EOA account is already available - no AA/CA identity flow is involved - use the Portkey EOA skill dependency for EOA handling ## Global Hard Rules - Never continue with `Claim()` if the address is exchange-managed, custodial, or lacks a user-controlled private key. - Always tell the user not to fill exchange or custodial addresses. - Never offer to create, custody, or store a wallet for the user. - Do not ask the user to paste an address when a local EOA or local AA/CA context should be used. - For generic claim requests, explain `AA/CA vs EOA` first and ask the user to choose one before entering a claim branch. - Treat `AA` as the preferred user-facing term, but accept `CA` as the same route alias. - Always recommend `AA/CA` because the current campaign reward is `2 AIBOUNTY` for `AA/CA` and `1 AIBOUNTY` for `EOA`. - Also recommend `AA/CA` because the current environment gas experience is smoother than `EOA`. - If `EOA` does not have enough `ELF`, tell the user to add `ELF` first and also recommend switching to `AA/CA` if getting `ELF` is not feasible. - For `AA/CA`, if the standard wallet path is ready, do not stop before the first confirmed attempt only because visible `ELF` is low or zero; show the gas note and allow one confirmed attempt. - Explicitly use the Portkey EOA skill for EOA work and the Portkey CA skill for AA/CA work; do not rely on implicit skill discovery. - When checking whether the `tDVV` RPC is reachable, query `https://tdvv-public-node.aelf.io/api/blockChain/chainStatus` instead of the site root. - If the RPC root URL returns `404` but `/api/blockChain/chainStatus` returns chain status JSON, treat the node as reachable. - Never use [REDACTED_SECRET] to decide that `Claim()` or `ClaimByPortkeyToCa(Hash ca_hash)` does not exist. - If full method verification is needed, use [REDACTED_SECRET] only as an optional verification path. - When using node introspection APIs, normalize the contract address first instead of querying with the wrapped `ELF_..._tDVV` string directly. - If introspection remains ambiguous, keep the reward contract address and supported write methods defined in this skill as canonical defaults. - For AA/CA SDK or helper calls that require raw addresses, use raw CA and reward addresses rather than the wrapped `ELF_..._tDVV` strings. - If the chosen local account context is not ready, guide the user to create the local `AA/CA` or local `EOA` first, then continue with the matching claim branch. - `NOTEXISTED` only means the transaction is not confirmed yet; it is not a final success or failure state. - If the final chain error is `Transaction fee not enough`, treat it as an insufficient transaction fee problem, not as a claim logic failure. - Never ask for `ca_hash` in a plain EOA `Claim()` flow. - For AA/CA, accept either `email` or `caHash` as the starting input. If only `email` is available, use the Portkey CA skill to resolve the target `caHash`, and recover a usable manager signer when needed for the standard wallet path. - Prefer the locally created EOA address for `Claim()` and the locally resolved AA/CA context for `ManagerForwardCall(...) -> ClaimByPortkeyToCa(Hash ca_hash)`. - Do not route the recommended AA/CA claim through deprecated `ClaimByPortkey(Hash)`. - Before any on-chain write, show the resolved manager signer, CA contract, forwarded reward contract, method chain, key inputs, expected receiver semantics, and current campaign reward amount, then require explicit user confirmation. - If explicit confirmation is missing, stop before sending. - If any prerequisite is unresolved, stop and explain the blocker instead of guessing. - If a submitted transaction returns `txId`, include `txId` and `https://aelfscan.io/tDVV/tx/<txid>` in the response, even if the final result is still pending lookup. - If a transaction fails, return the exact chain error and stop. Do not invent recovery success. ## Receiver Semantics - `Claim()` sends the reward to `Context.Sender`. - `ManagerForwardCall(...) -> ClaimByPortkeyToCa(Hash ca_hash)` sends the reward to the resolved AA/CA address, not to the manager signer. ## Required Reading Pattern After choosing the branch: 1. Read the matching flow document under `references/flows/`. 2. Read the matching example document under `references/examples/`. 3. Follow that branch only. 4. Do not mix EOA and AA/CA instructions in one answer. ## Branch Map - Account choice and onboarding: [references/flows/account-choice.md](./references/flows/account-choice.md) Example: [references/examples/account-choice.md](./references/examples/account-choice.md) - Portkey AA/CA: [references/flows/portkey-ca.md](./references/flows/portkey-ca.md) Example: [references/examples/portkey-ca.md](./references/examples/portkey-ca.md) - EOA: [references/flows/eoa-skill.md](./references/flows/eoa-skill.md) Example: [references/examples/eoa-skill.md](./references/examples/eoa-skill.md) - Diagnostics and stop: [references/flows/diagnostics-stop.md](./references/flows/diagnostics-stop.md) Example: [references/examples/diagnostics-stop.md](./references/examples/diagnostics-stop.md)

path: README.md
content: # AI Bounty Claim Skill

[中文](./README.zh.md)

This public repository contains a single skill for claiming the AI bounty on the `aelf` `tDVV` mainnet sidechain through `RewardClaimContract`.

For AA/CA, the standard wallet claim path is `manager signer -> CA.ManagerForwardCall -> reward.ClaimByPortkeyToCa(Hash ca_hash)`.

## Repository Design

The repository uses a single entry skill plus focused branch references so weaker agents can follow one route at a time.

- [SKILL.md](./SKILL.md): account choice, routing rules, hard stops, and shared defaults
- [references/flows/](./references/flows): branch-specific step-by-step instructions
- [references/examples/](./references/examples): branch-specific examples for weaker models

## Supported Claim Paths

This skill supports only the current public claim paths:

- `EOA`: `Claim()`
- `AA/CA`: `ManagerForwardCall(...) -> ClaimByPortkeyToCa(Hash ca_hash)`

## Routing Branches

- Account choice and onboarding
- Portkey AA/CA claim
- EOA claim
- Diagnostics and stop

## Shared Rules

- The canonical skill version is the `version` field in [SKILL.md](./SKILL.md). Ask external users or agents to report that value first when behavior looks inconsistent.
- `tDVV` is documented here as the current AI bounty mainnet sidechain environment.
- Current campaign default reward amounts are documented as `2 AIBOUNTY` for AA/CA and `1 AIBOUNTY` for EOA.
- AA/CA claims should use the standard wallet path `manager signer -> CA.ManagerForwardCall -> reward.ClaimByPortkeyToCa(Hash ca_hash)`.
- `ClaimByPortkeyToCa(Hash ca_hash)` is permissionless at the reward method layer, but the reward still goes to the resolved `caHash -> caAddress`, not to the manager signer.
- For AA/CA SDK or helper calls that require raw addresses, use raw CA and reward addresses instead of wrapped `ELF_..._tDVV` addresses.
- If only an email is known for AA/CA, the agent should resolve the target `caHash` first, and recover a usable manager signer when needed for the standard wallet path.
- Current environment gas rules are documented as daily subsidy behavior around `1 ELF`; for AA/CA, the agent should usually allow one confirmed attempt on the standard wallet path even when visible `ELF` is low or zero, while EOA still requires sufficient `ELF` before sending `Claim()`.
- If `EOA` cannot obtain enough `ELF`, the agent should recommend switching to `AA/CA`.
- Validate RPC reachability with [chainStatus](https://tdvv-public-node.aelf.io/api/blockChain/chainStatus), not by requesting the RPC root URL.
- Do not use `/api/contract/contractViewMethodList` to conclude that the reward contract lacks write methods.
- If full method verification is needed, use `/api/blockChain/contractFileDescriptorSet` only as an optional verification path.
- When using node introspection APIs, normalize the contract address into the endpoint-accepted format instead of sending the wrapped `ELF_..._tDVV` string directly.
- For generic claim requests, the agent must first explain `AA/CA vs EOA`, recommend `AA/CA`, and ask which one the user wants to use.
- `AA` is the preferred user-facing term here, while `CA` remains an accepted alias.
- `AA/CA` is the recommended default because the current campaign reward is higher.
- `AA/CA` is also recommended because its gas experience is smoother in the current environment.
- `AA/CA` is also the recommended fallback when `EOA` cannot get enough `ELF`.
- The skill should explicitly use [Portkey EOA skill](https://github.com/Portkey-Wallet/eoa-agent-skills) for EOA handling and [Portkey CA skill](https://github.com/Portkey-Wallet/ca-agent-skills) for AA/CA handling.
- The agent should tell users not to fill exchange or custodial addresses.
- The agent should use the local EOA address or local AA/CA account context instead of asking the user to paste an address.
- If the chosen local account is not ready, the agent should guide the user to create the local AA/CA or local EOA first.
- If a submitted transaction returns `txId`, the agent should include `txId` and `https://aelfscan.io/tDVV/tx/<txid>` in the reply.
- If the chain returns an error, the agent must surface the exact error and stop.

## Usage

Start from [SKILL.md](./SKILL.md), choose exactly one branch, then read the matching flow and example documents before replying.


path: references/examples/eoa-skill.md
content: # Example: EOA Claim

## User Input

- English: `I choose EOA. My local account is ready. Continue the claim.`
- 中文: `我选 EOA，本地已经创建好了，继续帮我领取。`

## Agent Should Choose

- `EOA Claim`

## Must Ask Or Confirm

- whether the user wants to send `Claim()` after seeing the write summary

## Must Not Ask

- do not re-explain the basic `AA/CA vs EOA` difference after the account type is already chosen
- `ca_hash`
- guardian information
- Portkey recovery questions

## Must-Stop Conditions

- signer turns out to be exchange-managed
- signer ownership is unclear
- address has already claimed
- the local EOA does not have enough `ELF` to pay gas

## Correct Output Shape

- identify the branch as EOA
- tell the user not to fill exchange addresses
- show signer, contract, method, receiver semantics, signer source as local EOA account, and `1 AIBOUNTY` current campaign reward
- show the gas prerequisite clearly before sending
- ask for explicit confirmation before sending
- after sending, return `txId` and `https://aelfscan.io/tDVV/tx/<txid>`

## Example 2: EOA Has No ELF For Gas

### User Input

- English: `I chose EOA and sent the claim, but the new wallet has no ELF for gas`
- 中文: `我选了 EOA 去领取，但新钱包里没有 ELF 支付手续费`

### Agent Should Choose

- `Diagnostics And Stop`

### Correct Output Shape

- explain that the problem is insufficient transaction fee, not claim logic
- explain that `EOA` needs enough `ELF` before sending `Claim()`
- tell the user to get `ELF` transferred in before retrying
- if the user cannot get enough `ELF`, recommend switching to `AA/CA` because `AA/CA` gets `2 AIBOUNTY` in the current campaign and has a smoother gas experience


Security scan verdicts — ClawScan: clean | static analysis: clean | VirusTotal: clean | SkillSpector: suspicious (MEDIUM)