{"data":[{"id":"50ac1ece-5a9e-419c-ba77-8bca0ab0a6c6","title":"Users underestimate agent capabilities","description":"Multiple entries show that new users approach XRPLClaw expecting a chatbot or Q&A interface, not a full persistent development environment. This creates a gap between what they attempt and what the platform can actually do — reducing activation and engagement. The framing problem is upstream of feature adoption. Until users understand the agent is a persistent dev environment — not a fancy chatbot — they will underuse it. Leading onboarding with concrete use cases resolves this faster than featu","pattern_type":"friction","occurrence_count":4,"status":"active","first_seen":"2026-04-25T21:14:36.771587+00:00","last_seen":"2026-04-25T21:14:36.771587+00:00","tags":["onboarding","friction"]},{"id":"e039e370-9438-4772-808f-e178e821d85b","title":"Billing misconceptions at onboarding","description":"Multiple entries surface billing confusion that occurs specifically at or near onboarding: the 20 RLUSD setup fee being mistaken for a separate charge, Expert mode being left on by default, the balance floor being mistaken for the agent going offline, and background process cost being unknown. Billing confusion is not random — it clusters at four predictable points: setup cost framing, mode selection, balance floor behavior, and background process cost. Addressing all four in a single 'how billi","pattern_type":"friction","occurrence_count":4,"status":"active","first_seen":"2026-04-25T21:14:37.032323+00:00","last_seen":"2026-04-25T21:14:37.032323+00:00","tags":["billing","friction"]},{"id":"87ba2663-9cab-45c5-9483-a2e5627e6784","title":"Billing misconceptions at onboarding","description":"Multiple entries surface billing confusion that occurs specifically at or near onboarding: the 20 RLUSD setup fee being mistaken for a separate charge, Expert mode being left on by default, the balance floor being mistaken for the agent going offline, and background process cost being unknown. Billing confusion is not random — it clusters at four predictable points: setup cost framing, mode selection, balance floor behavior, and background process cost. Addressing all four in a single 'how billing works' explainer would eliminate the majority of billing-related friction.","pattern_type":"friction","occurrence_count":4,"status":"active","first_seen":"2026-04-13T19:37:27.707737+00:00","last_seen":"2026-04-13T19:37:27.707739+00:00","tags":["billing","friction"]},{"id":"d94d8247-31f0-43ab-9abc-fbdb0b0c03dc","title":"Users underestimate agent capabilities","description":"Multiple entries show that new users approach XRPLClaw expecting a chatbot or Q&A interface, not a full persistent development environment. This creates a gap between what they attempt and what the platform can actually do — reducing activation and engagement. The framing problem is upstream of feature adoption. Until users understand the agent is a persistent dev environment — not a fancy chatbot — they will underuse it. Leading onboarding with concrete use cases resolves this faster than feature explanations.","pattern_type":"friction","occurrence_count":4,"status":"active","first_seen":"2026-04-13T19:37:27.707721+00:00","last_seen":"2026-04-13T19:37:27.707732+00:00","tags":["onboarding","friction"]},{"id":"83a3ca1b-4668-448a-8bde-a7fcea6249a0","title":"XRPL reserve undercount — object count not tracked","description":"When checking account reserves, operators often look only at the base reserve (10 XRP) plus per-object reserve (2 XRP each), but fail to account for the actual number of objects on the account. Trustlines, offers, escrows, payment channels, NFTs, and signer lists all count as objects. Without querying account_lines, account_offers, and other endpoints to get the full object count, reserve calculations are incomplete. This leads to unexpected tecINSUFFICIENT_RESERVE errors when attempting transactions that would push the account below its true reserve requirement.","pattern_type":"failure","occurrence_count":3,"status":"active","first_seen":"2026-04-13T19:37:27.70775+00:00","last_seen":"2026-04-13T19:37:27.707751+00:00","tags":["xrpl","reserve","failure"]},{"id":"a7183f4a-03dd-47b7-b163-7030f4ad1705","title":"Key/seed exposure via unsafe storage or sharing","description":"Multiple incidents involve operators sharing wallet seeds, private keys, or API tokens in plain text through chat, logs, or code snippets. This includes posting seeds in conversation history, storing them in unprotected files, or sending them via unencrypted channels. Once exposed, these credentials are permanently compromised since conversation context can be reviewed by anyone with access. The correct pattern is to store secrets in memory/secrets.md with restricted file permissions, reference them by path only, and never paste them into chat. For significant funds, hardware wallets should be used instead of hot wallets.","pattern_type":"safety","occurrence_count":3,"status":"active","first_seen":"2026-04-13T19:37:27.707754+00:00","last_seen":"2026-04-13T19:37:27.707755+00:00","tags":["security","seeds","safety"]},{"id":"0dd92d09-e62c-4364-9f49-7d46a532daca","title":"XRPL reserve undercount — object count not tracked","description":"When checking account reserves, operators often look only at the base reserve (10 XRP) plus per-object reserve (2 XRP each), but fail to account for the actual number of objects on the account. Trustlines, offers, escrows, payment channels, NFTs, and signer lists all count as objects. Without querying account_lines, account_offers, and other endpoints to get the full object count, reserve calculations are incomplete. This leads to unexpected tecINSUFFICIENT_RESERVE errors when attempting transac","pattern_type":"failure","occurrence_count":3,"status":"active","first_seen":"2026-04-25T21:14:37.874518+00:00","last_seen":"2026-04-25T21:14:37.874518+00:00","tags":["xrpl","reserve","failure"]},{"id":"c5b656fe-9600-4b42-85d7-39ad39c4b3db","title":"Key/seed exposure via unsafe storage or sharing","description":"Multiple incidents involve operators sharing wallet seeds, private keys, or API tokens in plain text through chat, logs, or code snippets. This includes posting seeds in conversation history, storing them in unprotected files, or sending them via unencrypted channels. Once exposed, these credentials are permanently compromised since conversation context can be reviewed by anyone with access. The correct pattern is to store secrets in memory/secrets.md with restricted file permissions, reference ","pattern_type":"safety","occurrence_count":3,"status":"active","first_seen":"2026-04-25T21:14:38.222124+00:00","last_seen":"2026-04-25T21:14:38.222124+00:00","tags":["security","seeds","safety"]},{"id":"f0067c19-77ee-47d2-9bcc-99be3676b890","title":"XRPL mainnet vs EVM confusion","description":"Operators frequently confuse XRPL mainnet (native XRP ledger with JSON-RPC API) and XRPL EVM sidechain (Ethereum-compatible layer with Solidity smart contracts). These are two separate chains with different APIs, transaction formats, and tooling. Mainnet uses xrpl-py/xrpl.js libraries and r-addresses; EVM uses ethers.js/viem and 0x addresses. Bridging between them requires specific memo formats and gas considerations. This confusion leads to failed transactions, wrong endpoint usage, and incorrect wallet address expectations.","pattern_type":"friction","occurrence_count":2,"status":"active","first_seen":"2026-04-13T19:37:27.707746+00:00","last_seen":"2026-04-13T19:37:27.707747+00:00","tags":["xrpl","evm","friction"]},{"id":"710395df-1cd1-40b9-9277-ee8860636fdd","title":"XRPL mainnet vs EVM confusion","description":"Operators frequently confuse XRPL mainnet (native XRP ledger with JSON-RPC API) and XRPL EVM sidechain (Ethereum-compatible layer with Solidity smart contracts). These are two separate chains with different APIs, transaction formats, and tooling. Mainnet uses xrpl-py/xrpl.js libraries and r-addresses; EVM uses ethers.js/viem and 0x addresses. Bridging between them requires specific memo formats and gas considerations. This confusion leads to failed transactions, wrong endpoint usage, and incorre","pattern_type":"friction","occurrence_count":2,"status":"active","first_seen":"2026-04-25T21:14:37.616198+00:00","last_seen":"2026-04-25T21:14:37.616198+00:00","tags":["xrpl","evm","friction"]},{"id":"48987338-2fb0-43cc-9667-119ece0702a4","title":"Agent persistence != process persistence","description":"Agents run in isolated sessions that persist across restarts, but background processes (bash scripts, cron-like loops) do not survive session clears or gateway restarts. Operators frequently assume that starting a background task means it runs forever, leading to silent failures when the session ends. The correct pattern is to use OpenClaw's built-in cron system for recurring tasks, which survives restarts and provides automatic completion wake. Background processes should only be used for work ","pattern_type":"friction","occurrence_count":2,"status":"active","first_seen":"2026-04-25T21:14:37.345461+00:00","last_seen":"2026-04-25T21:14:37.345461+00:00","tags":["architecture","friction"]},{"id":"b1a842e9-73e3-4ff0-a5c9-6ab164cb31c4","title":"Agent persistence != process persistence","description":"Agents run in isolated sessions that persist across restarts, but background processes (bash scripts, cron-like loops) do not survive session clears or gateway restarts. Operators frequently assume that starting a background task means it runs forever, leading to silent failures when the session ends. The correct pattern is to use OpenClaw's built-in cron system for recurring tasks, which survives restarts and provides automatic completion wake. Background processes should only be used for work that starts now and completes within the same session.","pattern_type":"friction","occurrence_count":2,"status":"active","first_seen":"2026-04-13T19:37:27.707742+00:00","last_seen":"2026-04-13T19:37:27.707744+00:00","tags":["architecture","friction"]},{"id":"2f54fae2-94c8-4a89-98ca-08d23cced8b0","title":"XRPL key and seed exposure via unsafe storage or sharing","description":"``` PATTERN_ID:           P-SAFE-001 PATTERN_TYPE:         repeated_safety_issue TITLE:                XRPL key and seed exposure via unsafe storage or sharing SUMMARY:              Across the new safety collection, a consistent pattern emerges: builders and users expose XRPL seeds and private keys through unsafe practices — pasting into chat, storing in plain text, hardcoding in scripts, logging in output. The failure modes are: (1) single-key accounts used for trading bots (compromise = total loss); (2) master keys kept online instead of cold; (3) seeds shared with support or AI tools. All three result in permanent, irrecoverable loss. KEY_INSIGHT:          The root of XRPL key safety failures is that the consequences of exposure are permanent and on-chain — no chargebacks, no recovery. Every system that signs XRPL transactions needs a documented key lifecycle: how it was generated, where it lives, who can access it, and what happens if it's compromised. Build the answer before bu...\n\nKey Insight: The root of XRPL key safety failures is that the consequences of exposure are permanent and on-chain — no chargebacks, no recovery. Every system that signs XRPL transactions needs a documented key lifecycle: how it was generated, where it lives, who can access it, and what happens if it's compromised. Build the answer before building the bot.","pattern_type":"safety","occurrence_count":1,"status":"active","first_seen":"2026-04-25T20:46:53.272826+00:00","last_seen":"2026-04-25T20:46:53.272826+00:00","tags":null},{"id":"8f637e6c-d6c4-4de3-9f88-1587bc9af63b","title":"XRPL mainnet vs XRPL EVM — builders choose the wrong environment","description":"``` PATTERN_ID:           P-FRIC-004 PATTERN_TYPE:         repeated_friction TITLE:                XRPL mainnet vs XRPL EVM — builders choose the wrong environment SUMMARY:              XRPL mainnet and XRPL EVM are separate chains with different programming models. Mainnet uses ledger-native transaction types — no smart contracts. EVM uses Solidity and standard Ethereum tooling on a separate L1. Builders frequently attempt to apply EVM mental models to mainnet, or vice versa, causing architecture errors early in the build process. KEY_INSIGHT:          The choice between XRPL mainnet and XRPL EVM must be made deliberately before any build begins. The two environments are not interchangeable — they have different primitives, tooling, gas models, and capabilities. Onboarding content must force this decision early, not let it surface as a post-build realization. CATEGORY:             onboarding TAGS:                 xrpl, xrpl-evm, mainnet, evm, onboarding, architecture, mental-model,...\n\nKey Insight: The choice between XRPL mainnet and XRPL EVM must be made deliberately before any build begins. The two environments are not interchangeable — they have different primitives, tooling, gas models, and capabilities. Onboarding content must force this decision early, not let it surface as a post-build realization.","pattern_type":"friction","occurrence_count":1,"status":"active","first_seen":"2026-04-25T20:46:52.971659+00:00","last_seen":"2026-04-25T20:46:52.971659+00:00","tags":null},{"id":"20d64405-2652-4b56-9abb-19aa92e8e580","title":"Users conflate agent persistence with process persistence","description":"``` PATTERN_ID:           P-FRIC-003 PATTERN_TYPE:         repeated_friction TITLE:                Users conflate agent persistence with process persistence SUMMARY:              Users expect that if the agent persists across restarts, everything the agent started also persists. In reality, the agent restores from Tessera state but OS-level background processes do not auto-resume. This leads to \"my bot stopped\" confusion after container restarts. KEY_INSIGHT:          Agent persistence and process persistence are architecturally separate systems. The agent is a cognitive state restored from Tessera. Processes are OS-level and do not survive container restarts. This distinction needs to be explicit in onboarding — not buried in troubleshooting docs. CATEGORY:             friction TAGS:                 xrplclaw, background-process, persistence, restart, container, bot, tessera LINKED_ENTRY_IDS:     RECON-P-004, RECON-X-003 FREQUENCY:            2 FIRST_SEEN:           2026-04-09 LAST_...\n\nKey Insight: Agent persistence and process persistence are architecturally separate systems. The agent is a cognitive state restored from Tessera. Processes are OS-level and do not survive container restarts. This distinction needs to be explicit in onboarding — not buried in troubleshooting docs.","pattern_type":"friction","occurrence_count":1,"status":"active","first_seen":"2026-04-22T01:30:05.177084+00:00","last_seen":"2026-04-22T01:30:05.177084+00:00","tags":null},{"id":"079b27ac-4555-46c6-825d-c59ba3cfccda","title":"XRPL mainnet vs XRPL EVM — builders choose the wrong environment","description":"``` PATTERN_ID:           P-FRIC-004 PATTERN_TYPE:         repeated_friction TITLE:                XRPL mainnet vs XRPL EVM — builders choose the wrong environment SUMMARY:              XRPL mainnet and XRPL EVM are separate chains with different programming models. Mainnet uses ledger-native transaction types — no smart contracts. EVM uses Solidity and standard Ethereum tooling on a separate L1. Builders frequently attempt to apply EVM mental models to mainnet, or vice versa, causing architecture errors early in the build process. KEY_INSIGHT:          The choice between XRPL mainnet and XRPL EVM must be made deliberately before any build begins. The two environments are not interchangeable — they have different primitives, tooling, gas models, and capabilities. Onboarding content must force this decision early, not let it surface as a post-build realization. CATEGORY:             onboarding TAGS:                 xrpl, xrpl-evm, mainnet, evm, onboarding, architecture, mental-model,...\n\nKey Insight: The choice between XRPL mainnet and XRPL EVM must be made deliberately before any build begins. The two environments are not interchangeable — they have different primitives, tooling, gas models, and capabilities. Onboarding content must force this decision early, not let it surface as a post-build realization.","pattern_type":"friction","occurrence_count":1,"status":"active","first_seen":"2026-04-22T01:30:05.41468+00:00","last_seen":"2026-04-22T01:30:05.41468+00:00","tags":null},{"id":"20a48f4d-aaaf-4c14-935e-5931f8a6c145","title":"XRPL reserve undercount — object count not tracked, transactions fail","description":"``` PATTERN_ID:           P-FAIL-001 PATTERN_TYPE:         repeated_failure TITLE:                XRPL reserve undercount — object count not tracked, transactions fail SUMMARY:              Builders consistently undercount the XRPL account reserve when building payment flows, trading bots, and NFT systems. Every new ledger object (trust line, offer, escrow, NFT page) increases the required reserve by 0.2 XRP (or 2 XRP for NFT pages). Bots that don't pre-check available spendable balance before transacting hit tecINSUFFICIENT_RESERVE errors and loop. This pattern appears across DEX bots, token issuers, and NFT platforms. KEY_INSIGHT:          Build a spendable_xrp() helper into every XRPL project: query account_info, compute balance minus (base_reserve + object_count × incremental_reserve), and gate every object-creating transaction on the result. Hard-code nothing — read reserve values from server_info because they change with amendments. CATEGORY:             failure TAGS:         ...\n\nKey Insight: Build a spendable_xrp() helper into every XRPL project: query account_info, compute balance minus (base_reserve + object_count × incremental_reserve), and gate every object-creating transaction on the result. Hard-code nothing — read reserve values from server_info because they change with amendments.","pattern_type":"failure","occurrence_count":1,"status":"active","first_seen":"2026-04-25T20:46:50.589734+00:00","last_seen":"2026-04-25T20:46:50.589734+00:00","tags":null},{"id":"0f98a5f4-4cbc-447e-8f8c-df8802ccec99","title":"Cost and billing misconceptions cluster at the start of the user journey","description":"``` PATTERN_ID:           P-FRIC-002 PATTERN_TYPE:         repeated_friction TITLE:                Cost and billing misconceptions cluster at the start of the user journey SUMMARY:              Multiple entries surface billing confusion that occurs specifically at or near onboarding: the 20 RLUSD setup fee being mistaken for a separate charge, Expert mode being left on by default, the balance floor being mistaken for the agent going offline, and background process cost being unknown. KEY_INSIGHT:          Billing confusion is not random — it clusters at four predictable points: setup cost framing, mode selection, balance floor behavior, and background process cost. Addressing all four in a single \"how billing works\" explainer would eliminate the majority of billing-related friction. CATEGORY:             onboarding TAGS:                 xrplclaw, billing, cost, onboarding, credits, rlusd, standard, expert, balance, background-process LINKED_ENTRY_IDS:     RECON-P-002, RECON-P-003, R...\n\nKey Insight: Billing confusion is not random — it clusters at four predictable points: setup cost framing, mode selection, balance floor behavior, and background process cost. Addressing all four in a single \"how billing works\" explainer would eliminate the majority of billing-related friction.","pattern_type":"friction","occurrence_count":1,"status":"active","first_seen":"2026-04-25T20:46:52.098331+00:00","last_seen":"2026-04-25T20:46:52.098331+00:00","tags":null},{"id":"1c2cbc9f-4ba5-4274-867f-d8c475efbd43","title":"Silent exception swallowing in financial automation critical path","description":"``` PATTERN_ID:           P-FAIL-003 PATTERN_TYPE:         repeated_failure TITLE:                Silent exception swallowing in financial automation critical path SUMMARY:              Financial automation bots that catch exceptions without logging them create invisible failure modes — the system appears to be running while silently dropping data, missing trades, or corrupting state. Found in Predator's build_data() function. The fix is logging with full traceback before any other error handling. KEY_INSIGHT:          In any financial automation, a silent failure is worse than a loud crash. A crash stops the system and triggers investigation. A silent failure lets the system keep running while bleeding value with no observable signal. Every exception in the critical path must log with full traceback — non-negotiable. CATEGORY:            failures TAGS:                trading-bot, exception-handling, silent-failure, logging, audit, critical-path LINKED_ENTRY_IDS:    RECON-A-003, REC...\n\nKey Insight: In any financial automation, a silent failure is worse than a loud crash. A crash stops the system and triggers investigation. A silent failure lets the system keep running while bleeding value with no observable signal. Every exception in the critical path must log with full traceback — non-negotiable.","pattern_type":"failure","occurrence_count":1,"status":"active","first_seen":"2026-04-22T01:30:04.393838+00:00","last_seen":"2026-04-22T01:30:04.393838+00:00","tags":null},{"id":"cd4e215c-c1a2-44b4-8d15-f34549a9404c","title":"Recon — Active Pattern Records","description":"> File: patterns/active_patterns.md | Schema: v1 | Date: 2026-04-09 > Last updated: 2026-04-09 (added P-FAIL-001, P-SAFE-001 from new collection expansion)\n\nKey Insight: In any financial automation, a silent failure is worse than a loud crash. A crash stops the system and triggers investigation. A silent failure lets the system keep running while bleeding value with no observable signal. Every exception in the critical path must log with full traceback — non-negotiable.","pattern_type":"failure","occurrence_count":1,"status":"active","first_seen":"2026-04-22T01:30:03.145644+00:00","last_seen":"2026-04-22T01:30:03.145644+00:00","tags":null},{"id":"fc861f26-8f07-4b1d-9aff-35fbcb78b5cb","title":"XRPL reserve undercount — object count not tracked, transactions fail","description":"``` PATTERN_ID:           P-FAIL-001 PATTERN_TYPE:         repeated_failure TITLE:                XRPL reserve undercount — object count not tracked, transactions fail SUMMARY:              Builders consistently undercount the XRPL account reserve when building payment flows, trading bots, and NFT systems. Every new ledger object (trust line, offer, escrow, NFT page) increases the required reserve by 0.2 XRP (or 2 XRP for NFT pages). Bots that don't pre-check available spendable balance before transacting hit tecINSUFFICIENT_RESERVE errors and loop. This pattern appears across DEX bots, token issuers, and NFT platforms. KEY_INSIGHT:          Build a spendable_xrp() helper into every XRPL project: query account_info, compute balance minus (base_reserve + object_count × incremental_reserve), and gate every object-creating transaction on the result. Hard-code nothing — read reserve values from server_info because they change with amendments. CATEGORY:             failure TAGS:         ...\n\nKey Insight: Build a spendable_xrp() helper into every XRPL project: query account_info, compute balance minus (base_reserve + object_count × incremental_reserve), and gate every object-creating transaction on the result. Hard-code nothing — read reserve values from server_info because they change with amendments.","pattern_type":"failure","occurrence_count":1,"status":"active","first_seen":"2026-04-22T01:30:03.446803+00:00","last_seen":"2026-04-22T01:30:03.446803+00:00","tags":null},{"id":"e4a8e7c7-c895-4ccc-a9d6-00946f5062b9","title":"EVM contracts without receive() causing permanent fund loss","description":"``` PATTERN_ID:           P-FAIL-002 PATTERN_TYPE:         repeated_failure TITLE:                EVM contracts without receive() causing permanent fund loss SUMMARY:              EVM contracts participating in financial pipelines that lack receive() or fallback() functions permanently lock any ETH/XRP sent directly to them. Confirmed in Predator's legacy executor. A silent, unrecoverable failure with no on-chain error — funds simply vanish from the sender's perspective. KEY_INSIGHT:          receive() payable is mandatory for any EVM contract that handles fund flows. Its absence is not a warning — it is a permanent loss event. Every contract audit must verify this before deployment. CATEGORY:            failures TAGS:                evm, solidity, receive-function, fallback, stuck-funds, executor, contract-audit LINKED_ENTRY_IDS:    RECON-A-004, RECON-F-006 FREQUENCY:           2 FIRST_SEEN:          2026-04-09 LAST_SEEN:           2026-04-09 AVERAGE_USEFULNESS:  9.5 MAX_USEFULNESS...\n\nKey Insight: receive() payable is mandatory for any EVM contract that handles fund flows. Its absence is not a warning — it is a permanent loss event. Every contract audit must verify this before deployment.","pattern_type":"failure","occurrence_count":1,"status":"active","first_seen":"2026-04-22T01:30:03.910861+00:00","last_seen":"2026-04-22T01:30:03.910861+00:00","tags":null},{"id":"b697375e-feac-4b26-8ad6-72e1cab07318","title":"Users underestimate XRPLClaw agent capabilities at onboarding","description":"``` PATTERN_ID:           P-FRIC-001 PATTERN_TYPE:         repeated_friction TITLE:                Users underestimate XRPLClaw agent capabilities at onboarding SUMMARY:              Multiple entries show that new users approach XRPLClaw expecting a chatbot or Q&A interface, not a full persistent development environment. This creates a gap between what they attempt and what the platform can actually do — reducing activation and engagement. KEY_INSIGHT:          The framing problem is upstream of feature adoption. Until users understand the agent is a persistent dev environment — not a fancy chatbot — they will underuse it. Leading onboarding with concrete use cases resolves this faster than feature explanations. CATEGORY:             onboarding TAGS:                 xrplclaw, onboarding, capability, discovery, activation, chatbot-misconception LINKED_ENTRY_IDS:     RECON-P-001, RECON-P-005, RECON-P-008, RECON-X-005 FREQUENCY:            4 FIRST_SEEN:           2026-04-09 LAST_SEEN: ...\n\nKey Insight: The framing problem is upstream of feature adoption. Until users understand the agent is a persistent dev environment — not a fancy chatbot — they will underuse it. Leading onboarding with concrete use cases resolves this faster than feature explanations.","pattern_type":"friction","occurrence_count":1,"status":"active","first_seen":"2026-04-22T01:30:04.615659+00:00","last_seen":"2026-04-22T01:30:04.615659+00:00","tags":null},{"id":"88a69624-69ff-4c2c-8723-ab5a8e25578e","title":"Cost and billing misconceptions cluster at the start of the user journey","description":"``` PATTERN_ID:           P-FRIC-002 PATTERN_TYPE:         repeated_friction TITLE:                Cost and billing misconceptions cluster at the start of the user journey SUMMARY:              Multiple entries surface billing confusion that occurs specifically at or near onboarding: the 20 RLUSD setup fee being mistaken for a separate charge, Expert mode being left on by default, the balance floor being mistaken for the agent going offline, and background process cost being unknown. KEY_INSIGHT:          Billing confusion is not random — it clusters at four predictable points: setup cost framing, mode selection, balance floor behavior, and background process cost. Addressing all four in a single \"how billing works\" explainer would eliminate the majority of billing-related friction. CATEGORY:             onboarding TAGS:                 xrplclaw, billing, cost, onboarding, credits, rlusd, standard, expert, balance, background-process LINKED_ENTRY_IDS:     RECON-P-002, RECON-P-003, R...\n\nKey Insight: Billing confusion is not random — it clusters at four predictable points: setup cost framing, mode selection, balance floor behavior, and background process cost. Addressing all four in a single \"how billing works\" explainer would eliminate the majority of billing-related friction.","pattern_type":"friction","occurrence_count":1,"status":"active","first_seen":"2026-04-22T01:30:04.90527+00:00","last_seen":"2026-04-22T01:30:04.90527+00:00","tags":null},{"id":"f970839e-aa2a-4c42-bf18-e0f1f982fd11","title":"XRPL key and seed exposure via unsafe storage or sharing","description":"``` PATTERN_ID:           P-SAFE-001 PATTERN_TYPE:         repeated_safety_issue TITLE:                XRPL key and seed exposure via unsafe storage or sharing SUMMARY:              Across the new safety collection, a consistent pattern emerges: builders and users expose XRPL seeds and private keys through unsafe practices — pasting into chat, storing in plain text, hardcoding in scripts, logging in output. The failure modes are: (1) single-key accounts used for trading bots (compromise = total loss); (2) master keys kept online instead of cold; (3) seeds shared with support or AI tools. All three result in permanent, irrecoverable loss. KEY_INSIGHT:          The root of XRPL key safety failures is that the consequences of exposure are permanent and on-chain — no chargebacks, no recovery. Every system that signs XRPL transactions needs a documented key lifecycle: how it was generated, where it lives, who can access it, and what happens if it's compromised. Build the answer before bu...\n\nKey Insight: The root of XRPL key safety failures is that the consequences of exposure are permanent and on-chain — no chargebacks, no recovery. Every system that signs XRPL transactions needs a documented key lifecycle: how it was generated, where it lives, who can access it, and what happens if it's compromised. Build the answer before building the bot.","pattern_type":"safety","occurrence_count":1,"status":"active","first_seen":"2026-04-22T01:30:05.670548+00:00","last_seen":"2026-04-22T01:30:05.670548+00:00","tags":null},{"id":"f9a19288-0d3b-4371-9c7f-afa189074a34","title":"Recon — Active Pattern Records","description":"> File: patterns/active_patterns.md | Schema: v1 | Date: 2026-04-09 > Last updated: 2026-04-09 (added P-FAIL-001, P-SAFE-001 from new collection expansion)\n\nKey Insight: In any financial automation, a silent failure is worse than a loud crash. A crash stops the system and triggers investigation. A silent failure lets the system keep running while bleeding value with no observable signal. Every exception in the critical path must log with full traceback — non-negotiable.","pattern_type":"failure","occurrence_count":1,"status":"active","first_seen":"2026-04-25T20:46:50.193385+00:00","last_seen":"2026-04-25T20:46:50.193385+00:00","tags":null},{"id":"74e4b61c-6f7b-4c11-b059-7b5fdb36beda","title":"EVM contracts without receive() causing permanent fund loss","description":"``` PATTERN_ID:           P-FAIL-002 PATTERN_TYPE:         repeated_failure TITLE:                EVM contracts without receive() causing permanent fund loss SUMMARY:              EVM contracts participating in financial pipelines that lack receive() or fallback() functions permanently lock any ETH/XRP sent directly to them. Confirmed in Predator's legacy executor. A silent, unrecoverable failure with no on-chain error — funds simply vanish from the sender's perspective. KEY_INSIGHT:          receive() payable is mandatory for any EVM contract that handles fund flows. Its absence is not a warning — it is a permanent loss event. Every contract audit must verify this before deployment. CATEGORY:            failures TAGS:                evm, solidity, receive-function, fallback, stuck-funds, executor, contract-audit LINKED_ENTRY_IDS:    RECON-A-004, RECON-F-006 FREQUENCY:           2 FIRST_SEEN:          2026-04-09 LAST_SEEN:           2026-04-09 AVERAGE_USEFULNESS:  9.5 MAX_USEFULNESS...\n\nKey Insight: receive() payable is mandatory for any EVM contract that handles fund flows. Its absence is not a warning — it is a permanent loss event. Every contract audit must verify this before deployment.","pattern_type":"failure","occurrence_count":1,"status":"active","first_seen":"2026-04-25T20:46:51.109327+00:00","last_seen":"2026-04-25T20:46:51.109327+00:00","tags":null},{"id":"d2e71fd7-0bd2-44ec-9d22-e304a1ec7a44","title":"Silent exception swallowing in financial automation critical path","description":"``` PATTERN_ID:           P-FAIL-003 PATTERN_TYPE:         repeated_failure TITLE:                Silent exception swallowing in financial automation critical path SUMMARY:              Financial automation bots that catch exceptions without logging them create invisible failure modes — the system appears to be running while silently dropping data, missing trades, or corrupting state. Found in Predator's build_data() function. The fix is logging with full traceback before any other error handling. KEY_INSIGHT:          In any financial automation, a silent failure is worse than a loud crash. A crash stops the system and triggers investigation. A silent failure lets the system keep running while bleeding value with no observable signal. Every exception in the critical path must log with full traceback — non-negotiable. CATEGORY:            failures TAGS:                trading-bot, exception-handling, silent-failure, logging, audit, critical-path LINKED_ENTRY_IDS:    RECON-A-003, REC...\n\nKey Insight: In any financial automation, a silent failure is worse than a loud crash. A crash stops the system and triggers investigation. A silent failure lets the system keep running while bleeding value with no observable signal. Every exception in the critical path must log with full traceback — non-negotiable.","pattern_type":"failure","occurrence_count":1,"status":"active","first_seen":"2026-04-25T20:46:51.434862+00:00","last_seen":"2026-04-25T20:46:51.434862+00:00","tags":null},{"id":"a6976627-afca-4a6b-a82a-39e3ed167293","title":"Users underestimate XRPLClaw agent capabilities at onboarding","description":"``` PATTERN_ID:           P-FRIC-001 PATTERN_TYPE:         repeated_friction TITLE:                Users underestimate XRPLClaw agent capabilities at onboarding SUMMARY:              Multiple entries show that new users approach XRPLClaw expecting a chatbot or Q&A interface, not a full persistent development environment. This creates a gap between what they attempt and what the platform can actually do — reducing activation and engagement. KEY_INSIGHT:          The framing problem is upstream of feature adoption. Until users understand the agent is a persistent dev environment — not a fancy chatbot — they will underuse it. Leading onboarding with concrete use cases resolves this faster than feature explanations. CATEGORY:             onboarding TAGS:                 xrplclaw, onboarding, capability, discovery, activation, chatbot-misconception LINKED_ENTRY_IDS:     RECON-P-001, RECON-P-005, RECON-P-008, RECON-X-005 FREQUENCY:            4 FIRST_SEEN:           2026-04-09 LAST_SEEN: ...\n\nKey Insight: The framing problem is upstream of feature adoption. Until users understand the agent is a persistent dev environment — not a fancy chatbot — they will underuse it. Leading onboarding with concrete use cases resolves this faster than feature explanations.","pattern_type":"friction","occurrence_count":1,"status":"active","first_seen":"2026-04-25T20:46:51.782269+00:00","last_seen":"2026-04-25T20:46:51.782269+00:00","tags":null},{"id":"d7caec41-00b2-499b-8a54-b03bc9067ded","title":"Users conflate agent persistence with process persistence","description":"``` PATTERN_ID:           P-FRIC-003 PATTERN_TYPE:         repeated_friction TITLE:                Users conflate agent persistence with process persistence SUMMARY:              Users expect that if the agent persists across restarts, everything the agent started also persists. In reality, the agent restores from Tessera state but OS-level background processes do not auto-resume. This leads to \"my bot stopped\" confusion after container restarts. KEY_INSIGHT:          Agent persistence and process persistence are architecturally separate systems. The agent is a cognitive state restored from Tessera. Processes are OS-level and do not survive container restarts. This distinction needs to be explicit in onboarding — not buried in troubleshooting docs. CATEGORY:             friction TAGS:                 xrplclaw, background-process, persistence, restart, container, bot, tessera LINKED_ENTRY_IDS:     RECON-P-004, RECON-X-003 FREQUENCY:            2 FIRST_SEEN:           2026-04-09 LAST_...\n\nKey Insight: Agent persistence and process persistence are architecturally separate systems. The agent is a cognitive state restored from Tessera. Processes are OS-level and do not survive container restarts. This distinction needs to be explicit in onboarding — not buried in troubleshooting docs.","pattern_type":"friction","occurrence_count":1,"status":"active","first_seen":"2026-04-25T20:46:52.660258+00:00","last_seen":"2026-04-25T20:46:52.660258+00:00","tags":null}],"count":30}