SEC User Interface Statement: 12 Conditions for Wallets

Video transcript

SEC staff will not object to wallets and front ends operating without broker registration, if they meet twelve conditions. Most describe how the software behaves.

It covers trades in crypto asset securities, signed in the user's self-custodial wallet. The provider can have no access to the key, encrypted or decrypted.

It is a staff view with no legal force, considered withdrawn after five years absent Commission action.

All twelve must hold. Users can change any default, routing stays neutral and affiliated venues get no special terms. Fees are fixed, parameters verifiable, disclosure prominent.

Users must be able to change slippage and gas defaults. Loose slippage invites front running, while a tight limit makes a sandwich attack revert.

Routes can be sorted by name, price or speed, but never called the best price. Routing software must run on pre-disclosed, verifiable parameters.

Pay is a fixed user charge, with no payment for order flow. Audit venue rebates, integrator fees and retained positive slippage.

If an attacker alters the served bundle, users sign what the attacker prepared. Alert on bundle changes and lock the registrar.

Guardian tests the build these conditions rest on, with web application and browser extension pentests, router contract audits, and Risk Monitoring of DNS and registrar changes.

Read the full article for all twelve conditions, or book a system review with a Guardian engineer at guardian.security.

On April 13, 2026, staff of the SEC's Division of Trading and Markets set out when they will not object to a wallet or front end operating without broker-dealer registration.

The statement covers interfaces that help users prepare their own trades in crypto asset securities, which include tokenized equity and debt.

Most of its 12 conditions describe how the software behaves, which makes them build and test requirements as much as legal ones.

This article explains the technical and security side of the SEC staff statement on broker-dealer registration of certain user interfaces. It is not legal advice; confirm how it applies to you with counsel.

What the Statement Covers

A Covered User Interface is an interface in a website, browser extension or app, standalone or in a wallet, for user-initiated crypto asset securities trades through the user's self-custodial wallet.

It converts the user's parameters (buy or sell, volume, asset, price or range) into "blockchain-legible commands" for the wallet to sign. It may also show routes, prices and estimated gas.

A wallet is self-custodial if neither its provider nor its interface has "custody of, or access to, the user's encrypted or decrypted private key."

The word "encrypted" matters for the build. Cloud key backups, recovery services and provider-held key shares need a close look with counsel.

Status

• Staff view: not a rule, guidance or Commission statement, with no legal force or effect.
• Scope: broker-dealer registration under Exchange Act Section 15(a), crypto asset securities only.
• Duration: considered withdrawn five years from April 13, 2026, absent Commission action.

The 12 Conditions at a Glance

The staff's position holds only where every condition is met.

Default Parameters and MEV

Footnote 10 gives examples of parameters: price slippage, transaction costs such as maximum gas, priority fees and tips, and transaction time.

Users must be able to change every default, with educational material to help them. Defaults must be set and periodically reassessed on objective factors, and disclosed with their risks and conflicts.

Disclosure also covers any controls protecting user trading information from fraud or manipulation, such as MEV strategies. Footnote 13 names front running.

A loose slippage default is an MEV exposure. As our sandwich attack guide explains, a tight slippage limit makes the attack revert.

• Keep defaults in versioned configuration, with the reason for each value.
• Let users edit slippage, maximum gas, priority fee and deadline on every trade.
• Check that the signed calldata carries the minimum output and deadline shown on screen.
• Remove hard-coded slippage in contracts and SDKs.
• Decide whether transactions go to the public mempool or a private route, and disclose it.

Routing and Fee Code

Sorting without commentary

Users must be able to see other routes, if any, and sort them on objective factors, such as name, price or speed.

The interface may not comment on any route, such as calling it the "best price" or "most reliable". Review badges, tooltips and translated copy too.

Verifiable parameters

Quote and route software must run on "pre-disclosed and objective parameters that are independently verifiable." The interface may exercise no other control or discretion.

• Publish the quote and routing parameters, with a version number.
• Make quotes reproducible: the same public inputs give the same routes.
• Put remote config, feature flags and server-side ranking under change control.
• Log each quote and route shown; the staff says books and records may help.

Affiliated venues

