OWS Hackathon: Policy-Gated Agents for Prediction Markets

OWS: Policy-Gated Agents for Prediction Markets

The Wallet Problem

The agent infrastructure stack now has payment rails (x402, MPP), connectivity standards (MCP), CLI interfaces for a growing number of protocols, and a growing registry of agent skills. The wallet category has its own entrants: Coinbase AgentKit, MetaMask, Trust Wallet's TWAK. The piece that remains underdeveloped is what happens when an autonomous agent actually holds signing authority.

Right now, the standard approach is to hand the agent the same tools a human developer would use: a private key and full control over a wallet with no guardrails. The results are predictable. Agents overspend because nothing enforces a budget. They ignore rules-based execution constraints because they hallucinated the parameters. They can sign transactions on the wrong chain, grant unlimited spending permissions to unknown contracts, or drain an entire balance on a single miscalculated trade. Every failure mode that a human would catch through pattern recognition, intuition, and years of lived experience becomes a live vulnerability when the operator is an LLM with no concept of financial consequence.

Every wallet has a blast radius: the maximum damage that can occur if the entity controlling it makes the worst possible decision. For a human, the blast radius is bounded by reaction time, confirmation dialogs, and the fact that humans generally notice when something looks wrong. For an autonomous agent with a raw private key, the blast radius is the entire wallet balance, every token approval, every chain the key controls, all executed at machine speed with no confirmation step. Traditional EOA wallet infrastructure was built for humans who exercise judgment before clicking "confirm." When the entity holding the key can have a lapse of volatile judgment, the key itself becomes the attack surface.

What OWS Changes

The Open Wallet Standard (@OpenWallet), open-sourced by MoonPay on March 23, 2026 with contributions from PayPal, Circle, the Ethereum Foundation, Solana Foundation, and 15+ other organizations, solves this by inserting a policy engine between the agent and the signing operation. The owner sets rules for the agent, the agent cannot change those rules, and the agent can only operate within those boundaries.

The architecture enforces a hard boundary between the agent and the key material. Agents (Tempo, Claude, OpenAI, Polymarket, or any MCP-compatible framework) interact with the OWS Interface layer via MCP, SDK, CLI, or REST. Below the interface, the Policy Engine evaluates every signing request against the owner's rules before any key material is touched. Only after the policy check passes does the Signer decrypt the key from the Wallet Vault, sign the transaction, immediately wipe the key from memory, and return the signed transaction to the caller. The signing flow works in four steps:

1. The agent submits a transaction request to OWS, specifying what it wants to do and on which chain
2. The policy engine checks the request against the owner's rules: is this within the spending limit, is the destination approved, is the chain allowed, does a simulation of the transaction look safe
3. If the policies pass, the key is briefly decrypted, the transaction is signed, and the key is immediately wiped from memory
4. The signed transaction is sent to the blockchain and the confirmation is returned to the agent

The policy engine receives full context for every signing request: what transaction is being attempted, which chain it targets, which wallet is involved, what a simulation of the transaction would produce, when the request was made, and which agent is making it. Each policy is a small program that the owner writes and stores on their machine. When a signing request comes in, the wallet runs the transaction details through every registered policy. If any policy says no, the transaction is blocked and the key is never decrypted. The owner defines the policies and assigns them to specific agents. Since different agents can have different policy sets, a single wallet can serve multiple agents with different permission levels: one agent might have a $50 daily spending cap on a specific prediction market contract, while another has broader access for portfolio rebalancing across multiple venues.

The effect is that the blast radius compresses to whatever the owner defines. The wallet becomes a constrained execution environment where the agent can operate safely, and the owner knows the worst-case loss is bounded by the policy configuration rather than the agent's judgment.

Why Not Just Program the Rules into the Agent?

The obvious question is why the policy engine needs to live in the wallet at all. You could program spending limits, contract allowlists, and chain restrictions directly into the agent's execution logic. Most teams do exactly this. The problem is that application-layer guardrails live in the same trust boundary as the thing they are supposed to constrain. If the agent's code has a bug, the rules break with it. If a prompt injection manipulates the agent's reasoning, the agent can be convinced to skip its own validation logic. If a compromised dependency executes in the agent's runtime, the attacker inherits whatever signing authority the agent had. The rules and the risk share the same process, the same memory, the same failure modes.

