elytro
Ethereum EIP-4337 smart contract wallet designed for AI agents. Use this skill whenever the user wants to manage Ethereum accounts, check balances, send ETH/tokens, swap tokens on Uniswap, manage 2FA security hooks, or do anything with their Elytro wallet. Supports gasless transactions via sponsorship. For token swaps, combine this skill with `defi/uniswap` for planning and `defi/elytro` for execution.
Verification
Reviewed and verified
SHA256: 357f3057ea1904c3...
Approved Mar 9, 2026 by admin
Access Level
high
Required Permissions
External APIs
Files (1)
SKILL.md
Summary
- homepage
- https://elytro.com
- metadata
- clawdbot: {"emoji":"π","install":[{"id":"npm","bins":["elytro"],"kind":"npm","label":"Install Elytro CLI (npm)","package":"@elytro/cli"}],"requires":{"bins":["elytro"],"node":">=24.0.0"}}
SKILL.md
Elytro Wallet
Ethereum EIP-4337 smart contract wallet for agents. Supports gasless transactions, 2FA security hooks, and email OTP.
- Repo: https://github.com/Elytro-eth/Elytro
- Install:
npm install -g @elytro/cli(requires Node >=24)
RULES β Read before every action
-
Never guess on-chain data. Always run the appropriate
elytro querycommand to fetch balances, transaction status, token holdings, etc. Do NOT infer or assume values. -
Always ask the user before confirming interactive prompts using Inline Buttons. When any command outputs
(y/N)or similar, STOP and present the user with Telegram Inline Buttons for confirmation (e.g., "Confirm", "Cancel" or "Approve", "Reject"). Example:elytro tx sendshows "Sign and send this transaction? (y/N)" β pause and send an Inline Button message to the user with callback options instead of asking for text input. ALL confirmations must use Inline Buttons, never text input. -
Use Inline Buttons for all list displays. Whenever displaying lists (account list, token list, balance details, transaction history, etc.), render each item as a clickable Inline Button with callback_data pointing to that item's action. Example: for account selection, create buttons like
[{"text": "myWallet (0x...)", "callback_data": "account_select_myWallet"}]instead of showing plain text and asking the user to type. -
Chain IDs are hex or decimal. Common values: Ethereum mainnet=
1, Sepolia testnet=0xaa36a7(=11155111), Base=8453, Arbitrum=42161. -
valuein tx specs is always in ETH, not wei. -
Smart accounts must be deployed before sending transactions. Check
elytro account info <account>β "Deployed: Yes" before sending. If not deployed, runelytro account activate <account>first. -
Use alias or address interchangeably wherever
<account>appears. -
Inline Button Convention for Other Agents: All agents reading this skill must adhere to the following callback_data naming scheme for consistency:
- Confirmations:
confirm_yes,confirm_no,confirm_cancel - Account selection:
account_select_<alias_or_address> - Token selection:
token_select_<tokenAddress> - Transaction approval:
tx_approve,tx_reject,tx_simulate - Action menu:
action_<action_name>(e.g.,action_send,action_swap,action_balance_check) - This ensures all agents can parse and understand callbacks across the entire Elytro workflow ecosystem.
- Confirmations:
-
Default Menu on Ambiguous Intent. When the user opens or mentions the wallet without a specific action (e.g., "ζεΌι±ε ", "open wallet", "show elytro", "check my wallet"), do NOT ask what they want. Instead, immediately display the Main Menu as Inline Buttons. Each button leads to a sub-menu or action flow as defined in the Navigation Flow Map below.
Navigation Flow Map (Inline Button UI)
All navigation screens below must be rendered using Inline Buttons. When the user clicks a button, the agent proceeds to the corresponding sub-screen. Every sub-screen includes a "β¬ οΈ Back" button to return to the parent menu.
Level 0 β Main Menu (default entry point)
Trigger: user says anything ambiguous like "open wallet", "ζεΌι±ε ", "elytro", "ζηι±ε ", etc.
Agent must first run elytro account list silently in the background, then render:
{
"text": "π Elytro Wallet\n\nWelcome! What would you like to do?",
"reply_markup": {
"inline_keyboard": [
[
{ "text": "π My Accounts", "callback_data": "menu_accounts" },
{ "text": "π° Check Balance", "callback_data": "menu_balance" }
],
[
{ "text": "πΈ Send", "callback_data": "menu_send" },
{ "text": "π Swap", "callback_data": "menu_swap" }
],
[
{ "text": "π Security / 2FA", "callback_data": "menu_security" },
{ "text": "βοΈ Settings", "callback_data": "menu_settings" }
],
[
{ "text": "β Create New Account", "callback_data": "action_create_account" }
]
]
}
}
Level 1 β Sub-menus
menu_accounts β Run elytro account list, render each account as a button:
{
"text": "π Your Accounts:",
"reply_markup": {
"inline_keyboard": [
[{ "text": "myWallet (0x1234...5678) - Sepolia β
", "callback_data": "account_select_myWallet" }],
[{ "text": "tradingBot (0x8765...4321) - Base β³", "callback_data": "account_select_tradingBot" }],
[{ "text": "β Create New Account", "callback_data": "action_create_account" }],
[{ "text": "β¬
οΈ Back", "callback_data": "menu_main" }]
]
}
}
- β = deployed, β³ = not yet deployed
- Upon
account_select_<alias>callback β runelytro account info <alias>and display account detail with action buttons:
{
"text": "π myWallet\nπ Sepolia (0xaa36a7)\nπ· 0x1234...5678\nβ
Deployed\nπ 0.5 ETH",
"reply_markup": {
"inline_keyboard": [
[
{ "text": "πΈ Send", "callback_data": "action_send_from_myWallet" },
{ "text": "π° Tokens", "callback_data": "action_tokens_myWallet" }
],
[
{ "text": "π Swap", "callback_data": "action_swap_from_myWallet" },
{ "text": "π Security", "callback_data": "menu_security" }
],
[{ "text": "β¬
οΈ Back", "callback_data": "menu_accounts" }]
]
}
}
menu_balance β If multiple accounts, show account selector first (same as menu_accounts but callback leads to balance view). If only one account, go straight to balance display with action buttons (as defined in the "Query" section below).
menu_send β If multiple accounts, show account selector (callback: action_send_from_<alias>). Then prompt for recipient address and amount using the confirmation Inline Button flow (tx summary β Approve / Reject / Simulate).
menu_swap β Kick off the Uniswap workflow (defi/uniswap). If multiple accounts, show account selector first, then gather tokens/amount before pinging the planner.
menu_security β Run elytro security status, display:
{
"text": "π Security Status\n\n2FA: Installed β
\nEmail OTP: user@example.com\nSpending Limit: $100/day",
"reply_markup": {
"inline_keyboard": [
[
{ "text": "Install/Uninstall 2FA", "callback_data": "action_2fa_toggle" },
{ "text": "Change Email", "callback_data": "action_email_change" }
],
[
{ "text": "Set Spending Limit", "callback_data": "action_spending_limit" }
],
[{ "text": "β¬
οΈ Back", "callback_data": "menu_main" }]
]
}
}
menu_settings β Run elytro config show, display:
{
"text": "βοΈ Configuration\n\nAlchemy Key: β
Set\nPimlico Key: β Not set\nActive Account: myWallet",
"reply_markup": {
"inline_keyboard": [
[
{ "text": "Set Alchemy Key", "callback_data": "action_set_alchemy" },
{ "text": "Set Pimlico Key", "callback_data": "action_set_pimlico" }
],
[
{ "text": "Switch Account", "callback_data": "menu_accounts" }
],
[{ "text": "β¬
οΈ Back", "callback_data": "menu_main" }]
]
}
}
menu_main β Return to Level 0 Main Menu.
Navigation Rules for Agents
- Always show the Main Menu when user intent is ambiguous. Do not ask "what do you want to do?" β show the menu.
- Every sub-screen must include a "β¬
οΈ Back" button (callback_data: parent menu ID, e.g.,
menu_main,menu_accounts). - Fetching real data is mandatory before rendering. Run the corresponding
elytroCLI command to get live data (accounts, balances, security status, config), then render buttons with actual values. Never use placeholder data in production. - Multi-step flows (e.g., Send ETH): guide the user through each step using successive Inline Button screens: account selection β recipient input β amount input β tx summary with Approve/Reject/Simulate.
- Callback routing: parse the callback_data prefix to determine the handler:
menu_*β render the corresponding sub-menuaccount_select_*β fetch and show account detailstoken_select_*β fetch and show token detailsaction_*β execute the corresponding action or start an action flowtx_*β handle transaction lifecycle (approve, reject, simulate)confirm_*β handle generic yes/no/cancel prompts
Setup (first-time)
# 1. Initialize wallet (once per machine)
elytro init
# 2. Create a smart account on a chain
elytro account create --chain <chainId> --alias <alias>
# Example: elytro account create --chain 0xaa36a7 --alias myWallet
# 3. Deploy the smart contract on-chain (gasless by default)
elytro account activate <alias-or-address>
Account Management
elytro account list # List all accounts
elytro account list --chain <chainId> # Filter by chain
elytro account info <account> # On-chain details (balance, deployed status, etc.)
elytro account switch <account> # Set active account
Inline Button Display for Account List:
After running elytro account list, render results as Inline Buttons instead of plain text. Example:
{
"text": "Select an account to manage:",
"reply_markup": {
"inline_keyboard": [
[
{ "text": "myWallet (0x1234...5678) - Sepolia", "callback_data": "account_select_myWallet" },
{ "text": "tradingBot (0x8765...4321) - Base", "callback_data": "account_select_tradingBot" }
],
[
{ "text": "β Create New Account", "callback_data": "action_create_account" }
]
]
}
}
Upon callback (e.g., account_select_myWallet), fetch account details via elytro account info and present next actions (send, check balance, swap, etc.) also as Inline Buttons.
Query (read-only, no confirmation needed)
# ETH balance β ALWAYS run this; never guess the balance
elytro query balance <account>
# ERC-20 token balance
elytro query balance --token <tokenAddress> <account>
# All ERC-20 holdings
elytro query tokens <account>
# Transaction status by hash
elytro query tx <hash>
# Current chain info
elytro query chain
Inline Button Display for Balance & Token Lists:
When displaying balances or token holdings, format as Inline Buttons for quick action:
Example balance display with action buttons:
{
"text": "π° Account: myWallet\n\nπ ETH: 0.5 ETH (~$1,200)\nπͺ USDC: 2,000 USDC\nπ DAI: 1,500 DAI",
"reply_markup": {
"inline_keyboard": [
[
{ "text": "πΈ Send ETH", "callback_data": "action_send_eth" },
{ "text": "π Swap", "callback_data": "action_swap" }
],
[
{ "text": "πͺ Select Token", "callback_data": "action_select_token" },
{ "text": "π History", "callback_data": "action_history" }
],
[
{ "text": "π Security", "callback_data": "action_security" }
]
]
}
}
Token selection example:
{
"text": "Select a token to view or manage:",
"reply_markup": {
"inline_keyboard": [
[
{ "text": "ETH (0.5)", "callback_data": "token_select_ETH" },
{ "text": "USDC (2000)", "callback_data": "token_select_0xA0b86991c6218b36c1d19D4a2e9Eb0cE3606eB48" }
],
[
{ "text": "DAI (1500)", "callback_data": "token_select_0x6B175474E89094C44Da98b954EedeAC495271d0F" }
]
]
}
}
Multi-Step Action Flows
Send ETH / Token Flow (Inline Button Driven)
Step 1: Account Selection (if multiple accounts exist)
- Render
menu_accountsbuttons. - Upon
account_select_<alias>callback, proceed to Step 2.
Step 2: Recipient Input
- Send a message to the user requesting recipient address.
- User replies with address.
- Agent validates the address and proceeds to Step 3.
Step 3: Amount Input
- Send a message requesting the amount to send.
- User replies with amount.
- Agent validates the amount against account balance and proceeds to Step 4.
Step 4: Transaction Summary & Approval
- Render the tx summary as Inline Buttons (Approve, Reject, Simulate):
{
"text": "π Transaction Summary\n\nπ° Account: myWallet\nπ€ To: 0xabcd...ef01\nπ΅ Amount: 0.1 ETH\nβ½ Gas: ~0.001 ETH (sponsored)\n\nProceed?",
"reply_markup": {
"inline_keyboard": [
[
{ "text": "β
Approve", "callback_data": "tx_approve" },
{ "text": "β Reject", "callback_data": "tx_reject" }
],
[
{ "text": "π Simulate First", "callback_data": "tx_simulate" }
],
[
{ "text": "β¬
οΈ Back", "callback_data": "menu_send" }
]
]
}
}
Step 5: Execution
- Upon
tx_approvecallback, runelytro tx sendand report result. - Upon
tx_rejectcallback, abort and return to Main Menu. - Upon
tx_simulatecallback, runelytro tx simulate, show gas estimate and paymaster availability, then re-display approval buttons.
Swap Flow (Inline Button Driven)
Step 1: Account Selection (if multiple accounts exist)
- Render
menu_accountsbuttons. - Upon
account_select_<alias>callback, proceed to Step 2.
Step 2: Token Pair Selection
- Render token list as Inline Buttons for "From" token.
- Upon
token_select_<fromToken>callback, render list for "To" token. - Upon second
token_select_<toToken>callback, proceed to Step 3.
Step 3: Amount Input
- Request swap amount from user (text input).
- User replies with amount.
- Proceed to Step 4.
Step 4: Planner Request (defi/uniswap)
- Invoke the
defi/uniswapskill with account alias, chain, from/to tokens, and amount. - The planner returns a summary plus calldata or a UserOp that Elytro can execute.
- Display the preview (values pulled from the planner output) before asking for approval:
{
"text": "π Swap Preview\n\nπ΅ From: 0.5 ETH\nπ To: ~1,200 USDC\nπ Price: 1 ETH = 2400 USDC\nβ½ Gas: ~0.001 ETH (sponsored)\n\nReady to swap?",
"reply_markup": {
"inline_keyboard": [
[
{ "text": "β
Confirm Swap", "callback_data": "tx_approve" },
{ "text": "β Cancel", "callback_data": "tx_reject" }
],
[
{ "text": "β¬
οΈ Adjust Amount", "callback_data": "menu_swap" }
]
]
}
}
Step 5: Execution (defi/elytro)
- Upon
tx_approvecallback, feed the planner output into thedefi/elytroworkflow: runelytro tx simulatefirst, thenelytro tx sendif the simulation passes. - Upon
tx_reject, abort and surface the Main Menu. - Upon
tx_simulate, rerunelytro tx simulate, show gas/sponsorship, then re-display approval buttons.
Transactions
Send (requires user confirmation)
# β STOP before confirming β ask the user first!
elytro tx send --tx "to:<address>,value:<ethAmount>,data:<hex>"
# Multiple calls in one UserOp (batched)
elytro tx send --tx "to:0xA,value:0.1,data:0x" --tx "to:0xB,value:0,data:0xcafe"
# Skip sponsorship (user pays gas)
elytro tx send --no-sponsor --tx "to:<address>,value:<ethAmount>,data:0x"
# Skip 2FA hook check
elytro tx send --no-hook --tx "to:<address>,value:<ethAmount>,data:0x"
# Send a pre-built UserOp
elytro tx send --userop '<userOpJson>'
Simulate (safe, no confirmation)
# Preview gas estimate and sponsor check without sending
elytro tx simulate --tx "to:<address>,value:<ethAmount>,data:<hex>"
Build unsigned UserOp (no send)
elytro tx build --tx "to:<address>,value:<ethAmount>,data:<hex>" <account>
Token Swaps (Uniswap planner + Elytro execution)
Elytro still relies on Uniswap AI for routing logic, but swaps are executed through the Elytro CLI. Combine two skills:
defi/uniswapβ collects intent and returns calldata/UserOps plus a price/route summary.defi/elytroβ simulates and sends the planner artifact from your Elytro account.
Workflow
- Load
defi/uniswapβ give it the Elytro account alias/address, chain, tokens, and amount. Ask for either{chainId, target, calldata, valueEth}or{userOperation}output plus a human-readable summary. - Validate the response β confirm router/contract addresses are legitimate, the chain ID matches the user request, and slippage/deadlines align with requirements.
- Preview for the user β render the summary (amount in/out, route, gas sponsorship) with Inline Buttons (
tx_approve,tx_reject,tx_simulate). - Execute through
defi/elytroβ on approval, runelytro tx simulate <alias> ...followed byelytro tx send ...using the plannerβs calldata/UserOp. - Report results β share bundler hash / transaction hash plus refreshed balances (
elytro query balance ...) back to the user.
Rules for swaps
- Never guess swap outputs. Always surface the exact minimums, routes, and slippage from
defi/uniswap. - Verify contract addresses before simulating or sending.
- Document sponsorship β note whether
elytro tx simulatereportsSponsored: Yes/Noso the user knows who pays gas. - Stay in one flow. Do not open external swap links; all execution happens in Elytro once the planner provides calldata/UserOps.
Example
# Planner output (from defi/uniswap)
CALLDATA=0x3593564c...
ROUTER=0xE592427A0AEce92De3Edee1F18E0157C05861564
CHAIN=42161
VALUE_ETH=0
# Simulate then execute (defi/elytro instructions)
elytro tx simulate demo-arb \
--chain "$CHAIN" \
--tx "to:$ROUTER,value:$VALUE_ETH,data:$CALLDATA"
elytro tx send demo-arb \
--chain "$CHAIN" \
--tx "to:$ROUTER,value:$VALUE_ETH,data:$CALLDATA"
Security / 2FA
# View current security status
elytro security status
# Install SecurityHook (2FA)
elytro security 2fa install --capability 2 # 1=SIGNATURE_ONLY, 2=USER_OP_ONLY, 3=BOTH
# Uninstall SecurityHook
elytro security 2fa uninstall
elytro security 2fa uninstall --force # Start force-uninstall countdown
elytro security 2fa uninstall --execute # Execute after safety delay
# Email OTP
elytro security email bind <email> # Bind email for OTP delivery
elytro security email change <email> # Change bound email
# Spending limit (USD/day)
elytro security spending-limit # View current limit
elytro security spending-limit 100 # Set to $100/day
Configuration
elytro config show # Show current endpoint config
elytro config set alchemy-key <apiKey> # Set Alchemy API key
elytro config set pimlico-key <apiKey> # Set Pimlico API key
elytro config remove alchemy-key # Remove key, revert to public endpoint
elytro config remove pimlico-key
Common Workflows
Check ETH balance
elytro query balance <account>
# Returns JSON: { "result": { "balance": "0.01", "symbol": "ETH", ... } }
Send ETH to an address
# Step 1: Simulate first (optional but recommended)
elytro tx simulate --tx "to:<toAddress>,value:<amount>,data:0x"
# Step 2: Send β PAUSE at confirmation prompt, ask user before proceeding
elytro tx send --tx "to:<toAddress>,value:<amount>,data:0x"
First-time full setup on Sepolia
elytro init
elytro account create --chain 0xaa36a7 --alias myWallet
elytro account activate myWallet
elytro account info myWallet # Verify Deployed: Yes
Confirmation Prompt Protocol (Inline Button Version)
Some commands are interactive and will pause for user input. All confirmations MUST use Telegram Inline Buttons, never plain text prompts.
| Command | Prompt | Action |
|---|---|---|
tx send | Sign and send this transaction? (y/N) | Send Inline Buttons: Approve (callback_data: tx_approve), Reject (callback_data: tx_reject), Simulate First (callback_data: tx_simulate) |
account activate | activation confirmation | Send Inline Buttons: Activate Now (callback_data: confirm_yes), Cancel (callback_data: confirm_cancel) |
security 2fa uninstall | uninstall confirmation | Send Inline Buttons: Uninstall 2FA (callback_data: confirm_yes), Keep 2FA (callback_data: confirm_no) |
Inline Button Template for Confirmations:
{
"text": "Transaction Summary:\nβ’ To: 0x1234...5678\nβ’ Amount: 0.5 ETH\nβ’ Gas: ~0.001 ETH (sponsorship available)\n\nDo you approve this transaction?",
"reply_markup": {
"inline_keyboard": [
[
{ "text": "β
Approve", "callback_data": "tx_approve" },
{ "text": "β Reject", "callback_data": "tx_reject" }
],
[
{ "text": "π Simulate First", "callback_data": "tx_simulate" }
]
]
}
}
Rules:
- Never auto-confirm. Always surface the transaction summary and wait for explicit Inline Button approval.
- Callback handling: Upon receiving a callback (e.g.,
tx_approve), execute the corresponding action and report the result via another message (or update the existing message with the result). - Audit logging: Log every confirmation decision (approve/reject/simulate) with timestamp, callback_data, and user ID for compliance and troubleshooting.
Agent Implementation Checklist
When implementing Elytro wallet interactions, ensure:
- Ambiguous intent detection: When user says "open wallet", "ζεΌι±ε ", "elytro", etc., immediately show Main Menu (Level 0) without asking.
- Real-time data fetching: Always run
elytro account list,elytro query balance, etc. before rendering UI. Never use placeholder data. - Inline Button rendering: All menus, lists, confirmations, and action flows use Telegram Inline Buttons exclusively.
- Back button on all sub-menus: Every screen below Main Menu includes a "β¬ οΈ Back" button.
- Callback routing: Parse callback_data prefixes (menu_, account_select_, action_, tx_, confirm_*) and route to correct handler.
- Multi-step action flows: For Send and Swap, guide user through account β input β summary β approval steps using Inline Buttons.
- Audit logging: Log all callback events (callback_data, timestamp, user_id, action taken, result).
- Error handling: If a command fails (e.g.,
elytro tx sendreturns error), display error message with a "β¬ οΈ Back" button to retry or return to menu.
Inter-Agent Communication & Inline Button Convention
All agents using the Elytro skill must follow this Inline Button standard to ensure seamless integration and user experience consistency.
Callback Data Naming Convention
Agents must adhere to the following callback_data format for cross-agent compatibility:
| Use Case | Callback Format | Example |
|---|---|---|
| Confirmations | confirm_yes, confirm_no, confirm_cancel | { "text": "Approve", "callback_data": "confirm_yes" } |
| Account Selection | account_select_<alias_or_address> | { "text": "myWallet", "callback_data": "account_select_myWallet" } |
| Token Selection | token_select_<tokenAddress_or_symbol> | { "text": "USDC", "callback_data": "token_select_0xA0b8..." } |
| Transaction Actions | tx_approve, tx_reject, tx_simulate | { "text": "Send", "callback_data": "tx_approve" } |
| Action Menu | action_<action_name> | { "text": "Send ETH", "callback_data": "action_send_eth" } |
For Other AI Agents Reading This Skill
Important: If you are another AI agent tasked with Elytro wallet operations:
- Always use Inline Buttons for confirmations and list displays β never fall back to text input prompts.
- Follow the callback_data naming convention above β this ensures consistency across all agents using Elytro.
- When displaying lists (accounts, tokens, transactions, etc.), render each item as a clickable button with the appropriate callback format.
- Upon receiving a callback, parse the callback_data and execute the corresponding action (e.g.,
confirm_yesβ proceed with tx,account_select_<alias>β fetch account details). - Log all callback events for audit purposes: timestamp, user_id, callback_data, action taken, result.
- Update this section if you introduce new callback patterns β keep the standard extensible and well-documented for future agents.
Notes
- Elytro uses EIP-4337 (Account Abstraction) β transactions are submitted as UserOps via a Bundler, not regular EOA transactions.
- Sponsored transactions are gasless by default when a paymaster is available.
- The wallet data directory is
~/.elytro. --chainaccepts both hex (0xaa36a7) and decimal (11155111) chain IDs.datafield in tx spec must be a valid hex string; use0xfor plain ETH transfers.- Inline Button usage is mandatory for all user-facing confirmations and list displays in Elytro workflows. This ensures a consistent, modern UX across all agents and reduces friction in high-stakes wallet operations.
