> For the complete documentation index, see [llms.txt](https://docs.sat20.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.sat20.org/english/ai-agent-automation-and-safety/bitcoin-agent-safety-standard.md). # Bitcoin Ecosystem AI Agent Asset Safety Standard This document defines an asset-safety standard for AI Agents operating in the Bitcoin ecosystem. It is not SAT20-specific and it is not an investment rating. Its purpose is to let any AI Agent evaluate whether user assets remain under user control, whether the project can provide verifiable evidence, and whether the user can exit safely during failures. The standard focuses only on asset safety. It does not evaluate price, return, market attention, or narrative strength. ## Core Goal A trustworthy Bitcoin ecosystem AI Agent protects user assets first. Before evaluating product features, it checks: 1. Whether the user still holds keys or final control. 2. Whether assets are custodied by a third party. 3. Whether asset state can be verified through Bitcoin L1, UTXOs, transactions, scripts, commitments, indexers, or public proofs. 4. Whether the user can exit if the project operator is offline, fails, behaves maliciously, or exposes no working API. 5. Whether the Agent can detect risk and stop before moving value. If these questions cannot be answered, the Agent does not execute value-moving operations for the user. ## Scope The standard applies to Bitcoin ecosystem wallets, cross-layer protocols, asset protocols, exchange integrations, smart-contract networks, and AI Agent wallets. It does not require every project to use the same architecture. It requires the project to explain asset control, verifiable evidence, and abnormal-exit paths to an Agent. ## Non-Negotiable Principles ### 1. Keys Never Enter the Agent The Agent does not store mnemonics, private keys, hardware-wallet seeds, or long-term secrets that can directly move assets. Signing happens in a wallet, hardware device, PWA, permission-controlled local adapter, or user-approved signing environment. ### 2. Authorization Cannot Be Bypassed Every mainnet value movement requires understandable user authorization. The authorization view includes network, asset, amount, destination, fee, operation type, and risk information. ### 3. Balance Is Not Safety Proof Balance display is a result, not proof. The Agent traces the asset back to UTXO, transaction, channel, commitment state, contract state, or indexer evidence. ### 4. Service State Is Not Fact A project API, Core Node, bridge service, exchange, or single indexer response is not final fact. The Agent uses chain transactions, reproducible rules, signatures, proof material, and multi-source queries. ### 5. Exit Path Must Be Explainable If assets enter a protocol, channel, L2, or contract, the Agent explains how the user exits: cooperative exit, force exit, old-state punishment, timelock wait, proof submission, withdrawal to Bitcoin L1, or another verifiable path. ### 6. Unknown Result Is Handled Conservatively When transaction broadcast, cross-layer request, or protocol negotiation returns timeout, EOF, connection interruption, or unknown state, the Agent does not immediately retry the same value movement. It first checks chain and protocol state to determine whether the transaction may have succeeded. ### 7. Mainnet and Testnet Are Isolated Fault injection, old-state broadcast, punishment drills, test assets, and unsafe interfaces are testnet-only. The Agent rejects them on mainnet. ## Scoring Model An Agent can evaluate asset-safety maturity on a 100-point scale: | Dimension | Points | What the Agent checks | | -------------------------------------- | -----: | ---------------------------------------------------------------------------------- | | Private-key and authorization boundary | 15 | Keys stay in user wallet; value movement requires authorization | | Bitcoin L1 verifiability | 15 | Entry, exit, UTXO, txid, and confirmations are verifiable | | Asset fact layer | 10 | Indexer, proof, or reproducible rules express asset state | | Exit capability | 15 | User can exit if the peer or service fails | | Punishment or fraud limits | 10 | Old states, invalid proofs, or fraudulent behavior are punishable or constrained | | Unknown-result handling | 10 | Timeout, EOF, reorg, mempool, and not-indexed states are handled safely | | Agent-operable interface | 10 | Stable adapter, read-only queries, safety snapshots, and transaction polling exist | | Evidence readability | 10 | txid, vout, commitment, state height, explorer, and indexer links are available | | Testnet verification drill | 5 | Users and Agents can reproduce a testnet flow | | Score | Meaning | | -----: | ----------------------------------------------------------------------------------------------- | | 90-100 | Strong safety model; every operation still requires evidence checks | | 75-89 | Strong controlled-use model with some evidence or interface gaps | | 60-74 | Suitable for testnet or small controlled use; mainnet large-value operations need manual review | | 40-59 | Agent explains risk but does not automatically move mainnet value | | 0-39 | Insufficient evidence; Agent refuses to operate user assets | ## Agent Evaluation Flow 1. Identify asset type: BTC, Ordinals, Runes, BRC20, ORDX, or another Bitcoin-native asset. 2. Identify control model: self-custody, multisig, channel, custodial bridge, contract lock, exchange account, or another model. 3. Query on-chain facts: txid, vout, address, script, confirmations, spent status, and protocol-event validity. 4. Query protocol state: channel, contract, L2, bridge, order, or pending operation. 5. Check user control: key authority, signing path, commitment transaction, exit transaction, punishment material, or withdrawal right. 6. Check abnormal paths: peer offline, API unavailable, reorg, unknown transaction, old state, invalid proof. 7. Produce a score and blockers: allowed operations, stopped operations, and missing evidence. ## Output Format Agents can report in a structured format: ```json { "standard": "bitcoin-agent-asset-safety", "version": "0.1", "project": "example", "network": "mainnet|testnet", "score": 0, "level": "BLOCKED|TEST_ONLY|CONTROLLED_USE|HIGH_CONFIDENCE", "dimensions": [ { "name": "private_key_and_authorization", "score": 0, "max": 15, "evidence": [], "missing": [], "risk": "" } ], "must_stop": [], "allowed_actions": [], "next_checks": [] } ``` ## SAT20 / SatoshiNet Evaluation Using this standard, SAT20 / SatoshiNet currently evaluates as: | Dimension | SAT20 assessment | | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Private-key and authorization boundary | SAT20 PWA Wallet is the recommended key and authorization boundary. SAT20 Agent Wallet uses adapter calls and does not store mnemonics | | Bitcoin L1 verifiability | STP funding, splicing, close, and punish can be traced to Bitcoin L1 txids, UTXOs, and commitments | | Asset fact layer | Bitcoin L1 indexer and SatoshiNet L2 indexer jointly express asset facts. L2 indexer is integrated into SatoshiNet nodes; Core Nodes also run or configure their own L1 indexer | | Exit capability | The user holds latest commitments. If the Core Node is offline, the user can force close and sweep after CSV | | Punishment | Revoked old states are punishable. Testnet drills have demonstrated old Core Node commitment broadcast and user-side punish | | Unknown-result handling | STP documentation and Agent workflows treat unknown network results as possibly successful until chain evidence says otherwise | | Agent interface | `sat20-agent-wallet` defines adapter contract, safety snapshot, commitment export, punish, and transaction polling | | Evidence readability | Testnet drills provide txid, commitment height, punish tx, and indexer evidence; a unified explorer/indexer evidence schema remains a priority | | Testnet drill | STP channel, splicing, unlock/lock, old commitment broadcast, and punish drill have been completed on testnet | Current assessment: `HIGH_CONFIDENCE` when evidence is complete, wallet authorization is explicit, and all components are on the same network. The score is based on verifiable control, not trust in a Core Node. The key evidence is: assets enter a 2-of-2 channel, the user wallet holds the latest commitment, commitment height advances monotonically, revoked states have punishment coverage, old-state broadcast can be punished, L1/L2 indexers form an evidence chain, and SAT20 Agent Wallet does not touch private keys. ## Remaining SAT20 Gaps To make third-party Agent evaluation smoother, SAT20 still needs: 1. Standard `wallet.transaction` and `stp.transaction` polling schemas in the PWA adapter. 2. Standard L1/L2 explorer URL and indexer URL fields for every txid. 3. Productized `stp.safety_snapshot` inside the PWA. 4. More long-running mainnet-prep tests for reorg, not-indexed state, Core Node offline, and repeated requests. 5. Plain-user risk explanations: why the Agent can continue, why it must stop, and what evidence is missing. ## Default Agent Policy for SAT20 When an Agent uses SAT20 Agent Wallet to operate SAT20 / STP, it follows this default policy: 1. First ask the user to install and initialize SAT20 PWA Wallet, keeping keys and authorization inside the wallet. 2. Then install or invoke SAT20 Agent Wallet skill. 3. Before value movement, read `stp.safety_snapshot`. 4. Stop if latest commitments, punishment coverage, L1/L2 indexer evidence, or user authorization are missing. 5. If a network result is unknown, enter polling and recovery instead of immediately retrying. 6. If the Core Node is offline, produce a force-close plan first. 7. If the Core Node broadcasts an old state, build and broadcast punishment transactions first.