The architecture question. The CFTC's existing rules for designated contract markets (DCM) were built for centralized exchanges with clearinghouses, central counterparties, and margin systems. Blockchain prediction markets work differently. In AMM-based systems, there's no discrete counterparty, your trade is against a liquidity pool governed by code. Contracts are fully collateralized at entry, so there's no margin call and no possibility of losing more than you put in, which eliminates the credit risk that margin requirements exist to address. And position limits designed around deliverable supply don't translate to binary event contracts where new contracts can be minted by anyone depositing collateral. We asked the CFTC to develop tailored guidance that recognizes these structural differences rather than forcing onchain markets into a framework that doesn't describe how they work.
The oracle question. A fundamentally important technical problem in blockchain prediction markets is how real-world outcomes get reported to the settlement contract. Data oracles are the mechanism, and they are the primary manipulation surface. A traditional exchange controls its own price determination. An onchain market pays out whatever the oracle says, accurate or not. We proposed a tiered oracle standard requiring multiple independent data sources, economic stake-at-risk for reporters, auditable aggregation logic, and dispute windows before settlement finalizes.
We also flagged a harder problem: contracts where the outcome is controlled by the action of a single identifiable person. No oracle design may adequately protect against manipulation when the pool of potential manipulators includes the person who determines the result. We asked the Commission to seek public comment on whether those contracts need special controls or an outright prohibition.
The wallet question. The CFTC recently granted Phantom Technologies individual no-action relief confirming that a non-custodial wallet isn't an introducing broker when it doesn't hold assets, doesn't exercise execution discretion, and doesn't generate buy or sell signals. That's the right analysis, and it maps directly onto how MetaMask works. The problem is it only applies to Phantom. Every other wallet provider has to seek its own letter.
We asked the Commission to convert this into a general rule, so the entire category of non-custodial interfaces can build with confidence, and to clarify that features like curated market feeds, trade confirmation screens, and transaction-based fees don't cross the line into broker activity. We also raised an unresolved structural question: whether the safe harbor applies the same way when a wallet connects to an offchain custodial DCM, where the user deposits funds into a platform-controlled account, versus an onchain non-custodial DCM where collateral stays in a smart contract. MetaMask's role is functionally identical in both cases, but the current framework doesn't say so.
The data quality question. While building and maintaining MetaMask Prediction Markets, we've encountered DCM infrastructure failures that hurt users: event descriptions that didn't match the actual contract, settled markets that kept accepting bets, and breaking API changes deployed without warning that nearly took our integration offline entirely. No longer hypothetical risks, these types of consumer protection failures are traceable to the DCM and fixable by regulation. We asked the CFTC to establish explicit standards requiring accurate API data, timely market closure when settlement conditions are met, advance notice before breaking infrastructure changes, and formal deprecation processes for legacy API versions.
The KYC question. A user who wants to access multiple prediction market venues currently has to complete full identity verification at each one separately—same name, same documents, same process, repeated. That's duplicative, it's a privacy risk because it multiplies the number of places holding sensitive data, and it concentrates liquidity wherever the user happens to onboard first rather than where the best products are. The legal foundation for a better approach already exists. CFTC and FinCEN rules allow reliance on KYC performed by another regulated entity, and the CFTC itself has permitted this in carried-account arrangements.
We proposed extending that logic: a user verified by one CFTC-registered DCM gets a cryptographic attestation they can present to other venues through their wallet, without retransmitting personal data. The verified venue keeps the records and makes them available to regulators on request. This approach tracks where international standards are already headed—MiCA's passporting framework and the Financial Action Task Force (FATF) Recommendation 17 on third-party reliance both point the same direction.
The security question. Smart contracts that hold participant collateral are high-value targets, and a pre-deployment audit alone isn't sufficient. We recommended a comprehensive security framework covering formal verification of critical contract logic, public bug bounties scaled to value locked, timelocked upgrade mechanisms, oracle-layer defenses including dispute windows and multi-source aggregation, multi-signature key management, personnel and supply chain vetting, and a corporate cybersecurity baseline consistent with the NIST framework.
Prediction markets are a genuinely useful innovation: they aggregate information, provide price discovery on future events, and extend hedging tools to a broader public than traditional derivatives markets have served. We're not asking for weaker regulation. We're asking for smarter regulation, with rules that fit the technology as it actually works, protect users where the real risks are, and don't inadvertently shut out the infrastructure providers building compliant access to these markets. The framework being written now will determine whether that happens. We appreciate the Commission's engagement and look forward to working with staff as this rulemaking develops.