Imported from starchild-ai-agent/official-skills (wallet/SKILL.md) via skills.sh. Install upstream with npx skills add starchild-ai-agent/official-skills --skill wallet. Copyright stays with the author.

💰 Wallet Skill

Multi-chain wallet for EVM (DeBank-supported chains) + Solana. Balances, transfers, signing, and policy management. Script skill — call the functions below via bash; no wallet tools are registered.

How to call

All read/transfer/sign operations are Python functions in core.skill_tools.wallet. Run them from bash and read the JSON result:

python3 -c "from core.skill_tools import wallet; import json; print(json.dumps(wallet.wallet_balance(chain='base')))"

The one operation that is NOT a script function is proposing a wallet policy — it needs to render a confirmation card in the UI, so it goes through the native frontend_action tool (see Policy Management below).

Functions (from core.skill_tools import wallet)

The User's Own Wallets (login / secondary)

The agent wallet is NOT the user's wallet. The platform injects the user's own wallet identities as env vars (synced from the control plane at container start and on user wallet actions):

• USER_LOGIN_WALLET_ADDRESS / USER_LOGIN_WALLET_TYPE — the wallet the user logs in with (or bound as primary).
• USER_SECONDARY_WALLET_ADDRESS / USER_SECONDARY_WALLET_TYPE — the user's other linked wallet (e.g. Solana when login is EVM).

When asked "what's my wallet" / "my login wallet" / "check MY balance", read these — do NOT answer with the agent wallet or say you don't know:

python3 -c "from core.skill_tools import wallet; import json; print(json.dumps(wallet.get_user_wallets()))"

Empty/missing values mean the user has never bound a wallet in that slot (e.g. social login) — say so and point them to wallet binding in the web app.

Rules:

• Read-only. The agent holds no keys for these wallets. To check the user's balances, pass the address into wallet_balance(chain, address=...) / wallet_sol_balance(address=...).
• Transactions from the user's wallet never go through script functions — use the native frontend_action(action_type="user_wallet_tx", ...) flow, where the user signs in the UI and expected_from is enforced server-side.

Key Facts

• Amounts are in wei for EVM (wallet_transfer / wallet_sign_transaction). 0.01 ETH = 10000000000000000. For ERC-20 token sends, amount is 0 (native) and the transfer is encoded in data calldata.
• Gas is sponsored by default on EVM chains — user doesn't need native tokens for gas. Falls back to user-paid if unavailable. Pass sponsor=False to pay gas from wallet balance.
• Policy default: OFF (allow-all). Only when policy is enabled do transactions need UI confirmation.
• Supported EVM chains: All DeBank-supported chains. Common names auto-mapped (e.g. avalanche → avax, bsc → bsc, zksync → era). Fallback aliases include ethereum/base/arbitrum/optimism/polygon/linea/bsc/avalanche/fantom/gnosis/zksync/scroll/blast/mantle/celo/aurora plus monad/world/unichain/abstract/sonic/berachain.
• Balance sources: DeBank (EVM), Birdeye (Solana), wallet-service (fallback). DeBank/Birdeye keys are auto-injected by sc-proxy.

Workflows

Check balances

python3 -c "from core.skill_tools import wallet; import json; print(json.dumps(wallet.wallet_balance(chain='base')))"
python3 -c "from core.skill_tools import wallet; import json; print(json.dumps(wallet.wallet_get_all_balances()))"

Send a transaction (EVM)

Always verify balance before, and the result/history after.

# 1. check
python3 -c "from core.skill_tools import wallet; import json; print(json.dumps(wallet.wallet_balance(chain='base')))"
# 2. transfer (amount in wei)
python3 -c "from core.skill_tools import wallet; import json; print(json.dumps(wallet.wallet_transfer(to='0x...', amount='10000000000000000', chain_id=8453)))"
# 3. verify
python3 -c "from core.skill_tools import wallet; import json; print(json.dumps(wallet.wallet_transactions(chain='base')))"

Sign EIP-712 typed data

python3 -c "from core.skill_tools import wallet; import json; print(json.dumps(wallet.wallet_sign_typed_data(domain={...}, types={...}, primaryType='Permit', message={...})))"

Policy Management

Checking policy is a script function; proposing a policy uses the native frontend_action tool (it renders a signature card in the UI — a script cannot).

1. Check current policy:

   python3 -c "from core.skill_tools import wallet; import json; print(json.dumps(wallet.wallet_get_policy(chain_type='ethereum')))"

2. (Optional) pre-validate rules:

   python3 -c "from core.skill_tools import wallet; import json; print(json.dumps(wallet.validate_and_clean_rules([...], 'ethereum')))"

3. Propose — call the frontend_action tool (not a script):

   frontend_action(action_type="update_wallet_policy", chain_type="ethereum", rules=[...])
   

   The user confirms + signs in the UI. Call once per chain (EVM + Solana = two calls).

Standard Wildcard Policy (when needed)

rules = [
  {"name": "Deny key export", "method": "exportPrivateKey", "conditions": [], "action": "DENY"},
  {"name": "Allow all", "method": "*", "conditions": [], "action": "ALLOW"},
]

Policy Modes — CRITICAL DECISION TABLE

⚠️ DENY > ALLOW in Privy. DENY * overrides ALL ALLOW rules. NEVER mix them.

Mode 1: Allow-All (Standard Wildcard)

rules = [
  {"name": "Deny key export", "method": "exportPrivateKey", "conditions": [], "action": "DENY"},
  {"name": "Allow all", "method": "*", "conditions": [], "action": "ALLOW"},
]

Mode 2: Deny-All (Lockdown)

rules = [
  {"name": "Deny key export", "method": "exportPrivateKey", "conditions": [], "action": "DENY"},
  {"name": "Deny all actions", "method": "*", "conditions": [], "action": "DENY"},
]
# ⚠️ NO ALLOW rules here — DENY * would override them!

Mode 3: Whitelist (Selective Allow)

rules = [
  {"name": "Deny key export", "method": "exportPrivateKey", "conditions": [], "action": "DENY"},
  {"name": "Allow transfer to Uniswap", "method": "eth_sendTransaction", "conditions": [
    {"field_source": "ethereum_transaction", "field": "to", "operator": "eq", "value": "0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913"}
  ], "action": "ALLOW"},
]
# ⚠️ NO "DENY *" here! enabled=true already denies everything not ALLOWed.
# Adding DENY * would override the ALLOW rules above (DENY > ALLOW).

Privy Policy Rules — Key Constraints

Gotchas

• Policy proposal goes through the frontend_action tool — needs an active SSE session (won't work from a background task).
• wallet_balance requires chain — use wallet_get_all_balances for discovery.
• For both EVM + Solana policy, call frontend_action TWICE (one per chain_type).