An affiliated venue must be clearly disclosed, and the interface must connect to it on the same terms as any unaffiliated interface.

Test it: the same API, fees, rate limits and data your venue gives any other front end.

Fixed fees, no order flow payments

Pay is limited to a fixed charge to the user, flat or a percentage per trade, applied consistently and agnostic to product, route, venue and counterparty.

Footnote 12 rules out pay from anyone but the user tied to a transaction's size, value or occurrence, including payment for order flow.

So audit every revenue path in the code: venue rebates, integrator fees paid by venues, and positive slippage the router keeps.

Venue Controls and Frontend Integrity

Venue reviews include security

Providers need controls to evaluate, onboard and audit venues on objective factors. The staff's examples are liquidity, latency, transparency, verifiability, neutrality, auditability and security.

For an AMM pool or aggregator, a security review can check:

• Verified source, audits and open findings.
• Upgrade, pause and fee powers, and who holds them.
• Oracle and bridge dependencies.
• Incident history, with a re-review after each upgrade.

Disclosures must name the venues and these controls, plus the interface's cybersecurity policies and controls, "if any".

When the interface is hijacked

The conditions assume users run the code you described. An attacker who changes the served bundle changes the defaults, routes, fees and transaction at once.

The disclosures no longer describe what users run, and they sign whatever the attacker prepared.

The controls: alerts on any change to the live bundle, Subresource Integrity, a strict Content Security Policy, signed build provenance and registrar locks.

Our signing interface guide covers the build and bundle controls. In the wallet, decode the real transaction before signing; see what a wallet pentest checks.

What Falls Outside

The statement does not extend to a provider that engages in, or holds itself out as providing, any of these services.

• Negotiating transaction terms
• Soliciting specific transactions
• Investment recommendations or advice
• Arranging financing
• Processing trade documentation
• Independent asset valuations
• Holding, accessing or managing user funds, securities or stablecoins
• Executing or settling transactions
• Taking or routing orders

Features that may touch that list, to check with counsel:

• Provider-held session keys: possible access to user funds.
• Backend order submission or matching: possibly taking or routing orders.
• Trade prompts and curated lists: possible solicitation or recommendations.

How Guardian Tests the Build

Guardian's pentests and monitoring cover the parts of the build these conditions rest on.

• Web application pentest: value-moving flows, the client-side surface and supply-chain exposure in the bundle.
• Browser extension pentest: key storage, signing flows and who can publish an update.
• Smart contract audit: router and settlement contracts, their integrations and privileged flows.
• Risk Monitoring: registrar locks, DNS records and the delivery path to users, watched for change.

To start, a system review call is an hour with a Guardian engineer on what you run.

Frequently Asked Questions

Does the SEC user interface statement cover custodial wallets?

No. Footnote 9 says it does not address custodial wallets. The wallet provider and its interface must have no custody of, or access to, the user's encrypted or decrypted private key.

Can a covered user interface accept payment for order flow?

No. Pay is limited to a fixed charge to the user, agnostic to product, route, venue and counterparty. Footnote 12 says this precludes payment for order flow.

Is the statement binding, and when does it end?

No. It is a staff view with no legal force or effect, not a Commission rule. Absent Commission action, it is considered withdrawn five years from April 13, 2026. Comments go to File Number 4-894.

How does the CFTC's Phantom letter compare?

CFTC Letter 26-09 (March 17, 2026) is a staff no-action position on introducing broker registration for Phantom's derivatives interface. Unlike the SEC conditions, it lets partner exchanges and brokers share revenue with Phantom.

Sources

• SEC Division of Trading and Markets: Staff Statement Regarding Broker-Dealer Registration of Certain User Interfaces Utilized to Prepare Transactions in Crypto Asset Securities (April 13, 2026)
• CFTC Market Participants Division: CFTC Letter No. 26-09, No-Action Position regarding Introducing Broker Registration, Phantom Technologies (March 17, 2026)
• Guardian: Sandwich Attacks in Crypto and Slippage Protection
• Guardian: Wallet Frontend Security: Signing Interfaces After Bybit
• Guardian: Web Application Penetration Testing
• Guardian: Browser Extension and Wallet Extension Pentest
• Guardian: Risk Monitoring and Rating