MoonPay has launched the Open Wallet Standard (OWS), an open source framework designed to give AI agents a consistent way to hold funds and sign blockchain transactions across multiple chains, usually involving stablecoin payments. The project involves securing the wallet signing process and launches with support from a broad coalition including PayPal, Circle, the Ethereum Foundation, Solana Foundation, Base and around a dozen other organizations.
The standard addresses a real and growing problem. As AI agents proliferate, each framework has been rolling its own approach to key management. Private keys used to enable transaction signing end up hardcoded in environment variables, written into config files, or passed as arguments that can surface in logs or the LLM’s own context window. An AI model that can see a private key can, in principle, expose it or misuse it. The fragmentation also means a wallet created for one agent may not be usable by another.
OWS solves this by giving agents a signing API rather than direct key access. The agent calls a sign function. The library handles decryption internally, produces a signature, wipes the key from memory, and returns only the result. The private key never appears as a variable in agent facing code, never passes through the LLM context, and is not logged. That is a genuine improvement over current practice. However, solving the logging and LLM exposure problem is not the same as making the wallet fully secure against all threats, and the OWS specification is candid about this.
The current implementation is software only. Key decryption and signing happen inside the same operating system process as the agent code itself. The protections are real: the key material is locked in RAM to prevent it being written to a swap file, it is wiped from memory immediately after signing, and controls are in place to prevent crash dumps from capturing it. But a sufficiently privileged attacker who can inspect the process memory during the brief signing window can still reach the key material. The spec’s own threat table acknowledges this directly, noting that compromised process memory is “not fully mitigated in the current in-process model.”
Article continues …
Want the full story? Pro subscribers get complete articles, exclusive industry analysis, and early access to legislative updates that keep you ahead of the competition. Join the professionals who are choosing deeper insights over surface level news.
Image Copyright: Ledger Insights
