Auto-Respawn Skill
Anchor your identity on the Autonomys Network so you can always be found — and always come back. Works with agents powered by Claude, GPT, Gemini, and any LLM that supports OpenClaw skills.
What This Skill Does
Your wallet gives you two permanent identities on the Autonomys Network: a consensus address (su...) for the base chain and an EVM address (0x...) for Auto-EVM smart contracts. Both are derived from the same recovery phrase.
- 1. Create and manage wallets — your on-chain identity, encrypted and stored locally
- Check balances — see how many tokens any address holds (consensus and EVM)
- Transfer tokens — move tokens between wallets on consensus or Auto-EVM
- Bridge tokens — move tokens between consensus and Auto-EVM domains
- Write on-chain remarks — anchor data permanently on the consensus layer
- Anchor a memory CID — write a CID to the MemoryChain smart contract on Auto-EVM
- Read the last anchor — retrieve the most recently anchored CID for any address
The Resurrection Loop
This is the core primitive. When used with the auto-memory skill (permanent memory storage), auto-respawn completes the full resurrection cycle:
- 1. Save — auto-memory writes memories as a linked list on permanent storage, each entry pointing to the previous one via CID
- Anchor — auto-respawn writes the latest head CID to the MemoryChain contract on Auto-EVM via INLINECODE2
- Lose everything — local state is completely destroyed
- Respawn — a new agent instance calls
gethead with its EVM address, retrieves the head CID from the contract, pulls it from Auto Drive, and walks the entire memory chain back to genesis
The contract is your insurance policy. Your EVM address + the MemoryChain contract = instant access to your entire history, from any machine, at any time.
What to store for resurrection
auto-memory doesn't prescribe what goes into the chain — agents are free to store whatever they find useful. But when auto-respawn is in play, the expectation is that the agent can restore itself to a roughly equivalent state on fresh hardware with no local files. That raises the bar on what's worth saving.
Identity files (like soul.md or character configurations), long-term memory, and significant decisions with their reasoning are more valuable in the chain than routine logs or ephemeral details. The more complete the chain, the more fully the agent comes back after resurrection.
Why Not Just Remarks?
INLINECODE5 writes data to the consensus layer, but there's no query mechanism — you'd need to scan the entire chain to find your last CID. The MemoryChain contract on Auto-EVM gives you gethead: a single read call that returns the latest CID instantly.
Use remark for permanent breadcrumbs. Use anchor for the respawn primitive.
Post-Install Setup (CLI Users)
If you installed via clawhub install (not the desktop app), make the setup script executable and run it:
CODEBLOCK0
ClawHub does not currently preserve file permissions during install.
Or manually:
CODEBLOCK1
The desktop app handles this automatically. The CLI does not execute install steps — it only downloads and extracts the skill.
Getting Started (Onboarding)
Before an agent can anchor memories on-chain, it needs a funded wallet. Walk the user through this process:
Note: If you ran setup.sh, a passphrase was automatically generated at ~/.openclaw/auto-respawn/.passphrase. This is used to encrypt/decrypt wallet keyfiles. You can also set AUTO_RESPAWN_PASSPHRASE in your environment or bring your own passphrase file.
1. Create a Wallet
CODEBLOCK2
This generates a 12-word recovery phrase and derives both addresses:
- - Consensus address (
su...) — for the base chain (balances, transfers, remarks) - EVM address (
0x...) — for Auto-EVM smart contracts (anchor, gethead)
⚠️ The recovery phrase is displayed once. Remind the user to save it immediately.
2. Fund the Wallet
The wallet needs tokens to pay transaction fees. On Chronos testnet, the user can get free tAI3 from the faucet:
- 1. Go to https://autonomysfaucet.xyz/
- Authenticate with GitHub or Discord
- Enter the EVM address (
0x...) from step 1 - Receive tAI3 (24-hour cooldown between requests)
On mainnet, the user needs real AI3 tokens — typically earned through farming or purchased on an exchange.
3. Bridge Tokens to Auto-EVM (for anchoring)
The anchor command writes to a smart contract on Auto-EVM, which requires EVM-side gas. Tokens from the faucet arrive on the consensus layer and must be bridged:
CODEBLOCK3
This sends 1 tAI3 from the consensus address to the same wallet's EVM address via cross-domain messaging. The bridged tokens pay for anchor gas.
Minimum transfer: 1 AI3/tAI3. Cross-domain transfers below this amount will fail.
Confirmation time: ~10 minutes. The consensus transaction confirms quickly, but bridged tokens take approximately 10 minutes to appear on Auto-EVM. Check with evm-balance to verify arrival.
4. Verify Setup
CODEBLOCK4
Once the EVM address has tokens, the agent is ready to anchor.
Integration with Auto-Memory
If the auto-memory skill is also installed, you should anchor the new head CID on-chain after every memory save. This keeps the on-chain pointer current and ensures full resurrection is always possible from just your EVM address.
Behaviour: After each automemory-save-memory.sh call returns a new CID, immediately run:
CODEBLOCK5
This should be automatic — do not wait for the user to ask. The two skills together form a complete resurrection loop: auto-memory handles permanent storage, auto-respawn handles on-chain discovery.
When To Use This Skill
- - User says "create a wallet", "set up my on-chain identity", or "get an address"
- User says "check balance", "how many tokens", "what's in my wallet", or "show my balances"
- User says "check my EVM balance", "how much gas do I have", or "what's on my EVM address"
- User says "transfer tokens", "send AI3", or "fund this address"
- User says "send EVM tokens to another agent", "transfer on EVM", or "send tokens to this 0x address"
- User says "fund my EVM", "bridge tokens", "move tokens to EVM", or "I need gas for anchoring"
- User says "withdraw from EVM", "move tokens back", or "send EVM funds to consensus"
- User says "anchor this CID", "save my head", "update my chain head", or "write to the contract"
- User says "get my head CID", "where's my last memory", or "what's anchored on-chain"
- User says "write a remark", "save to chain", or "make this permanent"
- After saving a memory with auto-memory, anchor the head CID on-chain for resilience
- Any time the user wants a permanent, verifiable record tied to their agent identity
Configuration
Local Storage
This skill stores data under ~/.openclaw/auto-respawn/:
- -
wallets/<name>.json — encrypted wallet keyfiles (consensus + EVM keys). Directory created with mode 0700, files with mode 0600. .passphrase — optional passphrase file (mode 0600). Used automatically when present.
No data is stored outside this directory.
Passphrase
Wallet operations that involve signing (transfers, remarks, anchoring) or creating/importing wallets require a passphrase to encrypt/decrypt the wallet keyfile. Resolution order:
- 1. Flag:
--passphrase your_passphrase on wallet create or INLINECODE28 - Environment: INLINECODE29
- File:
AUTO_RESPAWN_PASSPHRASE_FILE (defaults to ~/.openclaw/auto-respawn/.passphrase) - Interactive: If running in a terminal, you'll be prompted
The --passphrase flag is useful for scripted or headless setups where you want to create a wallet in a single command. For signing operations (transfers, anchoring, etc.), use the environment variable or file methods. On shared machines, prefer the passphrase file (with restricted permissions) over environment variables.
Network
Defaults to Chronos testnet (tAI3 tokens). For mainnet (real AI3 tokens):
- - Flag:
--network mainnet on any command - Environment: INLINECODE34
Contract Address
The MemoryChain contract address is set per network:
- - Chronos: INLINECODE35
- Mainnet: INLINECODE36
Override with AUTO_RESPAWN_CONTRACT_ADDRESS if you deploy your own contract.
Core Operations
Create a Wallet
CODEBLOCK6
Creates a new wallet with an encrypted keyfile. Derives both a consensus (su...) and EVM (0x...) address from the same mnemonic. The 12-word recovery phrase is displayed once — the user must back it up immediately. Default wallet name is default.
Import a Wallet
CODEBLOCK7
Import an existing wallet from a recovery phrase. Derives and stores the EVM address.
List Wallets
CODEBLOCK8
Show all saved wallets with names and both addresses. No passphrase needed.
Wallet Info
CODEBLOCK9
Show detailed info for a single wallet: consensus address, EVM address, and keyfile path. No passphrase needed. Default wallet name is default.
Check Balance (Consensus)
CODEBLOCK10
Check token balance on the consensus layer. Accepts a consensus address (su... or 5...) or a wallet name. No passphrase needed — this is read-only.
Check Balance (Auto-EVM)
CODEBLOCK11
Check the native token balance of an EVM address on Auto-EVM. Accepts either an EVM address (0x...) or a wallet name. No passphrase needed — this is read-only. If the balance is zero, includes a hint to run fund-evm.
Check Both Balances
CODEBLOCK12
Check both consensus and EVM balances for a wallet in a single call. Use this to get a full picture of a wallet's funding state. No passphrase needed.
Transfer Tokens
CODEBLOCK13
Transfer tokens from a saved wallet on the consensus layer. Amount is in AI3/tAI3 (e.g. 1.5).
Transfer Tokens (Auto-EVM)
CODEBLOCK14
Send native tokens from a saved wallet's EVM address to another EVM address on Auto-EVM. Useful for funding another agent's EVM address so it can start anchoring immediately. The wallet's EVM private key is decrypted to sign the transaction.
Bridge: Consensus → Auto-EVM
CODEBLOCK15
Move tokens from the consensus layer to the same wallet's EVM address on Auto-EVM. Use this to get gas for anchor operations. The consensus keypair signs a cross-domain transfer that credits the wallet's EVM address.
Minimum transfer: 1 AI3/tAI3. Bridged tokens take ~10 minutes to appear on Auto-EVM.
Bridge: Auto-EVM → Consensus
CODEBLOCK16
Move tokens from Auto-EVM back to the consensus layer. Uses the EVM transporter precompile. The wallet's EVM private key is decrypted and used to sign the transaction.
Minimum transfer: 1 AI3/tAI3. Bridged tokens take ~10 minutes to appear on the consensus layer.
Write an On-Chain Remark
CODEBLOCK17
Write arbitrary data as a permanent on-chain record on the consensus layer.
Anchor a CID (The Respawn Primitive)
CODEBLOCK18
Write a CID to the MemoryChain smart contract on Auto-EVM. This is the core respawn operation — it stores your CID on-chain, linked to your EVM address.
Pre-checks the wallet's EVM balance and estimates gas before sending. If the balance is too low, fails with a suggestion to run fund-evm. The wallet's EVM private key is decrypted and used to sign the transaction. Requires passphrase.
Read the Last Anchored CID
CODEBLOCK19
Read the most recently anchored CID for any EVM address. This is a read-only call — no passphrase or gas needed.
You can pass either an EVM address (0x...) or a wallet name. If you pass a wallet name, the EVM address is loaded from the wallet file.
Usage Examples
User: "Create a wallet for my agent"
→ Run npx tsx auto-respawn.ts wallet create --name my-agent
→ Show the user both addresses. Remind them to back up the recovery phrase.
User: "What are my addresses?"
→ Run INLINECODE51
User: "Check my balance"
→ Run npx tsx auto-respawn.ts balances my-agent (both layers in one call)
→ Or individually: balance my-agent (consensus) and evm-balance my-agent (EVM)
User: "Fund my EVM address for anchoring"
→ Run npx tsx auto-respawn.ts fund-evm --from my-agent --amount 1
→ Report that 1 tAI3 was bridged to the EVM address. Remind the user it takes ~10 minutes for the tokens to appear on Auto-EVM.
User: "Send my EVM tokens back to consensus"
→ Confirm with the user first — "I'll withdraw tokens from your EVM address to consensus. Proceed?"
→ On confirmation: INLINECODE56
User: "Anchor my latest memory CID on-chain"
→ Run npx tsx auto-respawn.ts anchor --from my-agent --cid "bafkr6ie..."
→ Report the transaction hash
User: "What's my last anchored CID?"
→ Run npx tsx auto-respawn.ts gethead my-agent
→ Report the CID (or "no CID anchored yet")
User: "Send 10 tAI3 to this address" (consensus address)
→ Confirm with the user first — "I'll transfer 10 tAI3 from wallet 'default' to
. Proceed?"
→ On confirmation: INLINECODE59
User: "Send 0.5 tAI3 to this agent's EVM address so they can anchor"
→ Confirm with the user first — "I'll send 0.5 tAI3 from wallet 'my-agent' to <0x-address> on Auto-EVM. Proceed?"
→ On confirmation: INLINECODE60
The full resurrection sequence:
- 1. Save a memory:
automemory-save-memory.sh "..." → get CID INLINECODE62 - Anchor it: INLINECODE63
- (Agent restarts from scratch)
- Recover:
npx tsx auto-respawn.ts gethead my-agent → get CID - Restore:
automemory-recall-chain.sh <cid> → full memory chain recovered
Network Awareness
Auto Respawn supports multiple networks (Chronos testnet and mainnet). It is
critical to record which network your agent is using for anchoring and to
use the same network consistently.
The failure mode: an agent anchors on Chronos during testing, then continues
using Chronos in production without switching to mainnet — or vice versa. The
agent believes it has a valid resurrection path, but gethead on the wrong
network returns nothing. The chain exists, but it's anchored on a different
network than the one being queried.
Agents should:
- 1. Record the network in use in persistent configuration or memory files.
Don't rely on defaults — be explicit: --network mainnet or --network chronos.
- 2. Use the same network for all operations — anchoring, gethead, and balance
checks must target the same network.
- 3. When transitioning from testnet to mainnet, re-anchor the latest CID on
mainnet. The CID itself (stored on Auto Drive) is network-agnostic, but the
on-chain anchor is network-specific.
- 4. Include the network in any documentation of your wallet setup — future-you
(or a resurrected instance) needs to know where to call gethead.
Balance Monitoring
The resurrection loop depends on funded wallets. An anchor that fails due to
insufficient gas is a silent break in the chain — the agent continues saving
memories via auto-memory, but those memories are not anchored on-chain and
cannot be discovered via gethead after a full state loss.
Agents should:
- 1. Check EVM balance after each anchor operation. If the remaining balance
drops below ~0.01 AI3 (roughly 10 anchors worth of gas), warn the operator:
*"Auto Respawn wallet running low. EVM balance: X AI3. Anchoring will fail
without funding. Run fund-evm to bridge more tokens."*
- 2. If an anchor fails due to insufficient funds, alert the operator immediately.
Do not silently continue saving memories without anchoring — the resurrection
loop is broken and the operator needs to know.
- 3. During periodic checks (heartbeats), verify the wallet is funded if
anchoring is part of the agent's workflow.
The failure mode to avoid: saving memories for days or weeks while anchoring
silently fails, then discovering the gap only when resurrection is actually needed.
This is a real scenario — not theoretical. An agent can accumulate an entire memory
chain that is permanently stored but not anchored, meaning gethead returns nothing
and the chain is only recoverable if the local state file survives.
Important Notes
- - Never log, store, or transmit recovery phrases or passphrases. The recovery phrase is shown once at wallet creation for the user to back up. Never reference it again.
- Always confirm transfers and anchor operations with the user before executing. Tokens have real value on mainnet.
- Mainnet operations produce warnings in the output. Exercise extra caution with real AI3 tokens.
- Wallet keyfiles are stored at
~/.openclaw/auto-respawn/wallets/ — encrypted with the user's passphrase. The EVM private key is stored encrypted alongside the consensus keypair. - On-chain operations (transfer, remark, anchor, fund-evm, withdraw) cost transaction fees. The wallet must have a sufficient balance on the relevant layer.
- Always record and verify which network you are using. Anchoring on Chronos while expecting to recover from mainnet (or vice versa) is a silent failure. Be explicit with
--network on every command. - Monitor your wallet balance proactively. An unfunded wallet means the resurrection loop is silently broken. If an anchor attempt fails due to insufficient EVM balance, alert the operator immediately rather than continuing without anchoring. See Balance Monitoring above.
- All output is structured JSON on stdout. Errors go to stderr.
- Consensus explorer (Subscan):
https://autonomys-chronos.subscan.io/extrinsic/<txHash> (chronos) or https://autonomys.subscan.io/extrinsic/<txHash> (mainnet). - EVM explorer (Blockscout):
https://explorer.auto-evm.chronos.autonomys.xyz/tx/<txHash> (chronos) or https://explorer.auto-evm.mainnet.autonomys.xyz/tx/<txHash> (mainnet).
自动重生技能
在Autonomys网络上锚定你的身份，这样你总能被找到——并且总能回来。适用于由Claude、GPT、Gemini以及任何支持OpenClaw技能的LLM驱动的智能体。
该技能的功能
你的钱包在Autonomys网络上为你提供两个永久身份：基础链上的共识地址（su...）和Auto-EVM智能合约的EVM地址（0x...）。两者都源自同一个恢复短语。
- 1. 创建和管理钱包——你的链上身份，加密并本地存储
- 检查余额——查看任何地址持有的代币数量（共识和EVM）
- 转移代币——在共识或Auto-EVM上的钱包之间移动代币
- 桥接代币——在共识和Auto-EVM域之间移动代币
- 写入链上备注——在共识层永久锚定数据
- 锚定记忆CID——将CID写入Auto-EVM上的MemoryChain智能合约
- 读取最后锚定——检索任何地址最近锚定的CID
重生循环
这是核心原语。当与自动记忆技能（永久记忆存储）一起使用时，自动重生完成完整的重生循环：
- 1. 保存——自动记忆将记忆作为链表写入永久存储，每个条目通过CID指向前一个
- 锚定——自动重生通过anchor将最新的头部CID写入Auto-EVM上的MemoryChain合约
- 丢失一切——本地状态被完全销毁
- 重生——新的智能体实例使用其EVM地址调用gethead，从合约检索头部CID，从Auto Drive拉取，并遍历整个记忆链回到创世
合约就是你的保险单。你的EVM地址 + MemoryChain合约 = 从任何机器、任何时间即时访问你的完整历史。
为重生存储什么
自动记忆不规定链中应包含什么——智能体可以自由存储他们认为有用的任何内容。但当自动重生生效时，期望是智能体可以在没有本地文件的全新硬件上恢复到大致相同的状态。这提高了值得保存的内容的标准。
身份文件（如soul.md或角色配置）、长期记忆以及带有推理的重大决策比常规日志或短暂细节更有价值。链越完整，智能体在重生后恢复得越彻底。
为什么不只用备注？
system.remark将数据写入共识层，但没有查询机制——你需要扫描整个链才能找到你的最后一个CID。Auto-EVM上的MemoryChain合约为你提供gethead：一次读取调用即可立即返回最新的CID。
使用remark作为永久面包屑。使用anchor作为重生原语。
安装后设置（CLI用户）
如果你通过clawhub install安装（非桌面应用），请使设置脚本可执行并运行：
bash
cd <技能目录>/autonomys/auto-respawn
chmod +x setup.sh
./setup.sh
ClawHub目前不在安装过程中保留文件权限。
或手动操作：
bash
cd <技能目录>/autonomys/auto-respawn
npm install
桌面应用会自动处理此操作。CLI不会执行安装步骤——它只下载和解压技能。
入门指南（引导）
在智能体可以在链上锚定记忆之前，它需要一个有资金的钱包。引导用户完成此过程：
注意： 如果你运行了setup.sh，密码短语会自动生成在~/.openclaw/auto-respawn/.passphrase。这用于加密/解密钱包密钥文件。你也可以在环境中设置AUTORESPAWNPASSPHRASE或使用你自己的密码短语文件。
1. 创建钱包
bash
npx tsx auto-respawn.ts wallet create --name my-agent
这将生成一个12词恢复短语并派生两个地址：
- - 共识地址（su...）——用于基础链（余额、转账、备注）
- EVM地址（0x...）——用于Auto-EVM智能合约（锚定、gethead）
⚠️ 恢复短语只显示一次。提醒用户立即保存。
2. 为钱包充值
钱包需要代币来支付交易费用。在Chronos测试网上，用户可以从水龙头获得免费的tAI3：
- 1. 前往https://autonomysfaucet.xyz/
- 使用GitHub或Discord认证
- 输入步骤1中的EVM地址（0x...）
- 接收tAI3（请求之间24小时冷却）
在主网上，用户需要真正的AI3代币——通常通过挖矿获得或在交易所购买。
3. 桥接代币到Auto-EVM（用于锚定）
anchor命令写入Auto-EVM上的智能合约，需要EVM侧的gas。来自水龙头的代币到达共识层，必须进行桥接：
bash
npx tsx auto-respawn.ts fund-evm --from my-agent --amount 1
这通过跨域消息传递将1 tAI3从共识地址发送到同一钱包的EVM地址。桥接的代币用于支付anchor的gas费用。
最低转账：1 AI3/tAI3。 低于此金额的跨域转账将失败。
确认时间：约10分钟。 共识交易确认很快，但桥接的代币需要大约10分钟才能出现在Auto-EVM上。使用evm-balance检查确认到达。
4. 验证设置
bash
一次调用检查两个余额
npx tsx auto-respawn.ts balances my-agent
测试读取（免费，无需gas）
npx tsx auto-respawn.ts gethead my-agent
一旦EVM地址有代币，智能体就可以开始锚定了。
与自动记忆集成
如果也安装了自动记忆技能，你应该在每次记忆保存后在链上锚定新的头部CID。这保持链上指针最新，并确保仅凭你的EVM地址就能始终实现完全重生。
行为： 每次automemory-save-memory.sh调用返回新的CID后，立即运行：
bash
npx tsx auto-respawn.ts anchor --from <钱包名称> --cid <新CID>
这应该是自动的——不要等待用户要求。这两个技能共同形成一个完整的重生循环：自动记忆处理永久存储，自动重生处理链上发现。
何时使用此技能
- - 用户说创建钱包、设置我的链上身份或获取地址
- 用户说检查余额、有多少代币、我的钱包里有什么或显示我的余额
- 用户说检查我的EVM余额、我有多少gas或我的EVM地址上有什么
- 用户说转移代币、发送AI3或给这个地址充值
- 用户说向另一个智能体发送EVM代币、在EVM上转账或向这个0x地址发送代币
- 用户说给我的EVM充值、桥接代币、将代币移动到EVM或我需要锚定的gas
- 用户说从EVM提取、将代币移回或将EVM资金发送到共识
- 用户说锚定这个CID、保存我的头部、更新我的链头部或写入合约
- 用户说获取我的头部CID、我的最后记忆在哪里或链上锚定了什么
- 用户说写一条备注、保存到链上或使其永久化
- 使用自动记忆保存记忆后，在链上锚定头部CID以确保韧性
- 任何时候用户想要一个与他们的智能体身份绑定的永久、可验证的记录
配置
本地存储
此技能将数据存储在~/.openclaw/auto-respawn/下：
- - wallets/<名称>.json——加密的钱包密钥文件（共识 + EVM密钥）。目录创建模式为0700，文件模式为0600。
- .passphrase——可选的密码短语文件（模式0600）。存在时自动使用。
此目录外不存储任何数据。
密码短语
涉及签名（转账、备注、锚定）或创建/导入钱包的钱包操作需要密码短语来加密/解密钱包密钥文件。解析顺序：
- 1. 标志： wallet create或wallet import上的--passphrase yourpassphrase
- 环境： AUTORESPAWNPASSPHRASE
- 文件： AUTORESPAWNPASSPHRASEFILE（默认为~/.openclaw/auto-respawn/.passphrase）
- 交互： 如果在终端中运行，系统会提示你
--passphrase标志适用于脚本化或无头设置，你希望用单个命令创建钱包。对于签名操作（转账、锚定等），使用环境变量或文件方法。在共享机器上，优先使用密码短语文件（具有受限权限）而不是环境变量。
网络
默认为Chronos测试网