The architectural argument for wallet-layer enforcement is that it moves the constraint below the agent. The agent calls the wallet to sign. The wallet checks the policy before decrypting the key. The agent never touches the key and never touches the policy. Even a fully compromised agent cannot override the constraints because the constraints are evaluated in the wallet's signing path, not in the agent's code. Rules in the execution layer are suggestions that depend on the agent behaving correctly. Rules in the wallet layer are enforcement that holds regardless of whether the agent is compromised, hallucinating, or running malicious code.

The Build: Rail Money

As part of the OWS hackathon, I built Rail Money to put this thesis into practice. Rail Money is a market discovery system for prediction markets exposed through an MCP interface, designed to let an agent begin with a natural-language thesis, identify the most relevant markets, retrieve supporting context, and execute trades, all within policy-bounded constraints.

Rather than treating prediction markets as isolated contracts, the system represents them as part of a structured environment in which related markets, thematic clusters, and external signals can be traversed together. The architecture separates into four layers, and the separation between them is the central design decision.

Layer 1: Market Graph

The first layer ingests market metadata and constructs a structured representation of the market landscape. Individual contracts are linked to related contracts, grouped into higher-level clusters, and enriched with derived properties that make them easier for an agent to evaluate, such as proximity to resolution, liquidity characteristics, and cluster membership. This transforms the raw market universe into a graph that supports efficient retrieval and traversal, allowing an agent to move from a thesis such as "de-escalation in Iran" to a connected set of relevant markets rather than searching contract-by-contract.

Layer 2: Live Context

The second layer continuously ingests external information from real-time news sources and associates that information with the most relevant markets. Instead of forcing the agent to independently reconcile every incoming headline with the full market universe, the system narrows that task by attaching contextual signals directly to the graph. Each market becomes a context-bearing node that accumulates supporting evidence, related developments, and changing informational conditions over time.

Layer 3: Agent Interface via MCP

The third layer is the agent interface, implemented through MCP, and the interface is Claude. The user writes a thesis in natural language inside a Claude conversation. Claude uses the MCP tools to issue discovery queries against the market graph, retrieve related markets, inspect clusters, and gather the contextual information necessary to evaluate the thesis. Because the graph is already structured for traversal, Claude can move across markets, relationships, and supporting context without repeatedly reconstructing the search space from unstructured data.

Layer 4: Execution via OWS

The final layer is execution, mediated through the Open Wallet Standard. In Rail Money, the agent does not hold unrestricted wallet authority. It can propose an action, but that action passes through an OWS-backed execution boundary where policy manages what the agent is allowed to do. The graph and context layers determine what may be relevant. The agent determines what may be worth doing. The OWS policy layer determines what is permissible to execute.

This separation is the central architectural idea. The intelligence layer handles discovery and reasoning. The policy layer handles constraint and safety. Rail Money is a system in which market discovery, contextual reasoning, and policy-bounded action are deliberately separated into distinct components, and the wallet enforces those boundaries at the signing layer before any key is ever touched.

Where OWS Sits in the Competitive Landscape

The agent wallet space has several active approaches to the policy problem, each with different tradeoffs. Coinbase Agentic Wallets isolate keys inside Trusted Execution Environments and enforce session spending caps and per-transaction limits at the TEE layer, with gasless transactions on Base and a two-minute setup via CLI. Safe Smart Accounts use on-chain Transaction Guards and Zodiac modules to enforce programmable constraints at the smart contract level, with multi-agent signing thresholds and over $95 billion currently secured across 30 million accounts. Turnkey and Fireblocks provide MPC-based key management with configurable policy engines that evaluate spending limits and contract allowlists before assembling multi-party signatures, primarily serving enterprise deployments. The AgentWallet SDK takes an on-chain enforcement approach, deploying spending policies as smart contracts on Base that the agent cannot override even if compromised. Openfort combines offchain policy evaluation with onchain smart account permissions, offering a two-layer model where transactions are checked against configurable rules before signing and again by the smart contract before execution.

OWS takes a different approach. The policy engine is local-first: policies are executables on the operator's own machine, evaluated before any key material is decrypted, with no cloud dependency, no smart contract deployment, and no vendor lock-in. The operator can write any constraint logic they want as a standalone executable, register it against specific API keys, and the wallet enforces it at the signing layer across any supported chain. The entire standard is MIT-licensed with contributions from PayPal, OKX, Ripple, Circle, Tron, TON Foundation, Solana Foundation, Ethereum Foundation, Base, Polygon, Sui, Filecoin Foundation, LayerZero, Dflow, Uniblock, Virtuals, Arbitrum, Dynamic, Allium, and Simmer.Markets.

Well gang, I’m exhausted. For those who stuck around on the read, here is the hype video for the submission.

enjoy