💰 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)

Function	Description
wallet_info()	Get all AGENT wallet addresses
get_user_wallets()	The USER'S OWN wallets (login + secondary) — read-only, from env
wallet_balance(chain, address="", asset="")	EVM balance on a chain (DeBank). chain required
wallet_sol_balance(address="", asset="")	Solana balance (Birdeye)
wallet_get_all_balances(evm_address="", sol_address="")	All chains at once
wallet_transfer(to, amount, chain_id=1, data="", **kw)	Broadcast EVM tx (gas sponsored by default)
wallet_sign_transaction(to, amount, chain_id=1, data="", **kw)	Sign EVM tx (no broadcast)
wallet_sign(message)	EIP-191 message signing
wallet_sign_typed_data(domain, types, primaryType, message)	EIP-712 typed data signing
wallet_transactions(chain="ethereum", asset="", limit=20)	EVM tx history
wallet_sol_transfer(transaction, caip2=...)	Broadcast Solana tx (base64)
wallet_sol_sign_transaction(transaction)	Sign Solana tx (no broadcast)
wallet_sol_sign(message)	Solana message signing
wallet_sol_transactions(chain="solana", asset="sol", limit=20)	Solana tx history
wallet_get_policy(chain_type="ethereum")	Check policy status
validate_and_clean_rules(rules, chain_type)	Pre-validate policy rules before proposing

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	Rules	Effect
Allow-all (default)	DENY exportPrivateKey + ALLOW *	Everything allowed except key export
Deny-all (lockdown)	DENY exportPrivateKey + DENY *	Nothing works. No ALLOW rules!
Whitelist (selective)	DENY exportPrivateKey + specific ALLOW rules only	Only whitelisted ops work, rest implicitly denied

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

Rule	Details
Default behavior	enabled=true → deny-all unless explicitly ALLOWed
DENY > ALLOW	DENY always wins when both match
Empty conditions	Only exportPrivateKey and * (wildcard) allow conditions: []
TX methods need conditions	eth_sendTransaction, eth_signTransaction, eth_signTypedData_v4, eth_signUserOperation, signAndSendTransaction, etc. ALL require ≥1 condition
Valid field_sources	EVM: ethereum_transaction (to/value/chain_id), ethereum_calldata (function_name), ethereum_typed_data_domain (chainId/verifyingContract), ethereum_typed_data_message, system
Valid operators	eq, gt, gte, lt, lte, in (array, max 100 values)
Dual chain	Call frontend_action(action_type="update_wallet_policy", ...) TWICE for EVM + Solana

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